December 2003 - NANOG - lists.nanog.org

201/8 block
by Ricardo G Patara 23 Dec '03

23 Dec '03

Hello, As many of you all might known, LACNIC has been allocated the block 201/8 from IANA back in April/2003: http://www.iana.org/assignments/ipv4-address-space it was announced in this mailing list: http://answerpointe.cctec.com/maillists/nanog/current/msg01094.html But, some users are facing problems with addresses in this range due to old filters in some backbones. There was recommendations and routes configurations tips in which the 201/8 block used to be referred as bogus route. At the time those documents were created, the mentioned blocks was not allocated by IANA yet. What is not true since April/2003. Based on this, we would like to ask to network administrators in general to revise their router configuration to make sure they are not filtering valid routes, like networks into 201/8 block. Thank you. Hostmaster // Registration Service ---------------------------------- Latin America and Caribbean Region Internet Addresses Registry http://www.lacnic.net ----------------------------------

3 4

.ORG Registrar ID List (was: Stupid .org registry code change)
by Bruce Beckwith 23 Dec '03

23 Dec '03

Mike, You should deal with a registrar for this information, since that is one of the services they can provide for you. If you are interested in the cross-reference list, please see http://www.pir.org/whois_search/registrar_whois_ids, which can be accessed via the link at http://www.pir.org/whois_search/. In addition, if you choose to use the web-based whois, then you can use the link on the whois output for the registrar - so for example, the domain nanog.org is at http://www.pir.org/cgi-bin/whois.cgi?yes_popup_flag=0&whois_query_field= domain+NANOG.ORG, and using the link for Sponsoring Registrar, in this example "NSI(R63-LROR)" will give information on how to reach the registrar - see http://www.pir.org/cgi-bin/whois.cgi?yes_popup_flag=0&whois_query_field= registrar+id+R63-LROR. I will pass on your offer of career advice ;-) Regards, Bruce Bruce W. Beckwith VP, Operations Public Interest Registry 1775 Wiehle Avenue Suite 102A Reston, VA 20190 v: +1 703.464.7005 x105 bbeckwith(a)pir.org -----Original Message----- From: Michael Lewinski [mailto:mike@rockynet.com] Sent: Monday, December 22, 2003 6:19 PM To: nanog(a)nanog.org Subject: Stupid .org registry code change During the recent changes to .org, whois stopped being useful for what I need. > Sponsoring Registrar:R11-LROR All I really want to know is the Registrar's name/URL to tell my client so they can modify their nameservers. Does anyone have: 1) A URL to the table that will allow me to lookup a name from the above code (or better, a hack to whois that will do said lookup for me)? 2) The e-mail address where I should my suggestion that the person who came up with this brilliant scheme needs to pursue a new career in a non-IT related field? TIA, Mike

4 3

RE: Router Server problem
by Burns, Keith 23 Dec '03

23 Dec '03

Complete shot in the dark... next-hop reachability? Keith Burns Principal Network Architect ICG Telecommunications IP Ph: 303-414-5385 Cell: 303-912-3777 "The dogs may bark, but the caravan rolls on...." > -----Original Message----- > From: pramod babu G [mailto:pramod@lantana.tenet.res.in] > Sent: Saturday, December 20, 2003 10:46 PM > To: nanog(a)merit.edu > Subject: Router Server problem > > > > hai all, > I am simulating an IXP and this has 4 router servers which > are connected > to the ISP routers. > I connected the 4 router server by means of Internal Bgp. > This is as shown > below > IBGP > ISP1------ RS1------- RS2 ------ ISP3 > | | > ISP2------ --------ISP4 > > Now the routes injected by ISP1 into R1 are received by ISP2. > And there is > exchange of routes between ISP3 and 4. But the routes send by > ISP3 are not > seen by ISP1 and ISP2. But RS1 has got those routes in its data base. > These routes are not selected as best routes in the RS1 bgpd > > So to overcome this do u have any suggestions ?? > >

1 0

RE: Trace and Ping with Record Option on Cisco Routers
by Danny.Andaluz＠triaton-na.com 23 Dec '03

23 Dec '03

That's exactly it, Crist. I did a little research and that the PIX drops any packets with IP Options turned on. Currently there is no workaround. This is IP Option 7 to be exact. Thanks, Danny -----Original Message----- From: Crist Clark [mailto:crist.clark@globalstar.com] Sent: Monday, December 22, 2003 6:18 PM To: Andaluz, Danilo, Triaton/NA Cc: nanog(a)merit.edu Subject: Re: Trace and Ping with Record Option on Cisco Routers > Danny.Andaluz(a)triaton-na.com wrote: > > Hey, Group. > > In my production network, I'm trying to do some extended traces and > pings with the record option turned on to see what route my packets > take going and returning. It's not working. If I do the extended > traceroute or ping without the record option, it works fine. There is > a firewall (PIX) a few hops in front of the destination I'm trying to > record the route for. What part of ICMP is this that needs to be > opened on the firewall to allow this to come back? First time I'm > coming across this. It's not ICMP. It's the IP Options. Most firewalls will drop any packet with an IP Options. Many firewalls will not let you turn this off. I do not know how to allow IP Options through a PIX, but I know how to do it in Cisco IOS. -- Crist J. Clark crist.clark(a)globalstar.com Globalstar Communications (408) 933-4387

1 0

