- NANOG - lists.nanog.org

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

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

08 Dec '99

>>> 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? > Interesting question... even though it's significantly faster than an hard > drive, it does have some inherent bottlenecks such as a maximum number of > operations per second which might be a little stifling on a backbone core > router :) Still, I've never actually tried *that*, so don't know for sure. > > There's also latency in other areas - that leads me to think that regular > memory is still faster. Finally, it would be attached to the host system > through a bus (SCSI, whatever) that's a lot slower than the internal > memory bus. > > These kinds of devices tend to be a better fit for systems that doesn't > have extreme time limitations on processing data such as for mail spool > files, etc. 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. telcos don't mind a second or two in call setup, because it is CALL SETUP, not 42 times a second. [ credit scott bradner for making this quite clear even to me in some ietf bar ] randy

1 0

Problems with sl-bb10-rly?
by Ryan Tucker 08 Dec '99

08 Dec '99

Greetings... Anyone else noticing problems with Sprint's sl-bb10-rly router? 4 sl-bb10-pen-6-1.sprintlink.net (144.232.9.102) 18.171 ms 12.329 ms 12.302 ms 5 sl-bb10-rly-10-1.sprintlink.net (144.232.8.153) 785.079 ms 787.017 ms 787.332 ms Another admin here noticed the same problem coming into bb10-rly from one of the NYC routers, so it doesn't look like just that pipe... An e-mail to noc(a)sprint.net this morning hasn't been responded to (not even by an autoresponder), and I haven't heard anything on NANOG, so just checking to see if anyone in NANOG land knows what's up. Thanks! -rt -- Ryan Tucker <rtucker(a)netacc.net> Unix Systems Administrator NetAccess, Inc. Phone: +1 716 756-5596 3495 Winton Place, Building E, Suite 265, Rochester NY 14623 www.netacc.net

2 2

Re[2]: RPSL announcement text
by chuck_metzger＠MERCER.COM 08 Dec '99

08 Dec '99

Please remove Chuck_Metzger(a)mercer.com from this list! He no longer works here. ____________________Reply Separator____________________ Subject: Re: RPSL announcement text Author: Sean Donelan <sean(a)donelan.com> Date: 12/8/99 10:50 AM > Hmm, who was this clueless manager who decided to do such things in the 1-th > of January. I guess the programmers over the world will be very busy during > january looking for the hidden Y2K bugs and fixing it, and why RADB decided > to add some more troubles just in this days? Why don't wait until, at least, > February? What terrible happen if this changes will be delayed a little? One way or another, the old routing description language will stop working at the end of this century. The syntax doesn't include four-digit years or a rollover of two digit years. Merit could terminate support sooner, but they can't really extend it. Although there have been several announcements about the end of life for ripe-181, and everyone should have switched by now, I'm sure someone will not update their procedures until after it breaks. Should Merit have "broken" them on December 1 instead of January 1? I don't know. I guess it goes under the saying, no good deed goes unpunished. Hopefully most of those users broke already when Merit changed the default on the servers, and have used the last couple of months to update their procedures. Of course those networks which have never used a routing database will say, Nah, Nah, I told you so. Received: from segue.merit.edu ([198.108.1.41]) by mail.mercer.com with SMTP (IMA Internet Exchange 3.13) id 0005AD6B; Wed, 8 Dec 1999 12:58:25 -0600 Received: by segue.merit.edu (Postfix) id 8FC965DDC6; Wed, 8 Dec 1999 13:56:09 -0500 (EST) Delivered-To: nanog-outgoing(a)merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1DD305DDC5; Wed, 8 Dec 1999 13:56:09 -0500 (EST) Received: from c004.sfo.cp.net (c004-h020.c004.sfo.cp.net [209.228.14.67]) by segue.merit.edu (Postfix) with SMTP id 4E8835DDBF for <nanog(a)merit.edu>; Wed, 8 Dec 1999 13:56:06 -0500 (EST) Received: (cpmta 23407 invoked from network); 8 Dec 1999 10:50:02 -0800 Date: 8 Dec 1999 10:50:02 -0800 Message-ID: <19991208185002.23406.cpmta(a)c004.sfo.cp.net> X-Sent: 8 Dec 1999 18:50:02 GMT Received: from [12.75.45.110] by mail.donelan.com with HTTP; 08 Dec 1999 10:50:02 PST Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: nanog(a)merit.edu From: Sean Donelan <sean(a)donelan.com> X-Mailer: Web Mail 3.3 Subject: Re: RPSL announcement text Sender: owner-nanog(a)merit.edu Precedence: bulk Errors-To: owner-nanog-outgoing(a)merit.edu X-Loop: nanog

1 0