- Test - lists.nanog.org

to learn about routing.
by Vaul Pixie 18 Jul '00

18 Jul '00

For those interested in learning more about basic routing, I would like to direct your attention to the follow book, "Internet Routing Architectures, Second Edition, Volume I", this fine text can be ordered from many bookstores. Below is a purchase order for it from Amazon, filled out to one, Hansen Chan. I'm sure you will be just as pleased with it as he was. Vaul Pixie vaul(a)wayabove.net ---------- Forwarded message ---------- Date: Sat, 17 Jun 2000 03:39:36 -0400 From: orders(a)amazon.com Subject: Your Order with Amazon.com (#xxx-xxxxxxx-xxxxxxx) Thank you for ordering from Amazon.com. Your purchase information appears below. <snip> Order #1: (Order #103-4820841-6376601) Hansen Chan Alcatel Network Systems 1225 N. Alma Road, MS 401-102 Richardson, TX 75081-2206 United States Shipping method: Standard Shipping Shipping Preference: Ship this when complete 1 "Internet Routing Architectures, Second Edition, Volume I" Bassam Halabi; Hardcover; @ $55.00 each Usually available in 24 hours ---------------------------------------------- ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

5 4

***Announcement: Merit to convert to 'PGPKEY' authentication (RFC 2726)
by gerald＠merit.edu 18 Jul '00

18 Jul '00

On 7/30/00 between 5 AM - 8 AM EDT Merit will convert from 'PGP-FROM' to 'PGPKEY' authentication as described in RFC 2726. All maintainer object 'PGP-FROM' instances will be converted to a 'PGPKEY' instance and a 'key-cert' object will be created for each unique 'PGPKEY' instance. After the conversion all public keys used for signing DB submissions will be visible in the registry as 'key-cert' objects. Registering public keys allows users to verify a maintainer's identity and to submit, update and maintain their own public keys like any other DB object. Normal PGP signing of DB submissions will continue to work exactly as before the conversion. The conversion should be seamless to our DB user community and no action is required. Merit will send email to all users who will be affected by the conversion. The notice will give users a chance to remove their PGP references if (for whatever reason) they do not wish to take part in the new PGP authentication scheme. The new 'PGPKEY' scheme makes it easier for users to integrate PGP signing into their DB update process. It is our wish that into the future all registry users will PGP sign their DB submissions. Please see www.radb.net/docs/keyfaq.html for additional information on the conversion process and tutorial information regarding the use of 'PGPKEY' authentication. Please consult RFC 2726 for the authoritative specification. IRRd team --Gerald Winters

1 0

RADB and building router filters
by Jim Mercer 18 Jul '00

18 Jul '00

i'm running into difficulties getting my routes announced via networks that use the RADB to build their filters. i'm being told that some of my routes are being ignored because there are supercede'ing entries at whois.radb.net. for example, "whois -h whois.radb.net 198.96.117.0" contains two entries: route: 198.96.117.0/24 descr: NETBLK-TORMAN origin: AS813 mnt-by: MAINT-AS813 changed: support(a)uunet.ca 19950920 source: RADB route: 198.96.117.0/24 descr: Reptilian Research admin-c: JM7718-ARIN tech-c: JM7718-CSAS origin: AS843 remarks: in use by Reptilian Research remarks: parent is ARIN notify: jim(a)reptiles.org mnt-by: MAINT-AS843 changed: jim(a)reptiles.org 20000527 source: CSAS should i be requesting that the entry from UUNET be removed? -- [ Jim Mercer jim(a)reptiles.org +1 416 410-5633 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]

3 4

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