July 2000 - Test - lists.nanog.org

Re: exchange point media
by Richard A. Steenbergen 17 Jul '00

17 Jul '00

On Mon, 17 Jul 2000, Mikael Abrahamsson wrote: > > On Mon, 17 Jul 2000, Richard A. Steenbergen wrote: > > > A Foundry BigIron doing L3 should, exactly as if it was a router and > > interfaces not a switch, I believe. At that point there is no real > > technical distinction between it and a router with lots of ethernet > > ports however. I'm not aware of any exchanges doing L3... > > Well, the device should do no routing in the classical meaning of the > word, not on L3 anyway. To do fragmentation it has to be semi-L3-aware > though. It also needs an IP adress to send the needtofrag-ICMPs from. I'm not sure if there is anyone who is doing L3 only in regards to fragmentation when traversing through a switch with multiple interfaces and disparate MTUs in a modern environment. You'd have to ask the switch vendors, my guess is if its a L3 switch-functionality it could be made to do so at decent levels of performance, but this is still bad. > > FreeBSD lets you set the MTU based on the route... You could do something > > like this, enabling a larger MTU for specific targets, I suppose. I'm not > > aware of anyone who is doing this (or probably anyone who would, > > especially at L2, without a good reason). This assumes the exchange point > > has a switch capable of it. > > We're talking L3 here (routers). Normally the L3 MTU is derived from > the L2 MTU, here we would need to derive it from either static > configuration or from the below MSS/MTU mechanism (which I don't think > will happen as it has too much of a "hack" in it). The OS model you're refering to lets you derive it from the routing entry instead of just the physical interface, so you can specify a different MTU for a different prefix, for whatever reason, even if its on the same physical interface. At this point you're talking a grody poorly managed hack which assumes an aweful lot and probably is going to break a lot of things. > > The TCP MSS is negiotated based off the MTU, so yo cannot base the MTU off > > the MSS, circular logic. I highly doubt you will ever get support for > > jumbo frames auto-negotiated without first standarding the jumbo-frames. > > Yes, it can. Router1 should be able to figure out router2:s MTU from > the MSS of its TCP session with router2. Router2 has no problem here > since it's MTU is the lowest one anyway. This could work in a very backwards fashion. Something like both sides starting with an MTU of 1500, but configured to try and reach 9k if possible. During a BGP Peer, Router1 lies and offers up an MSS of 9k in its SYN, and if Router2 accepts and both sides complete a handshake with an agreed upon value, both physical MTUs would be increased. This is a horrible hack, among other things it assumes there must be a TCP based BGP peer in order for the sides to negiotiate > 1500, and that the switch will accept this. I can't imagine it working like this in any production system. > I was under the impression that there is nothing magical about jumbo > frames and that there are no interoperational problems with them as > long as they're supported at all. Please correct me if I am wrong. There is no standardization on maximium size of the jumbo frame, or guarentee to support them at all. There is also no guarentee that the ability to go > 1500 will not disappear in 10GigE. > > I for one would love to see an intelligent standard realizing that 1500 is > > a remarkably stupid and limiting number, and enabling us to bring new life > > to public exchange point peering. > > I think any new exchange point technology needs to have an MTU > 1500. I would agree with that, but is the IEEE taking that into account or just focusing on traditional desktop server and datacenter networking? One of the most powerful advantages ethernet offers is the ability to be cheaply and easily switched. Personally I'd love to have a cheap effective high density OC48 PoS switch (no flames please). :P -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

Re: exchange point media
by Richard A. Steenbergen 17 Jul '00

17 Jul '00

