February 2002 - Test - lists.nanog.org

Just keep telling yourself, "Worldcom won't fail, Worldcom won't fail"
by Fletcher E Kittredge 25 Feb '02

25 Feb '02

This is an interesting NYT article (free registration required) for all of those of us trying to convince themselves that even if Worldcom goes bankrupt, UUnet will stay up. The example used is Global Crossings. If a company has complex enough finances and gets deeply enough under water, the courts might not be able to figure it out and creditors may just liquidate... whether or not it makes sense for the customers and society as a whole. If the government is not willing to step in for Enron, would they step in for UUnet? http://www.nytimes.com/2002/02/25/technology/25GLOB.html By the way, I never said to Dan Hollis and others: "You were right; I was wrong." about Global Crossing. If one had listened to Dan, one would have known 12 months that Global Crossing was in trouble. I read their press releases and balance sheets and didn't see it... Mea Culpa. regards, fletcher

1 0

Re: [nsp] Cisco DS3 Questions..
by rs＠seastrom.com 25 Feb '02

25 Feb '02

Jesper Skriver <jesper(a)skriver.dk> writes: > On Mon, Feb 25, 2002 at 07:36:11AM -0800, Eliot Lear wrote: > > > > At 09:24 PM 2/22/2002 +0100, Jesper Skriver wrote: > > > > > > int Serial0 > > > > encap hdlc > > > > down-when-looped > > > > > >I know, but that needs to be configued in both ends, and as it's not the > > >default, it's likely not to be configured on the CPE device ... > > > > Neither is PPP. > > The customer will never get the link up if he/she doesn't > configure PPP, he/she will get link up if the link is configured > for HDLC but they havn't configured 'down-when-looped' The customer's failure to configure "down-when-looped" on his end will not adversely affect the behavior of "down-when-looped" on your end. But this argument is really pedantic and silly. Can we call it quits? Please? ---rob

2 1

Cisco DS3 Questions..
by Gyorfy, Shawn 25 Feb '02

25 Feb '02

Since the topic exploded, what are your opinions on encapsulation of leased line DS3s. We currently use Frame Relay for out Point to Point DS3 connections. Personally, I don't know why we use FR as our encapsulation, and so the question to all. If you are running Cisco to Cisco, would it be wise to run HDLC or PPP? Our DS3s' here are hardly maxed out, 15% or so, so I'm not complaining about the few extra bits I can squeeze out them but maybe that 15% can shrink to 10% with less overhead. Opinions or examples of life appreciated. Thanks shawn -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] Sent: Wednesday, February 20, 2002 4:28 PM To: Jon Mansey Cc: nanog(a)merit.edu Subject: Re: Cisco PPP DS-3 limitations - 42.9Mbpbs? On Wed, 20 Feb 2002, Jon Mansey wrote: > OMG! Arent we missing the point here? What about never running links above > 60% or so to allow for bursts against the 5 min average, and <shudder> > upgrading or adding capacity when we get too little headroom. > And here we are, nickel and diming over a few MBps near to 45M on a DS3... And why not? Obviously there is a reason why they're not upgrading, because there is plenty of traffic to fill up a second or faster circuit if packets are being dropped because of congestion. (Which has not been confirmed so far.) There shouldn't be any problems pushing a DS3 well beyond 99% utilization, by the way. With an average packet size of 500 bytes and 98 packets in the output queue on average, 99% only introduces a 9 ms delay. The extra RTT will also slow TCP down, but not in such a brutal way as significant numbers of lost packets will. Just use a queue size of 500 or so, and enable (W)RED to throttle back TCP when there are large bursts.

10 11

IEPG in Minneapolis?
by Howard C. Berkowitz 24 Feb '02

24 Feb '02

Will there be an IEPG on Sunday?

1 0

The Cidr Report
by CIDR Report 23 Feb '02

23 Feb '02

