- Test - lists.nanog.org

Re: BGP dampening parameters
by smd＠clock.org 10 Dec '99

10 Dec '99

"Other" Sean: | Have people adjusted their dampening parameters or are they still using the | Cisco defaults? Please see http://www.ripe.net/docs/ripe-178.html Sean.

1 0

BGP dampening parameters
by Sean Donelan 10 Dec '99

10 Dec '99

In the past when a large provider would do a rolling reboot of their routers, usually in the early morning, some routes would get dampened for a while. It usually cleared up before the morning business traffic hit. Although there were some complaints from our friends in Europe about rebooting routers in the middle of their business day. I haven't heard of BGP dampening issues for a while. Do they still happen? Have people adjusted their dampening parameters or are they still using the Cisco defaults? My concern is false reports due to the increasing number of sites who plan to bounce their networks overnight on New Year's. http://dailynews.yahoo.com/h/nm/19991209/wr/yk_usa_3.html The original BGP dampening parameters were very agressive. I don't know if all these sites are aware if they bounce their network more than a couple times in a short time, they will get dampened. And will start reporting Internet problems because their network was dampened. Has anyone in their lab testing done any work to see how well modern Cisco's react to large scale world-wide network reboots if lots of sites follow suit?

1 0

Need help from UUNet's routing specialist!
by Dmitry S. Esakov 10 Dec '99

10 Dec '99

Hello! We (as8470) are Teleglobe customer. And we experience terrible delays on Teleglobe to UUNet interconnect points. Teleglobe's customer support engineers insist, that the problem caused by UUNet's routes prioritization. But I belive that this assymetric routing initiated by Teleglobe, not UUNet. Could you please send me 'sh ip bgp 195.128.65.33' performed at Serial3-1-1.GW1.DCA3.ALTER.NET (157.130.39.89). I am expecting to see communities or MEDs set at TG router that lowres route priority and makes traffic to go back via _Seattle_Denver_Chicago_NY_. Any help is _greatly_ appreciated! --------------------- Example of delays: --------------------- nyy-1#trace Protocol [ip]: Target IP address: www.uu.net Translating "www.uu.net"...domain server (195.128.64.3) [OK] Source address: 195.128.65.33 Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to www.uu.net (208.243.117.123) 1 if-0-1-0.bb6.NewYork.Teleglobe.net (207.45.205.13) [AS 6453] 0 msec 0 msec 0 msec 2 if-3-0.core2.nqt.Teleglobe.net (207.45.221.98) [AS 6453] 4 msec 0 msec 0 msec 3 if-1-0.core1.Washington.Teleglobe.net (207.45.223.170) [AS 6453] 8 msec 4 msec 8 msec 4 if-2-0-0.bb1.Washington.Teleglobe.net (207.45.221.228) [AS 6453] 8 msec 4 msec 8 msec 5 Serial3-1-1.GW1.DCA3.ALTER.NET (157.130.39.89) [AS 701] 1356 msec 1152 msec 1180 msec ^^^^^^^^^^^^^^^^^^ !!!!!!!!!!! 6 110.ATM3-0.XR1.DCA1.ALTER.NET (146.188.161.54) [AS 701] 1048 msec 1144 msec 1136 msec 7 195.ATM8-0-0.GW1.DCA1.ALTER.NET (146.188.161.17) [AS 701] 1172 msec 1036 msec 1244 msec 8 260.GW1.TCO3.customer.ALTER.NET (157.130.33.222) [AS 701] 876 msec 788 msec 812 msec 9 prod-334a.tco3.web.uu.net (208.243.113.236) [AS 11486] 1112 msec [cut] Serial3-1-1.GW1.DCA3.ALTER.NET (157.130.39.89) ---------------- Have a nice day! Esakov Dmitriy, Macomnet Internet Dpt.

3 2

OPERATIONAL: NSI.Registery died yesterday. Updates lost
by John M. Brown 09 Dec '99

09 Dec '99

According to several NSI.Registrar techs (first and second level) that I spoke with today The SRS died yesterday. Updates made yesterday may not have made it to the real world. Further comments stated that updates today may also be problematic. Just a heads up on the REGISTERY

1 0

Event sites: Mars polar lander
by Sean Donelan 09 Dec '99

09 Dec '99

NASA engineer's made some public comments about the performance of the network and web sites during the Mars Polar Lander event. Even without any data from the lander, NASA used up much of its public bandwidth. http://www.fcw.com/pubs/fcw/1999/1206/web-mars-12-08-99.html I also heard from a couple of people about the problems I experienced accessing the mars polar lander cache pages. Apparently there was an operator error loading some of the information, leading to missing pages. It was quickly corrected, but not before the bad links got out to the mirrors.

