December 1999 - Test - lists.nanog.org

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

Re: Please help me...
by Hyunseog Ryu/Brookfield/Norlight 08 Dec '99

08 Dec '99

I tried that already. I can see the routing information from GTE for our network information in route-views.oregon-ix.net. But route-server.cerf.net does not show any routing information from GTE. In this situation, I'm thinking the possibility for routing problem if UUNET connection is down by accident or something like that. Hyun Kevin Nicholson <kcn(a)skycache.com> on 12/08/99 12:10:45 PM To: Hyunseog Ryu/Brookfield/Norlight <HRyu(a)norlight.com> cc: (bcc: Hyunseog Ryu/Brookfield/Norlight) Fax to: Subject: Re: Please help me... On Wed, 8 Dec 1999, Hyunseog Ryu/Brookfield/Norlight wrote: > Hi, folks > > Please help me. > I need your help. > If you have the right to access your router, > please send me the result of following command at your router. > > Show ip bgp reg 1_7260 > > Maybe it will be long. > But I need that. why not just telnet to route-server.cerf.net or route-views.oregon-ix.net and do a sh ip bgp regexp yourself. -Kevin Hyun

2 1

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

08 Dec '99

> 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.

1 0

Re: CNN connection
by Hyunseog Ryu/Brookfield/Norlight 08 Dec '99

08 Dec '99

Thank you for your comment. The problem is not a network down. They blocked traceroute and ping for their internal network. ;< I didn't think about that. There is no way to confirm network connection except real WWW traffic. Thank you, again. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hyun Ryu Network Engineer/Applications Engineering Norlight Telecommunications Tel. +1.262.792.7965 Fax. +1-262.792.7733

1 0

CNN connection
by Hyunseog Ryu/Brookfield/Norlight 08 Dec '99

08 Dec '99

Good morning Do you know anything about CNN connection? It seems that they have some internet network problem or something like that. I couldn't reach to cnn.com. One of our customer complained about that yesterday. But it still doesn't work. I checked SPRINT, GTE, and UUNET connection also, but it was same result. Traffic was timeout at the serial port of CNN gateway. If you have some information about this, please let me know. 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

1 0

Please help me...
by Hyunseog Ryu/Brookfield/Norlight 08 Dec '99

08 Dec '99

Hi, folks Please help me. I need your help. If you have the right to access your router, please send me the result of following command at your router. Show ip bgp reg 1_7260 Maybe it will be long. But I need that. Actually we connected to GTE recently. But we are not sure that our routing is going to anywhere in Internet. I used DIGEX's looking glass home page. But we can not see any information for our GTE connection from there. Please help me. 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

1 0

Re: Verio Decides what parts of the internet to drop
by George Herbert 08 Dec '99

08 Dec '99

Austin writes: >George writes: >>I am not sure whether the danger in opening up the B space for >>/17 blocks is particularly bad, but lacking a single consistent >>policy body with sufficient clue about both the Tier-1 backbone >>issues and the address allocation issues, it's hard to fault >>any given ISP for insisting on /16s in B space. >> > Sounds good, but what exactly does that mean? Does any end network >capable of justifying a /24 then get a routable chunk, thus blowing up the >tables? What if you could do it based upon traffic generation? That would be >difficult to verify, and the definition for 'large' amounts of traffic is >ever changing. > So, if we say that a /20 is a sufficiently large amount of space to >get a routable chunk, then they would be able to get it from ARIN anyway, >and we're back to square one. > In the far term as space becomes scarce we will need to find a solution >to wasted B space, but that is several years out. Perhaps by that time routers >will have so much memory and CPU as to make an extra ~4 million possible routes >negligible. The danger of /17 blocks in B space is limited to 64*256 more routes (16 k more, maximum). All at once that would be bad, but over time it would be reasonable. I would personally, were I setting route policy at a Tier 1, allow a /17 in B space, but there's no reason to try and force anyone else to accept that. As others don't right now and aren't inclined to, I would dissuade anyone from trying it as it's either going to be a royal pain or impossible to get routing for. Again, this is where not having a single policy body is killing us; some people get oddball blocks, somehow or another, and are then screwed on routability. I am most certainly not going to suggest radical surgery to the current way of doing it; right now, small places deserving of multihoming have to work at it, and you have to be clued enough to not step in a few holes like trying to portably subdivide a B. I am not sure that there's any obvious fix in the nearterm for those problems, which are avoidable. As long as they're avoidable I think the thing to do is to leave well enough alone. -george william herbert gherbert(a)crl.com Disclaimer: I speak for myself only, not my ISP, Cats, wife, or car.

7 6

Re: multi-homing
by Rich Braun 07 Dec '99

07 Dec '99

Roeland M.J. Meyer <rmeyer(a)mhsc.com> wrote on Dec 5: > For large capacity sites, colo is the only way, with potential self-homing > within two years. It just can't happen faster than that. Also, smaller > providers are out, because of public peering point congestion and that is > usually their only avenue. As someone else pointed out, us smaller providers often have multiple connections to tier-1's. In the past, it was likely that your friendly local ISP had only two tier-1 pipes and your regional had a big pipe into one of the NAPs. But given the overwhelming market consolidation of the tier-1's these days, independent regionals are more likely to have done what we've done: just go out and pay UUNET, GTE, et al whatever their toll is so we can guarantee high availability. Even at those high prices, we can still provide better service than any one of those companies can on its own within our market (i.e. it's no big deal to UUNET if their Boston PoP goes down for a few minutes, but it would be if _our_ Boston PoP went down). What I'm also finding these days is that, with the exception of UUNET, wholesale pricing is favorable to us. This business model has, in fact, recently sold well on Wall Street. A company called InterNAP just went public, and that's what they're doing. > Large providers, with their own private > dark-fiber network, leaving only last-mile traffic to the public Internet, > appears to be the only way to go <sigh>. I sure hope not...it takes even longer for them to bring up a new long-haul link than it does for us to upgrade or bring in a new local circuit to one of the major tier-1's. -rich

2 1

IOPS silent night press release
by Sean Donelan 07 Dec '99

07 Dec '99

IOPS.ORG has issued its press release about its "silent night" Y2K monitoring effort over the New Year's weekend. http://www.iops.org/iops-release.html Blame me, not merit, for the mention of nanog. It should NOT be taken as an endorsement or selection by nanog of special ISPs. But as a convient shorthand to refer to the group of ISPs from the nanog mailing list who are participating in some Y2K monitoring and notification efforts.

1 0