- Test - lists.nanog.org

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

RPSL announcement text
by Gerald Andrew Winters 09 Dec '99

09 Dec '99

A reminder for users of the RADB database service: at 12:00:00 a.m. EDT on January 1, 2000, the transition to the Routing Policy Specification Language (RPSL) database will be complete. After January 1, RIPE-181 object submissions will no longer be accepted. RIPE-181 submissions made between now and 1/1/2000 will continue to be visible on whois.radb.net as RIPE-181 objects converted to RPSL. Availability of the database in both syntax languages eases the transition to RPSL by allowing users to view RIPE-181 objects converted to RPSL. RIPE-181 queries will be possible until January 1 via whois queries to whois-ripe181.radb.net. However, you will need to *RECONFIGURE* your tools to explicitly query whois-ripe181.radb.net and send RIPE-181 submissions to auto-ripe181.radb.net. For more information, see: http://www.merit.edu/radb/announce.html Please send questions or comments to db-admin(a)radb.net. --Gerald Winters Merit IRRd team

6 9

Re: A call for the future. Was: Re: Verio Decides what parts ofthe internet to drop
by Dean Anderson 08 Dec '99

08 Dec '99

Around 03:09 PM 12/8/1999 -0800, rumor has it that Randy Bush said: >reality check: > >if you had 100TB of on-ASIC SRAM you would still be screwed. you can't >afford the PER-PACKET LATENCY of telco number style portability REFERRAL. > >once again: ip is a connectionless protocol. each packet is potentially a >new route. Potentially, but not really. >telcos don't mind a second or two in call setup, because it is CALL SETUP, >not 42 times a second. Call setups do not take a second or two. Call setups that traverse 50 switches take a second or two. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: A call for the future. Was: Re: Verio Decides what parts ofthe internet to drop
by Dean Anderson 08 Dec '99

08 Dec '99

Around 04:18 PM 12/8/1999 -0500, rumor has it that Vijay Gill said: > >On Wed, 8 Dec 1999, Dean Anderson wrote: > >> >ip is a connectionless protocol. before hitting the reply key, think about >> >that. >> >> I thought about it. It seems to me that a router is not presented with a >> stream of randomly addressed packets. In any time frame, there are going >> to be from 1 to many hundreds of packets between the same set of >> addresses. > >This is a major fallacy. Yes, fallacy that you can do this today with current routers. I agree. But the problem is that the existing routers are too slow. Jared says let the buyer beware. Well, if you nail the roughly current routing policies described, we run out of space in practice much sooner that we would otherwise. So the space becomes more valuable. Subnetting A's and B's is inevitable. Router technology will need to be more robust in the future. But the choice comes down to this: Do it (figure out how to do it) or run out of useful space a lot quicker than we expected to run out of actual space. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0