Packet loss and inexplicable delays
by Constantinos A. Kotsokalis 23 Dec '03

23 Dec '03

Hello All, In the process of testing certain circuits delivered as parts of a WAN, we have found that two links are having serious packet loss and (inexplicable!) delays. To be more specific, they have packet loss on one direction, and huge delays on the other direction. The following diagram shows the situation (all equipment is made by Cisco): 1. Site A <-> Site B: Delay -----------> -------- ATM -------- ATM ------- E3 -------------- | 7500 | <---> | 7200 | <---> | GSR | <----> | 6500/MSFC2 | -------- -------- ------- -------------- <----------- Packet loss The GSR connects to the E3 with an Engine0 12E3-SMB LC. The ATM link between the 7500 and the 7200 is shaped at 58 Mbps (ATM rate), while the link between the 7200 and the GSR is 155 Mbps. The E3 is an HDLC circuit. During the test, we noticed interface resets on the E3 link (line down). We thought that maybe the MSFC2 has prioritization problems (i.e. PPP keepalives are not prioritized over normal traffic), but that does not seem to be the case according to documentation found. LDP between the GSR and the 6500 was also dropped a few times (this is an MPLS Carrier-supporting-Carrier scheme). 2. Site A <-> Site C: Packet loss -----------> -------- ATM -------- ATM -------- E3 ------- | 7500 | <---> | 7200 | <---> | 7200 | <----> | GSR | -------- -------- -------- ------- <----------- Delay The GSR connects to the E3 (HDLC) with an Engine0 6E3-SMB LC. The 7500<->7200 ATM subinterface is shaped at 40 Mbps (which, if I am correct, does explain packet loss for small packets, but not for large --i.e. 1500 byte-- packets due to cell tax). Interface/LPD resets did not happen during this experiment. The packet loss is about 5% from end to end, and the delays vary (they grow up to 10 seconds!). The testing tool we are using is Rude/Crude, and the test PCs seem to handle the load in general. These test PCs are connected on the two end-routers through FastEthernet interfaces. The send-rate used for the two tests is 34 Mbps, in both directions. It is probably useful to mention that the delay is increasing as the packet size increases. The two GSRs are running IOS 12.0(26)S, which according to the caveats list does not seem to have any problems with HDLC E3 links under any circumstances. Any ideas/insight at all, would be greatly welcome! Thank you in advance, Costas -- Constantinos A. Kotsokalis || ckotso(a)grnet.gr Greek Research and Technology Network || http://www.grnet.gr 56 Mesogeion Av., Ampelokipi, 11527 Athens, Greece Tel: +30-210-7474249 || Cell: +30-697-7606620 || Fax: +30-210-7474490

1 0

northeast fiber cut
by Alex Rubenstein 23 Dec '03

23 Dec '03

Circuits we had that were affected by the fiber cut in NJ/PA have been coming up over the last hour. two notes: a) anyone know of where this happened, specifically, and also what actually happened? I heard ?langhorne?, pa, and two 288 bundles were affected, MFN had to dig to find it -- if thats the case, what cuases fiber to magically go boom? b) is it me, or does it seem the number of fiber cuts per time period is decreasing, or does sean donelan no longer have an email client?

2 1

Bay area Earthquake
by Brennan_Murphy＠NAI.com 23 Dec '03

23 Dec '03

foxnews reporting 6.5 on the richter scale cant get more info than that

2 1

Request for submissions: messy cabling and other broken things
by Eric Kuhnke 23 Dec '03

23 Dec '03

Sometimes illustrating the way a job should *not* be done is a powerful educational tool. I have collected a gallery of messy and ridiculous cabling jobs: http://gallery.colofinder.net/shameful-cabling my favorite (not horrible, but funny): http://gallery.colofinder.net/shameful-cabling/cables Anonymous submissions can be sent to fnord(a)fnordsystems.com , equipment labels and faces will be blurred if requested.

21 30

Minimum Internet MTU
by Chris Brenton 23 Dec '03

23 Dec '03

Greetings all, I'm working with a few folks on firewall and IDS rules that will flag suspicious fragmented traffic. I know the legal minimum of a non-terminal fragment is 28 bytes, but given non-terminals should reflect the MTU of the topologies along the link, this number is far lower than what I expect you should see for legitimate fragmentation in the wild. A few years back I noted some 512-536 MTU links in ASIA. I've been doing some testing and can't seem to find them anymore. Is is safe to assume that 99.9% of the Internet is running on 1500 MTU or higher these days? I know some people artificially set their end point MTU a bit lower (like 1400) to deal with things like having their traffic encapsulated by GRE or IPSec. With this in mind, would we be safe to flag/drop/what ever all fragments smaller than 1200 bytes that are not last fragments (i.e., more fragments is still set)? Does anyone maintain, or is aware, of links that would not meet this 1200 MTU? Any and all feedback would be greatly appreciated, C

8 10

Trace and Ping with Record Option on Cisco Routers
by Danny.Andaluz＠triaton-na.com 23 Dec '03

23 Dec '03

Hey, Group. In my production network, I'm trying to do some extended traces and pings with the record option turned on to see what route my packets take going and returning. It's not working. If I do the extended traceroute or ping without the record option, it works fine. There is a firewall (PIX) a few hops in front of the destination I'm trying to record the route for. What part of ICMP is this that needs to be opened on the firewall to allow this to come back? First time I'm coming across this. Thanks, Danny

4 3