On Mon, 17 Jul 2000, Mikael Abrahamsson wrote: > We had a discussion here a while back about exchange point media. The > outcome was that Gigabit ethernet vendors do support jumbo frames and > that the MTU disadvantage GE has could be overcome. > > Now, imagine the following scenario: > > We connect a router (router1)to this fictous exchange point running > (gig)ethernet. This router does support jumbo frames and has a 8k MTU. > > Somewhere else on the exchange point is another router (router2), also > connected to the same broadcast domain. This router does NOT support jumbo > frames but has the standard 1500 MTU. > > What happens if router1 tries to send a packet to router2 which is > 1500 MTU? It thinks it's perfectly valid to send an 8k packet. (PMTUd > won't work here, we're talking layer2). Correct, Silent L2 discard, giant frame... > My other guess is that if the switch in between (we're probably not > talking point-to-point-links here because this is an exchange point, > right?) is layer3-aware (as most are today) it could/would fragment the > packet or give a needtofrag-ICMP to the originator IP. Will any switch > today do this? What vendors do this? (I have been told that the old DEC > Gigaswitches will do this between FDDI and FastEth, it will fragment the > IP packet if neccessary). A Foundry BigIron doing L3 should, exactly as if it was a router and not a switch, I believe. At that point there is no real technical distinction between it and a router with lots of ethernet ports however. I'm not aware of any exchanges doing L3... > A third solution would be that I think I saw somewhere that some OSes > support setting host routes where you could enter the MTU of certain > specific IPs. This could also rectify the problem by simply > configuring the switches for jumbo frames and then setting the default > MTU to 1500 on routers and then people who support jumbo frames could > include this in their perring announcements/agreements and if two > parties do support these both then their equipment could use the > larger frames when talking to each other over this shared medium. FreeBSD lets you set the MTU based on the route... You could do something like this, enabling a larger MTU for specific targets, I suppose. I'm not aware of anyone who is doing this (or probably anyone who would, especially at L2, without a good reason). This assumes the exchange point has a switch capable of it. > Another option would be to pick the other unit's MTU off of the TCP > session enabled for the (very probable) BGP peering. I seem to > remember that TCP involves a MTU negotiation between endpoints and > that would mean that you implicitly get to know the MTU of all your > peers (which are the ones you might send packets to). Any vendors > which do a "hack" like this? This would not work if the default MTU is > 1500 though, it would rather mean you have to have a default MTU of 8k > (or so) and find out anyone who is not jumbo capable via the TCP > session involved with the BGP peering. The TCP MSS is negiotated based off the MTU, so yo cannot base the MTU off the MSS, circular logic. I highly doubt you will ever get support for jumbo frames auto-negotiated without first standarding the jumbo-frames. I for one would love to see an intelligent standard realizing that 1500 is a remarkably stupid and limiting number, and enabling us to bring new life to public exchange point peering. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

2 1

Re: trouble in Sprint land?
by Steven M. Bellovin 17 Jul '00

17 Jul '00

In message <20000717193302.4069.cpmta(a)c004.sfo.cp.net>, Sean Donelan writes: >On Mon, 17 July 2000, "Steven M. Bellovin" wrote: >> I managed to delete the traceroute from my note. From other replies, >> it seems to affect folks who are going through UUnet to Sprint: > >What did UUNET's NOC say when you opened a ticket with them? Did UUNET >followup with Sprint's NOC, and what was Sprint's NOC response? After this week's thread, do I dare open a trouble ticket for some other provider? --Steve Bellovin

4 3

Exchange-point address space announcement...
by John Fraizer 17 Jul '00

17 Jul '00

Isn't is considered widely to be bad form to announce exchange-point address space? *192.41.177.0/24 ASPath: 6347 1239 1800(IGP) Weight: 0 Community: 13944:6347 Last update: Sun Jul 16 21:06:37 2000 SURAnet (NET-MAE-EAST) 8400 Baltimore Boulevard College Park, MD 20740 Netname: MAE-EAST Netnumber: 192.41.177.0 Coordinator: SURAnet (SURA-NOC-ARIN) noc(a)SURA.NET (301) 982-3214 Domain System inverse mapping provided by: SOL.SURA.NET 128.167.1.100 SOL.SURA.NET 128.167.1.100 TRANTOR.UMD.EDU 128.8.10.14 NS.SESQUI.NET 128.241.0.84 NS.UU.NET 137.39.1.3 Record last updated on 08-Jan-1997. Database last updated on 17-Jul-2000 06:24:11 EDT. I ask because... traceroute to mae-east.fnsi.net (192.41.177.11), 30 hops max, 40 byte packets 1 Gigabit-3.Columbus.EnterZone.Net (209.41.244.1) 0.626 ms 0.763 ms 0.820 ms 2 64.241.88.6 (64.241.88.6) 16.305 ms 16.045 ms 16.456 ms 3 64.241.88.65 (64.241.88.65) 300.996 ms 16.153 ms 16.151 ms 4 sl-gw23-chi-6-1-1.sprintlink.net (144.232.218.241) 17.290 ms 18.776 ms 17.437 ms 5 sl-bb13-chi-0-1.sprintlink.net (144.232.10.45) 17.401 ms 16.817 ms 17.426 ms 6 sl-bb11-chi-5-1.sprintlink.net (144.232.10.62) 18.372 ms 16.851 ms 19.382 ms 7 sl-bb11-atl-4-0.sprintlink.net (144.232.18.34) 30.004 ms 30.534 ms 30.174 ms 8 sl-bb10-atl-9-0.sprintlink.net (144.232.12.17) 31.008 ms 29.573 ms 30.208 ms 9 sl-bb21-rly-14-0.sprintlink.net (144.232.9.197) 43.693 ms 45.228 ms 43.818 ms 10 sl-bb10-rly-9-0.sprintlink.net (144.232.25.6) 49.683 ms 50.052 ms 50.589 ms 11 sl-bb4-dc-0-0-0.sprintlink.net (144.232.7.154) 42.808 ms 42.244 ms 43.823 ms 12 sl-e2-mae-4-1-0-T3.sprintlink.net (144.228.10.94) 45.721 ms 71.589 ms 43.878 ms 13 mae-east.fnsi.net (192.41.177.11) 34.915 ms * 34.852 ms Um, would anyone else consider this to be a strange thing since we peer with FNSI directly? *206.220.243.0/24 ASPath: 6347 701 3549(IGP) Weight: 0 Community: 13944:6347 Last update: Sun Jul 16 21:10:59 2000 Ameritech ATM Exchange Point (NETBLK-AADSNET2) 85 W. Algonquin Road Suite 110 Arlington Heights, IL 60005 US Netname: AADSNET1 Netblock: 206.220.240.0 - 206.220.243.255 Coordinator: Cnota, Mark (MC386-ARIN) mcnota(a)AMERITECH.NET 847-952-2920 Domain System inverse mapping provided by: DNS.MERIT.NET 198.108.1.42 DNS2.MERIT.NET 198.109.36.3 DNS3.MERIT.NET 198.108.130.5 Record last updated on 24-Jun-1999. Database last updated on 17-Jul-2000 06:24:11 EDT. *198.32.136.0/24 Description: SAVVIS TRANSIT ASPath: 6347 1239 2685(IGP) Weight: 0 Community: 13944:6347 Last update: Sun Jul 16 21:08:10 2000 Exchange Point Blocks (NET-EP-) PO 12317 Marina del Rey, CA 90295 US Netname: NET-EP-1 Netblock: 198.32.0.0 - 198.32.255.255 Coordinator: Manning, Bill (WM110-ARIN) bmanning(a)KAROSHI.COM (310) 322 8102 Domain System inverse mapping provided by: DOT.EP.NET 198.32.2.10 NS.ISI.EDU 128.9.128.127 FLAG.EP.NET 198.32.4.13 Record last updated on 10-May-1999. Database last updated on 17-Jul-2000 06:24:11 EDT. --- John Fraizer EnterZone, Inc

