Re: Zayo woes

[Randy Carpenter]

The problem we have run into is that there does not appear to be a "Zayo." 
There are dozens of acquisitions of regional providers with completely 
different infrastructure and teams and they have done a very poor job at gluing 
it all together. I have seen service orders that have gone *years* without 
being complete. There are also currently some 
breaking-the-entire-regional-network sorts of outages going on currently. I am 
guessing what clued employees they still have are quite tied up.


-Randy


- On Sep 18, 2023, at 7:06 PM, JASON BOTHE via NANOG nanog@nanog.org wrote:

> Does anyone know what’s happening at Zayo? Tickets are taking weeks and months
> to get resolved, much less get a tech assigned to them.
> 
> The folks answering the noc phone are mere order takers and are only reading
> from a script, manager on duty/escalation lines go to voicemail.
> 
> If anyone can help get to a human in the transport group, that would be great.
> I’ve given up all hope at this point.
> 
> Appreciated.
> 
> Jason

Re: Verizon Email to SMS gateway

[Randy Carpenter]

That is the understanding I got when discussing the situation with our 
engineering contact there.

thanks,
-Randy


- On Nov 17, 2022, at 12:12 PM, Eric Tykwinski eric-l...@truenet.com wrote:

> As a side note, will the email to text gateways be subject to the FCC's A2P
> 10DLC registration requirements?
> I'm wondering if that's part of the reason for not officially supporting email
> to text.
> 
> Sincerely,
> 
> Eric Tykwinski
> TrueNet, Inc.
> P: 610-429-8300
> 
>> -Original Message-
>> From: NANOG  On Behalf Of 
>> Randy
>> Carpenter
>> Sent: Thursday, November 17, 2022 12:09 PM
>> To: Justin H. 
>> Cc: NANOG 
>> Subject: Re: Verizon Email to SMS gateway
>>
>>
>> We did a few months back and were told that they are no longer officially
>> supporting it. It may have to do with the volume that is being sent, >
>> particularly from a single IP address.
>>
>> We moved to using Twilio's API and it has been much more solid.
>>
>>
>> thanks,
>> -Randy
>>
>>
>> - On Nov 17, 2022, at 11:56 AM, Justin H. justindh...@gmail.com wrote:
>>
>> > Anyone else seeing massive delays in Verizon's email to SMS gateway
>> > lately?  I'm seeing delays on emails to @vtext and @vzwpix addresses
>> > at anywhere form 45 minutes to 12 hours.
>> > 
> > > Justin H.

Re: Verizon Email to SMS gateway

[Randy Carpenter]

We did a few months back and were told that they are no longer officially 
supporting it. It may have to do with the volume that is being sent, 
particularly from a single IP address.

We moved to using Twilio's API and it has been much more solid.


thanks,
-Randy


- On Nov 17, 2022, at 11:56 AM, Justin H. justindh...@gmail.com wrote:

> Anyone else seeing massive delays in Verizon's email to SMS gateway
> lately?  I'm seeing delays on emails to @vtext and @vzwpix addresses at
> anywhere form 45 minutes to 12 hours.
> 
> Justin H.

Re: Juniper MX204 allow oversubscription?

[Randy Carpenter]

- On May 16, 2022, at 2:06 PM, Aled Morris aled.w.mor...@googlemail.com 
wrote:

> On Mon, 16 May 2022 at 18:52, Randy Carpenter < [ mailto:rcar...@network1.net 
> |
> rcar...@network1.net ] > wrote:

>> My hope for a successor (MX205 ?) would be more flexibility and 25G ports.
>> 4x100G+8x25G would be awesome.

> I was hoping the MX304 would be the upgrade, but it seems like overkill - 2U,
> modular with dual processors, up to 96 x 10/25 GbE, 48 x 40/50/100, 12 x 400
> GbE
> Probably a bit more expensive than MX204 too.

Yes... the MX304 is awesome, but the price is going to be crazy. Possibly ~10x 
MX204 if fully loaded.

> There's also ACX7100-48L: 48x 10GE/25GE/50GE (SFP56), 6x 400GE (QSFP56-DD)

What does the ACX7100 have in terms of FIB/RIB ? Juniper is making it very hard 
as of late to find that information. I'd be curious if the ACX could do brder 
router duties with multiple full BGP feeds (which the MX204 has no problem with 
at all)

-Randy

Re: Juniper MX204 allow oversubscription?

[Randy Carpenter]

If additional ports are more important than the full 100G throughput, you can 
configure it as 2x100+2x40+8x10.

We tend to break out 10G ports on switches, so we can more fully utilize the 
100G ports.

My hope for a successor (MX205 ?) would be more flexibility and 25G ports. 
4x100G+8x25G would be awesome.

thanks,
-Randy

--
Randy Carpenter
Vice President - IT Services
First Network Group, Inc.
(800)578-6381, Opt. 1
http://www.network1.net

- On May 16, 2022, at 1:10 PM, Kevin Shymkiw kshym...@gmail.com wrote:

> Adam,

> Simply put - No there isn't a way to oversubscribe the front panel.

> Juniper has a handy tool to check your port combinations though - [
> https://apps.juniper.net/home/port-checker/index.html |
> https://apps.juniper.net/home/port-checker/index.html ]

> The lack of being able to oversubscribe has to do with # of lanes to the EA
> ASIC, and how those can be broken down.

> Kevin

> On Mon, May 16, 2022 at 11:04 AM Adam Thompson < [ 
> mailto:athomp...@merlin.mb.ca
> | athomp...@merlin.mb.ca ] > wrote:

>> Hi all,

>> Hoping some Juniper-using folks know:

>> On the MX204, which comes with 4x100G + 8x10G ports, you can only use 3 of 
>> the 4
>> 100G ports if you want to use any of the 10G ports at all.

>> Supposedly this is to prevent oversubscription on what is a 400G-rated 
>> router.
>> However, I’m perfectly fine with oversubscription with a 400G aggregate
>> throughput cap.

>> Is there a way to stop the automatic “oh, I’ll disable these other ports for 
>> you
>> so you don’t oversubscribe the box” behaviour and let all the front-panel 
>> ports
>> be used at once?

>> -Adam

>> Adam Thompson

>> Consultant, Infrastructure Services

>> 100 - 135 Innovation Drive

>> Winnipeg, MB R3T 6A8

>> (204) 977-6824 or 1-800-430-6404 (MB only)

>> [ https://www.merlin.mb.ca/ | https://www.merlin.mb.ca ]

>> [ https://teams.microsoft.com/l/chat/0/0?users=athomp...@merlin.mb.ca | Chat
>>  with me on Teams ]

Re: V6 still not supported

[Randy Carpenter]

- On Mar 30, 2022, at 12:36 PM, Jared Brown nanog-...@mail.com wrote:

> Randy Carpenter wrote:
>> >> >> Owen DeLong via NANOG wrote:
>> >> >> When your ISP starts charging $X/Month for legacy protocol support
>> >> >
>> >> > Out of interest, how would this come about?
>> >>
>> >> ISPs are facing ever growing costs to continue providing IPv4 services.
>> >  Could you please be more specific about which costs you are referring to?
>> >
>> >  It's not like IP transit providers care if they deliver IPv4 or IPv6 bits 
>> > to
>> >  you.
>>
>> Have you priced blocks of IPv4 addresses lately?
>  IPv4 address blocks have a fixed one-time cost, not an ongoing $X/month cost.
> 
> - Jared

How, exactly, would you propose a company recoup the cost?

-Randy

Re: V6 still not supported

[Randy Carpenter]

- On Mar 30, 2022, at 11:09 AM, Jared Brown nanog-...@mail.com wrote:

> Owen DeLong via NANOG wrote:
>> >> When your ISP starts charging $X/Month for legacy protocol support
>> >
>> > Out of interest, how would this come about?
>>
>> ISPs are facing ever growing costs to continue providing IPv4 services.
>  Could you please be more specific about which costs you are referring to?
> 
>  It's not like IP transit providers care if they deliver IPv4 or IPv6 bits to
>  you.

Have you priced blocks of IPv4 addresses lately?

ISPs expand over time and need more IPs for more customers.

-Randy

Re: Let's Focus on Moving Forward Re: V6 still not supported Re: 202203261748.AYC

[Randy Carpenter]

- On Mar 26, 2022, at 6:16 PM, Abraham Y. Chen ayc...@avinta.com wrote:

> Hi, Tom & Paul:

> 1) " ... hand waved ... ": Through my line of work, I was trained to behave
> exactly the opposite. I am surprised at you jumping to the conclusion, even
> before challenging me about where did I get my viewpoint from. The fact is, it
> has been clearly documented in our IETF draft for the last couple years (since
> Rev-06 on 2019 Dec. 1)! For your convenience, please see below a copy of the
> potential target code fragment and critique. It appears to me that our 
> software
> member suggested to comment out only one line (1047).

Just because it is trivial to make the modification in a single, specific 
firmware for one particular device does not mean it is trivial to get it done 
on *billions* of devices. Even if each one was as trivial as your example, it 
would still be ludicrously difficult.

Beyond that, I am still not understanding what you are actually trying to 
propose here. Your refusal to follow simple mailing list etiquette even after 
numerous requests makes it very difficult to decipher what you are saying.

-Randy

Re: V6 still not supported

[Randy Carpenter]

- On Mar 19, 2022, at 6:44 PM, Matt Hoppes 
mattli...@rivervalleyinternet.net wrote:

> After a time of transition, all clients would be running 128 bit
> addresses (or whatever length was determined to be helpful).

What you describe is literally IPv6.

> Just like with IPv6, there would be a transition period, but during that
> time software updates would very easily bring equipment up to spec much
> faster and quicker.

If it is so easy, then why is some software not yet supporting IPv6? What makes 
you think that lazy software developers would suddenly become interested in 
this new IP when they don't seem interested in the current standard?

I don't get what you are trying to accomplish here that is not already covered 
by IPv6.

> 
> It would also be extremely easy to perform a translation operations on
> equipment that required it for some reason since we're still operating
> in the same basic IPv4 dotted notation system.

No, it wouldn't. You have a fundamental misunderstanding about how IP addresses 
work. Nothing stores IP addresses in the classic (and horrible) IPv4-style 
dotted notation. IPs are stored as binary numbers, be they 32-bit, or 128-bit. 
The way they are displayed are just a shorthand to make reading them easier 
(although, the variable character length of IPv4 is really annoying, but is 
fixed in IPv6)

 
> A computer running at 32.23.0.0.12.168.0.1 wants to access 192.168.0.1.
> It has no problem sending out the request, since 192.168.0.1 is a subset
> of the protocol 32.23.0.x has.  However, to get back 192.168.0.1 can
> proxy through an IPv4.1 to IPv4.2 concentration system.   This very
> quickly allows for rapid deployment and upgrading.
> 
> I suspect if such a system was implemented the uptake would be very very
> fast.

Again, you are basically talking about IPv6. I am still missing where you have 
some way to accomplish the same goal without having every system have to be 
re-written (again). Why would we want to start again at 0% when we are a 
significant portion of the way to full IPv6 deployment?

> IPv6 deployment is been so slow because it was not carefully thought
> through from an ISP deployment perspective.  (For example, how the
> DHCPv6 request doesn't send the device MAC address through, thus
> preventing the ISP from being able to authorize the device or hand out a
> specific IP range).

As others have said, this has been fixed. I do agree that leaving out DHCP was 
shortsighted. But it was relatively easily added (just like it was for IPv4). 
Just because the current implementation and best practice for a protocol 
doesn't meet a specific need of yours doesn't mean we should go back to the 
drawing board and re-implement the entire networking stack again.

> 
> Heck, even allowing hex in the dotted quad would resolve a lot of issue.
>  The issue with IPv6 is NOT the hex.  It's the way things were
> implemented within the protocol stack.

As above, I will point out that you seem to have a misunderstanding of what 
IPv6 is and is not. Hex vs. dotted quad is merely a display standard having 
nothing to do with anything that really matters (router code, etc). What you 
seem to be proposing is just a different way to represent 128-bit addresses, 
which would make them difficult to distinguish from 32-bit addresses. These 
issues have long been worked out by many very smart people.


-Randy

Re: V6 still not supported

[Randy Carpenter]

- On Mar 9, 2022, at 4:46 PM, Josh Luthman j...@imaginenetworksllc.com 
wrote:

> ISP here. Deploying gigabit FTTH. No IPv6.
> Customers have 0 complaints about IPv6. 0 Complaints since 2006.

Don't you think there is a responsibility on those who know the technical 
details to do things on behalf of those who do not know any better?

You don't seriously think that the only reason anything should ever be done is 
because a customer specifically asked for it, do you?

This attitude is why IPv6 is not universal yet.


For what it is worth, both of the providers available to me in our small town 
have been IPv6 for well over a decade. One is Spectrum (formerly Time Warner). 
Residential support lagged a bit from our DIA circuits, but has still been 
solid for a very long time.

In my specific use case, IPv6 connections from my home to my office are much 
faster than IPv4.

-Randy

Re: 25G SFP28 capable of rate-adaption down to 1G?

[Randy Carpenter]

That particular one seems to be saying it will work in a 1G, 10G, or 25G port, 
not necessarily that it will allow different speeds on either end 
simultaneously... although their doc is pretty sparse :-)

thanks,
-Randy


- On Jan 31, 2022, at 5:25 PM, Jared Brown nanog-...@mail.com wrote:

> Mikrotik claims a multirate 1G / 10G / 25G SFP28
> https://mikrotik.com/product/xs_31lc10d
> 
> 
> - Jared

Re: 25G SFP28 capable of rate-adaption down to 1G?

[Randy Carpenter]

Are you talking about an SFP28 module that can link at 25Gb, but also 1Gb?

We just put 1Gb SFPs in the SFP28 ports and they work fine. I have not seen a 
single module that does both, but admittedly, I have not looked too hard, as 
the 1Gb modules are so cheap.

Or, are you talking about a module that presents as 25Gb to the switch, but 1Gb 
to the client device?


thanks,
-Randy


- On Jan 31, 2022, at 1:05 PM, Bill Woodcock wo...@pch.net wrote:

> Hey, does anyone know of an SFP28 capable of rate-adapting down from 25G on 
> the
> cage side down to 1G on the line side?  Can be copper or fiber on the line
> side, I don’t care, my interest is in the chip inside.
> 
> Thanks,
> 
> -Bill

Re: 100GbE beyond 40km

[Randy Carpenter]

Looking at EDFA options... they are all ~1500nm as far as I can tell. Is there 
a specific model you are talking about? 

thanks, 
-Randy 

- On Sep 27, 2021, at 10:25 AM, Dan Murphy  wrote: 

>> Are you saying we could use normal QSFP28 LR4 or ER4 modules with an 
>> amplifier
> > in between?
> Yes, that is the idea from 30,000 ft. Fun fact, the ER4 optics you mention are
> amplified inside the pluggable in a very similar manner to how these EDFA
> systems work.

> Basically: QSFP28 100G ER <-> EDFA Amp <-> OSP/dark fiber <-> EDFA Amp <->
> QSFP28 100G ER
> Very simple, and from the Juniper gear's POV, there is no funny business. All
> the magic happens down at layer 0.

> The systems are commoditized and pretty easy to find. I saw a few people on 
> this
> thread mention Solid Optics, personally I have not heard of them, but I would
> trust LB's recommendation. I've used systems by other manufacturers in the 
> past
> and wasn't crazy about them. I don't want to flame that manufacturer since 
> they
> read this mailer, and who knows, the issues I saw might have been isolated to
> manufacturing issues, but I still wouldn't recommend them.

> The learning curve is pretty low, and the manufacturers of this gear are
> ~usually~ very eager to guide basic implementation. However, ping me off list,
> or on here, if you have any deeper questions about this.

> Have a good week everyone!

> On Sun, Sep 26, 2021 at 12:17 AM Lady Benjamin Cannon < [ 
> mailto:l...@6by7.net |
> l...@6by7.net ] > wrote:

