Re: Internet Exchanges supporting jumbo frames?

On 10/Mar/16 00:22, Tassos Chatzithomaoglou wrote: > I must be missing something very obvious here, because i cannot think of any > reason why an IXP shouldn't enable the maximum possible MTU on its > infrastructure to be available to its customers. Then it's clearly customers' > decision on

Re: Internet Exchanges supporting jumbo frames?

Niels Bakker wrote on 10/3/16 02:44: > * nanog@nanog.org (Kurt Kraut via NANOG) [Thu 10 Mar 2016, 00:59 CET]: >> I'm pretty confident there is no need for a specific MTU consensus and not >> all IXP participants are obligated to raise their interface MTU if the IXP >> starts allowing jumbo

RE: Facebook & Traceroute

> maybe their loadbalancer is a little wonky? (I don't see this in > traceroutes from a few places, but I also don't end up at IAD for > 'www.facebook.com' traceroutes... here's my last 4 hops though to the > dest-ip you had: > > .13.28.75) 0.597 ms ae0.dr08.ash2.tfbnw.net (31.13.26.235) 0.576

Re: Facebook & Traceroute

On 03/09/2016 10:53 PM, Sam Norris wrote: Why does Facebook spoof the source IP address of the hop before this server? They spoof the source IP address that is performing the traceroute. ... (31.13.28.207) 67.846 ms ae12.dr08.ash3.tfbnw.net (31.13.29.191) 68.629 ms 12 * * * 13 * * * 14

Re: Facebook & Traceroute

On Wed, Mar 9, 2016 at 10:53 PM, Sam Norris wrote: > Why does Facebook spoof the source IP address of the hop before this server? > They spoof the source IP address that is performing the traceroute. > > 66.220.156.68 > > --- > 7 FACEBOOK-IN.ear1.Atlanta2.Level3.net

Facebook & Traceroute

Why does Facebook spoof the source IP address of the hop before this server? They spoof the source IP address that is performing the traceroute. 66.220.156.68 --- 7 FACEBOOK-IN.ear1.Atlanta2.Level3.net (4.16.185.58) 51.736 ms 51.678 ms 52.075 ms 8 ae2.bb01.atl1.tfbnw.net (74.119.78.214)

Re: .pro whois registry down?

On 03/09/2016 04:54 PM, Mark Andrews wrote: Additionally we should be publishing where the whois server for the tld is in the DNS. whois applications could be looking for this then falling back to other methods. e.g. _whois._tcp.pro. srv 0 100 43 whois.afilias.net. If we want

Re: [tld-admin-poc] Fwd: Re: .pro whois registry down?

Worst comes to worst there's a python based whois client called pwhois that lets you dump whois data into json --srs > On 10-Mar-2016, at 6:50 AM, Royce Williams wrote: > > I'm not affiliated, but there are a couple of companies that normalize > whois data. It's a

Re: FW: [tld-admin-poc] Fwd: Re: .pro whois registry down?

On Wed, Mar 9, 2016 at 3:54 PM, Mark Andrews wrote: > > Additionally 'whois' is free form text. Whois doesn't include a > AI to workout what this free form text means so, no, there isn't a > actual referral for a whois application to use. I'm not affiliated, but there are a

Re: FW: [tld-admin-poc] Fwd: Re: .pro whois registry down?

Additionally 'whois' is free form text. Whois doesn't include a AI to workout what this free form text means so, no, there isn't a actual referral for a whois application to use. Additionally we should be publishing where the whois server for the tld is in the DNS. whois applications could be

Re: Internet Exchanges supporting jumbo frames?

* nanog@nanog.org (Kurt Kraut via NANOG) [Thu 10 Mar 2016, 00:59 CET]: I'm pretty confident there is no need for a specific MTU consensus and not all IXP participants are obligated to raise their interface MTU if the IXP starts allowing jumbo frames. You're wrong here. The IXP switch

Re: FW: [tld-admin-poc] Fwd: Re: .pro whois registry down?

Joseph, Thanks for the update. However the current state of things is not good ... My Ubuntu host tries to use whois.dotproregistry.net, which has no address records. FreeBSD by default uses pro.whois-servers.net, which resolves to whois.registrypro.pro (which has an A record), but never

Re: Internet Exchanges supporting jumbo frames?

Hello folks, First of all, thank you all for this amazing debate. So many important ideas were exposed here and I wish we keep going on this. I've seen many opposition to my proposal but I still remain on the side of jumbo frame adoption for IXP. I'm pretty confident there is no need for a

Re: .pro whois registry down?

Doug Barton wrote: > On 03/09/2016 01:24 PM, Bryan Holloway wrote: > > Anyone else noticing that the .pro TLD is failing for some things, and > > their WHOIS registry appears to be unavailable? > > The address records for whois.dotproregistry.net are missing. Well, it

Re: Internet Exchanges supporting jumbo frames?

I must be missing something very obvious here, because i cannot think of any reason why an IXP shouldn't enable the maximum possible MTU on its infrastructure to be available to its customers. Then it's clearly customers' decision on what MTU to use on their devices, as long as: * It fits

Re: Internet Exchanges supporting jumbo frames?

Saku Ytti wrote: > Member may puke L2 loop to IXP, you must have some channel to deal > with your customers. First, mac filters. Second, if someone l2 loops and it causes problems because of hardware failure on our side, we reserve the right to pull connectivity:

Re: Internet Exchanges supporting jumbo frames?

On 9/Mar/16 16:26, Kurt Kraut via NANOG wrote: > > Could anyone share with me Internet Exchanges you know that allow jumbo > frames (like https://www.gr-ix.gr/specs/ does) and how you notice benefit > from it? NAPAfrica in South Africa support jumbo frames: https://www.napafrica.net/

Re: Internet Exchanges supporting jumbo frames?

On 10 March 2016 at 00:01, Nick Hilliard wrote: > Other people would be fine with 1522 core because that suits both their > needs and equipment limitations. So what do you do? Go with 9100 > because it suits you, or 9000 because that's what lots of other people > use? Or 4470

Re: Internet Exchanges supporting jumbo frames?

Saku Ytti wrote: > I would go for 1500B edge, and 9100B core, but that's just me. Other people would be fine with 1522 core because that suits both their needs and equipment limitations. So what do you do? Go with 9100 because it suits you, or 9000 because that's what lots of other people use?

Re: .pro whois registry down?

On 03/09/2016 01:24 PM, Bryan Holloway wrote: Anyone else noticing that the .pro TLD is failing for some things, and their WHOIS registry appears to be unavailable? The delegation from the root to PRO, and the PRO name servers themselves, seem to be working. I appear to be able to

Re: Internet Exchanges supporting jumbo frames?

On 9 March 2016 at 22:56, Nick Hilliard wrote: > - hardware problems If we build everything on LCD, we'll have Internet where just HTTP/80 works on 576B. You can certainly find platform which has problems doing else. > - lack of interest among ixp participants outside

.pro whois registry down?

Anyone else noticing that the .pro TLD is failing for some things, and their WHOIS registry appears to be unavailable? I appear to be able to resolve, but whois times out, and we're getting reports that mail isn't going through for some folks with this TLD.

Re: Internet Exchanges supporting jumbo frames?

On 9 March 2016 at 22:28, Nick Hilliard wrote: > iirc, we had problems with a bunch of ios based platforms. It worked > fine on junos / xr platforms. I share your surprise that this could > even have caused a problem, but it did. This is very poor reason to kill it for

Re: Internet Exchanges supporting jumbo frames?

On Wed, 9 Mar 2016, Nick Hilliard wrote: Many IXPs have either looked at or attempted to build jumbo peering lans. You can see how well they worked out by looking at the number of successful deployments. The reason for this tiny number isn't due to lack of effort on the part of the ixp

Re: Internet Exchanges supporting jumbo frames?

Saku Ytti wrote: > It works and has worked 2 decades in real IXP. If you're referring to Netnod, this started out as a fddi platform with a native max frame size of 4470. Maintaining something which already exists is not nearly as difficult as starting something from scratch and trying to reach

Re: Internet Exchanges supporting jumbo frames?

Mikael Abrahamsson wrote: > On all platforms I've configured and connected to an IXP, they would all > be configured by setting max L2 MTU on the main interface, and then you > configure whatever needed IPv4 and IPv6 L3 MTU on the subinterface. iirc, we had problems with a bunch of ios based

Re: Internet Exchanges supporting jumbo frames?

On Wed, 9 Mar 2016, Nick Hilliard wrote: For example, many types of hardware don't allow you to specify a different MTU for different .1q tags on the same physical interface. What hardware types typically connected to an IXP would that be, where this would be a problem? On all platforms

Re: Internet Exchanges supporting jumbo frames?

On Wed, Mar 9, 2016 at 9:50 AM, Kurt Kraut via NANOG wrote: > Thank you for replying so quickly. I don't see why the consensus for an MTU > must be reached. IPv6 Path MTU Discovery would handle it by itself, > wouldn't it? If one participant supports 9k and another 4k, the

Re: Internet Exchanges supporting jumbo frames?

On 9 March 2016 at 21:46, Nick Hilliard wrote: > I've spent a good deal of time and effort trying to get a jumbo peering > vlan to work and it didn't work for the reasons that I've mentioned, and > others. It works and has worked 2 decades in real IXP. -- ++ytti, boy who

Re: Internet Exchanges supporting jumbo frames?

Saku Ytti wrote: > If customer does not react, put it on quarantine VLAN. This can be > automated too. Wrong MTU => open internal case, contact customers > email, no customer response in N days, quarantine VLAN. ... and then the customer will leave the service down because it the primary peering

Re: Internet Exchanges supporting jumbo frames?

Saku Ytti wrote: > > If customer does not react, put it on quarantine VLAN. This can be > automated too. Wrong MTU => open internal case, contact customers > email, no customer response in N days, quarantine VLAN. > > Even the most outrageous success stories in the world, majority of the > people

Re: Internet Exchanges supporting jumbo frames?

On 9 March 2016 at 20:59, Nick Hilliard wrote: > There is a critical difference between these two situations. In the case of > an arp sponge, the ixp operator has control of both the polling and the > workaround. In the case of mtu management they would only have control of

Re: Internet Exchanges supporting jumbo frames?

On 9 Mar 2016, at 18:29, Saku Ytti wrote: > It's not a novel idea, IXPs already do active polling, even ARP > sponges. In a competitive market, hopefully customers will choose the > IXP operator who knows how to ensure minimal pain for the customers. There is a critical difference

Re: remote serial console (IP to Serial)

For a long time I used an Equinox SST which was a PCI card and a plugboard of (daisy-chain-able up to 128) 16 x RJ-45 serial ports. It was handy in one machine room, usually a Cat-5 RJ-45 cable with a D-connector was all that was needed. Unfortunately the Linux driver seems to have disappeared

Re: remote serial console (IP to Serial)

If you're going to go that route, a PI is a much cheaper moboard to build on. Also consider the Pine64 (cheaper and more powerful than the PI) > On Mar 8, 2016, at 21:36, Doug McIntyre wrote: > >> On Tue, Mar 08, 2016 at 10:45:30AM -0900, Royce Williams wrote: >>> On Tue,

Re: Internet Exchanges supporting jumbo frames?

On 9 March 2016 at 20:25, Nick Hilliard wrote: > any ixp configuration which requires active polling to ensure correct > configuration is doomed to failure. You are completely overestimating > human nature if you believe that the IXP operator can make this work by > harassing

Re: Internet Exchanges supporting jumbo frames?

Saku Ytti wrote: > I'm suggesting IXP has active poller which detects customer MTU misconfigs. any ixp configuration which requires active polling to ensure correct configuration is doomed to failure. You are completely overestimating human nature if you believe that the IXP operator can make

Re: Internet Exchanges supporting jumbo frames?

On 9 March 2016 at 20:14, Nick Hilliard wrote: > you're recommending that routers at IXPs do inflight fragmentation? I'm suggesting IXP has active poller which detects customer MTU misconfigs. -- ++ytti

re: Cogent - Google - HE Fun

This doesn't surprise me. Cogent get's into Peering Chicken from time to time. Just like Cogent and HE still have no IPv6 peering. *Insert picture of cake here*. Can also confirm I'm not learning AS15169 routes via Cogent v6. Nick Olsen Network Operations (855) FLSPEED x106

Re: Internet Exchanges supporting jumbo frames?

Mikael Abrahamsson wrote: > I have many times ping:ed with 1 byte packets on a device that has > "ip mtu 9000" configured on it, so it sends out two fragments, one being > 9000, the other one around 1100 bytes, only to get back a stream of > fragments, none of them larger than 1500 bytes.

Re: remote serial console (IP to Serial)

I'd get something like a 1U ATOM server ($120 eBay) with small SSD ($18). Runup your favorite FOSS OS, and conserver. For more than the single real serialport, you can most likely fit a USB hub inside the case still, and hang a number of USB serial dongles off. We use Raspberry Pi 2s with

Re: Internet Exchanges supporting jumbo frames?

Saku Ytti wrote: > Poller in the IXP has too large MTU, it tries to send ping packets > with max_size+1, if they work, customer has too large MTU. Also it > tries to send max_size, if it does not work, customer has too small > MTU. As icing on top, it tries to send max_size+1 but fragments it to >

Re: AW: Cogent - Google - HE Fun

In other words, GOOG is playing peering chicken with Cogent for IPv6. I'm not surprised. I suggested it during talks with GOOG roughly 10 years ago...not saying I had any influence...I'm pretty sure I did not. :) GOOG wants Cogent to peer. Cogent wants GOOG to pay for transit (from them or

Re: Internet Exchanges supporting jumbo frames?

On Wed 2016-Mar-09 15:32:32 +0100, Grzegorz Janoszka wrote: On 09/03/2016 15:26, Kurt Kraut via NANOG wrote: Could anyone share with me Internet Exchanges you know that allow jumbo frames (like https://www.gr-ix.gr/specs/ does) and how you notice benefit from it?

Re: Internet Exchanges supporting jumbo frames?

On 3/9/16 7:58 AM, Mikael Abrahamsson wrote: > On Wed, 9 Mar 2016, Nick Hilliard wrote: > >> used. Some will want 9000, some 9200, others 4470 and some people > > I have a strong opinion for jumboframes=9180bytes (IPv4/IPv6 MTU), > partly because there are two standards referencing this size

Re: Internet Exchanges supporting jumbo frames?

On 9 March 2016 at 16:34, Job Snijders wrote: > > https://www.nanog.org/sites/default/files/wednesday.general.steenbergen.antijumbo.pdf IXP can verify if MTU is too large or too small with active poller. Poller in the IXP has too large MTU, it tries to send ping packets

Re: Internet Exchanges supporting jumbo frames?

On Wed, 9 Mar 2016, David Bass wrote: Could you do the same with a 1501 byte packet? I have many times ping:ed with 1 byte packets on a device that has "ip mtu 9000" configured on it, so it sends out two fragments, one being 9000, the other one around 1100 bytes, only to get back a

Re: Cogent - Google - HE Fun

http://mailman.nanog.org/pipermail/nanog/2016-February/084147.html - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com - Original Message - From: "Dennis Burgess" To: "North

AW: Cogent - Google - HE Fun

Hi, mail from Cogent: Dear Cogent Customer, Thank you for contacting Cogent Customer Support for information about the Google IPv6 addresses you are unable to reach. Google uses transit providers to announce their IPv4 routes to Cogent. At this time however, Google has chosen not to

Re: Internet Exchanges supporting jumbo frames?

Could you do the same with a 1501 byte packet? > On Mar 9, 2016, at 10:51 AM, Nick Hilliard wrote: > > Kurt Kraut wrote: >> Thank you for replying so quickly. I don't see why the consensus for an >> MTU must be reached. IPv6 Path MTU Discovery would handle it by itself, >>

Cogent - Google - HE Fun

I just noticed that I am NOT getting IPV6 Google prefixes though Cogent at all. I was told google pulled all of their peering with Cogent? If I bring up a SIT tunnel with HE, I get the prefixes but at horrible speed and latency .. anyone else? [DennisBurgessSignature]

Re: Internet Exchanges supporting jumbo frames?

On Wed, 9 Mar 2016, Nick Hilliard wrote: interface MTU configured to be 9000 bytes, the packet will be blackholed, not rejected with a PTB. That is only true if the router/host sets MRU=MTU. That is definitely not always the case.

Re: Internet Exchanges supporting jumbo frames?

On Wed, 9 Mar 2016, Nick Hilliard wrote: used. Some will want 9000, some 9200, others 4470 and some people I have a strong opinion for jumboframes=9180bytes (IPv4/IPv6 MTU), partly because there are two standards referencing this size (RFC 1209 and 1626), and also because all major core

Re: Internet Exchanges supporting jumbo frames?

Kurt Kraut wrote: > Thank you for replying so quickly. I don't see why the consensus for an > MTU must be reached. IPv6 Path MTU Discovery would handle it by itself, > wouldn't it? If one participant supports 9k and another 4k, the traffic > between them would be at 4k with no manual intervention.

Re: Internet Exchanges supporting jumbo frames?

There is no way to avoid breaking MTU for IPv4 but use PMTUD for IPv6, is there? Meaning to stick to 1500 for IPv4 and use something larger for IPv6? Kind regards, Stefan On 09.03.2016 15:59, Kurt Kraut via NANOG wrote: > Hi Mike, > > The adoption of jumbo frames in a IXP doesn't brake IPv4.

Re: Internet Exchanges supporting jumbo frames?

Hi Mike, The adoption of jumbo frames in a IXP doesn't brake IPv4. For an ISP, their corporate and residencial users would still use 1,5k. For datacenters, their local switches and servers are still set to 1,5k MTU. Nothing will brake. When needed, if needed and when supported, from a specific

Re: Internet Exchanges supporting jumbo frames?

Maybe breaking v4 in the process? - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com - Original Message - From: "Kurt Kraut via NANOG" To: "Nick Hilliard" Cc:

Re: Internet Exchanges supporting jumbo frames?

2016-03-09 11:45 GMT-03:00 Nick Hilliard : > this has been tried before at many ixps. No matter how good an idea it > sounds like, most organisations are welded hard to the idea of a 1500 > byte mtu. Even for those who use larger MTUs on their networks, you're > likely to find

Re: Internet Exchanges supporting jumbo frames?

Kurt Kraut via NANOG wrote: > I'm trying to convince my local Internet Exchange location (and it is not > small, exceed 1 terabit per second on a daily basis) to adopt jumbo frames. this has been tried before at many ixps. No matter how good an idea it sounds like, most organisations are welded

Re: Internet Exchanges supporting jumbo frames?

Hi Kurt, On Wed, Mar 09, 2016 at 11:26:35AM -0300, Kurt Kraut via NANOG wrote: > I'm trying to convince my local Internet Exchange location (and it is not > small, exceed 1 terabit per second on a daily basis) to adopt jumbo frames. > For IPv6 is is hassle free, Path MTU Discovery arranges the

Re: Internet Exchanges supporting jumbo frames?

On 09/03/2016 15:26, Kurt Kraut via NANOG wrote: Could anyone share with me Internet Exchanges you know that allow jumbo frames (like https://www.gr-ix.gr/specs/ does) and how you notice benefit from it? Netnod does it in separate vlan's. -- Grzegorz Janoszka

Internet Exchanges supporting jumbo frames?

Hi, I'm trying to convince my local Internet Exchange location (and it is not small, exceed 1 terabit per second on a daily basis) to adopt jumbo frames. For IPv6 is is hassle free, Path MTU Discovery arranges the max MTU per connection/destination. For IPv4, it requires more planning. For

Re: mrtg alternative

Hi, Cacti works... Biggest case I know, ~180 devices. A few issues with THold plugin but nothing that can't be fixed. And they are working on a new release (available thru github) which include most of the useful plugins. - Alain Hebert

Re: remote serial console (IP to Serial)

+1 on the Lantronix Spider as it is an awesome tool but Lantronix make devices for very small rollouts also, http://www.lantronix.com/products/eds1100-eds2100/#tab-features might be great for only one device and http://www.lantronix.com/products/lantronix-slb/ for site management with remote power

Re: IPV6 planning

On 05.03.2016 22:19, Laurent Dumont wrote: Hiya, Hi, We are currently considering deploying IPv6 for a Lan event in April. We are assigned a /48 which we then split into smaller subnets for each player vlan. That said, what remains to be decided is how we are going to assign the IPv6.

Re: remote serial console (IP to Serial)

On 9 March 2016 at 07:36, Doug McIntyre wrote: Hey, > I'd get something like a 1U ATOM server ($120 eBay) with small SSD > ($18). Runup your favorite FOSS OS, and conserver. For more than the > single real serialport, you can most likely fit a USB hub inside > the case