November 1999 - Test - lists.nanog.org

should TCPs do MTU black hole detection?
by Vern Paxson 19 Nov '99

19 Nov '99

The IETF's tcp-impl (TCP implementation) working group has a draft document discussing problems with path MTU discovery: http://www.ietf.org/internet-drafts/draft-ietf-tcpimpl-pmtud-02.txt The main issue we're trying to decide is whether the draft should advocate "black hole detection". That is, when a TCP is doing PMTU discovery, but somewhere the necessary ICMPs are either not being generated or are being filtered out before the TCP receives them, the TCP notices that it's losing multiple packets of the same size, so it then tries sending smaller segments, even though it hasn't received a "Datagram Too Big" ICMP. The plus of black hole detection is that it can work around a sometimes very hard to debug problem. The minus is that it masks problems that should instead be fixed. To help resolve this issue, I'm wondering whether the ISP community has a clear preference for either yes-do-detection or no-we-want-the-problems-fixed. Comments appreciated. Thanks, Vern

7 9

The Cidr Report
by Tony Bates 19 Nov '99

19 Nov '99

This is an auto-generated mail on Fri Nov 19 12:00:00 PST 1999 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 19Nov99 0) General Status Table History ------------- Date Prefixes 041199 66135 051199 66177 061199 66189 071199 66095 081199 66195 091199 66908 101199 65842 111199 67577 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 4241 Number of ASes announcing only one prefix: 1433 (0 cidr, 1433 classful) Largest number of cidr routes: 0 announced by Largest number of classful routes: 1720 announced by AS1890 1) Gains by aggregating at the origin AS level --- 19Nov99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1890 1720 797 923 53.7% UUNET NL Autonomous System AS271 383 141 242 63.2% BCnet Backbone AS7046 389 258 131 33.7% UUNET-CUSTOMER AS2609 126 11 115 91.3% EUnet-TN AS1221 614 506 108 17.6% TELSTRA-AS AS9269 123 30 93 75.6% Hong Kong CTI AS7657 253 162 91 36.0% The Internet Group Limited AS7545 146 60 86 58.9% TPG Internet Pty Ltd AS7496 123 38 85 69.1% Power Up AS174 555 471 84 15.1% Performance Systems International AS4293 220 138 82 37.3% Internal ASN for C&W AS577 263 182 81 30.8% Bell Canada Backbone AS3749 138 63 75 54.3% TECNET AS4200 181 111 70 38.7% AGIS (Apex Global Information Ser AS6944 63 6 57 90.5% RapidSite, Inc. AS4740 347 292 55 15.9% Ozemail Pty Ltd (ASN-OZEMAIL) AS816 239 190 49 20.5% UUNET Canada (ASN-UUNETCA-AS4) AS209 304 257 47 15.5% Qwest Communications AS684 92 46 46 50.0% Manitoba Regional Network Backbon AS9304 55 16 39 70.9% Hutchcity AS4755 107 68 39 36.4% Videsh Sanchar Nigam Ltd. India AS6528 45 7 38 84.4% WORLD-LYNX AS549 206 168 38 18.4% ONet Backbone AS2493 125 87 38 30.4% iSTAR Internet, Inc. AS719 195 159 36 18.5% LANLINK autonomous system AS701 962 926 36 3.7% Alternet AS6629 63 28 35 55.6% NOAA-AS AS1 503 468 35 7.0% GTE Internetworking AS7568 48 14 34 70.8% C.S. Communications Co., Ltd. AS3737 99 66 33 33.3% PenTeleData Inc. (ASN-PTD) For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

GW-List - Routing Maintenance
by brandon＠rd.bbc.co.uk 19 Nov '99

19 Nov '99

I haven't seen this mentioned, they'll go on to do the others then life will be wonderful? ----- Begin Included Message ----- >From Gateways-owner(a)COWS.NET Fri Nov 19 00:07:28 1999 From: n1uro(a)www.n1uro.ampr.org Date: Fri, 19 Nov 1999 0:03:49 GMT Subject: GW-List - Routing Maintenance On Wednesday 11/24 at 12:01AM PST MAE-West Ames will be taken down for reconfiguration. The outage window is from 12:01AM PST to 6:00AM PST. The purpose of the reconfiguration is to eliminate the Head-Of-Line blocking problems caused by the DEC Gigaswitch FDDI. The Gigaswitches will be moved to an edge position at the exchange and divided into multiple logical bridges AKA: expect ampr.org to vanish for a few ----- End Included Message -----

1 0

Proactive notification, one disaster at a time
by Sean Donelan 19 Nov '99

19 Nov '99

Since I posted about the problem, I guess I should also post when a company announces an improvement. Worldcom announced today it will proactively notify customers about network problems. Its subsidary, UUNET, had a proactive notification program for a few years. Worldcom joins other companies such as BBN (now GTEI), who established a proactive notification program after a rat took down its west coast operation and AT&T announced improvements in its notification program after its network outage last year including multiple notification methods. We all know there will be network problems from time to time. Its good to see one more company's management decide to add proactive customer notification. I speak only for myself.

2 1

RFC1712 - is anyone actually using GPOS RR's ?
by Jesper Skriver 18 Nov '99

18 Nov '99

Hi, As subject says, is anyone actually using these ? We were thinking of adding this to our automated dns scripts ... but if nobody actually uses them, we don't want to spend time on it ... /Jesper -- Jesper Skriver (JS4261-RIPE), Network manager Tele Danmark DataNet, IP section (AS3292) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.

4 5

Internet coordination effort for the New Year
by Sean Donelan 18 Nov '99

18 Nov '99

I have a fair amount of participation. Interestingly enough no one reported they were already participating in a reporting channel. I have coverage from ISPs, academic and maybe some data from a few exchange points. I'll be sending out details to those people by the end of November. I would also like to get some coverage from large-scale web hosting people and large-scale multi-play game sites. They both seem to track their network performance closely. Also, does anyone have a contact at Keynote or Inverse? The people I knew have moved on. Perhaps most worrisome is I've seen several "consultants" recommending to customers to shutdown their e-mail over the new year's weekend. Unfortunately this could create a mail jam, and a large traffic load when they turn the e-mail back on the following Monday.

2 1

CISCO ISO version 12.0 (5)
by K. Graham 18 Nov '99

18 Nov '99

Following Hyun's lead I am also looking for information concerning CISCO ISO version 12.0 (5). At present we are running Version 11.3(8)DB1 on our Cisco 6400. We are using this equipment for our DSL deployment. Due to some implementation issues we need to try a more recent version of software to see if it will eliminate a high CPU utilization which causes a us to reset the blade. Unfortunately we do not have a long testing period, if any, and would appreciate any information you can send our way. Feel free to reply to my directly or to the list. Kim Graham Network Analyst kgraham(a)ican.net

1 0

Re: stability of IOS 12.0(5)T1
by Hyunseog Ryu/Brookfield/Norlight 18 Nov '99

18 Nov '99

Yes, I know, Paul. But last time when we tried to upgrade to 12.0(7)S, there was some strange thing happened. If you read the previous email that I sent, you can understand the situation. For your convenience, the situation was as follow. We runned IOS 11.2(12a)P on our Cisco 7507. For compatability of new hardware, we tried to upgrade IOS to 12.0(7)S. When we upgraded to 12.0(7)S, there was some abnormal thing happened. Each traffic from the other interface didn't go through another interface. Router doesn't work as router. ;< We tried something, but it didn't work. So we went back to previous IOS version. Basically we put both version to flash PCMCIA card memory. Because of that, it didn't take long time. After that, I got some responses from you guys. It was that IOS 12.0 or 11.0.(?)CC has some unstable fact related to "ip cef" or Routing cache management. Hyun "Paul G. Donner" <pdonner(a)cisco.com> on 11/18/99 10:03:33 AM To: "Hyunseog Ryu/Brookfield/Norlight" <HRyu(a)norlight.com> cc: (bcc: Hyunseog Ryu/Brookfield/Norlight) Fax to: Subject: Re: stability of IOS 12.0(5)T1 For stability, the best thing to do is contact the TAC. However, turning off caching and CEF will force your router into process switching mode. Process switching mode is the slowest form of forwarding. Do you really want to do this? Then you essentially obviate the need for the 7500 processing power and the only thing left is the benefit of aggregation. You need to look at what features you require and talk with the TAC about this and then find a stable version (if you haven't already done this)... basedon the ffeatures you need and the load you put on the box. Of course, if you don't need the horsepower, then this is a different issue. -Donner At 09:53 AM 11/18/1999 -0600, you wrote: > >Dear folks, > >Thank you for your kind comment about IOS 12.0(7)S. >I got a lot of response from nanog-pals. :-) >According to that comment and Cisco's recommend, >we will try another IOS version, 12.0(5)T1. >Currently we have Cisco 7507 and 2 physical HSSI interface >(one is VIP2 module), 3 HSSI software interface (because of VIP2 module). >And we put the PA-2T3+ card on Cisco 7507 for another connection. >Problem is that PA-2T3+ can be recognized only by 11.1.(?)CC, 12.0(?)T, or >12.0(?)S version. >Cisco guy said that 12.0(?)S version is too early. >So we will try 12.0(5)T1 on monday morning. >Our Cisco 7507 has one RSP4 card with 256MB RAM. > >Is there anyone have experience with 12.0(5)T1? >Is it stable? >If it is not stable, we have only one option remaining, 11.1(?)CC. >Please tell me your experiences. > >Basically we will try to turn off "ip cef" and "ip route-cache" option, >too. > >I appreciate your comment. >Thanks in advance. > >Hyun > > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >Hyunseog Ryu >Network Engineer/Applications Engineering >Norlight Telecommunications, Inc. >275 North Corporate Drive >Brookfield, WI 53045-5818 >Tel. +1.262.792.7965 >Fax. +1.262.792.7733 > > > Paul Donner Consulting Engineering Office of the CTO Internet Architecture ciscoSystems, Inc. Hyun

1 0

stability of IOS 12.0(5)T1
by Hyunseog Ryu/Brookfield/Norlight 18 Nov '99

18 Nov '99

Dear folks, Thank you for your kind comment about IOS 12.0(7)S. I got a lot of response from nanog-pals. :-) According to that comment and Cisco's recommend, we will try another IOS version, 12.0(5)T1. Currently we have Cisco 7507 and 2 physical HSSI interface (one is VIP2 module), 3 HSSI software interface (because of VIP2 module). And we put the PA-2T3+ card on Cisco 7507 for another connection. Problem is that PA-2T3+ can be recognized only by 11.1.(?)CC, 12.0(?)T, or 12.0(?)S version. Cisco guy said that 12.0(?)S version is too early. So we will try 12.0(5)T1 on monday morning. Our Cisco 7507 has one RSP4 card with 256MB RAM. Is there anyone have experience with 12.0(5)T1? Is it stable? If it is not stable, we have only one option remaining, 11.1(?)CC. Please tell me your experiences. Basically we will try to turn off "ip cef" and "ip route-cache" option, too. I appreciate your comment. Thanks in advance. Hyun ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hyunseog Ryu Network Engineer/Applications Engineering Norlight Telecommunications, Inc. 275 North Corporate Drive Brookfield, WI 53045-5818 Tel. +1.262.792.7965 Fax. +1.262.792.7733

2 1

Re: TrACESroute 6.0 release
by Martin Cooper 18 Nov '99

18 Nov '99

Ehud Gavron <GAVRON(a)ACES.COM> wrote: > Announcing the All New TrACESroute 6.0 GOLD! > > At the suggestion of several nanog readers, my traceroute 2.9.4 has been > renumbered to The All New TrACESroute 6.0 GOLD. Note that this is a > higher revision level than either Netscape 4.8, IE5, or AOL 5, and is > therefore the clearly superior software.* [...] > * In the United Kingdom, please consider this superiour software. Annoyingly perhaps, it's still "superior" at Hyde Park corner... ;-) M.

1 0