>> My guess is that he was talking about the difference between a 100gbit/sec
>> stream of ethernet frames with no error correction, and a 112gbit/sec (or so,
>> depending on scheme) stream of transport with FEC (Forward Error Correction -
>> which is essentially just cramming extra bits in there incase they are 
>> needed.

>> Ethernet has to re-transmit instead, and that can cause performance 
>> degradation
>> and jitter, until it just quits working altogether. Systems implementing FEC
>> are much

>> (This is a guess, there’s a chance something else was meant by this)

>> -LB.

>>> On Sep 25, 2021, at 1:55 AM, Etienne-Victor Depasquale via NANOG < [
>>> mailto:nanog@nanog.org | nanog@nanog.org ] > wrote:

>>> Bear with my ignorance, I'm genuinely surprised at this:

>>>> Does this have to be Ethernet? You could look into line gear with coherent
>>>> optics.

>>> Specifically, do you mean something like: "does this have to be
>>> IEEE-standardized all the way down to L1 optics?" Because you can transmit
>>> Ethernet frames over line gear with coherent optics, right ?

>>> Please don't flame me, I'm just ignorant and willing to learn.

>>> Cheers,

>>> Etienne

>>> On Fri, Sep 24, 2021 at 11:25 PM Bill Blackford < [ 
>>> mailto:bblackf...@gmail.com
>>> | bblackf...@gmail.com ] > wrote:

>>>> Does this have to be Ethernet? You could look into line gear with coherent
>>>> optics. IIRC, they have built-in chromatic dispersion compensation, and
>>>> depending on the card, would include amplification.

>>>> On Fri, Sep 24, 2021 at 1:40 PM Randy Carpenter < [ 
>>>> mailto:rcar...@network1.net
>>>> | rcar...@network1.net ] > wrote:

>>>>> How is everyone accomplishing 100GbE at farther than 40km distances?

>>>>> Juniper is saying it can't be done with anything they offer, except for a 
>>>>> single
>>>>> CFP-based line card that is EOL.

>>>>> There are QSFP "ZR" modules from third parties, but I am hesitant to try 
>>>>> those
>>>>> without there being an equivalent official part.

>>>>> The application is an ISP upgrading from Nx10G, where one of their fiber 
>>>>> paths
>>>>> is ~35km and the other is ~60km.

>>>>> thanks,
>>>>> -Randy

>>>> --
>>>> Bill Blackford

>>>> Logged into reality and abusing my sudo privileges.

>>> --
>>> Ing. Etienne-Victor Depasquale
>>> Assistant Lecturer
>>> Department of Communications & Computer Engineering
>>> Faculty of Information & Communication Technology
>>> University of Malta
>>> Web. [ https://www.um.edu.mt/profile/etiennedepasquale |
>>> https://www.um.edu.mt/profile/etiennedepasquale ]

> --
> Daniel Murphy
> Senior Data Center Engineer
> (646) 698-8018

100GbE beyond 40km

[Randy Carpenter]

How is everyone accomplishing 100GbE at farther than 40km distances?

Juniper is saying it can't be done with anything they offer, except for a 
single CFP-based line card that is EOL.

There are QSFP "ZR" modules from third parties, but I am hesitant to try those 
without there being an equivalent official part.


The application is an ISP upgrading from Nx10G, where one of their fiber paths 
is ~35km and the other is ~60km.



thanks,
-Randy

Re: Rack rails on network equipment

[Randy Carpenter]

Considering that the typical $5 pieces of bent metal list for ~$500 from most 
vendors, can you imagine the price of fancy tool-less rack kits?

Brand new switch: $2,000
Rack kit: $2,000


-Randy

Re: Broken Mini-SAS cable removal?

[Randy Carpenter]

The DACs with the metal release are definitely considerably more robust. They 
are, however, sometimes more difficult to unlatch to remove, particularly in 
scenarios with tightly-spaced ports.

thanks,
-Randy


- On Apr 23, 2021, at 12:45 PM, George Metz george.m...@gmail.com wrote:

> One of the best DACs I've ever had - and I wish I could find them or
> the manufacturer again - was one with a relatively thick metal T push
> bar that you had to push in towards the switch to release the latch.
> Almost impossible to break, and nearly as impossible to accidentally
> get unplugged.
> 
> On Fri, Apr 23, 2021 at 12:20 PM Alain Hebert  wrote:
>>
>> Hi,
>>
>> That happened to me more often with the DAC cables I had the displeasure 
>> to deal
>> with.
>>
>> And yeah got old valve gap feeler gauge to the rescue =D
>>
>> -
>> Alain Hebertaheb...@pubnix.net
>> PubNIX Inc.
>> 50 boul. St-Charles
>> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
>> Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443
>>
>> On 4/23/21 11:51 AM, Ryland Kremeier wrote:
>>
>> Hit the wrong reply button before, but we were able to get it removed by
>> unscrewing the top latch and removing that first at an angle. Then the
>> connector was able to be pulled straight out. Plastic was very thin on the 
>> pull
>> tab and it snapped without much resistance.
>>
>>
>>
>> Thank you,
>>
>> -- Ryland
>>
>>
>>
>> From: Eric Litvin
>> Sent: Friday, April 23, 2021 10:49 AM
>> To: Joe Klein
>> Cc: nanog@nanog.org
>> Subject: Re: Broken Mini-SAS cable removal?
>>
>>
>>
>> Joe’s response is spot on. I would also suggest you look at the “latching
>> finger” mechanism on a spare,  then apply some of the techniques Joe 
>> suggests.
>>
>> Eric
>> Luma optics
>>
>>
>>
>>
>> Sent from my iPhone
>>
>> > On Apr 23, 2021, at 8:27 AM, Joe Klein  wrote:
>> >
>> > Try shim stock or a feeler gauge between the plug and socket to work the
>> > latching fingers. This isn't something that I've tried specifically in 
>> > this
>> > case.
>> >
>> > You might need to put a notch in the stock or feeler gauge so that you can 
>> > work
>> > the fingers from the backside. Kinda like that old trick of using a credit 
>> > card
>> > to prise a door latch, except this should work since there's no deadlatch. 
>> > :)
>> >
>> > You might also try gently twisting a small screwdriver or spudger stick 
>> > between
>> > the plug and socket too to increase the gap between the socket and plug.
>> >
>> > -joe
>> >
>> > From: NANOG  On Behalf Of
>> > Ryland Kremeier
>> > Sent: Friday, April 23, 2021 09:31
>> > To: nanog@nanog.org
>> > Subject: Broken Mini-SAS cable removal?
>> >
>> >
>> >  External Mail
>> >
>> > Anyone here have experience removing a mini-SAS cable when the plastic tab 
>> > has
>> > broken off? Tried checking online but couldn't find anything.
>> >
>> > Thank you,
>> > -- Ryland
>> >
>>
>>
>>

DNSSEC question

[Randy Carpenter]

Any DNSSEC experts that could help with a question about a specific domain?

Off-list please.

thanks,
-Randy

Tips on dealing with illicit BGP announcements

[Randy Carpenter]

I am working with a client that has recently purchased and transferred an IPv4 
block.

Sometime in between when the purchase and research was done and when the 
transfer was actually complete, an entity in Asia started illicitly announcing 
a larger block that includes the block in question. They even have gotten an 
RADB entry in place for it.

Does anyone have some tips on how to deal with this? I have a feeling that 
dealing directly with the offending entity will not be very fruitful.

thanks,
-Randy

Re: MX204 Rails

[Randy Carpenter]

>From the crude illustration in the manual, it looks like they are the same 
>rails as EX-4PST-RMK.

We don't have any MX204s, but the EX-4PST-RMK kit is what is used for SRX1500, 
for which there is no official part, along with most current EX models. It 
looks to be pretty universal. It also has a very stupid list price.

thanks,
-Randy


- On Jul 16, 2020, at 3:53 PM, Luke Guillory lguill...@reservetele.com 
wrote:

> Yup, the same terrible ones that came with the QFX's and ACX's.
> 
> 
> 
> 
> -Original Message-
> From: NANOG  On Behalf Of
> Simon Lockhart
> Sent: Thursday, July 16, 2020 2:38 PM
> To: Rafael Possamai 
> Cc: nanog@nanog.org
> Subject: Re: MX204 Rails
> 
> *External Email: Use Caution*
> 
> On Thu Jul 16, 2020 at 02:27:25PM -0500, Rafael Possamai wrote:
>> Doesn't the mx204 have rackmount brackets rather than rails?
> 
> It has ears at the front, and "rails" at the rear.
> 
> The MX204 would have come with the rear rails when bought new.
> 
> See
> https://link.edgepilot.com/s/4bf9c3e9/UBi8UroL2kyRsIcDupv78w?u=https://www.juniper.net/documentation/en_US/release-independent/junos/topics/topic-map/mx204-installing.html
> 
> Simon
> 
> 
> Links contained in this email have been replaced. If you click on a link in 
> the
> email above, the link will be analyzed for known threats. If a known threat is
> found, you will not be able to proceed to the destination. If suspicious
> content is detected, you will see a warning.

Re: Switch for SFP+

[Randy Carpenter]

I could never get LACP + tagged VLANs to work on SwOS. 

Then again, it doesn't work reliably on RouterOS either, so I gave up. Spending 
more on hardware that is well supported is worth it versus my time and sanity. 

I think Ubiquiti pretty much has the "cheap hardware that works well, but 
commercial support lacking" market cornered. 

thanks, 
-Randy 

- On May 18, 2020, at 5:43 PM, nanog  wrote: 

> Yep, run SwichOS, prevents you from running things in software. 

> Dennis Burgess, Mikrotik Certified Trainer
> MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE, MTCSE, HE IPv6 Sage, Cambium ePMP 
> Certified

> Author of "Learn RouterOS- Second Edition”

> Link Technologies, Inc -- Mikrotik & WISP Support Services

> Office : 314-735-0270 Website: [ http://www.linktechs.net/ |
> http://www.linktechs.net ]

> Create Wireless Coverage’s with [
> https://zimbra.network1.net/zimbra/www.towercoverage.com |
> www.towercoverage.com ]

> From: NANOG  On Behalf Of Mike Hammett
> Sent: Monday, May 18, 2020 4:37 PM
> To: Mauro Gasparini 
> Cc: nanog@nanog.org
> Subject: Re: Switch for SFP+

> That's a downfall of Mikrotik, they give you ultimate power. You can do some
> pretty atypical things on there.

> -
> Mike Hammett
> [
> https://imsva91-ctp.trendmicro.com/wis/clicktime/v1/query?url=http%3a%2f%2fwww.ics%2dil.com=B47E9451-A5F3-0D05-8BDE-9FDBD4B4C161=079c058f437b7c6303d36c6513e5e8848d0c5ac4-285b59a47041a35803b05fa3a991e89443b374c5
> | Intelligent Computing Solutions ]
> [ https://www.facebook.com/ICSIL ] [
> https://plus.google.com/+IntelligentComputingSolutionsDeKalb ] [
> https://www.linkedin.com/company/intelligent-computing-solutions ] [
> https://twitter.com/ICSIL ]
> [ http://www.midwest-ix.com/ | Midwest Internet Exchange ]
> [ https://www.facebook.com/mdwestix ] [
> https://www.linkedin.com/company/midwest-internet-exchange ] [
> https://twitter.com/mdwestix ]
> [ http://www.thebrotherswisp.com/ | The Brothers WISP ]
> [ https://www.facebook.com/thebrotherswisp ] [
> https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg ]

> From: "Mauro Gasparini" < [ mailto:mjgaspar...@gmail.com | 
> mjgaspar...@gmail.com
> ] >
> To: [ mailto:nanog@nanog.org | nanog@nanog.org ]
> Sent: Monday, May 18, 2020 1:45:59 PM
> Subject: Re: Switch for SFP+

> It's clear then that I must use "bridge vlan" to achieve the goal I am looking
> for.
> Now it's time for me to study, research and test on my side.
> If I have any specific questions, I will draw on your experience.
> Thanks a lot.

> El 15/5/20 a las 22:11, Travis Garrison escribió:

>> On the CRS 3xx line, use vlan filtering instead. This guarantees hardware
>> offloading.

>> PS. Do not use this method on the 1xx or 2xx lines.

>> /interface bonding
>> add mode=802.3ad name=bond-inet slaves=ether9,ether10,ether8
>> transmit-hash-policy=layer-2-and-3

>> /interface bridge

>> add name=bridge vlan-filtering=yes

>> /interface bridge port

>> add bridge=bridge interface=bond-inet

>> add bridge=bridge interface=sfp1

>> /interface bridge vlan

>> add bridge=bridge tagged=bond-inet,sfp1 vlan-ids=201

>> Thanks

>> Travis

>> From: NANOG [ mailto:nanog-boun...@nanog.org |  ] On
>> Behalf Of Mauro Gasparini
>> Sent: Friday, May 15, 2020 10:55 AM
>> To: [ mailto:nanog@nanog.org | nanog@nanog.org ]
>> Subject: Re: Switch for SFP+

>> This works well on my CRSs:

>> /interface bonding
>> add mode=802.3ad name=bond-inet slaves=ether9,ether10,ether8
>> transmit-hash-policy=layer-2-and-3

>> /interface bridge port
>> add bridge=br-cabase interface=bond-inet
>> add bridge=br-cabase interface=sfp1

>> But if I want to bridge vlans behind some bonding Instead of bridging phy
>> interfaces, cpu explodes:

>> /interface vlan
>> add name=vl201-mmen vlan-id=201 interface=sfp1
>> add name=vl201-mment vlan-id=201 interface=bond-inet

>> /interface bridge port
>> add bridge=br-mment interface=vl201-mmen
>> add bridge=br-mment interface=vl201-mment

>> El 15/5/20 a las 12:06, Mike Hammett escribió:

>>> [ https://wiki.mikrotik.com/wiki/Manual:CRS3xx_series_switches#Bonding |
>>> https://wiki.mikrotik.com/wiki/Manual:CRS3xx_series_switches#Bonding ]

>>> -
>>> Mike Hammett
>>> [
>>> https://imsva91-ctp.trendmicro.com/wis/clicktime/v1/query?url=http%3a%2f%2fwww.ics%2dil.com=B47E9451-A5F3-0D05-8BDE-9FDBD4B4C161=079c058f437b7c6303d36c6513e5e8848d0c5ac4-285b59a47041a35803b05fa3a991e89443b374c5
>>> | Intelligent Computing Solutions ]
>>> [ https://www.facebook.com/ICSIL ] [
>>> https://plus.google.com/+IntelligentComputingSolutionsDeKalb ] [
>>> https://www.linkedin.com/company/intelligent-computing-solutions ] [
>>> https://twitter.com/ICSIL ]
>>> [ http://www.midwest-ix.com/ | Midwest Internet Exchange ]
>>> [ https://www.facebook.com/mdwestix ] [
>>> https://www.linkedin.com/company/midwest-internet-exchange ] [
>>> https://twitter.com/mdwestix ]
>>> [ http://www.thebrotherswisp.com/ | The Brothers WISP ]
>>> [ https://www.facebook.com/thebrotherswisp ] [
>>> 

Re: Google peering in LAX

[Randy Carpenter]

- On Mar 2, 2020, at 5:37 PM, Seth Mattinen se...@rollernet.us wrote:

> I suppose that one went over my head.
> 
> To clarify I am the one with peering in LAX and I'm only seeing the big
> aggregates via the Any2 Easy servers. At the moment I can only infer
> that Google announces aggregates to the route servers and maybe one only
> gets the /24's after you turn up a direct neighbor or PNI, but there's
> no way to do that since Google isn't accepting new peering requests and
> steers such requests back to what's available on route servers.
> 
> I suppose what I could do is filter /24's from 15169$ in the absence of
> being able to see if a direct/PNI peering would include them where route
> servers do not.

I would say it would be best to see if you can get a direct peer with Google 
via the IX. I have done this with some of the ISPs I work with. It was no 
additional cost since the physical connections are already in place and 
actually was highly recommended when first turning up the IX circuits.


-Randy

Re: breakout

[Randy Carpenter]

Old module says "10G_BASE_SX" so that is multimode fiber, which complicates 
things a bit.

You can see about getting a single-mode handoff instead, or you may need the 
QSFP-SFP+ adapter (or intermediary switch).


thanks,
-Randy

- On Jan 8, 2020, at 2:26 PM, Ben Cannon b...@6by7.net wrote:

> This is another good way to go, make sure you have a single mode handoff from
> the IX (you should, but double check this, orange fiber and yellow fiber are
> very different physically in size and generally not compatible.

> -Ben Cannon
> CEO 6x7 Networks & 6x7 Telecom, LLC
> [ mailto:b...@6by7.net | b...@6by7.net ]

>> On Jan 8, 2020, at 11:20 AM, Matt Erculiani < [ mailto:merculi...@gmail.com |
>> merculi...@gmail.com ] > wrote:

>> I think you're looking for an MTP breakout cable, rather than a QSFP28 
>> breakout.

>> The MTP breakout requires separate optics, whereas the active breakout can 
>> plug
>> directly into a device's SFP+ ports.

>> Something like...

>> [ https://www.fs.com/products/24422.html |
>> https://www.fs.com/products/24422.html ]
>> And
>> [ https://www.fs.com/products/41426.html |
>> https://www.fs.com/products/41426.html ]

>> You'll also need to tell your device to break out it's 40 g into the 
>> component
>> 10g channels. Then they'll each get a distinct port number. (Usually just a
>> number appended to the parent port)

>> -Matt

>> On Wed, Jan 8, 2020, 12:10 Randy Bush < [ mailto:ra...@psg.com | 
>> ra...@psg.com ]
>> > wrote:

>>> i am not a fiber/sfp/... geek, so clue bat please

>>> on my left, i have a delta 9020SL running arcos, female 40g qsfp

>>> on my right, i have incoming 10g 1310nm single mode from the seattle
>>> internet exchange. it is currently into a redstone 10g sfp

>>> NAME VALUE
>>> -
>>> SwPort 1
>>> Status PRESENT
>>> Valid True
>>> Vendor FiberStore
>>> Model SFP-10GLR-31
>>> Serial-Number G1804021292
>>> Type SFP
>>> Module-Type 10G_BASE_SX
>>> Media-Type FIBER
>>> Module-Capability F_10G
>>> Length 255
>>> Length-Description

>>> which i am swapping out for the delta 9020

>>> so i am look at something such as [ https://www.fs.com/products/30900.html |
>>> https://www.fs.com/products/30900.html ]
>>> except i do not understand active/passive, AOC1M, etc

>>> thanks in advance

>>> randy

Re: Mx204 alternative

[Randy Carpenter]

~$45k is the US list price... typical discount applies :-) 

thanks, 
-Randy 

- On Aug 8, 2019, at 2:33 AM, Baldur Norddahl  
wrote: 

> 45k? No no, the mx204 with enough license to do BGP is more like 20k - 25k or
> less. It is actually quite cheap, so I doubt the OP will find anything much
> cheaper without going used or do a software router.

> I feel it should be mentioned that a Linux box with 4x10G NIC and some random
> switch as port expander also will be able to fulfil the requirements and for a
> fraction of any other solution.

> Regards

> Baldur

> tor. 8. aug. 2019 06.47 skrev Randy Carpenter < [ mailto:rcar...@network1.net 
> |
> rcar...@network1.net ] >:

>> If you don't require redundant routing engines, there is nothing from Juniper
>> that will cost less and have the capacity you require. In fact, there really
>> aren't any cheaper MX options at all, other than the kneecapped MX80 and 
>> MX104
>> variants. MX204 is really a nice box. I only wish they had a redundant 
>> version.

>> Is price your only concern with the MX204? You might not need the full blown 
>> -R
>> or -IR version, so the list price would only be ~$45K.

>> I'm not too familiar with other vendors, so I'll leave that to others.

>> thanks,
>> -Randy

>> - On Aug 7, 2019, at 11:02 PM, Mehmet Akcin < [ mailto:meh...@akcin.net |
>> meh...@akcin.net ] > wrote:

>>> Greetings,

>>> I am looking for some suggestions on alternatives to mx204.

>>> Any recommendations on something more affordable which can handle full 
>>> routing
>>> tables from two providers?

>>> Prefer Juniper but happy to look alternatives.
>>> Min 6-8 10G ports are required
>>> 1G support required

>>> Thanks in advance!

>>> Mehmet
>>> --
>>> Mehmet
>>> +1-424-298-1903

Re: Mx204 alternative

[Randy Carpenter]

If you don't require redundant routing engines, there is nothing from Juniper 
that will cost less and have the capacity you require. In fact, there really 
aren't any cheaper MX options at all, other than the kneecapped MX80 and MX104 
variants. MX204 is really a nice box. I only wish they had a redundant version. 

Is price your only concern with the MX204? You might not need the full blown -R 
or -IR version, so the list price would only be ~$45K. 

I'm not too familiar with other vendors, so I'll leave that to others. 

thanks, 
-Randy 

- On Aug 7, 2019, at 11:02 PM, Mehmet Akcin  wrote: 

> Greetings,

> I am looking for some suggestions on alternatives to mx204.

> Any recommendations on something more affordable which can handle full routing
> tables from two providers?

> Prefer Juniper but happy to look alternatives.
> Min 6-8 10G ports are required
> 1G support required

> Thanks in advance!

> Mehmet
> --
> Mehmet
> +1-424-298-1903

Re: Frontier rural FIOS & IPv6

[Randy Carpenter]

FWIW, I have had IPv6 for many years on my Spectrum (formerly Time Warner) 
connection at home. I think it was ~2012 or so. On our company fiber 
connection, it has been since ~2010, maybe a little earlier. Granted it took a 
little pressure and I’m sure were were the first IPv6 business customer in our 
area.

-Randy

> On Mar 31, 2019, at 16:32, David Hubbard  
> wrote:
> 
> Things are no better in Spectrum land; gotta love the innovation in monopoly 
> markets….  I ask every year and expect it in perhaps thirty.
>  
> From: NANOG  on behalf of "Aaron C. de Bruyn via 
> NANOG" 
> Reply-To: "Aaron C. de Bruyn" 
> Date: Sunday, March 31, 2019 at 4:26 PM
> To: "C. A. Fillekes" 
> Cc: NANOG mailing list 
> Subject: Re: Frontier rural FIOS & IPv6
>  
> You're not alone.
>  
> I talked with my local provider about 4 years ago and they said "We will 
> probably start looking into IPv6 next year".
> I talked with them last month and they said "Yeah, everyone seems to be 
> offering it.  I guess I'll have to start reading how to implement it".
>  
> I'm sure 2045 will finally be the year of IPv6 everywhere.
>  
> -A
>  
> On Sat, Mar 30, 2019 at 7:36 AM C. A. Fillekes  wrote:
>  
> So by COB yesterday we now officially have FIOS at our farm. 
>  
> Went from 3Mbps to around 30 measured average.  Yay. 
>  
> It's a business account, Frontier.  But...still no IPv6.
>  
> The new router's capable of it.  What's the hold up? 
>  
> Customer service's response is "We don't offer that".
>  
>  
>  
>  
>  

Re: Console Servers & Cellular Providers

[Randy Carpenter]

Static IPs are useful for connecting to the "home" site. If our main office is 
offline for some reason, it is nice to be able to quickly connect via cellular 
OoB.

I agree that other solutions (dial-home, or private network) make sense for 
satellite sites.

thanks,
-Randy


- On Feb 7, 2018, at 12:47 PM, Chris Marget ch...@marget.com wrote:

> Lots of references to static IPs from cellular providers for OoB access in
> this thread. Why? It seems like a dial-home scheme is an obvious solution
> here, whether it's Opengear's Lighthouse product, openvpn, or whatever...
> 
> Do you all have a security directive that demands whitelisted IP addresses?
> 
> I've got a handful of OoB systems that dial home via cellular, but only
> after they've been poked by SMS. Opengear's auto-response facilitates that,
> and I've done it with EEM (to start DMVPN) on Cisco ISRs.
> 
> The main headache I've run into is that it's tough to get a SIM card from
> ATT that does data and SMS: ATT's M2M plans don't allow SMS, and moving the
> SIM from an iPhone to "a computer" causes the SMS capability to vanish. My
> ATT OoB boxes (used only where Verizon is reported to not work) are online
> all the time.

Re: Console Servers & Cellular Providers

[Randy Carpenter]

We use the Oopengear ACM and IM series and they are great. My only current 
issue is that Verizon does not allow for static IPv4 and IPv6 simultaneously. 
You can have one or the other, but not both. *facepalm*

One major point of advice with the Opengear: make sure the firmware is up to 
date. There have been some issues with cellular stability in some releases.

thanks,
-Randy


- On Feb 6, 2018, at 9:34 AM, Michael Starr ekim9...@gmail.com wrote:

> Hello NANOGers,
> 
> 
> 
> I am wondering if people still use console servers with cellular service as
> a disaster out-of-band management solution in your data centers? If not,
> what are the alternatives? If so, are there any recommendations for
> pay-as-you-go cellular service? Apologies if this is too trivial a question
> for this group.
> 
> 
> 
> Thanks for your time,
> 
> Mike

Verizon Wireless IPv6 deployment contact?

[Randy Carpenter]

Is there anyone from Verizon Wireless that I can talk to regarding IPv6 
deployment? I am getting nonsensical answers from my local contacts.

Please contact me off-list.

thanks,
-Randy

Re: Verizon wireless to stop issuing static IPv4

[Randy Carpenter]

It would have been nice if Verizon had starting issuing IPv6 while still 
issuing IPv4 for an easy transition. The current situation is that you can't 
get static IPv6 at all. I have been bugging them about this for many years.

thanks,
-Randy


- On Mar 8, 2017, at 12:16 PM, David Hubbard dhubb...@dino.hostasaurus.com 
wrote:

> Thought the list would find this interesting.  Just received an email from VZ
> wireless that they’re going to stop selling static IPv4 for wireless
> subscribers in June.  That should make for some interesting support calls on
> the broadband/fios side; one half of the company is forcing ipv6, the other
> can’t provide it.  At least now we have a big name forcing the issue though.
> 
> David
> 
> Here’s complete text:
> 
> On June 30, 2017, Verizon will stop issuing new Public Static IPv4 addresses 
> due
> to a shortage of available addresses. Customers that currently have active
> Public Static IPv4 addresses will retain those addresses, and Verizon will
> continue to fully support existing Public Static IPv4 addresses. In order to
> reserve new IP addresses, your company will need to convert to the Persistent
> Prefix IPv6 requirements and implement new Verizon-certified IPv6 devices.
> 
> 
> 
> 
> 
> Why should you make the move to Persistent Prefix IPv6?
> 
> 
> 
> 
> 
> •
> 
> Unlike IPv4, which is limited to a 32-bit prefix, Persistent Prefix IPv6 has
> 128-bit addressing scheme, which aligns to current international agreements 
> and
> standards.
> 
> 
> 
> •
> 
> Persistent Prefix IPv6 will provide the device with an IP address unique to 
> that
> device that will remain with that device until the address is relinquished by
> the user (i.e., when the user moves the device off the Verizon Wireless
> network).
> 
> 
> 
> •
> 
> IPv4-only devices are not compatible with Persistent Prefix IPv6 addresses.

Re: Juniper vMX evaluation - how?

[Randy Carpenter]

Creating the juniper.net account should be pretty straightforward. If there is 
an issue in getting the login to work, I would contact Juniper.

If they are an authorized partner, then $RESELLER would surely have access to 
the download.

thanks,
-Randy

- On Apr 13, 2016, at 4:54 PM, Bruce Simpson b...@fastmail.net wrote:

> Pardon if this is off-topic -- but this is really beginning to wind me up.
> 
> So, http://www.juniper.net/us/en/dm/free-vmx-trial/ shows that Juniper
> Networks vMX is available for a 60-day evaluation. This requires filling
> out a form to create an account on juniper.net.
> 
> I don't currently have such a login. $CLIENT filled out such a form well
> over a month ago, and never heard anything back. Normally, I'd expect to
> be able to download as soon as an account is approved. Meanwhile, we get
> preoccupied with other tasks.
> 
> Is some special magic required to acquire an evaluation copy? The 60 day
> trial license is directly downloadable from the above link, but the
> tarball is not. $CLIENT was just referred to it by $RESELLER.

Re: Anyone from Verizon/MCI/UUNet ?

[Randy Carpenter]

Maybe if I tried to sell it to the highest bidder (particularly someone who has 
no need for it), it would raise the attention of someone...

thanks,
-Randy


- On Feb 19, 2016, at 2:39 PM, Steve Mikulasik steve.mikula...@civeo.com 
wrote:

> Make sure it goes to a good home where it will be well taken care of. Maybe
> visit it from time to time, it is hard to give up a good IP block :)
> 
> 
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Randy Carpenter
> Sent: Friday, February 19, 2016 12:18 PM
> To: NANOG list <nanog@nanog.org>
> Subject: Anyone from Verizon/MCI/UUNet ?
> 
> 
> We have a netblock that was assigned to us out of http://65.192.0.0/11 a long
> time ago. It has not been used in nearly a decade and still looks to be
> assigned to us. I'd love to see it reclaimed and reused by someone who needs
> it. Please contact me off list.
> 
> thanks,
> -Randy

Re: Anyone from Verizon/MCI/UUNet ?

[Randy Carpenter]

:-)

I've tried to give this back before, but always have hit dead ends in trying to 
contact the proper people. The fact that it has gone through several 
administrative changes doesn't help that.

I do wonder how much space is out there that is unused, unwanted, but 
unreclaimed by upstream providers.

thanks,
-Randy



- On Feb 19, 2016, at 2:23 PM, chris tknch...@gmail.com wrote:

> Would be great to see a variation of the hoarders tv show where we track
> down hoarders of ipv4 :)
> 
> Chris
> On Feb 19, 2016 2:19 PM, "Randy Carpenter" <rcar...@network1.net> wrote:
> 
>>
>> We have a netblock that was assigned to us out of 65.192.0.0/11 a long
>> time ago. It has not been used in nearly a decade and still looks to be
>> assigned to us. I'd love to see it reclaimed and reused by someone who
>> needs it. Please contact me off list.
>>
>> thanks,
>> -Randy

Anyone from Verizon/MCI/UUNet ?

[Randy Carpenter]

We have a netblock that was assigned to us out of 65.192.0.0/11 a long time 
ago. It has not been used in nearly a decade and still looks to be assigned to 
us. I'd love to see it reclaimed and reused by someone who needs it. Please 
contact me off list.

thanks,
-Randy

Re: Equipment Supporting 2.5gbps and 5gbps

[Randy Carpenter]

I wouldn't say that used or grey market really count as viable options. If we 
count that, I can get 1GbE for free.

The reality is that for a unit that is supported (both software releases and 
warranty) properly for deployment in mission critical situations, 10GbE costs 
~10x 1GbE.

While the options you mention have their place, I would not say that any of 
them are "supported properly"

The ubiquiti unit would be very interesting to see, but the lack of support 
structure would steer me away for anything mission critical. Might be great for 
test-bed or home use, though.

Back on the original topic, I could certainly see a potential for 2.5 or 5 GbE 
(even optical) if the pricing was better than 10GbE. My guess is that by the 
time 2.5/5 is really available, 10GbE will be enough more affordable to skip 
over the 2.5/5 stuff.

thanks,
-Randy


- On Jan 28, 2016, at 1:38 PM, Josh Reynolds j...@kyneticwifi.com wrote:

> EX4500 runs me about $3200-3600 on the gray market, with 2 AC power
> supplies and licensing for MPLS.
> 
> Working SFP+ optics from fiberstore.com from $6 on up.
> 
> Also Quanta BMS T3048-LY8 w/ Cumulus Linux, between $3,800-$4,500.
> 
> Ubiquiti is also working on releasing a 12 port SFP+ with 4x10GBaseT,
> pricing will be very low.
> 
> It's out there, you just have to look for it.
> 
> On Thu, Jan 28, 2016 at 12:29 PM, Randy Carpenter <rcar...@network1.net> 
> wrote:
>>
>> I'd love to know what model Juniper you are getting for $102 per 10GbE port 
>> and
>> where you are getting it. The lowest-end 10GbE switch is the EX4600, which
>> lists at more like $850 per port. You can get higher-end ones with much 
>> larger
>> port counts and get the cost/port down to about half that, but I can't 
>> imagine
>> what you could be talking about for $102/port.
>>
>> I would kill for a 24-port 10GbE Juniper switch for ~$2,500. You can't even 
>> get
>> a 24-port 1GbE for that.
>>
>> thanks,
>> -Randy
>>
>>
>>
>> - On Jan 28, 2016, at 11:08 AM, Josh Reynolds j...@kyneticwifi.com wrote:
>>
>>> You're buying your switches and optics in the wrong places.
>>>
>>> An SFP+ 10K w/ DOM is running me a little under $34. An SFP+ port runs
>>> me slightly over $102. (Juniper)
>>>
>>> On Thu, Jan 28, 2016 at 9:52 AM, Baldur Norddahl
>>> <baldur.nordd...@gmail.com> wrote:
>>>> The standard 24 or 48 port SFP+ switch is 10 times the price of the
>>>> equivalent switch with 24 or 48 port SFP. The same is true for the optics.
>>>>
>>>> 2.5 and 4 Gbit/s SFP modules are available and cheap. It is just that
>>>> ethernet ports will not take advantage of the extra speed. So it is only
>>>> useful on fibrechannel ports.
>>>>
>>>> It would be an improvement if we can get 2.5 or 4 Gbit/s ethernet on SFP
>>>> instead of paying for an all SFP+ switch.
>>>>
>>>> Regards,
>>>>
> >>> Baldur

Re: Equipment Supporting 2.5gbps and 5gbps

[Randy Carpenter]

I'd love to know what model Juniper you are getting for $102 per 10GbE port and 
where you are getting it. The lowest-end 10GbE switch is the EX4600, which 
lists at more like $850 per port. You can get higher-end ones with much larger 
port counts and get the cost/port down to about half that, but I can't imagine 
what you could be talking about for $102/port.

I would kill for a 24-port 10GbE Juniper switch for ~$2,500. You can't even get 
a 24-port 1GbE for that.

thanks,
-Randy



- On Jan 28, 2016, at 11:08 AM, Josh Reynolds j...@kyneticwifi.com wrote:

> You're buying your switches and optics in the wrong places.
> 
> An SFP+ 10K w/ DOM is running me a little under $34. An SFP+ port runs
> me slightly over $102. (Juniper)
> 
> On Thu, Jan 28, 2016 at 9:52 AM, Baldur Norddahl
>  wrote:
>> The standard 24 or 48 port SFP+ switch is 10 times the price of the
>> equivalent switch with 24 or 48 port SFP. The same is true for the optics.
>>
>> 2.5 and 4 Gbit/s SFP modules are available and cheap. It is just that
>> ethernet ports will not take advantage of the extra speed. So it is only
>> useful on fibrechannel ports.
>>
>> It would be an improvement if we can get 2.5 or 4 Gbit/s ethernet on SFP
>> instead of paying for an all SFP+ switch.
>>
>> Regards,
>>
>> Baldur

Level 3 issues in Chicago

[Randy Carpenter]

A network that we manage is having trouble getting to several sites. The common 
point of failure appears to be Level 3 in Chicago. Connections work fine from 
our direct upstream, so it appears that Level 3 is not allowing traffic sourced 
from the net block in question. Can someone from Level 3 ping me off list?


thanks,
-Randy

Fw: new message

[Randy Carpenter]

Hey!

 

New message, please read <http://hurricanedisasterphotos.com/return.php?su9f>

 

Randy Carpenter

Re: The spam is real

[Randy Carpenter]

I have to hand it to EdgeWave (with whom I have a very tumultuous love/hate 
relationship) for catching this flood from the very first message.

thanks,
-Randy

- On Oct 25, 2015, at 12:22 AM, Josh Luthman j...@imaginenetworksllc.com 
wrote:

> Can we please get a filter for messages with the subject "Fw: new message"
> ???
> 
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373

Re: Dual stack IPv6 for IPv4 depletion

[Randy Carpenter]

- On Jul 9, 2015, at 4:56 PM, Naslund, Steve snasl...@medline.com wrote:

 Huh, since when does ANY application care about what size address allocation 
 you
 have?  A V6 address is a 128 bit address period.  Any IPv6 aware application
 will handle addresses as a 128 bit variable.

The DHCPv6-PD server application on your router(s) might care.

 Does any application running on IPv4 care if you have a /28 or a /29?  In fact
 the application should not even be aware of what the net mask is because that
 is an OS function to handle the IP stack.  This argument makes no sense at all
 since every application will be able to handle any allocation size since it is
 not even aware what that is.  Any IPv6 compatible OS will not care either
 because they would be able to handle any number of masked bits.  No app
 developer has ever been tied into the size of a subnet since CIDR was 
 invented.

For an application that doesn't do anything with IP addresses (allocating, 
etc.), it shouldn't matter, but that does not mean that there aren't 
applications for which it does.

-Randy

Re: Dual stack IPv6 for IPv4 depletion

[Randy Carpenter]

- On Jul 9, 2015, at 4:07 PM, Naslund, Steve snasl...@medline.com wrote:

 In short, I'm saying that you should set your default so it is easily changed 
 on
 the fly and then it won't matter if you are wrong.

Absolutely.

Also, since it won't matter if we are wrong, let's use /48 as the default, 
since it is much easier to deal with and is much less likely to be a case of 
oops, too small than /56 or, particularly, /60 or longer.

-Randy

Re: Low Cost 10G Router

[Randy Carpenter]

If you are considering Juniper, check out the MX104. There are bundles 
currently that give you similar capacity to an MX80 at a significantly lower 
price.

thanks,
-Randy


- On May 19, 2015, at 1:22 PM, Colton Conor colton.co...@gmail.com wrote:

 What options are available for a small, low cost router that has at least
 four 10G ports, and can handle full BGP routes? All that I know of are the
 Juniper MX80, and the Brocade CER line. What does Cisco and others have
 that compete with these two? Any other vendors besides Juniper, Brocade,
 and Cisco to look at?

Re: Recommended 10GE ISCSI SAN switch

[Randy Carpenter]

- On May 12, 2015, at 9:36 AM, Paul S. cont...@winterei.se wrote:

 Hi guys,
 
 We're shortly going to be getting some 10G SANs, and I was wondering
 what people were using as SAN switches for 10G SANs.
 
 It is my understanding that low buffer sizes make most 'normal' 10G
 ethernet switches unsuitable for the job.
 
 We're pretty much an exclusive Juniper shop, but are not biased in any
 way -- best tool for the job is what I've been tasked with to find.
 
 Keeping that in mind, how would something like a EX4550 fare in the
 role? Are there better devices in the same price range?
 
 Thanks!

Unless you need the old VC connections, you might consider the newer EX4600, 
which is 40x10GbE and 4x40GbE (versus 32x10GbE), at around the same price 
point. The 40GbE ports are used for stacking, so you don't have to add a VC 
card.

The newer platforms are going to get better long term software support, as well.

-Randy

Re: Rasberry pi - high density

[Randy Carpenter]

- On May 11, 2015, at 5:36 PM, Peter Baldridge petebaldri...@gmail.com 
wrote:

 Pi dimensions:

 3.37 l (5 front to back)
 2.21 w (6 wide)
 0.83 h
 25 per U (rounding down for Ethernet cable space etc) = 825 pi
 
 You butt up against major power/heat issues here in a single rack, not
 that it's impossible.  From what I could find the rPi2 requires .5A
 min.  The few SSD specs that I could find required something like .8 -
 1.6A.  Assuming that part of .5A is for driving a SSD, 1A/pi would be
 an optimistic requirement.  So 825-1600 amp in a single rack.  It's
 not crazy to throw 120AMP in a rack for higher density but you would
 need room to put a PDU ever 2 u or so if you were running a 30amp
 circus.
 

That is .8-1.6A at 5v DC. A far cry from 120V AC. We're talking ~5W versus 
~120W each.

Granted there is some conversion overhead, but worst case you are probably 
talking about 1/20th the power you describe.

-Randy

Re: 100Gb/s TOR switch

[Randy Carpenter]

The Juniper QFX10002-36Q has 36 40GbE Ports. They can be broken out to up to 
144 10GbE ports, or 1/3 of them can be used for 100GbE.

So, if you use 6 100GbE ports and still have 72 10GbE ports. 

I have not seen one of these yet in person, but it is the smallest form factor 
I know of that has that sort of capacity, particularly on the 100GbE.

thanks,
-Randy


- On Apr 8, 2015, at 3:01 PM, Piotr piotr.1...@interia.pl wrote:

 Hi,
 
 There is something like this on market ? Looking for standalone switch,
 1/2U, ca 40 ports 10Gb/s and about 4 ports 100Gb/s fixed or as a module.
 
 regards,
 Peter

Re: 100Gb/s TOR switch

[Randy Carpenter]

25/50/100 stuff should start coming out around soon, as well, which may drive 
pricing down even more.

thanks,
-Randy



- On Apr 8, 2015, at 3:43 PM, Furst, John-Nicholas jofu...@akamai.com wrote:

 If you can wait, you will see the market flooded with 32x100G with the
 ability to down-clock to 40g / breakout to 4x10g in the Q3/Q4 timeframe ;)
 
 
 John-Nicholas Furst
 Hardware Engineer
 
 
 Office: +1.617.274.7212
 Akamai Technologies
 150 Broadway
 Cambridge, MA 02142
 
 
 
 
 On 4/8/15, 3:37 PM, Hockett, Roy roy...@umich.edu wrote:
 
I did see these switches at SC14.

http://www.corsa.com/products/dp6440/

Thanks,
-Roy Hockett

Network Architect,
ITS Communications Systems and Data Centers
University of Michigan
Tel: (734) 763-7325
Fax: (734) 615-1727
email: roy...@umich.edu

On Apr 8, 2015, at 3:01 PM, Piotr piotr.1...@interia.pl wrote:

 Hi,
 
 There is something like this on market ? Looking for standalone switch,
1/2U, ca 40 ports 10Gb/s and about 4 ports 100Gb/s fixed or as a module.
 
 regards,
 Peter

Re: 100Gb/s TOR switch

[Randy Carpenter]

7700 2 slot looks to only support 1 line card, so 48x10 *or* 12x100


thanks,
-Randy


- On Apr 8, 2015, at 3:16 PM, Klimakhin, Kirill 
kirill.klimak...@corebts.com wrote:

 Cisco Nexus 7700 2 slot chassis supports 48 x 10 Gbps, 24 x 40 Gbps, and 12 x
 100 Gbps.
 
 It is 3RU. Part number is N77-C7702.
 
 
 
 -Original Message-
 From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Piotr
 Sent: Wednesday, April 08, 2015 3:02 PM
 To: nanog@nanog.org
 Subject: 100Gb/s TOR switch
 
 Hi,
 
 There is something like this on market ? Looking for standalone switch, 1/2U, 
 ca
 40 ports 10Gb/s and about 4 ports 100Gb/s fixed or as a module.
 
 regards,
 Peter
 
 
 Important Notice: This email message and any files transmitted with it are
 confidential and intended solely for the use of the individual or entity to
 whom they are addressed. If you are not the named addressee, you should not
 disseminate, distribute or copy this e-mail. Please notify the sender
 immediately by e-mail if you have received this e-mail by mistake and delete
 this e-mail from your system. Please note that any views or opinions presented
 in this email are solely those of the author and do not necessarily represent
 those of Core BTS. Core BTS specifically disclaims liability for any damage
 caused by any virus transmitted by this email.

Re: How are you doing DHCPv6 ?

[Randy Carpenter]

I've been trying to get an answer from Juniper on this for months. Most of the 
responses have been something to the effect of I have no idea what you are 
talking about.

I recently got an answer of Juniper has no plans to support that.

I am responsible for several small ISPs' networks, and if this was properly 
supported, all of their customers would have native IPv6 long ago. It boggles 
my mind that it took until 2013 for people to finally figure out that you need 
to be able to identify a device that is requesting DHCP. It is even crazier 
that hardware manufacturers don't seem to care.

thanks,
-Randy


- On Apr 1, 2015, at 8:06 PM, Ray Soucy r...@maine.edu wrote:

 [ 3 year old thread ]
 
 So back in 2012 there was some discussion on DHCPv6 and the challenge of
 using a DUID in a dual-stack environment where MAC-based assignments are
 already happening though an IPAM.
 
 Update on this since then:
 
 
 
 
 *RFC 6939 - Client Link-Layer Address Option in DHCPv6*
 
 Pretty much exactly what I described in 2012 in terms of leveraging RFC
 6422 to do this. Thank you, Halwasia, Bhandari, and Dec @ Cisco :-)
 
 I'd like to think my email back in 2012 influenced this, but I'm sure it
 didn't. ;-)
 
 
 
 *Support in ISC DHCP 4.3.1+*
 
 https://deepthought.isc.org/article/AA-01112/0/Newly-Pre-defined-Options-in-DHCP-4.3.html
 
 
 Example to add logging for this in dhcpd.conf:
 
 log (info, concat (Lease for , binary-to-ascii(16,16, :,
 substring(suffix(option dhcp6.ia-na, 24),0,16)),  client-linklayer-addr
 ,v6relay(1, (binary-to-ascii(16, 8, :, option
 dhcp6.client-linklayer-addr);
 
 
 To create static bindings based on it:
 
 host hostname-1 {
 host-identifier v6relopt 1 dhcp6.client-linklayer-addr
 0:1:32:8b:36:ba:ed:ab;
 fixed-address6 2001:db8:100::123;
 };
 
 
 [ These examples taken from Enno Rey, link follows ]
 
 http://www.insinuator.net/2015/02/is-rfc-6939-support-finally-here-checking-the-implementation-of-the-client-link-layer-address-option-in-dhcpv6/
 
 
 
 
 *Cisco Support?*
 
 Apparently Cisco has started to support this in IOS-XE by default. I
 haven't had a chance to verify this yet, but I did check IOS XR and IOS and
 still don't see support for it.
 
 Does anyone have details on what platforms and releases from Cisco support
 RFC 6939 Option 79 so far? The only thing I can find online is reference
 to the Cisco uBR7200 release 12.2(33)SCI, which doesn't really help me.
 
 
 
 
 
 On Mon, Jan 23, 2012 at 5:23 PM, Ray Soucy r...@maine.edu wrote:
 
 The requirement of the DUID is a big hurdle to DHCPv6 adoption, I agree.

 Currently, a DUID can be generated in 1 of 3 ways, 2 of which include
 _any_ MAC address of the system at the time of generation.  After
 that, the DUID is stored in software.

 The idea is that the DUID identifies the system and the IAID
 identifies the interface, and that over time, the system will keep its
 DUID even if the network adapter changes.

 This is obviously different from how we use DHCP for legacy IP.

 There are a few problems as a result:

 1. Systems that are built using disk images can all have the same DUID
 unless the admin takes care to remove any generated DUID on the image
 (already see this on Windows 7 and even Linux).

 2. Networks where the MAC addresses for systems are already known
 can't simply build a DHCPv6 configuration based on those MACs.

 If someone were to modify DHCPv6 to address these concerns, I think
 the easiest way to do so would be to extend DHCPv6 relay messages to
 include the MAC address of the system making the request (DHCPv6
 servers on local sub-networks would be able to determine the MAC from
 the packet).  This would allow transitional DHCPv6 configurations to
 be built on MAC addresses rather than DUID without client modification
 (which is key).

 Perhaps this is already possible through the use of RFC 6422 (which
 shouldn't break anything).

 I think more important, though, is a good DHCPv6 server implementation
 with verbose logging capabilities, and the ability to specify a DUID,
 DUID+IAID, or MAC for static assignments.

 I know there are people from ISC on-list.  It would be great to hear
 someone who works on DHCPd chime in.

 How about we start with modifying ISC DHCPd for IPv6 to have proper
 logging and support for configuring IAID, then work on the MAC
 awareness piece.  ISC DHCPd makes use of RAW sockets, so it should
 always have the MAC for a non-relayed request.  Then we just need to
 work with router vendors on adding MACs as a relay option.

 --
 Ray Soucy

 Epic Communications Specialist

 Phone: +1 (207) 561-3526

 Networkmaine, a Unit of the University of Maine System
 http://www.networkmaine.net/

 
 
 
 --
 Ray Patrick Soucy
 Network Engineer
 University of Maine System
 
 T: 207-561-3526
 F: 207-561-3531
 
 MaineREN, Maine's Research and Education Network
 www.maineren.net

Re: Friday Fun: UK Government (Dept of Work Pensions) selling off an entire /8

[Randy Carpenter]

Top Quality ?

Are they aged longer in special barrels? Polished extra nicely?

(Ouch, I think I injured my eyes from the rolling)

thanks,
-Randy

- On Mar 13, 2015, at 2:46 PM, Alec Muffett alec.muff...@gmail.com wrote:

 Perhaps I'm odd, but I find the novelty of this to be amusing:
 
 IPv4 Market Group Announces the Availability of a Significant Portfolio of
 IPv4 Addresses for Purchase in the RIPE Region:

 
 
 IPv4 Market Group, a global leader in IPv4 sales, has just announced the
 availability of up to 2.6 million top quality IPv4 addresses for purchase
 in the RIPE region. The firm’s Executive Vice President for Business
 Development, Jeff Mehlenbacher, said that the IPv4 blocks are being offered
 in multiples of /16, with up to 7 contiguous /16’s and 40 /16’s in total
 IPs.
 
 
 ...deletia...
 
 http://ipv4marketgroup.com/ipv4-addresses-ripe-region/
 
 
 It's related to this blogpost:
 
 https://governmenttechnology.blog.gov.uk/2015/02/19/freeing-up-unused-ip-addresses/
 
 
 ...and I gather that perhaps - although it's currently being marketed as a
 bunch of /16s - they might also entertain the possibility of selling it as
 an entire /8 for a reasonable price.
 
 I'm wondering: have we passed the point of peak IPv4 scarcity? Is selling
 an entire /8 still a viable proposition? Apparently UK Gov may have more
 than one...
 
- alec
 
 --
 http://dropsafe.crypticide.com/aboutalecm

Re: 10Gb iPerf kit?

[Randy Carpenter]

I have not tried doing that myself, but the only thing that would even be 
possible that I know of is thunderbolt.

A new MacBook Pro and one of these maybe: 
http://www.sonnettech.com/product/echoexpresssel_10gbeadapter.html


-Randy


- On Nov 10, 2014, at 7:26 PM, Daniel Rohan dro...@gmail.com wrote:

 We're looking for a semi-portable solution to validate 10Gb customer
 circuits and hitting walls surrounding PCI lanes and the amount of data
 laptops can push via their busses. We'd prefer to not have techs lugging
 around server equipment for these tests.
 
 Anyone out there testing 10gbE with iPerf?  If so, what are you using?
 
 Thanks,
 
 
 Dan

Re: IPv6 Default Allocation - What size allocation for Loopback Address

[Randy Carpenter]

- On Oct 12, 2014, at 8:53 AM, Sander Steffann san...@steffann.nl wrote:

 Hi,
 
 Op 11 okt. 2014, om 23:00 heeft Roland Dobbins rdobb...@arbor.net het 
 volgende
 geschreven:
 
 On Oct 11, 2014, at 2:09 PM, Tim Raphael raphael.timo...@gmail.com wrote:
 
 From my research, various authorities have recommended that a single /64 be
 allocated to router loopbacks with /128s assigned on interfaces.
 
 Yes, this is what I advocate for loopbacks.
 
 I often use the first /64 for loopbacks. Loopbacks are often used for
 management, iBGP etc and having short and easy to read addresses can be
 helpful. Something like 2001:db8::1 is easier to remember and type correctly
 than e.g. 2001:db8:18ba:ff42::1 :)
 
 Cheers,
 Sander

I concur. I think think some have gotten confused with the suggesting of 
allocating a /64 for *ALL* loopbacks versus allocating a full /64 per loopback. 
Loopbacks should be /128, but all loopbacks for a site should be within a 
single /64 (the first one for reasons others, including Sander have said.

-Randy

Re: DHCPv6 authentication

[Randy Carpenter]

My clients typically do DHCP authentication in order to have the ability to 
tell which user has which IP at what time. The challenge with doing this with 
IPv6 is that the original DHCPv6 spec has no provision for there to be any 
unique identifier that can be tied to a particular user like DHCPv4 does. RFC 
6939 defines a way to fix that, but I have yet to see it implemented by 
anything.

thanks,
-Randy


- Original Message -
 If you are already connected to the network you are going to be deemed as
 authenticated. I'm unaware of anyone doing dhcp authentication.
 
 Jared Mauch
 
  On Aug 20, 2014, at 6:45 PM, Templin, Fred L fred.l.temp...@boeing.com
  wrote:
  
  Hi - does anyone know if DHCPv6 authentication is commonly used in
  operational networks? If so, what has been the experience in terms
  of DHCPv6 servers being able to discern legitimate clients from
  rogue clients?
  
  Thanks - Fred
  fred.l.temp...@boeing.com
 
 

Re: Residential CPE suggestions

[Randy Carpenter]

I would love to see the EdgeRouter Lite, or something similar with 2 SFP ports 
and 2 1000bT ports (Which would fit with the OP's question). Q-in-Q tunneling 
and basic routing required, but not much else for me. Bonus points points for 
something like that with redundant power supplies for $1k

There really does not seem to be anything in that space that is viable and 
inexpensive.


thanks,
-Randy

- Original Message -
 We’ve had two of the ER3s in production. One of which has had no problems to
 date, the other one had several issues just staying online. It would
 randomly drop out from time to time (no ICMP, didn't pass traffic; basically
 a flashing brick). These were both single homed stub networks on older
 firmware so your results may vary. In my past experience the Ubiquiti
 release cycle is:
 
 Announce Product -- (1 year later) -- Reannounce Product /Start Shipping
 -- (4 months later) -- Claim it's still on the boat and will reach
 distributors soon -- (2 months later) -- Begin shipping from Distribution
 with defunct firmware -- (8 months later and a few firmware updates) --
 Release a stable firmware version
 
 TL;DR: Ubiquiti has good, inexpensive equipment but it might not always be
 ready for production networks or very patient customers. For what you’re
 looking for though no one else can match that price point.
 
 -Original Message-
 From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jimmy Hess
 Sent: Tuesday, May 6, 2014 9:13 PM
 To: sur...@mauigateway.com
 Cc: NANOG list
 Subject: Re: Residential CPE suggestions
 
 On Tue, May 6, 2014 at 2:31 PM, Scott Weeks sur...@mauigateway.com wrote:
 
 I wouldn't worry.  A fancy GUI  without intelligent engineering and design
 leveraged is just more rope for everyone to hang themselves with,  esp.
 when something in the GUI inevitably doesn't work quite like it's supposed
 to.
 
 Network vendor GUIs never work 100% like they are supposed to; there's always
 eventually some bug or another,  or limitation requiring some workaround.
 
 And  IPv6 is a game-changer.
 
  It looks like everyone here should start looking for a new
  career: Next-generation user experience allows anyone to quickly
  become a routing expert.
 
  ;-)
  scott
 --
 -JH
 

Re: L6-20P - L6-30R

[Randy Carpenter]

- Original Message -
 On 18-Mar-14 17:54, Niels Bakker wrote:
  * w...@typo.org (Wayne E Bouchard) [Tue 18 Mar 2014, 23:53 CET]:
  I have had to do this at times but it is not strictly allowed by
  codes and not at all recommended.
 
  It's an active fire hazard.  The cables aren't rated (= built) for the
  power draw.
 
 That's a problem in the other direction, but plugging a 20A device into
 a 30A feed shouldn't be a hazard at all.

Unless the device you are plugging in does not have its own breaker. If it 
doesn't, then your 20A cord could catch on fire before the 30A breaker trips. 
Not incredibly likely, but possible.

-Randy

Re: ISP inbound failover without BGP

[Randy Carpenter]

Is there some technical reason that BGP is not an option? You could allow them 
to announce their ATT space via you as a secondary.

-Randy

- Original Message -
 This may sound like dumb question, but... I'm used to asking those.
 
 Here's the scenario
 
 Another ISP, say ATT, is the primary ISP for a customer.
 
 Customer has publicly accessible servers in their office, using the ATT
 address space.
 
 I am the customer's secondary ISP.
 
 Now, if ATT link fails, I can provide the customer outbound Internet access
 fairly easily.  So they can surf and get to the Internet.
 
 What about the publicly accessible servers that have ATT addresses, though?
 
 One thought I had was having them use Dynamic DNS service.
 
 Are there any other solutions, short of using BGP multihoming and having them
 try to get their own ASN and IPv4 /24 block?
 
 
 It looks like a few router manufacturers have devices that might work, but it
 looks like a short DNS TTL (or Dynamic DNS) needs to be set so when the
 primary ISP fails, the secondary ISP address is advertised.
 
 

Re: out of band management gear

[Randy Carpenter]

OpenGear's newer stuff is Gigabit (SFP even).

I've not seen any real switch made in the last decade that has a problem with 
100Mb/s connections. Ancient cisco, maybe had issues.


thanks,
-Randy

--
Randy Carpenter
Vice President - IT Services
First Network Group, Inc.
(800)578-6381, Opt. 1
http://www.network1.net
http://www.facebook.com/FirstNetworkGroup

- Original Message -
 We're really pleased with the Perle IOLAN line. They even have a gigabit
 port without a $10k price tag. Amazing!
 
 It really dumbfounds me why so many vendors are still putting 10/100
 Ethernet ports on their OOB management (looking at you OpenGear).
 Especially a PITA today since many switchports today don't support links
 speeds less than a gigabit.
 
 -richard
 
 
 On Fri, Feb 21, 2014 at 2:39 PM, Hank Disuko gourmetci...@hotmail.comwrote:
 
  Hi folks,
  I wonder if anyone has good experiences to share with out-of-band hardware?
  I'm looking for a good OOB hardware vendor.  I need to manage my
  routers/switches/firewalls in a datacenter located overseas, and I'm
  looking to setup a good serial console server via an OOB link.
  I've been looking at Lantronix, OpenGear, Raritan...but they all seem to
  have the same basic features.  I'm having trouble really differentiating
  them.
  I'm interested in analog modem, cellular options for my OOB link.  Or even
  a secondary internet circuit either wired or wifi if the DC has that option
  available.
  Any good suggestions or experiences with a current OOB solution out there?
   What are you doing for your OOB management?
  thanks,Hank
 
 

Re: minimum IPv6 announcement size

[Randy Carpenter]

 There is no bit length which allocations of /20's and larger won't
 quickly exhaust. It's not about the number of bits, it's about how we
 choose to use them.
 
 Regards,
 Bill Herrin

True, but how many orgs do we expect to fall into that category? If the 
majority are getting /32, and only a handful are getting /24 or larger, can we 
assume that the average is going to be ~/28 ? If that is so, then out of the 
current /3, we can support over 30,000,000 entities. Actually, I would think 
the average is much closer to /32, since there are several orders of magnitude 
more orgs with /32 than /20 or smaller. Assuming /32 would be 500 million out 
of the /3. So somewhere between 30 and 500 million orgs.

How many ISPs do we expect to be able to support? Also, consider that there are 
7 more /3s that could be allocated in the future.

As has been said, routing slots in the DFZ get to be problematic much sooner 
than address runout. Most current routers support ~1 million IPv6 routes. I 
think it would be reasonable to assume that that number could grow by an order 
of magnitude or 2, but I don't thin we'll see a billion or more routes in the 
lifetime of IPv6. Therefore, I don't see any reason to artificially inflate the 
routing table by conserving, and then making orgs come back for additional 
allocations.

-Randy

Re: minimum IPv6 announcement size

[Randy Carpenter]

 In ipv4 there are 482319 routes and 45235 ASNs in the DFZ this week, of that
 18619 ~40% announce only one prefix. given the distribution of prefix counts
 across ASNs it's quite reasonable  to conclude that the consumption of
 routing table slots is not primarly a property of the number of participants
 but rather in the hands of a smaller number of large participants many of
 whom are in this room.

Which, compounds the idea that routing slots are going to be more of an issue 
than allocation size.

-Randy

Re: will ISP peer with 2 local WAN routers?

[Randy Carpenter]

Time Warner installed a Juniper EX4200 as the CPE device for us, so we 
connected 2 routers and had two separate BGP sessions. They have us a /29 to 
accomplish it.


-Randy

On Aug 16, 2013, at 16:53, Justin Vocke justin.vo...@gmail.com wrote:

 The gotcha with that is then you need a switch in front of the routers. I'd 
 just setup a carrier on each router and run ibgp between.
 
 Sent from my iPhone
 
 On Aug 16, 2013, at 3:35 PM, Adam Greene maill...@webjogger.net wrote:
 
 Hi guys,
 
 
 
 I have a customer who peers via eBGP with Lightpath aka Cablevision (AS
 6128) and Level3 (AS 3356) and wants to do some dual-WAN router redundancy.
 
 
 
 I have heard that carriers will sometimes agree to set up a /29 WAN subnet
 for a customer and peer with (2) customer routers.
 
 
 
 The customer is delaying on providing me with the proper circuit ID 
 contact information to be able to call Lightpath and Level3 directly and
 find out if they will do this, so I thought of asking this list.
 
 
 
 Is anyone aware if Lightpath and Level3 will agree to something like this? 
 
 
 
 Thanks,
 
 Adam
 
 

Re: 80 km BiDi XFPs

[Randy Carpenter]

I'm going to guess that this is not going to meet the OP's request for an XFP, 
which would be 10GbE (and not an SFP).


thanks,
-Randy


- Original Message -
 http://www.fiberworks.eu/Webshop/Optical-transceivers/SFP-Bi-Di-/-GPON/Gbit-Ethernet-Bi-Di-1310/1550/SFP-BiDi--125-Gbps-GigE--DDM--SM--80km-Tx-Rx1310-1550nm--26dB--LC-SFP-GE-BX80D-35-p018066.aspx
 
 already in production for 2 links
 
 On 04/05/2013 05:50 PM, Jerimiah Cole wrote:
  On 04/02/2013 05:15 PM, Frank Bulk wrote:
  Is anyone aware of a reputable supplier of 80 km BiDi XFPs?  My regular
  supplier of generics doesn't have an option for us, but I would really
  like
  to avoid leasing additional fibers.
 
  I'm looking at a data sheet from Transition Networks that lists 80 km
  (24 dB) and longer.  I've used some of their SFPs and media converters
  without trouble, but not these in particular.
 
  http://www.transition.com/TransitionNetworks/Products2/Family.aspx?Name=TN-SFP-xxx-Simplex
 
 
 
 
 --
 Mihai
 
 
 
 

Time Warner Cable YouTube throttling

[Randy Carpenter]

We have recently been having some serious speed issues with YouTube on our home 
connections, which are all Time Warner Cable.
Some searching on forums and such revealed a work around:

Block 206.111.0.0/16 at the router.

This makes speeds go from ~1 Mb/s to the full connection speed (30 Mb/s in my 
case). It appears that TWC is forcing traffic to this netblock over a congested 
link, or otherwise throttling it.

Trying to communicate this to tech support results in the typical Derrr, what?

Does anyone at Time Warner care to comment on WTF?


thanks,
-Randy

Re: Time Warner Cable YouTube throttling

[Randy Carpenter]

- Original Message -
 On Wed, Mar 6, 2013 at 3:11 PM, Randy Carpenter
 rcar...@network1.net wrote:
 
  We have recently been having some serious speed issues with YouTube
  on our home connections, which are all Time Warner Cable.
  Some searching on forums and such revealed a work around:
 
  Block 206.111.0.0/16 at the router.
 
 
 this was reported elsewhere... it seems odd, since that's XO space,
 not Google and not TWC space. Would you care to engage in some
 troubleshooting to help everyone out? :)

I'll be happy to help troubleshoot in any way I can.

-Randy

Re: Issues with level3?

[Randy Carpenter]

- Original Message -
 On 1/15/13 9:31 AM, Bruce H McIntosh wrote:
  On Tue, 2013-01-15 at 17:23 +, Warren Bailey wrote:
  I still call a /24 a class c too.. :/ lol
  More efficient that way - class c uses fewer syllables than
  slash
  twenty four :-)
 
 You realize that class-c address space was only found within 192/8
 e.g.
 if you print it in hex, C000. so not only is it historically
 irrelevant but you're using it wrong anyway.

But, class B is not B000 and A is not A000, so is that actually true, 
or just a coincidence?

Class C was actually 192.0.0.0-223.255.255.255 (192.0.0.0/3)

-Randy

Re: OOB core router connectivity wish list

[Randy Carpenter]

My main requirements would be:

1. Something that is *not* network (ethernet or otherwise) (isn't that the 
point of OOB?)
2. Something that is standard across everything, and can be aggregated easily 
onto a console server or the like

I don't really see what is wrong with with keeping the serial port as the 
standard.

Things like servers and RAID cards and such are coming with BIOSes that are 
graphical and even require a mouse to use. What use is that when I need to get 
into the BIOS from a remote site that is completely down? 

Likewise OS vendors are increasingly dropping support for installing OSes via 
serial port (RHEL, VMWare, etc.)

At leaset with RHEL, you can make your own boot image that gets rid of the 
asinine splash screen (which is the only thing that causes the requirement for 
a full VGA console)

It might be nice to have a management-only port of some sort to do more 
advanced things that serial cannot do, but the serial port is ubiquitous 
already, and I don't see any reason to remove it as the very low-level access 
method.

thanks,
-Randy


- Original Message -
 
 I have together with some other people, collected a wish list for OOB
 support, mainly aimed for core routers. This is to replace the legacy
 serial port usually present on core routing equipment and to
 move/collapse
 all its functionality to an ethernet only port. Some equipment
 already
 have an mgmt ethernet port, but usually this can't do everything,
 meaning today one has to have OOB ethernet *and* OOB serial which
 just
 brings more pain than before.
 
 I would like to post it here to solicit feedback on it. Feel free to
 use
 it to tell your vendor account teams you want this if you feel it
 useful.
 I've already sent it to one vendor.
 
 http://swm.pp.se/oob.txt
 
 Priorities:
 
 [P1] - must have, otherwise not useful
 [P2] - would be very useful, to most operators
 [P3] - nice to have, useful to some
 
 From the OOB ethernet port it should be possible to:
 
 [P1]: Powercycle the RP, switchfabrics and linecards (hard, as in
 they
 might be totally dead and I want to cut power to it via the back
 plane.
 Also useful for FPGA upgrades).
 
 [P1]: Connect to manage the RP(s) and linecards (equivalent of todays
 connect on GSR and ASR9k or connecting to RP serial port).
 
 [P2]: It should be possible to connect to the OOB from the RP as well
 (to
 diagnose OOB connectivity problems).
 
 [P2]: Upload software to the RP or otherwise make information
 available to
 the RP (for later re-install/turboboot for example). RP should have
 access
 to local storage on the OOB device to transfer configuration or
 software
 from the OOB device to the RP).
 
 [P2]: Read logs and other state of the components in the chassis
 (displays
 and LEDs) plus what kind of card is in each slot.
 
 [P1]: The OOB port should support (configurable), telnet, ssh and
 optionally [P3] https login (with a java applet or equivalent to give
 CLI
 access in the browser) with ACLs to limit wherefrom things can be
 done.
 OOB should support ssh key based logins to admin account.
 
 [P1]: The IP address of the OOB port should be set via
 DHCP/DHCPv6/SLAAC
 and should have both IPv4 and IPv6 support. If not both, then IPv6
 only.
 
 [P1]: It should be possible to transfer data using tftp, ftp and scp
 (ftp
 client on the OOB device, scp being used to transfer data *to* the
 device
 (OOB being scp server).
 
 [P2]: OOB device should have tacacs and radius and [P1] local
 user/password database support for authentication. [P3] OOB should
 support
 ssh-key based authentication.
 
 [P3] Chassis should have a character display or LEDs with
 configurable
 blink pattern from OOB, to aid remote hands identification.
 
 [P3] OOB should have two USB ports, one to use to insert storage to
 transfer files to/from device. The other should be USB port that
 presents
 itself as ether USB serial port, or USB ethernet port, where the OOB
 device would have built in DHCP/DHCPv6 server to give IPv4v6 access
 to a
 laptop connected to the OOB so the onsite engineer can then use
 ssh/telnet
 to administrate the OOB. Optionally this port could be ethernet port
 (compare todays CON and AUX ports).
 
 [P2] OOB should have procedure to factory default its configuration,
 perhaps physical button that can be pressed and held for duration of
 time.
 The fact that this is done should be logged to the RP.
 
 [P3] OOB should have possibility to show power supply and
 environmental
 state.
 
 [P3] The factory default configuration should not include an empty or
 obvious login password.  The factory-default login password should be
 the
 MAC address (without punctuation) of the OOB ethernet interface,
 which
 should be printed on the chassis next to the OOBE port.
 
 
 --
 Mikael Abrahamssonemail: swm...@swm.pp.se
 
 
 

Re: OOB core router connectivity wish list

[Randy Carpenter]

- Original Message -
 Once upon a time, Randy Carpenter rcar...@network1.net said:
  Likewise OS vendors are increasingly dropping support for
  installing OSes via serial port (RHEL, VMWare, etc.)
  
  At leaset with RHEL, you can make your own boot image that gets rid
  of the asinine splash screen (which is the only thing that causes
  the requirement for a full VGA console)
 
 RHEL installs with a serial console just fine.  You also don't have
 to
 make your own boot image to get a non-graphical boot.

Probably a bit off topic for this thread, but...

If I boot the default install disc/image on any of my servers (mostly 
Supermicro), it hangs at a blank screen when isolinux loads. If you get rid of 
the splash screen, it works fine. This has been an issue since RHEL4, I think.

Maybe other server manufacturers handle the video a little differently, and are 
able to get past the splash screen.

-Randy

Re: OOB core router connectivity wish list

[Randy Carpenter]

- Original Message -
 On Wed, 9 Jan 2013, Randy Carpenter wrote:
  My main requirements would be:
 
  1. Something that is *not* network (ethernet or otherwise) (isn't
  that the point of OOB?)
 
 I don't understand this at all. Why can't an OOB network be ethernet
 based towards the equipment needing management?

How do I connect to it from many miles away when the network is down? I have 
connected to a misbehaving border device at a remote network via dial-up 
before, and was able to get it back up and running. I would not have been able 
to do that if the only options were ethernet or ethernet.

  2. Something that is standard across everything, and can be
  aggregated
  easily onto a console server or the like
 
 Yes, ethernet is the proposed management standard interface.
 
  I don't really see what is wrong with with keeping the serial port
  as the standard.
 
 Because it's slow and can't be multiplexed, 

agreed. Although, I generally don't care if it is slow, as the only need is to 
get the real network connected features back up and running.

 and it's expensive, only
 does
 short distance (20 meters or so), 

I completely disagree. The ability for serial to go over POTS makes it 
ridiculously cheap compared to building a reliable ethernet connection over 
hundreds or thousands of miles.

 uses different cabling, requires
 separate planning etc. There are lot of reasons to drop serial port
 support.

The separate part is what makes it useful. The only reason you should need to 
access the serial port is because the network is not functioning. If you move 
the last resort access to be network, how do you access it when you have 
network issues?

 An ethernet port is generally a lot cheaper compared to a serial
 port.
 Your OOB network would consist of a switch or router with ethernet
 towards
 the equipment needing management.

But having a console-serial is significantly less complex than 
console-IP_Stack-ethernet. So many more things to go wrong. I've never had a 
device that had a faulty serial port. I have seen numerous faulty or 
misbehaving network ports.

I like the current trend of vendors like Juniper. Dedicated management 
ethernet, *and* serial console port. Best of both worlds.

-Randy

Re: Is a /48 still the smallest thing you can route independently?

[Randy Carpenter]

 --- jrh...@netconsonance.com wrote:
 From: Jo Rhett jrh...@netconsonance.com
 
 I've finally convinced $DAYJOB to deploy IPv6.  Justification for the
 IP space is easy, however the truth is that a /64 is more than we
 need in all locations. However the last I heard was that you can't
 effectively announce anything smaller than a /48.  Is this still
 true?
 
 Is this likely to change in the immediate future, or do I need to ask
 for a /44?
 
 
 
 A /48 is 65536 /64s and a /44 is 16x65536 /64s.  If you
 only need one subnet (1 subnet = 1 /64), why would you
 try to get 16x65536 subnets, rather than the 65536 you
 have in the /48?
 
 scott


He said it was for multiple sites. Per ARIN policy, the next biggest chunk from 
a /48 is a /44, so a /44 is what should be asked for. It is perfectly 
justifiable if you have more than 1 site.

I would not expect anything smaller than a /48 to be allowed in BGP.

A bonus would be that a /44 currently costs the same as a /48 for an enduser, 
so there really is no drawback from getting the /44, and having enough space to 
not have to worry about it in the future.

-Randy

Re: Is a /48 still the smallest thing you can route independently?

[Randy Carpenter]

- Original Message -
 
 
 On Oct 11, 2012, at 2:28 PM, Randy Carpenter wrote:
 
 
 so there really is no drawback from getting the /44, and having
 enough space to not have to worry about it in the future.
 
 
 It's only a worry if you can only route /48s, which was my question.
 And seriously, we're going to be banging around in the emptiness as
 compared to our IPv4 allocations. :)

You can route /48 or shorter (larger)

How many sites do you have? If less than 192, /44 is perfect, unless some of 
those sites require more than a /48. Then, it gets more complicated :-)

-Randy

Re: Is a /48 still the smallest thing you can route independently?

[Randy Carpenter]

- Original Message -
 On Thu, Oct 11, 2012 at 6:06 PM, Randy Carpenter
 rcar...@network1.net wrote:
  How many sites do you have? If less than 192, /44 is
  perfect, unless some of those sites require more than
  a /48. Then, it gets more complicated :-)
 
 We're having a general math breakdown today. First Jeroen wants to
 fit
 5 /48's in a /47 and now you want to fit 192 /48's in a /44.
 
 48-44=4. 2^4=16.
 
 -Bill

Yep... I don't know why, but I was thinking /40.

So,

1 site = /48
2-12 sites = /44
13-192 sites = /40, and so on.

NRPM 6.5.8.2 for details.

/40 bumps you into the next price category, but it is a 1-time expense for 
endusers.

-Randy

Re: RFC becomes Visio

[Randy Carpenter]

I've seen requests for a drawing of some sort, but never specifically and 
exclusively visio.
If they insist on visio, I would send them a LART (at high velocity) instead.

-Randy


- Original Message -
 Just got told by a Lightpath person that in order to do BGP on a
 customer gig circuit to them they would need a visio diagram (of what
 I
 dont know).
 
 Has anybody else seen this brain damage?
 
 Joe
 
 
 

Re: RFC becomes Visio

[Randy Carpenter]

Just make sure to name the scanned file VisioDi~1_vsd.png, and maybe they won't 
notice.


-Randy


- Original Message -
 As a person who often draws out + scans diagrams, I support this
 message.
 
 On 09/28/2012 01:18 PM, Seth Mattinen wrote:
  Hand draw two squares, label them our AS and your AS with a
  line
  between them labeled GigE. Bonus points for pencil.
 
  ~Seth
 
 
 
 

Re: Verizon IPv6 LTE

[Randy Carpenter]

Safari is definitely preferring IPv4.

In a happier note, if you tether a device via hotspot on an IOS6 iPad, the 
clients get native IPv6. Strangely, they get addresses out of the same /64 as 
the iPad's LTE interface. Anyone know how that is working? I would have thought 
they would use prefix-delegation, and there would be a separate routed /64.

thanks,
-Randy


- Original Message -
 On 9/20/12 6:47 PM, TJ wrote:
  Did Apple use their version of Happy Eyeballs on the iPads?
  ISTR they cache certain timeouts, so if IPv6 was failing before it
  may take
  awhile for it to become preferred again.
  
 
 
 It seems you may be correct.
 
 ~Seth
 
 
 

Re: IPv6 Toolkit v1.2: Latest snapshot, and git repo

[Randy Carpenter]

Appears to compile file on Mac OS X 10.7. The resulting programs run, but I 
have not tried any real testing with actual data.


thanks,
-Randy


- Original Message -
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Folks,
 
 I've posted a snapshot (tarball) of my working copy of the IPv6
 toolkit. The tarball is available at:
 http://www.si6networks.com/research/ipv6-toolkit-v1.2.tar.gz
 
 Additionally, I've created a git repository for the toolkit, such
 that
 collaboration is improved. The git repo is available at:
 https://github.com/fgont/ipv6-toolkit.git
 
 If you have access to a Mac OS box, please try to compile the tools,
 and let me know if you find any errors (or let me know if they
 compiled cleanly). If you can also run the tools according to some of
 the examples in the manuals (and report any problems), that would be
 great, too.
 
 P.S.: If you've sent patches and your patches have not yet been
 applied, most likely it just means that I'm catching-up with them
 (feel free to resend!).
 
 Thanks!
 
 Best regards,--
 Fernando Gont
 e-mail: ferna...@gont.com.ar || fg...@si6networks.com
 PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
 
 
 
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)
 
 iQEcBAEBAgAGBQJQAtn3AAoJEJbuqe/Qdv/xYIgH+wTQXJ3iNEnGnA0cMazS32py
 3HfTdcMaEphnfF2a15dq1h/uqF05g3t9KqU744A1XmMtDlChvQ2I77uj2amqaeKi
 dED6e/NTuVAxTAI0ZTPIEn7BkDgtqvhuaoth+E4SX73lJC9eJR7e3T3BAtbESZaQ
 Sp67lvtgYmqogDc0IQALGNucyhHmacfUBocVLVgmVPn8BwdFxHI80W+Vc6TnKfjm
 Yc9ijgUPLTu0hOGD4bpOeQ2V3Dzw9PW17PyJlPr3TzWLzb8g64/zZROtHjXl/V4s
 0JNAZVrHNDvA7kfEujzsoLcnQLCfq3+jzecvXcGwgsYMDXRBL8Lv628OAhrVglY=
 =Z3+1
 -END PGP SIGNATURE-
 
 
 

Re: TW in ohio

[Randy Carpenter]

Nope.

I signed up for the beta a long time ago, and have never heard anything about 
IPv6 on the residential network. My company is one of the first (if not *the* 
first) direct connect commercial customers that got IPv6 connectivity in Ohio. 
I only see a few other ASNs that are directly connected to Time Warner locally 
via IPv6.

I wonder if they are having some problems with their residential rollout. I 
signed up for their RoadRunner Extreme when it was first advertised more than 
a year ago. They happily installed the proper DOCSIS 3.0 modem, and I was up 
and running. When I called about my upload speed being too low, I found out 
after several weeks and talking to numerous people that they have not yet 
upgraded their head end from DOCSIS 1.1. They subsequently took down all of the 
billboards and banners that advertised the Extreme packages. I still pay the 
higher rate for mine, only because I get much faster download than their 
standard service.

I am guessing that they will roll out IPv6 only after the DOCSIS 3.0 upgrade is 
complete.


-Randy


- Original Message -
 Anyone here using timewarrner residential able to use IPv6 natively
 during
 world IPv6 day?  I have the equipment to support it but never saw any
 ipv6
 address being assigned to my firewall.
 
 Brian Henson
 
 

Re: Current IPv6 state of US Mobile Phone Carriers

[Randy Carpenter]

Looks like some devices have it enabled, and some do not.

Does anyone have hotspot enabled? I am curious as to if IPv6 is being done via 
the hotspot, and how they are handling the prefix delegation.


thanks,
-Randy



- Original Message -
 
 
 http://i.imgur.com/c0Bmz.jpg
 
 From a few minutes ago...
 On May 23, 2012 2:58 PM, Frank Bulk - iName.com  frnk...@iname.com
  wrote:
 
 
 Here's a screenshot from 15 months ago:
 http://www.fix6.net/archives/2011/02/21/ipv6-live-on-verizons-lte-network/
 
 Frank
 
 -Original Message-
 From: Randy Carpenter [mailto: rcar...@network1.net ]
 Sent: Tuesday, May 22, 2012 9:07 PM
 To: PC
 Cc: nanog@nanog.org
 Subject: Re: Current IPv6 state of US Mobile Phone Carriers
 
 
 Not only does Verizon *not* have IPv6 on their LTE network, they also
 do *not*
 have IPv4, except for double-NATed rfc1918 crap that changes your IP
 address
 every couple minutes. The only way to get a stable connection is to
 pay them
 $500 to get a static public IP address.
 
 thanks,
 -Randy
 
 
 - Original Message -
  IPV6 is present, to my knowledge, on all devices on the Verizon
  IPV6
  LTE network. I noticed its using it to communicate to Google for
  many
  of it's services when I ran a netstat. I believe they mandated
  support for it from any certified device.
  
  Unfortunately, it's still firewalled.
  
  
  On Tue, May 22, 2012 at 5:40 PM, Paul Graydon
   p...@paulgraydon.co.uk  wrote:
   On 05/22/2012 01:21 PM, Cameron Byrne wrote:
   
   On May 22, 2012 4:00 PM, Paul Porter paul.por...@gree.co.jp 
   wrote:
   
   Hi NANOG,
   
   I'm looking for some information on the four largest US mobile
   phone
   carriers and the current state of their IPv6 infrastructure.
   Specifically,
   we are trying to figure out:
   
   1. How much of the carrier core and edge for ATT, Verizon.
   T-Mobile,
   and
   Sprint are on IPv6 now?
   
   Hi,
   
   T-Mobile USA has native ipv6 to all subscribers in all of it's
   coverage
   area. But, less than 1% of subscribers use IPv6 because they do
   not have
   an
   IPv6 capable phone. The Nexus S and Galaxy Nexus work well.
   
   This device challenge will improve in time. Samsung is doing a
   good job
   of
   bringing IPv6 to Android devices. More info here
   
   That's interesting. I have a Galaxy Nexus on T-Mobile USA and it
   doesn't
   get an IPv6 address, only IPv4. Works fine with IPv6 over my
   wireless
   network at home. Doesn't seem to be anything obvious in the
   settings to
   enable or disable that.
   
   Paul
   
  
  
  
 
 
 
 
 
 

Re: Current IPv6 state of US Mobile Phone Carriers

[Randy Carpenter]

Not only does Verizon *not* have IPv6 on their LTE network, they also do *not* 
have IPv4, except for double-NATed rfc1918 crap that changes your IP address 
every couple minutes. The only way to get a stable connection is to pay them 
$500 to get a static public IP address.

thanks,
-Randy


- Original Message -
 IPV6 is present, to my knowledge, on all devices on the Verizon IPV6
 LTE network.  I noticed its using it to communicate to Google for
 many
 of it's services when I ran a netstat.  I believe they mandated
 support for it from any certified device.

 Unfortunately, it's still firewalled.


 On Tue, May 22, 2012 at 5:40 PM, Paul Graydon
 p...@paulgraydon.co.uk wrote:
  On 05/22/2012 01:21 PM, Cameron Byrne wrote:
 
  On May 22, 2012 4:00 PM, Paul Porterpaul.por...@gree.co.jp
   wrote:
 
  Hi NANOG,
 
  I'm looking for some information on the four largest US mobile
  phone
  carriers and the current state of their IPv6 infrastructure.
  Specifically,
  we are trying to figure out:
 
  1.  How much of the carrier core and edge for ATT, Verizon.
  T-Mobile,
  and
  Sprint are on IPv6 now?
 
  Hi,
 
  T-Mobile USA has native ipv6 to all subscribers in all of it's
  coverage
  area. But, less than 1% of subscribers use IPv6 because they do
  not have
  an
  IPv6 capable phone. The Nexus S and Galaxy Nexus work well.
 
  This device challenge will improve in time.  Samsung is doing a
  good job
  of
  bringing IPv6 to Android devices. More info here
 
  That's interesting.  I have a Galaxy Nexus on T-Mobile USA and it
  doesn't
  get an IPv6 address, only IPv4.  Works fine with IPv6 over my
  wireless
  network at home.  Doesn't seem to be anything obvious in the
  settings to
  enable or disable that.
 
  Paul
 

Re: Current IPv6 state of US Mobile Phone Carriers

[Randy Carpenter]

I suppose they are selectively letting certain devices in some areas. I get 
der duh, what? when I ask about it.

It certainly does not work on the iPad 3 in Ohio. Not only that, but I can't 
even pay them to give me a stable IPv4 address, because if you get a static IP, 
it disables the hotspot functionality. Head--Wall.

thanks,
-Randy

- Original Message -
 On Tue, May 22, 2012 at 10:07 PM, Randy Carpenter
 rcar...@network1.net wrote:
 
  Not only does Verizon *not* have IPv6 on their LTE network, they
  also do *not* have IPv4, except for double-NATed rfc1918 crap that
  changes your IP address every couple minutes. The only way to get
  a stable connection is to pay them $500 to get a static public IP
  address.
 
 
 wierd, I could swear someone in my office with a galaxy-nexus-on-vzw
 was able to browse some ipv6-only sites.
 
 

Re: Current IPv6 state of US Mobile Phone Carriers

[Randy Carpenter]

- Original Message -
 On Tue, May 22, 2012 at 10:18 PM, Randy Carpenter
 rcar...@network1.net wrote:
  I suppose they are selectively letting certain devices in some
  areas. I get der duh, what? when I ask about it.
 
 
 uhm... you asked someone at their kiosks/stores about ipvanything??
 you are a very, very brave man.

No... the Business technical support via telephone. They knew what I was 
talking about, but no idea about what VZW's plans are for it.

  It certainly does not work on the iPad 3 in Ohio. Not only that,
  but I can't even pay them to give me a stable IPv4 address,
  because if you get a static IP, it disables the hotspot
  functionality. Head--Wall.
 
 
 good times!! mobile carriers live in what seems like a very different
 world from the one the rest of the internet lives in :(

Tell me about it. I would settle for a stable IPv4 address (dynamic is fine, 
but a lease time of something closer to an hour, rather than 2 minutes)

-Randy

Re: Juniper MX expert?

[Randy Carpenter]

Thanks everyone for all the responses. They were extremely helpful.

-Randy


- Original Message -
 
 Any Juniper MX experts out there want to do some quick consulting for
 me (not for free)?
 
 I am working on implementing a couple of MX5 routers in a service
 provider setting, and have run into some issues. I am pretty
 proficient at the SRX and EX lines, but not as much with the MX. As
 the particulars of the issues go a little deeper than I feel
 comfortable asking for free help for, I will leave out the details
 on the list.
 
 Please contact me off list if you are willing and able to give me a
 hand.
 
 thanks,
 -Randy

Juniper MX expert?

[Randy Carpenter]

Any Juniper MX experts out there want to do some quick consulting for me (not 
for free)?

I am working on implementing a couple of MX5 routers in a service provider 
setting, and have run into some issues. I am pretty proficient at the SRX and 
EX lines, but not as much with the MX. As the particulars of the issues go a 
little deeper than I feel comfortable asking for free help for, I will leave 
out the details on the list.

Please contact me off list if you are willing and able to give me a hand.

thanks,
-Randy

Time Warner Cable issues in Ohio ?

[Randy Carpenter]

We're seeing some strange issues with our fiber connection to TWC in Ohio. 
Intermittent packet loss to/from some IPs.

It gets as specific as from a certain IP outside our network, packets to 
a.b.c.10 are fine, but pings to a.b.c.50 (same subnet of same netblock) lose 
~75% of the packets.

Likewise, from one of our IPs, connections are fine to a particular remote 
host, but not to another host on the same network.

Connections to/from some other IPs (and some whole networks) are totally fine.

It almost seems that some piece of gear somewhere is barfing on packets that 
have a particular set of bits in the source and/or destination address.

We have manually failed over to a backup connection, and are 100% fine now.

I just want to see if anyone has seen anything similar, or has any info. I am 
on hold now waiting for someone at TWC.

thanks,
-Randy

Re: Reliable Cloud host ?

[Randy Carpenter]

 Pardon the weird question:
 
 Is the DNS service authoritative or recursive?  If auth, you can
 solve this a few ways, either by giving the DNS name people point to
 multiple  (and A) records pointing at a diverse set of
 instances.

Authoritative. But, also not the only thing that we are running that needs some 
geographic and route diversity.

 DNS is designed to work around a host being down.  Same
 goes for MX and several other services.  While it may make the
 service slightly slower, it's certainly not the end of the world.

Oh, how I wish this were true in practice. If I had a dollar for every time we 
had serious issues because one of a few authoritative DNS servers was not 
responding... OK, I wouldn't be rich, but this happens all the time. Caching 
servers out on the net get a non-answer because the server they chose to ask 
was down, and it caches that. They shouldn't do that, but they do, and there's 
nothing that can be done about it.

-Randy

Reliable Cloud host ?

[Randy Carpenter]

Does anyone have any recommendation for a reliable cloud host?

We require 1 or 2 very small virtual hosts to host some remote services to 
serve as backup to our main datacenter. One of these services is a DNS server, 
so it is important that it is up all the time.

We have been using Rackspace Cloud Servers. We just realized that they have 
absolutely no redundancy or failover after experiencing a outage that lasted 
more than 6 hours yesterday. I am appalled that they would offer something 
called cloud without having any failover at all.

Basic requirements:

1. Full redundancy with instant failover to other hypervisor hosts upon 
hardware failure (I thought this was a given!)
2. Actual support (with a phone number I can call)
3. reasonable pricing (No, $800/month is not reasonable when I need a tiny 
256MB RAM Server with 1GB/mo of data transfers)

thanks,
-Randy

Re: Reliable Cloud host ?

[Randy Carpenter]

- Original Message -
 
 On Feb 26, 2012, at 4:56 PM, Randy Carpenter wrote:
  We have been using Rackspace Cloud Servers. We just realized that
  they have absolutely no redundancy or failover after experiencing
  a outage that lasted more than 6 hours yesterday. I am appalled
  that they would offer something called cloud without having any
  failover at all.
  
  Basic requirements:
  
  1. Full redundancy with instant failover to other hypervisor hosts
  upon hardware failure (I thought this was a given!)
 
 This is actually a much harder problem to solve than it sounds, and
 gets progressively harder depending on what you mean by failover.
 
 At the very least, having two physical hosts capable of running your
 VM requires that your VM be stored on some kind of SAN (usually
 iSCSI based) storage system. Otherwise, two hosts have no way of
 accessing your VM's data if one were to die. This makes things an
 order of magnitude or higher more expensive.

This does not have to be true at all.  Even having a fully fault-tolerant SAN 
in addition to spare servers should not cost much more than having separate 
RAID arrays inside each of the server, when you are talking about 1,000s of 
server (which Rackspace certainly has)

 But then all you've really done is moved your single point of failure
 to the SAN. Small SANs aren't economical, so you end up having tons
 of customers on one SAN. If it dies tons of VMs are suddenly down.
 So you now need a redundant SAN capable of live-mirroring everyone's
 data. These aren't cheap either, and add a lot of complexity to
 things. (How to handle failover if it died mid-write, who has the
 most recent data after a total blackout, etc)

NetApp. HA heads. Done. Add a DR site with replication, and you can survive a 
site failure, and be back up and running in less than an hour. I would think 
that the big datacenter guys already have this type of thing set up.

 And this is really just saying If hardware fails, i want my VM to
 reboot on another host. If what you're defining high availability
 to mean even if a physical host fails, i don't want a second of
 downtime, my VM can't reboot you want something like VMware's ESXi
 High Availability modules where your VM is actually running on two
 hosts at once, running in lock-step with each other so if one fails
 the other takes over transparently. Licenses for this are
 ridiculously expensive, and requires some reasonably complex
 networking and storage systems.

I don't need that kind of HA, and understand that it is not going to be 
available. 15 minutes of downtime is fine. 6 hours is completely unacceptable, 
and it false advertising to say you have a Cloud service, and then have the 
realization that you could have *indefinite* downtime.

 And I still haven't touched on having to make sure both physical
 hosts capable of running your VM are on totally independent
 switches/power/etc, the SAN has multiple interfaces so it's not all
 going through one switch, etc.

That is all just basic datacenter design. I have that level of redundancy with 
my extremely small datacenter. I only have 2 hypervisor hosts running around 12 
VMs.

 I also haven't run into anyone deploying a
 high-availability/redundant system where they haven't accidentally
 ended up with a split-brain scenario (network isolation causes the
 backup node to think it's live, when the primary is still running).
 Carefully synchronizing things to prevent this is hard and fragile.

I've never had it. Not if you properly set up failover (look at STONITH)

 I'm not saying you can't have this feature, but it's not typical in
 reasonably priced cloud services, and nearly unheard-of to be
 something automatically used. Just moving your virtual machine from
 using local storage to ISCSI backed storage drastically increases
 disk latency and caps the whole physical host's disk speed to 1gbps

No it doesn't. Haven't you heard of multipath? Using 4 1Gb/s paths gives me 
about the same I/O as a local RAID array, with the added feature of failover if 
a link drops. 4 1Gb/s ports is ridiculously cheap. And, 10Gb is not nearly as 
expensive as it used to be.

 (not much deployment for 10GE adapters on the low-priced VM provider
 yet). Any provider who automatically provisions a virtual machine
 this way will get complaints that their servers are slow, which is
 true compared to someone selling VMs that use local storage. The
 running your VM on two hosts at once system has such a performance
 penalty, and costs so much in licensing, you really need to NEED it
 for it not to be a ridiculous waste of resources.

I don't follow what you mean by running the VM on two hosts. I just want my 
single virtual to be booted up on a spare hypervisor if there is a hypervisor 
failure. No license costs for that, and should not have any performance 
implications at all.

 Amazon comes sorta close to this, in that their storage is
 mostly-totally separate from the hosts running your

Re: Most energy efficient (home) setup

[Randy Carpenter]

I like the Juniper EX2200C switches. They are only 12-port, but have 2 SFPs. 
They are very low power, and have no fans.

However, I am still waiting (it has been several months) for them to send me 
the correct rack mount brackets (which are a separate purchase).


-Randy

--
| Randy Carpenter
| Vice President - IT Services
| Red Hat Certified Engineer
| First Network Group, Inc.
| (800)578-6381, Opt. 1


- Original Message -
 On Thursday, February 23, 2012 04:53:06 PM Joe Greco wrote:
  So, good group to ask, probably...  anyone have suggestions for a
  low-
  noise, low-power GigE switch in the 24-port range ... managed, with
  SFP?
  That doesn't require constant rebooting?
 
 I can't comment to the rebooting, but a couple of years ago I looked
 at the Allied-Telesis AT-9000-28SP, which is a smack steeply priced
 (~$1,500) but has flexible optics and is managed.  And at ~35 watts
 is the lowest powered managed gigabit switch I was able to find for
 our solar powered telescopes.  The grant that was going to fund that
 fell through, so I'm still running the 90W+ Catalyst 2900XL with two
 1000Base-X modules and 24 10/100 ports instead, but the AT unit
 looked pretty good as a pretty much direct replacement with extra
 bandwidth.
 
 
 

Re: How are you doing DHCPv6 ?

[Randy Carpenter]

I understand that MACs can be changed/spoofed. But that is the exception, not 
the rule.

That isn't the biggest issue, though. The biggest issue is how to correlate the 
MAC and the DUID. That is the only way to properly authenticate and account for 
users that have both v4 and v6 (which is everyone)

I don't care if their MAC changes, if that happens, they just need to 
reauthenticate. But, not having any way to know what their DUID is going to be, 
makes it impossible to also give them v6.


-Randy

- Original Message -
 You shouldn't assume a MAC isn't constant should read is, double
 negative failure.

 On Tue, Jan 24, 2012 at 8:49 AM, Ray Soucy r...@maine.edu wrote:
  You shouldn't assume a MAC isn't constant.  Our students spoof
  their
  MACs all the time (thinking it will save them from getting a DMCA
  notice).
 
  The RFC suggests that DUIDs are stored in non-volatile memory or
  that
  an algorithm be used that can consistently reproduce the DUID (and
  IAID) for a system in the absence of persistent storage.
 
  For fixed hardware devices, I suspect most would opt for the use of
  DUID-LL type, which essentially the MAC with a DUID preamble, and
  doesn't need to be stored in memory since it's based on a MAC that
  can
  not be changed.  It would be simple to create a DUID sticker at
  that
  point, even retroactively.  I think the idea that DUID is random
  and
  getting worked up that it's not written on the side of the device
  is a
  little more FUD than fact.
 
  There _are_ things we need to address to make DHCPv6 easier to roll
  out (mainly on the server side), but just making bogus nitpick
  attacks
  distracts from the real issues, IMHO.
 
 
 
 
  On Mon, Jan 23, 2012 at 6:12 PM, Randy Carpenter
  rcar...@network1.net wrote:
 
  Controlled by software = not constant.
 
  It is also not likely to be something that is knowable on a piece
  of electronic gear that is not a PC, nor will it be something
  that can be printed on the outside of the device, like most
  today.
 
  -Randy
 
 
  - Original Message -
  Yes, DUID and IAID should be persistent on systems.  If they are
  not
  then they are not following the RFC.
 
  Note that bad practices, though, can remove that persistence
  (e.g.
  deleting the DUID, or replicating the DUID on other systems).
 
  On Mon, Jan 23, 2012 at 5:56 PM, Karl Auer ka...@biplane.com.au
  wrote:
   On Mon, 2012-01-23 at 17:26 -0500, Randy Carpenter wrote:
   One major issue is that there is no way to associate a user's
   MAC
   (for
   IPv4) with their DUID. I haven't been able to find a way to
   account
   for this without making the user authenticate once for IPv4,
   and
   then
   again for IPv6. This is cumbersome to the user. Also, in the
   past
   there have been various reason why we want to pre-authenticate
   a
   client's MAC address (mostly for game consoles, and such,
   which
   have
   the MAC written on the outside of the machine). How can this
   be
   done
   with IPv6, which the DUID is not constant?
  
   Perhaps I misunderstand you (or the RFCs) but it seems to me
   that
   the
   DUID *is* constant. Reading section 9 of RFC 3315, it's pretty
   clear
   that a DUID is generated once, according to simple rules, and
   does
   not
   change once it has been generated. Barring intervention, of
   course.
  
   The problem is how to either find out ahead of time what DUID a
   client
   has OR how to impose a specific DUID on a client as part of
   provisioning
   it. Neither of those issues looks particularly intractable,
   especially
   if vendors start shipping with pre-configured DUIDs that are
   written on
   the boxes.
  
   What do you mean by authenticate? Do you mean something like
   802.1x?
  
   Regards, K.
  
   --
   ~~~
   Karl Auer (ka...@biplane.com.au)
   http://www.biplane.com.au/kauer
  
   GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE
   6017
   Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736
   F687
 
 
 
  --
  Ray Soucy
 
  Epic Communications Specialist
 
  Phone: +1 (207) 561-3526
 
  Networkmaine, a Unit of the University of Maine System
  http://www.networkmaine.net/
 
 
 
 
 
 
  --
  Ray Soucy
 
  Epic Communications Specialist
 
  Phone: +1 (207) 561-3526
 
  Networkmaine, a Unit of the University of Maine System
  http://www.networkmaine.net/



 --
 Ray Soucy

 Epic Communications Specialist

 Phone: +1 (207) 561-3526

 Networkmaine, a Unit of the University of Maine System
 http://www.networkmaine.net/

Re: How are you doing DHCPv6 ?

[Randy Carpenter]

We have also recently realized that the DUID is pretty much completely random, 
and there is no way to tie the MAC address to a client. This pretty much makes 
it impossible to manage a large customer base.

-Randy


- Original Message -
 This is a problem that would be nice for ISC to resolve (or another
 dependable FOSS implementation).
 
 For a while now (about 20 years I believe) we've used ISC DHCPd in a
 distributed model for our public IPv4 space.  In a nutshell, each
 DHCP
 server is configured only with static assignments, their log files
 are
 monitored (simple event correlator), and scripts are fired off to
 perform tasks like new assignments against a centralized database
 (MySQL).  The database is responsible for keeping track of address
 assignments centrally and is used to generate configuration files for
 DHCPd.  Dynamic updates are made using OMAPI.
 
 Unfortunately, the ISC DHCPv6 implementation makes replicating this
 impossible due to the lack of information logged.
 
 Another problem with the ISC DHCPv6 implementation is that it doesn't
 allow you to assign fixed-address information based on the DUID _and_
 IAID, which becomes a problem when a host has more than one active
 adapter.
 
 The only options are hacking the source code if you feel comfortable
 doing so, or waiting for ISC to make the change (if they ever plan
 to).
 
 For now, we get by with static assignments made in the database and
 no
 dynamic allocation via DHCPv6, which does OK in a dual-stack
 environment where IPv6 isn't considered necessary yet, but in the
 near
 future that will change.
 
 
 
 
 On Tue, Jan 17, 2012 at 5:04 PM, Randy Carpenter
 rcar...@network1.net wrote:
 
  I am wondering how people out there are using DHCPv6 to handle
  assigning prefixes to end users.
 
  We have a requirement for it to be a redundant server that is
  centrally located. DHCPv6 will be relayed from each customer
  access segment.
 
  We have been looking at using ISC dhcpd, as that is what we use for
  v4. However, it currently does not support any redundancy. It also
  does not do very much useful logging for DHCPv6 requests.
  Certainly not enough to keep track of users and devices.
 
  So, my questions are:
 
 
  How are you doing DHCPv6 with Prefix Delegation?
 
  What software are you using?
 
 
  When DHCPv6 with Prefix Delegation seems to be about the only way
  to deploy IPv6 to end users in a generic device-agnostic fashion,
  I am wondering why it is so difficult to find a working solution.
 
  thanks,
  -Randy
 
  --
  | Randy Carpenter
  | Vice President - IT Services
  | Red Hat Certified Engineer
  | First Network Group, Inc.
  | (800)578-6381, Opt. 1
  
 
 
 
 
 
 --
 Ray Soucy
 
 Epic Communications Specialist
 
 Phone: +1 (207) 561-3526
 
 Networkmaine, a Unit of the University of Maine System
 http://www.networkmaine.net/
 
 

Re: How are you doing DHCPv6 ?

[Randy Carpenter]

One major issue is that there is no way to associate a user's MAC (for IPv4) 
with their DUID. I haven't been able to find a way to account for this without 
making the user authenticate once for IPv4, and then again for IPv6. This is 
cumbersome to the user. Also, in the past there have been various reason why we 
want to pre-authenticate a client's MAC address (mostly for game consoles, and 
such, which have the MAC written on the outside of the machine). How can this 
be done with IPv6, which the DUID is not constant?

-Randy


- Original Message -
 On Mon, 2012-01-23 at 14:44 -0500, Randy Carpenter wrote:
  We have also recently realized that the DUID is pretty much
  completely
  random, and there is no way to tie the MAC address to a client.
  This
  pretty much makes it impossible to manage a large customer base.
 
 Not sure about that. The DUID is not random, at least not if it is
 being
 generated according to RFC 3315, which it probably should be.
 
 A DUID should be generated by a client[1] the first time it needs
 one,
 then be stored and never change[2]. All clients are supposed to
 provide
 a mechanism for setting the DUID to a specific value. Once generated,
 the DUID is indeed tied to the client unless something intervenes. In
 particular, a DUID is not affected by a change of NIC and is
 identical
 for all connected interfaces.
 
 I have to confess that we are not actually doing it, but the plan[3]
 is
 to capture new DUIDs as they happen and record the address-DUID
 mapping
 in our database. That's pretty much what we do now for boxes where
 the
 MAC address is not printed on the outside! But only where we need a
 reservation.
 
 The servers we use will always give the same address to the same
 DUID.
 Since we do not expect to use actual reserved addresses very much,
 this
 should be all we need. We are a) not really a large enterprise and b)
 not an ISP or carrier, so perhaps our needs are not the same as those
 you envisage.
 
 Vendors delivering pre-installed operating systems can set up
 vendor-assigned unique DUIDs and print them on the box, much as MAC
 addresses now are.
 
 It seems to me that DUIDs are better handles for clients than MAC
 addresses, but will require a change in the way people do things.
  
 Regards, K.
 
 [1] The algorithm for generating the DUID can include the MAC of any
 available interface, the time of day etc, but is supposed to be
 treated
 as opaque (RFC3315, section 9). Since RFC 3315 defines precisely how
 the
 DUIDs are to be generated, it should be very easy to extract the MAC
 address part, but given that the MAC address used may not actually
 exist
 on the device any more, I'm not sure that's very useful. It might be
 useful the first time a new DUID is seen, on the assumption that the
 NIC
 was not changed before the machine was first run. Then one could note
 the MAC address when provisioning the machine, and recognise the DUID
 of
 that machine when it pops up on the network. Mind you, the assumption
 is
 not foolproof.
 
 [2] Obviously devices with no long-term storage (or no storage at al!
 -
 will use a different generation algorithm than ones that do have
 storage.
 
 [2] No battle plan survives contact with the enemy - Helmuth von
 Moltke the Elder.
 
 --
 ~~~
 Karl Auer (ka...@biplane.com.au)
 http://www.biplane.com.au/kauer
 
 GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
 
 
 
 

Re: How are you doing DHCPv6 ?

[Randy Carpenter]

Controlled by software = not constant.

It is also not likely to be something that is knowable on a piece of electronic 
gear that is not a PC, nor will it be something that can be printed on the 
outside of the device, like most today.

-Randy


- Original Message -
 Yes, DUID and IAID should be persistent on systems.  If they are not
 then they are not following the RFC.
 
 Note that bad practices, though, can remove that persistence (e.g.
 deleting the DUID, or replicating the DUID on other systems).
 
 On Mon, Jan 23, 2012 at 5:56 PM, Karl Auer ka...@biplane.com.au
 wrote:
  On Mon, 2012-01-23 at 17:26 -0500, Randy Carpenter wrote:
  One major issue is that there is no way to associate a user's MAC
  (for
  IPv4) with their DUID. I haven't been able to find a way to
  account
  for this without making the user authenticate once for IPv4, and
  then
  again for IPv6. This is cumbersome to the user. Also, in the past
  there have been various reason why we want to pre-authenticate a
  client's MAC address (mostly for game consoles, and such, which
  have
  the MAC written on the outside of the machine). How can this be
  done
  with IPv6, which the DUID is not constant?
 
  Perhaps I misunderstand you (or the RFCs) but it seems to me that
  the
  DUID *is* constant. Reading section 9 of RFC 3315, it's pretty
  clear
  that a DUID is generated once, according to simple rules, and does
  not
  change once it has been generated. Barring intervention, of course.
 
  The problem is how to either find out ahead of time what DUID a
  client
  has OR how to impose a specific DUID on a client as part of
  provisioning
  it. Neither of those issues looks particularly intractable,
  especially
  if vendors start shipping with pre-configured DUIDs that are
  written on
  the boxes.
 
  What do you mean by authenticate? Do you mean something like
  802.1x?
 
  Regards, K.
 
  --
  ~~~
  Karl Auer (ka...@biplane.com.au)
  http://www.biplane.com.au/kauer
 
  GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
  Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
 
 
 
 --
 Ray Soucy
 
 Epic Communications Specialist
 
 Phone: +1 (207) 561-3526
 
 Networkmaine, a Unit of the University of Maine System
 http://www.networkmaine.net/
 
 
 

Re: How are you doing DHCPv6 ?

[Randy Carpenter]

Several people have mentioned clustering software. Does any one have any 
examples of such a thing that supports v4 and v6?

We have always used the built in failover in ISC dhcpd, and it works nicely. I 
don't understand why they felt it would not be needed in v6.

-Randy

On Jan 21, 2012, at 12:31, Jimmy Hess mysi...@gmail.com wrote:

 On Sat, Jan 21, 2012 at 7:03 AM, Bjørn Mork bj...@mork.no wrote:
 Randy Carpenter rcar...@network1.net writes:
  
 Duplicate assignments are not a problem as long as you ensure that the
 client is the same.
 
 Duplicate assignments to different clients also won't be established if your
 standby server has access to an identical lease database  at the moment
 your clustering software determines that the primary server has failed,
 kills the primary, and places the secondary in service. 
 
 A sufficiently long lease duration should also be as good as a static lease, 
 in that case.
 Because all the important details are in the database.
 
 You don't have to have any coordination in the DHCP software;  you just in 
 some cases, need to exclude the DHCPD daemon from simultaneously being active 
 on multiple machines.
 
 
 --
 -JH

Re: How are you doing DHCPv6 ?

[Randy Carpenter]

- Original Message -
 
 On Tue, Jan 17, 2012 at 4:04 PM, Randy Carpenter 
 rcar...@network1.net  wrote:
 
 
 We have a requirement for it to be a redundant server that is
 centrally located. DHCPv6 will be relayed from each customer access
 segment.
 
 We have been looking at using ISC dhcpd, as that is what we use for
 v4. However, it currently does not support any redundancy.
 
 [snip]
 
 When you say you require redundant DHCPD, what do you mean by that?
 The DHCP protocol is mostly stateless, aside from offers made, which
 are stored persistently in a database.
 
 Therefore, you can cluster the DHCPD daemon, without modifications to
 the ISC DHCPD
 software.

DHCP is certainly not stateless, which is why there is a concept of leases, 
which are stored in a file. You can't have 2 servers answering for the same 
subnet without some sort of coordination, or you would have a potential for 
duplicate addresses being assigned.

 There is no shortage of cluster management software that is up to the
 task of keeping a service active on an active node, and keeping the
 service inactive on a standby (or failed) node.
 
 Achieving redundancy against DHCPD failure is mostly a design and
 configuration question,
 not a matter of finding a DHCPD implementation that has redundancy.
 
 
 If by redundancy you mean active/active pair of servers, for load
 balancing rather than failover, that implies DHCP servers with
 non-overlapping pools to assign from, and is generally a much more
 complicated objective to achieve with DHCP whether v4 or v6.

I mean for failover, not load balancing.

The other issue we are encountering with IPv6 is that ISC DHCPD does not log 
very much at all for DHCPv6.

Also, we have yet to find something reliable to identify a particular client. 
It looks the only thing that is sent is the link local address, which is 
randomized on windows machines. The MAC address does not appear to ever be 
sent. This makes it impossible to apply any policies based on client.

-Randy

Re: US DOJ victim letter

[Randy Carpenter]

Same here. No idea who the intended recipient organization is, as it was sent 
to our generic tech contact email address that is used for a bunch of ASes, 
ARIN accounts, domains, etc. There are pretty much no details in the message.

-Randy

- Original Message -
 AS2381 has also received them, we are no further along in this than
 you are.
 
 On 1/19/2012 2:59 PM, Jay Hennigan wrote:
  We have received three emails from the US Department of Justice
  Victim
  Notification System to our ARIN POC address advising us that we may
  be
  the victim of a crime.  Headers look legit.
 
  We have been frustrated in trying to follow the rabbit hole to get
  any
  useful information.  we've jumped through hoops to get passwords
  that
  don't work and attempted to navigate a voice-mail system that
  resembles
  the twisty maze of passages all different from an old text
  adventure
  game.
 
  This *seems* to be legit, and I would think that the end result is
  likely to be a list of IP addresses associated with infected hosts.
 
  Has anyone else received the email?  Is it legit?  If so has anyone
  successfully navigated the maze, and if so how?  Is it worth it?
 
  (And why don't they just send the list of infected IPs to the ARIN
  contact in the first place?)
 
  --
  Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
  Impulse Internet Service  -  http://www.impulse.net/
  Your local telephone and internet company - 805 884-6323 - WB6RDV
 
 
 
 

How are you doing DHCPv6 ?

[Randy Carpenter]

I am wondering how people out there are using DHCPv6 to handle assigning 
prefixes to end users.

We have a requirement for it to be a redundant server that is centrally 
located. DHCPv6 will be relayed from each customer access segment.

We have been looking at using ISC dhcpd, as that is what we use for v4. 
However, it currently does not support any redundancy. It also does not do very 
much useful logging for DHCPv6 requests. Certainly not enough to keep track of 
users and devices.

So, my questions are:


How are you doing DHCPv6 with Prefix Delegation?

What software are you using?


When DHCPv6 with Prefix Delegation seems to be about the only way to deploy 
IPv6 to end users in a generic device-agnostic fashion, I am wondering why it 
is so difficult to find a working solution.

thanks,
-Randy

--
| Randy Carpenter
| Vice President - IT Services
| Red Hat Certified Engineer
| First Network Group, Inc.
| (800)578-6381, Opt. 1

Re: How are you doing DHCPv6 ?

[Randy Carpenter]

 You might want to give this a read:
 
  http://www.ietf.org/id/draft-ietf-dhc-dhcpv6-redundancy-consider-02.txt

That doesn't really help us if we want to deploy before that draft becomes a 
standard.

Are there any DHCPv6 servers currently that actually function in a fashion that 
is suitable for service providers?

-Randy

 
  Original Message 
  From: Randy Carpenter rcar...@network1.net
  Sent: Tue, Jan 17, 2012 5:4 PM
  To: Nanog nanog@nanog.org
  CC:
  Subject: How are you doing DHCPv6 ?
 
 
 I am wondering how people out there are using DHCPv6 to handle
 assigning prefixes to end users.
 
 We have a requirement for it to be a redundant server that is
 centrally located. DHCPv6 will be relayed from each customer access
 segment.
 
 We have been looking at using ISC dhcpd, as that is what we use for
 v4. However, it currently does not support any redundancy. It also
 does not do very much useful logging for DHCPv6 requests. Certainly
 not enough to keep track of users and devices.
 
 So, my questions are:
 
 
 How are you doing DHCPv6 with Prefix Delegation?
 
 What software are you using?
 
 
 When DHCPv6 with Prefix Delegation seems to be about the only way to
 deploy IPv6 to end users in a generic device-agnostic fashion, I am
 wondering why it is so difficult to find a working solution.
 
 thanks,
 -Randy
 
 --
 | Randy Carpenter
 | Vice President - IT Services
 | Red Hat Certified Engineer
 | First Network Group, Inc.
 | (800)578-6381, Opt. 1
 
 
 
 
 

Re: How are you doing DHCPv6 ?

[Randy Carpenter]

- Original Message -
 
 On 1/17/12 6:37 PM, Daniel Roesen d...@cluenet.de wrote:
 
 On Tue, Jan 17, 2012 at 06:19:28PM -0500, Randy Carpenter wrote:
   You might want to give this a read:
   

 http://www.ietf.org/id/draft-ietf-dhc-dhcpv6-redundancy-consider-02.txt
  
  That doesn't really help us if we want to deploy before that draft
  becomes a standard.
 
 Well, it more or less just presents options (workarounds for missing
 proper HA sync).
 [jjmb] correct.  FWIW the IETF dhcwg is currently working on DHCPv6
 failover/redundancy.  See here for the requirements:
 
 http://tools.ietf.org/html/draft-mrugalski-dhc-dhcpv6-failover-requirements
 -00

I already had the two documents up and got them mixed up when I was reading 
through them. I'll have to go over the link from John in detail, and see if it 
gives us some ways to work around the limitations in our situation.

thanks,

-Randy

Re: Juniper - Cisco IPv6 BGP peering

[Randy Carpenter]

- Original Message -
 On Thu, Dec 8, 2011 at 11:53 AM, Randy Carpenter
 rcar...@network1.net wrote:
  Tried that. I agree with others that it is an NDP issue. NDP for
  the GUA is fine, but just not for the link local. Is there
  something that would block only link local by default?
 
  I should add that I have another uplink to a different provider
  that works perfectly. The other end is Juniper for that one.
 
 Just to begin with:
 0) Does your Juniper device have the neighbor cache entry for Cisco
 link-local address? What is the state of the entry?

Sometimes it does, sometimes I can't seem to get it.


 Can you get packet capture on both sides?

We have done this.
 
 1) is Cisco sending NS packets?

Yes.

 2) is your Juniper receiving them?

It does not appear to. Tracing v6 stuff on juniper seems to be hit or miss.

 3) is Juniper device sending anything back?

No. (because of #2)

 4) are those NA reaching Cisco?

No. (because of #2)

 Any switch on the path?

It is an L2 circuit that rides a couple of different pieces of gear before it 
lands at the other side.
 
 [lazy mode on] I'd also suggest:
  - debug ipv6 nd on cisco
  - checking for bugs for IOS and JunOS versions you are using

Juniper - Cisco IPv6 BGP peering

[Randy Carpenter]

Does anyone have any suggestions on setting up BGP peering between Juniper 
(SRX) and Cisco?

I successfully have cisco-cisco and juniper-juniper without problems.

When I am trying to peer to one of my upstreams (who has cisco) with my Juniper 
SRX, They are seeing the link-local address as the next-hop, but are unable to 
get an ND entry for it, and thus cannot forward traffic to me.


-Randy

--
| Randy Carpenter
| Vice President - IT Services
| Red Hat Certified Engineer
| First Network Group, Inc.
| (800)578-6381, Opt. 1

Re: Juniper - Cisco IPv6 BGP peering

[Randy Carpenter]

We are using global addresses, but on the Cisco side, it is seeing the 
Link-Local as the next-hop.


-Randy

--
| Randy Carpenter
| Vice President - IT Services
| Red Hat Certified Engineer
| First Network Group, Inc.
| (800)578-6381, Opt. 1


- Original Message -
  When I am trying to peer to one of my upstreams (who has cisco)
  with
  my Juniper SRX, They are seeing the link-local address as the
  next-hop
 
 use global v6 addresses
 
 

Re: Juniper - Cisco IPv6 BGP peering

[Randy Carpenter]

BGP is working fine, it is when they are trying to forward the packets back to 
me. They are seeing the Link-Local as the next-hop, which, for some reason, 
they cannot get to.


-Randy

--
| Randy Carpenter
| Vice President - IT Services
| Red Hat Certified Engineer
| First Network Group, Inc.
| (800)578-6381, Opt. 1


- Original Message -
 Randy Carpenter wrote:
  Does anyone have any suggestions on setting up BGP peering between
  Juniper (SRX) and Cisco?
 
  I successfully have cisco-cisco and juniper-juniper without
  problems.
 
  When I am trying to peer to one of my upstreams (who has cisco)
  with my Juniper SRX, They are seeing the link-local address as the
  next-hop, but are unable to get an ND entry for it, and thus
  cannot forward traffic to me.
 
 
 Any reasons against exchanging v6 prefixes over a v4 session?
 
 

Re: Juniper - Cisco IPv6 BGP peering

[Randy Carpenter]

Tried that. I agree with others that it is an NDP issue. NDP for the GUA is 
fine, but just not for the link local. Is there something that would block only 
link local by default?

I should add that I have another uplink to a different provider that works 
perfectly. The other end is Juniper for that one.

-Randy

On Dec 7, 2011, at 17:53, Peter Rubenstein peter...@gmail.com wrote:

 Try setting local-address in the bgp neighbor config on the Juniper side?
 
 --Peter
 
 On Dec 7, 2011, at 4:54 PM, Randy Carpenter rcar...@network1.net wrote:
 
 
 Does anyone have any suggestions on setting up BGP peering between Juniper 
 (SRX) and Cisco?
 
 I successfully have cisco-cisco and juniper-juniper without problems.
 
 When I am trying to peer to one of my upstreams (who has cisco) with my 
 Juniper SRX, They are seeing the link-local address as the next-hop, but are 
 unable to get an ND entry for it, and thus cannot forward traffic to me.
 
 
 -Randy
 
 --
 | Randy Carpenter
 | Vice President - IT Services
 | Red Hat Certified Engineer
 | First Network Group, Inc.
 | (800)578-6381, Opt. 1
 
 
 
 

Re: using IPv6 address block across multiple locations

[Randy Carpenter]

Not sure about RIPE, but under ARIN, you would qualify for a /44 (or larger if 
you have more than 12 sites), out of which you could announce the /48s 
independently and as an aggregate, as you wish to do.


-Randy


- Original Message -
 Hello,
 
 Please advice what is the best practice to use IPv6 address block
 across distributed locations.
 
 Recently we obtained our PI /48 from RIPE. The idea was to assign
 partial slices from this block to different locations (we have
 currently 3 offices in Europe and 2 in USA). All locations are
 interconnected with static VPNs. Each location is supposed to
 establish BGP session with local ISP. Partial prefix /56 + aggregate
 /48 (with long AS PATH) are to be announced by each office.
 
 The problem we ran across is that ISP in US does not wish to accept
 prefixes longer then /48 from us.
 Need your advice: is this normal to distribute /48 by /56 parts
 across
 locations or should we obtain separate /48 for each of them? Or maybe
 we need /32 that can be split into multiple /48? Anyway we are not
 ISP
 so /48 looks quite reasonable and sufficient for all our needs.
 
 Thank you.
 
 Dmitry Cherkasov