1 0

Re: A call for the future. Was: Re: Verio Decides what parts of the internet to drop
by Andrew Bender 09 Dec '99

09 Dec '99

In the design of contemporary core routers, table maintenance and packet processing are discrete functions. The maintenance of comprehensive routing information that includes a superset of best paths is common practice, with proven benefits. However, it is neither necessary nor desirable to consult this database for a forwarding decision. Instead, the fastpath need only have knowledge of the best next hop matching a DA prefix. Whatever changes we believe to be in store for the table population, this is unlikely to affect the typical number of adjacencies for a core router. Assuming also that we continue to use IPv4 for a while, the "input length" of composite information for the FIB could be less than 7 bytes for unicast routes. For the 2.5E5 best paths discussed, this equates to approximately 1.4MB. Also, since the matching (ideally) yields a singular, exclusive result, this matching operation is easily "parallelized" , in hardware or otherwise; observed work need not even be linear with FIB size. In short, the technical obstacles presented by high table / route population are no greater for forwarding logic than for the control plane. Regards, Andrew Bender Total Network Solutions, Inc. > Date: Mon, 06 Dec 1999 18:27:07 -0800 > From: George Herbert <gherbert(a)crl.com> > > The issue isn't in storing hundreds of thousands, millions, > or tens of millions of routes. This is, all things considered, > a piece of cake. > > The issue is getting the route out of storage, for each packet coming > through the router, at a rate of millions of packets per second for > each core router. Each IP core router is doing about the same > lookup work as the whole combined PSTN network is for all of its > freely routed numbers. It is, or should be, quite viable... but not > easy, as we've all found. > > - -george william herbert > gherbert(a)crl.com >

1 0

Re: Need help from UUNet's routing specialist!
by Erik-Jan Bos 09 Dec '99

09 Dec '99

Dmitry, > We (as8470) are Teleglobe customer. And we experience terrible > delays on Teleglobe to UUNet interconnect points. Teleglobe's customer > support engineers insist, that the problem caused by UUNet's routes > prioritization. > But I belive that this assymetric routing initiated by Teleglobe, not > UUNet. We are a TGO customer as well and we do not see the problem. Here's a traceroute: surgeon bos % date Thu Dec 9 18:10:43 CET 1999 surgeon bos % traceroute www.uu.net traceroute to www.uu.net (208.243.117.123): 1-30 hops, 38 byte packets 1 surroute.surfnet.nl (192.87.109.1) 0.554 ms 0.441 ms 0.399 ms 2 AR1.Utrecht.surf.net (145.41.49.161) 101 ms 2.28 ms 1.82 ms 3 AR2.Utrecht.surf.net (145.41.7.181) 1.48 ms 2.14 ms 1.51 ms 4 BR7.Amsterdam.surf.net (145.41.7.125) 2.87 ms 2.70 ms 2.49 ms 5 BR2.Amsterdam.surf.net (145.41.7.146) 2.91 ms 2.71 ms 2.75 ms 6 BR2.NewYork.surf.net (145.41.7.110) 79.5 ms 79.9 ms 80.0 ms 7 if-6-3.core1.NewYork.Teleglobe.net (207.45.196.129) 79.8 ms 79.8 ms 79.7 ms 8 if-0-3.core2.nqt.Teleglobe.net (207.45.223.178) 80.0 ms 80.1 ms 80.6 ms 9 if-1-0.core1.Washington.Teleglobe.net (207.45.223.170) 84.6 ms 84.7 ms 84.8 ms 10 if-10-0-0.bb1.Washington.Teleglobe.net (207.45.221.195) 85.3 ms 85.6 ms 84.8 ms 11 Serial3-1-1.GW1.DCA3.ALTER.NET (157.130.39.89) 86.7 ms 87.2 ms 87.0 ms 12 110.ATM3-0.XR1.DCA1.ALTER.NET (146.188.161.54) 86.3 ms 86.0 ms 85.7 ms 13 195.ATM8-0-0.GW1.DCA1.ALTER.NET (146.188.161.17) 87.2 ms 88.0 ms 86.6 ms 14 260.GW1.TCO3.customer.ALTER.NET (157.130.33.222) 220 ms 112 ms 136 ms 15 prod-334a.tco3.web.uu.net (208.243.113.236) 92.7 ms * 88.3 ms Perhaps this is fixed? > Could you please send me 'sh ip bgp 195.128.65.33' performed at > Serial3-1-1.GW1.DCA3.ALTER.NET (157.130.39.89). > > I am expecting to see communities or MEDs set at TG router that lowres > route priority and makes traffic to go back via _Seattle_Denver_Chicago_NY_. > Any help is _greatly_ appreciated! > > --------------------- > Example of delays: > --------------------- > nyy-1#trace > Protocol [ip]: > Target IP address: www.uu.net > Translating "www.uu.net"...domain server (195.128.64.3) [OK] > > Source address: 195.128.65.33 > Loose, Strict, Record, Timestamp, Verbose[none]: > Type escape sequence to abort. > Tracing the route to www.uu.net (208.243.117.123) > > 1 if-0-1-0.bb6.NewYork.Teleglobe.net (207.45.205.13) [AS 6453] 0 msec 0 msec 0 msec > 2 if-3-0.core2.nqt.Teleglobe.net (207.45.221.98) [AS 6453] 4 msec 0 msec 0 m sec > 3 if-1-0.core1.Washington.Teleglobe.net (207.45.223.170) [AS 6453] 8 msec 4 msec 8 msec > 4 if-2-0-0.bb1.Washington.Teleglobe.net (207.45.221.228) [AS 6453] 8 msec 4 msec 8 msec > 5 Serial3-1-1.GW1.DCA3.ALTER.NET (157.130.39.89) [AS 701] 1356 msec 1152 mse c 1180 msec > ^^^^^^^^^^^^^^^^^^ > !!!!!!!!!!! > > 6 110.ATM3-0.XR1.DCA1.ALTER.NET (146.188.161.54) [AS 701] 1048 msec 1144 mse c 1136 msec > 7 195.ATM8-0-0.GW1.DCA1.ALTER.NET (146.188.161.17) [AS 701] 1172 msec 1036 m sec 1244 msec > 8 260.GW1.TCO3.customer.ALTER.NET (157.130.33.222) [AS 701] 876 msec 788 mse c 812 msec > 9 prod-334a.tco3.web.uu.net (208.243.113.236) [AS 11486] 1112 msec > [cut] > > > > Serial3-1-1.GW1.DCA3.ALTER.NET (157.130.39.89) __ Erik-Jan Bos Manager Network Services SURFnet The Netherlands, Europe