This is an auto-generated mail on Fri Feb 22 23:00:00 PST 2002 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. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. 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 GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 22Feb02 0) General Status Table History ------------- Date Prefixes 150202 105693 160202 105736 170202 105803 180202 105879 190202 105989 200202 106186 210202 105821 220202 106236 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 96.0.0.0/20 from AS3549 AS Summary ---------- Number of ASes in routing system: 12451 Number of ASes announcing only one prefix: 7566 (4299 cidr, 3267 classful) Largest number of cidr routes: 728 announced by AS701 Largest number of classful routes: 1369 announced by AS701 1) Gains by aggregating at the origin AS level --- 22Feb02 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1150 886 264 23.0% Telstra Pty Ltd AS701 1369 1125 244 17.8% UUNET Technologies, Inc. AS17557 224 96 128 57.1% Pakistan Telecom AS7018 836 712 124 14.8% AT&T AS577 320 197 123 38.4% Bell Advanced Communications Inc. AS16473 198 77 121 61.1% Bell South AS4151 254 149 105 41.3% USDA AS705 309 205 104 33.7% UUNET Technologies, Inc. AS852 425 324 101 23.8% Telus Advanced Communications AS6595 150 55 95 63.3% DoD Education Activity Network As AS7046 324 239 85 26.2% UUNET Technologies, Inc. AS19632 94 9 85 90.4% Metropolis Intercom S.A. AS2048 186 105 81 43.5% State of Louisiana AS12302 110 31 79 71.8% MobiFon S.A. AS1239 482 405 77 16.0% Sprint AS4323 432 356 76 17.6% Time Warner Communications, Inc. AS4755 221 147 74 33.5% Videsh Sanchar Nigam Ltd. Autonom AS3908 339 271 68 20.1% Supernet, Inc. AS3464 157 97 60 38.2% Alabama SuperComputer Network AS724 215 156 59 27.4% DLA Systems Automation Center AS7303 106 48 58 54.7% Telecom Argentina Stet-France Tel AS16758 63 6 57 90.5% IKON Office Solutions AS226 145 89 56 38.6% Los Nettos AS19834 63 8 55 87.3% NetForce, Inc. AS10620 77 22 55 71.4% TVCABLE BOGOTA AS9051 75 22 53 70.7% INCONET Autonomous System AS702 621 568 53 8.5% UUNET Technologies, Inc. AS703 271 219 52 19.2% UUNET Technologies, Inc. AS2149 305 253 52 17.0% Performance Systems, Inc. AS209 300 248 52 17.3% Qwest Total 53958 42075 11883 22.0% 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

XO Communication expects to file for bankruptcy
by Joe Blanchard 22 Feb '02

22 Feb '02

FYI > XO Communication expects to file for bankruptcy--report > > NEW YORK, Feb 21 (Reuters) - Voice and data services firm XO > Communications > Inc. (OTC BB:XOXO.OB - news) expects to file for Chapter 11 bankruptcy > protection within the next two weeks, Business Week magazine reported on > Thursday. > > XO, founded by wireless pioneer Craig McCaw, said on Nov. 29 that buyout > firm Forstmann Little and Mexican telecommunications firm Telefonos de > Mexico S.A. de C.V. planned to invest $400 million each in XO. > > But XO said the restructuring, if completed, would essentially leave > current stockholders with nothing. > > Business Week reported that XO expects to file for bankruptcy protection > in > order to convince debtholders to agree to the restructuring plan. > > ``It could happen in days; it could be two weeks,'' a source close to XO > told the magazine. > > XO was not immediately available for comment. >

2 1

RE: [nsp] Cisco DS3 Questions..
by Martin, Christian 22 Feb '02

22 Feb '02