3 2

exchange point media
by Mikael Abrahamsson 17 Jul '00

17 Jul '00

We had a discussion here a while back about exchange point media. The outcome was that Gigabit ethernet vendors do support jumbo frames and that the MTU disadvantage GE has could be overcome. Now, imagine the following scenario: We connect a router (router1)to this fictous exchange point running (gig)ethernet. This router does support jumbo frames and has a 8k MTU. Somewhere else on the exchange point is another router (router2), also connected to the same broadcast domain. This router does NOT support jumbo frames but has the standard 1500 MTU. What happens if router1 tries to send a packet to router2 which is > 1500 MTU? It thinks it's perfectly valid to send an 8k packet. (PMTUd won't work here, we're talking layer2). My guess is that if the switch inbetween the routers is configured for jumbo frames the frame will be sent to router2 which will probably give a frame error and discard the packet (silently from router1:s point of view). My other guess is that if the switch in between (we're probably not talking point-to-point-links here because this is an exchange point, right?) is layer3-aware (as most are today) it could/would fragment the packet or give a needtofrag-ICMP to the originator IP. Will any switch today do this? What vendors do this? (I have been told that the old DEC Gigaswitches will do this between FDDI and FastEth, it will fragment the IP packet if neccessary). A third solution would be that I think I saw somewhere that some OSes support setting host routes where you could enter the MTU of certain specific IPs. This could also rectify the problem by simply configuring the switches for jumbo frames and then setting the default MTU to 1500 on routers and then people who support jumbo frames could include this in their perring announcements/agreements and if two parties do support these both then their equipment could use the larger frames when talking to each other over this shared medium. Another option would be to pick the other unit's MTU off of the TCP session enabled for the (very probable) BGP peering. I seem to remember that TCP involves a MTU negotiation between endpoints and that would mean that you implicitly get to know the MTU of all your peers (which are the ones you might send packets to). Any vendors which do a "hack" like this? This would not work if the default MTU is 1500 though, it would rather mean you have to have a default MTU of 8k (or so) and find out anyone who is not jumbo capable via the TCP session involved with the BGP peering. Comments on all this, please? -- Mikael Abrahamsson email: swmike(a)swm.pp.se

1 0

Re: Different customer service reactions (was Re: Wanted: Clueful Individual @ TeleGlobe.net)
by Sean Donelan 17 Jul '00

17 Jul '00

On Sun, 16 July 2000, Alex Bligh wrote: > I guess argues for the 'hop-by-hop' methodology of interprovider > cooperation and problem resolution. However, given there are > some NOC's who won't open a trouble ticket for *peers*, or > (sometimes amusingly) for *upstreams*, perhaps this is a > broken metaphor. Some NOCs won't open a trouble ticket for *customers* for another part of the same company. I've had trouble getting Sprintlink to troubleshoot problems with Sprint ICM. Sprintlink told me to call ICM, ICM told me I should call Sprint. So if you won't open trouble tickets for customers, peers or upstreams who will you open a trouble ticket for? Why does GlobalCenter tell people to call AT&T instead of GlobalCenter contacting AT&T directly? IOPS tried to set up a common trouble ticket system between its members. But I don't know how much use it gets.