2 1

Re: A call for the future. Was: Re: Verio Decides what parts ofthe internet to drop
by rs＠seastrom.com 09 Dec '99

09 Dec '99

Tim Wolfe <tim(a)clipper.net> writes: > On Wed, 8 Dec 1999, Vijay Gill wrote: > > > Full route table size is not a problem. You can burn a hard disk as you > > mentioned to store it. The issue is getting data in and out of the > > processor, i.e. number of pins. Core flows are not ameneable to caching. > > This approach will fail the first time you see a new packet and need to > > swap from hard disk. > > Not that it would be very economical, but what are the technical > implications of using a solid state device (such as the Quantum's > RUSHMORE NTE series) instead of a normal hard drive? You slightly change the point at which life becomes unmanageable. In the grand scheme of things it would be about as noticeable as a 1/2 mpg increase in your car's fuel economy. ---Rob

1 0

Re: RPSL announcement text
by Joao Luis Silva Damas 09 Dec '99

09 Dec '99

Thanks David for you message. Yes, dates are not a fundamental part of RIPE 181 and the sw was modified a while ago to work with 4 digit years AND to understand that 00 means 2000, 01 means 2001... As for the migration to RPSL, the RIPE NCC is currently working on a new whois server which supports RPSL. We plan to migrate next spring (Northern Hemisphere). If you want to find more about this, please visit our website. Regards, Joao Damas ===================================================== | Joao Luis Silva Damas http://www.ripe.net | | RIPE DB Group Manager email: joao(a)ripe.net | | RIPE NCC | | Amsterdam | =====================================================

1 0

Re: RPSL announcement text
by Sean Donelan 09 Dec '99

09 Dec '99

On Wed, 08 December 1999, Randy Bush wrote: > the operational issue is not y2k this or that. the issue for ops folk is > that it is a change being made during what is anticipated to be the worst > part of the the y2k window which could be made some other time. this means > that, if it is visible in any way, it can be confused with y2k symptoms thus > adding to real operators' (as opposed to nanog posters') debugging problems > at what may be a bad time. I'm not a big fan of making changes that night, but this was announced several months ago at IETF, NANOG and several mailing lists. I didn't hear anyone object to the schedule when it was announced. I did hear people complain about the RADB maintainer fee, so people were listening. For better or worse, is it getting a bit late to go changing the schedule? Is anyone still using the ripe-181 version of the IRR?

1 0