> link in a controlled way. Not saying that's a particularly > good use, just > that that's the most common reason I've seen it deployed on otherwise > simple point-to-points. The idea behind frame relay is that > it gives you > a multipoint layer-2 protocol to use on a more complicated network of > circuits. > > -Bill It can also be used to 'equalize' two links of different speeds in such a way that you can do reasonable equal-cost load-balancing. For example, if you have a DS3 and an OC3, you can create 3 FR subinterfaces on the OC3 and add the DS3 to the mix to give you essentially 4 DS3s. There is a slight speed difference, but it is minimal. This can be done for 2 OC-12s and an OC-48, for example. Another reason for virtualizing a ptp circuit is for differentiate billing in a MPLS VPN environment with an Internet offload component. You can direct VPN traffic on one VC and Internet on the other, and then take advantage of basic MIB-II stats for billing and per-(sub)interface CAR for enforcement of contract and reclassification, etc. regards, chris

1 0

RE: [nsp] Cisco DS3 Questions..
by Daniel Golding 22 Feb '02

22 Feb '02

That sub-interface numbering is useless for a point-to-point circuits. - Daniel Golding > -----Original Message----- > From: Eric So [mailto:eric.so@graduate.hku.hk] > Sent: Thursday, February 21, 2002 5:16 PM > To: Gyorfy, Shawn > Cc: 'nanog(a)merit.edu'; 'cisco-nsp(a)puck.nether.net' > Subject: Re: [nsp] Cisco DS3 Questions.. > > > The proprietry HDLC will give you headache if you want > to change the platform in the future. > > FR encap gives you sub-interface numbering which acts > as an identifier to network devices through a proper > indexing scheme. > > -e > > On Thu, 21 Feb 2002, Gyorfy, Shawn wrote: > > > Since the topic exploded, what are your opinions on > encapsulation of leased > > line DS3s. We currently use Frame Relay for out Point to Point DS3 > > connections. Personally, I don't know why we use FR as our > encapsulation, > > and so the question to all. If you are running Cisco to Cisco, > would it be > > wise to run HDLC or PPP? Our DS3s' here are hardly maxed out, > 15% or so, so > > I'm not complaining about the few extra bits I can squeeze out them but > > maybe that 15% can shrink to 10% with less overhead. Opinions > or examples > > of life appreciated. > > > > Thanks > > > > shawn > > > > -----Original Message----- > > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > > Sent: Wednesday, February 20, 2002 4:28 PM > > To: Jon Mansey > > Cc: nanog(a)merit.edu > > Subject: Re: Cisco PPP DS-3 limitations - 42.9Mbpbs? > > > > > > On Wed, 20 Feb 2002, Jon Mansey wrote: > > > > > OMG! Arent we missing the point here? What about never > running links above > > > 60% or so to allow for bursts against the 5 min average, and <shudder> > > > upgrading or adding capacity when we get too little headroom. > > > > > And here we are, nickel and diming over a few MBps near to > 45M on a DS3... > > > > And why not? Obviously there is a reason why they're not upgrading, > > because there is plenty of traffic to fill up a second or faster circuit > > if packets are being dropped because of congestion. (Which has not been > > confirmed so far.) > > > > There shouldn't be any problems pushing a DS3 well beyond 99% > utilization, > > by the way. With an average packet size of 500 bytes and 98 > packets in the > > output queue on average, 99% only introduces a 9 ms delay. The extra RTT > > will also slow TCP down, but not in such a brutal way as significant > > numbers of lost packets will. Just use a queue size of 500 or so, and > > enable (W)RED to throttle back TCP when there are large bursts. > > >

1 0

Strange behavior
by Christopher J. Wolff 21 Feb '02

21 Feb '02