2 1

Re: trouble in Sprint land?
by Sean Donelan 17 Jul '00

17 Jul '00

On Mon, 17 July 2000, "Steven M. Bellovin" wrote: > I managed to delete the traceroute from my note. From other replies, > it seems to affect folks who are going through UUnet to Sprint: What did UUNET's NOC say when you opened a ticket with them? Did UUNET followup with Sprint's NOC, and what was Sprint's NOC response?

1 0

Re: trouble in Sprint land?
by Steven M. Bellovin 17 Jul '00

17 Jul '00

Steve Bellovin writes: >What is going on here? I've seen similar delays -- i.e., over 4 >seconds -- for several days now, though only during the day. It's also >not just the routers being slow about pings; round-trip to the >destination (www.law.cornell.edu, in this case) is over 5 seconds: I managed to delete the traceroute from my note. From other replies, it seems to affect folks who are going through UUnet to Sprint: traceroute to www.law.cornell.edu (128.253.22.200) from sigaba.research.att.com (135.207.23.169), 40 hops max, 40 byte packets 1 oden.research.att.com (135.207.31.1) 0.511 ms 0.545 ms 0.507 ms 2 opsec.research.att.com (135.207.1.2) 1.321 ms 1.178 ms 1.316 ms 3 192.20.225.225 (192.20.225.225) 3.429 ms 2.472 ms 3.297 ms 4 Serial1-1-1.GW1.EWR1.ALTER.NET (157.130.0.177) 9.495 ms 7.279 ms 29.985 ms 5 113.ATM2-0.XR1.EWR1.ALTER.NET (146.188.176.34) 10.142 ms 5.166 ms 3.784 ms 6 193.ATM7-0.XR1.NYC4.ALTER.NET (146.188.178.53) 5.283 ms 6.269 ms 4.283 ms 7 189.ATM11-0-0.BR1.NYC4.ALTER.NET (146.188.177.189) 71.224 ms 10.384 ms 200.119 ms 8 137.39.23.146 (137.39.23.146) 10.799 ms 5.844 ms 5.543 ms 9 sl-bb10-nyc-2-3-155M.sprintlink.net (144.232.8.221) 6.910 ms 6.153 ms 7.388 ms 10 sl-bb22-rly-13-0.sprintlink.net (144.232.9.226) 853.712 ms 861.250 ms 888.238 ms 11 sl-gw9-rly-9-0.sprintlink.net (144.232.7.254) 4891.870 ms 4958.808 ms * --Steve Bellovin

1 0

trouble in Sprint land?
by Steve Bellovin 17 Jul '00

17 Jul '00

What is going on here? I've seen similar delays -- i.e., over 4 seconds -- for several days now, though only during the day. It's also not just the routers being slow about pings; round-trip to the destination (www.law.cornell.edu, in this case) is over 5 seconds: PING www.law.cornell.edu (128.253.22.200): 56 data bytes 64 bytes from 128.253.22.200: icmp_seq=0 ttl=238 time=5116.59 ms 64 bytes from 128.253.22.200: icmp_seq=1 ttl=238 time=5174.68 ms 64 bytes from 128.253.22.200: icmp_seq=2 ttl=238 time=5200.65 ms 64 bytes from 128.253.22.200: icmp_seq=3 ttl=238 time=5163.74 ms 64 bytes from 128.253.22.200: icmp_seq=4 ttl=238 time=5062.49 ms 64 bytes from 128.253.22.200: icmp_seq=5 ttl=238 time=5075.5 ms 64 bytes from 128.253.22.200: icmp_seq=6 ttl=238 time=5112.46 ms 64 bytes from 128.253.22.200: icmp_seq=7 ttl=238 time=5205.24 ms 64 bytes from 128.253.22.200: icmp_seq=8 ttl=238 time=5228.75 ms --Steve Bellovin

1 0

Foot in my mouth
by Chris Cappuccio 17 Jul '00

17 Jul '00

http://www.directmag.com/content/newsline/main.html#81 The beginning of this article... "Yesmail.com, a Chicago-based permission marketer, won a temporary restraining order Thursday against Mail Abuse Prevention System LLC (MAPS) in the first legal challenge to the Redwood, CA-based group. Issued by the Northern District Court of Illinois (Eastern Division), the order blocks MAPS from adding yesmail to its list of alleged spammers. It is good through Aug. 2. A hearing has been scheduled for July 18."

1 0