Greetings, For the last two days I've seen massive delays around the following hops: Does anyone have any thoughts on what is going on? 9 15 ms 31 ms 32 ms 0.so-0-3-0.XL1.LAX9.ALTER.NET [152.63.115.2] 10 32 ms 31 ms 31 ms 0.so-1-0-0.TL1.LAX9.ALTER.NET [152.63.115.142] 11 47 ms 31 ms 47 ms 0.so-4-0-0.TL1.SAC1.ALTER.NET [152.63.0.98] 12 1109 ms 1360 ms 1547 ms 0.so-7-0-0.XL1.SJC2.ALTER.NET [152.63.55.105] 13 2110 ms 2093 ms 2016 ms POS1-0.XR1.SJC2.ALTER.NET [152.63.56.138] 14 1906 ms 1766 ms 2046 ms 193.ATM7-0.GW5.SJC2.ALTER.NET [146.188.144.25] Regards, Christopher J. Wolff, VP CIO Broadband Laboratories http://www.bblabs.com

3 2

RE: red [was Re: Cisco PPP DS-3 limitations - 42.9Mbpbs?]
by Brennan_Murphy＠NAI.com 21 Feb '02

21 Feb '02

Remember too that if you have multiple types of flows on your link (FTP, TELNET, HTTP) the key isn't so much to utilize your DS3 99% as it is to ensure that the end user's expectations aren't upset. So, you might use WRED to drop bulky FTP packets instead of Voice, Video, Telnet, some HTTP, etc...in those cases where you reach the threshold that you specify. Does an FTP user really notice if their download starts at 160kbs and gyrates around between 30-150kbs..especially if they are very large downloads? But a web page taking 12 seconds to load...not good. -----Original Message----- From: smd(a)clock.org [mailto:smd@clock.org] Sent: Wednesday, February 20, 2002 1:02 PM To: nanog(a)merit.edu Subject: red [was Re: Cisco PPP DS-3 limitations - 42.9Mbpbs?] randy bush writes: | you can turn on [x]red. it will make a better choice of which packets | to drop. but packets will still be dropped [0]. fsvo "better". red drops packets randomly, a little earlier than packets will be tail-dropped by being unable to find buffer space in a queue. in most cases, tail-drop is worst for TCP connections in slow-start, and leads to such fun things as web-page-slowdown-syndrome, or ssh-stall-syndrome, with the attendant hitting of the "reload" button or frustrated banging on the keyboard trying to get one's keys to echo back, or trying to unstick the page of text being sent to /dev/tty on the remote end. "r" for random: this spreads out loss randomly, and in most cases, this means that several different TCPs each observe a single lost segment, which is quickly detected and causes an attendant slow-down, but not a stall. "e" for early: we have to keep the queue from filling, because that leads to tail-drop, so we have to drop packets when we could really send them. there is no way around this -- in virtually any implementation, the mechanism to turn on red can be translated into more fifo-queue space. the trade-off (early random dropping) is usually worth it. there are some corner cases where there is insufficient ability to spread drops across enough flows, where resulting behaviour can be alot like tail-drop (a huge difference between fast input speed and slow output speed, with only a few bulk-transfer flows), but these cases are rare, particularly where average_segment_size / bottleneck_kbps <= 0.4, with the 0.4 being a historical minimum target for queueing in the presence of flows which experience long RTTs (like ones across oceans). in general, you don't have to worry about that, though. | you can increase buffers blah blah blah. but twenty tomatoes will still | not fit in a fifteen tomato can. yup, the trick is to deploy a red control law that drops just before tail-dropping would start, so we don't lose packets unnecessarily, yet early enough before tail-dropping would start that the senders have time to back off in response to the detected lost segment, which is driven by the RTT. drop too early, and you get an underused line. drop too late and you get tail-drop, which also gives you an underused line. drop just right, and you can keep your line very very very close to 100% for sustained periods of time (hours!), assuming a large enough set of TCP flows that random dropping spreads the early dropping across different flows. | [0] - corollary: qos mechanisims decide which packets to drop. but isps | are paid not to drop any packets. it is impossible to get 0 drop and enjoy statistical multiplexing gain. statmux gain keeps the network cheap enough to use. red minimizes the liklihood that anyone will complain about performance during those inevitable periods when one's statistical bet goes wrong. Sean.

2 1