- NANOG - lists.nanog.org

Update: Sprint Outage
by Bownes, Robert M. (EXCH) 10 Mar '98

10 Mar '98

Interesting that my last notice took ~2 hours to get to NANOG and back to me... Anyway, an update. Looks like mostly voice traffic involved. Site (for those who didn't recognize it, like myself) of outage is in Florida. Unless I see some data traffic affected or demand for updates, I won't update this incident anymore. Bob >---------- >Sent: Tuesday, March 10, 1998 2:07 PM >Subject: RE: Sprint Outage > >Sprint has started repair and many areas can call out 800 >numbers again. The outage is affecting any 800 numbers >having to route through the Sprint Orlando DMS 250 and the >calling areas between Jacksonville to Atlanta. More to come. > >

1 0

Sprint Outage
by Bownes, Robert M. (EXCH) 10 Mar '98

10 Mar '98

forwarded from our NOC... Sprint has a major fiber outage affecting 89 DS-3s. The outage is between Marrianna and Sneed. Repair personnel are expected to be pon trouble location by 12:15 eastern. No ETR at this time. 800 customers not being able to complete calls that are riding the Sprint network. More to come.

1 0

Re: BGP Confederation config problem...
by Richard Parker 10 Mar '98

10 Mar '98

Andy McConnell wrote: >Avi Freedman suggested using a +1 metric when leaving each member-AS. >But it doesn't seem to help - perhaps I didn't do it right. >In fact, it doesn't look like the metrics are adjusted more than 1. >... >Setting the MED is the crux of the problem - I can set it "statically", >but the idea is to make the whole confederation dynamic. I want the >confederation to work like a true "internet". (Yes, I'm asking for the >world...) Andy, Perhaps a solution, albeit an ugly solution, to the problem is to use a large route-map that matches and increments the MED for the expected range of MED values. Each router would have a route-map to increment the metric on updates that it sends. On the Cisco this configuration might look something like the following: neighbor a.b.c.d route-map INC-MED out ! route-map INC-MED permit 1 match metric 0 set metric 1 route-map INC-MED permit 2 match metric 1 set metric 2 (etc.) If dorian's remark is true... >This won't work because Cisco's bgp implementation skips over MED >from neighboring sub ASes inside a confederation in its decision >process. ...then instead use a route map to increment the local preference for each route received. You would still probably want to set the MED from the local preference before you export routes so that the external neighbors (in other ASes) of the confederation members choose to send data into the confederation at the point closest to the ultimate destination. -Richard

2 1

Re: More smurf fun
by Jeffrey Haas 10 Mar '98

10 Mar '98

Dave Rand was known to have said: > Here's the latest group of smurf-able networks. [...] > Some of the phone calls were interesting. Many of the NOC staff did not > know what a smurf attack was (so I explained it to them). Many did not want > to set no ip directed-broadcast because they didn't know what it would do. [...] > 148.59.0.0 A quick note: If you find yourself having problems from this netblock, please contact either jmh(a)msen.com (me) or noc(a)msen.com. We currently cannot disable directed broadcast due to a NASTY bug in the packet forwarding code of the Proteon routers we use on our backbone. We are working with Proteon to solve this issue. (I'm also trying to figure out if the issue is worth posting to Bugtraq.) In the meanwhile, we have implemented blackhole routing for the subnets that seemed to be at issue. > Dave Rand -- Jeffrey Haas "He that breaks a thing to find out what it is has elezar(a)pfrc.org left the paths of wisdom." (Or works for Fermilab...)

2 1

More smurf fun
by dlr＠bungi.com 10 Mar '98

10 Mar '98

Here's the latest group of smurf-able networks. Note some cool, high-connectivity networks are on here, like Bay Networks. At least one was still active on mae-west, if you can believe it. I've filed trouble tickets with each of the network's NSP's that are on here. Operators, please check to see if a network you advertise is on this list. If it is, please set no ip directed broadcast on the lan interfaces (or get your customers to do it, as appropriate). Some of the phone calls were interesting. Many of the NOC staff did not know what a smurf attack was (so I explained it to them). Many did not want to set no ip directed-broadcast because they didn't know what it would do. Most were helpful, however, called back in a timely fashion, and had their interfaces configured quickly. 128.139.0.0 132.166.0.0 132.169.0.0 132.202.0.0 132.226.0.0 132.229.0.0 132.248.0.0 132.74.0.0 132.77.0.0 132.79.0.0 132.80.0.0 132.87.0.0 134.120.0.0 134.121.0.0 134.177.0.0 134.205.0.0 134.39.0.0 134.57.0.0 134.59.0.0 134.74.0.0 134.82.0.0 134.87.0.0 136.205.0.0 138.210.0.0 138.231.0.0 138.28.0.0 138.73.0.0 139.181.0.0 139.223.0.0 139.51.0.0 139.70.0.0 139.91.0.0 140.185.0.0 148.132.0.0 148.144.0.0 148.59.0.0 149.35.0.0 192.93.124.0 198.32.136.0 198.118.128.0 199.209.166.0 -- Dave Rand dlr(a)bungi.com http://www.bungi.com

2 1

Re: BGP Confederation config problem...
by Andy McConnell 10 Mar '98

10 Mar '98

At each member AS, either IGRP or OSPF. They do not interact. By design... two of the AS's are across the Pacific from the other two :-) -Andy -- Andy McConnell アンディマッコネル Network Architect, NTT Multimedia Communications Laboratories Slogan of 105.9, the classic rock radio station in Chicago: "Of all the radio stations in Chicago ... we're one of them." On Fri, 6 Mar 1998, Blake Willis wrote: blakew> Andy, blakew> blakew> What IGP are you running on this network? blakew> blakew> -Blake Willis blakew> CAIS Engineering blakew> blakew> --------------------------------------------------------------------------- blakew> Blake Willis 703-448-4470x483 blakew> Network Engineer, New Customers blakew(a)cais.net blakew> CAIS Internet, a CGX Communications Company blakew> --------------------------------------------------------------------------- blakew> blakew> On Fri, 6 Mar 1998, Andy McConnell wrote: blakew> blakew> > I have a problem I cannot solve. If anyone is running confederations like blakew> > mine, I would appreciate some help :-) blakew> > blakew> > We have a 4-memberAS confederation, each with two IBGP peers. The blakew> > arrangement looks sort of like an octagon. the "r" is AS3 is an internal blakew> > hop, not a BGP peer. blakew> > blakew> > _______ ______ blakew> > | R-----R---r | blakew> > | / | | | | blakew> > |AS2 R | |AS3 R | blakew> > ----|-- ----|- blakew> > | | blakew> > ____|__ ____|_ blakew> > |AS4 R | |AS1 R | blakew> > | \ | | / | blakew> > | R-------R | blakew> > ------- ------ blakew> > blakew> > The problem is this: How do you get BGP to choose the shortest "AS PATH", blakew> > since internal AS paths are ignored in selecting BGP routes? Right now, blakew> > to top router in AS4 will always choose a route through (2 3 1) instead of blakew> > (1), because it prefers "external" routes (even external confederation blakew> > routes) over internal routes. blakew> > blakew> > So, when given a choice, the router on the distant side of the AS will blakew> > ALWAYS prefer the three-AS-hop path, because it is external. Is there a blakew> > way around this?!? blakew> > blakew> > Avi Freedman suggested using a +1 metric when leaving each member-AS. blakew> > (Thanks Avi!) But it doesn't seem to help - perhaps I didn't do it right. blakew> > In fact, it doesn't look like the metrics are adjusted more than 1. for blakew> > example, from AS2, the lower router sees every route outside of AS2 as blakew> > having only metric 1! The top router in AS3 does not add 1 to the metrics blakew> > it readvertises to AS2. blakew> > blakew> > I've been stewing over this problem for some time... I believe there is blakew> > some clue that I've missed. Any help would be greatly appreciated! blakew> > blakew> > -Andy blakew> > blakew> > blakew> > -- blakew> > Andy McConnell アンディマッコネル blakew> > Network Architect, NTT Multimedia Communications Laboratories blakew> > blakew> > Writing about music is like dancing about architecture. blakew> > blakew>

5 6

simple question as always..
by mhirse＠UU.NET 10 Mar '98

10 Mar '98

They seem to using access-list on their gateway routers. That would explain your problem. Mohamed Dear nanog, could someone explain to me why I can ping but traceroute seems to have problem reaching it. i.e. ping -s auth3.ipass.com. 64 bytes from holmes.ipass.com (204.198.128.102): icmp_seq=0. time=352. ms yet traceroute ... 6 s2/2-decker-hi.digisle.net (167.216.156.57) 147 ms 149 ms 148 ms 7 s2/2-decker-hi.digisle.net (167.216.156.57) 205 ms * 147 ms 8 * s2/2-decker-hi.digisle.net (167.216.156.57) 152 ms * 9 s2/2-decker-hi.digisle.net (167.216.156.57) 148 ms * 159 ms 10 * s2/2-decker-hi.digisle.net (167.216.156.57) 148 ms * 11 s2/2-decker-hi.digisle.net (167.216.156.57) 177 ms * 161 ms ... thnx in adv. tatsuya = = = = = = BEEOCB 03-3239-0607 fax 03-3239-2609 business network telecom http://www.giganet.net

2 1

simple question as always..
by Tatsuya Kawasaki 10 Mar '98

10 Mar '98

Dear nanog, could someone explain to me why I can ping but traceroute seems to have problem reaching it. i.e. ping -s auth3.ipass.com. 64 bytes from holmes.ipass.com (204.198.128.102): icmp_seq=0. time=352. ms yet traceroute ... 6 s2/2-decker-hi.digisle.net (167.216.156.57) 147 ms 149 ms 148 ms 7 s2/2-decker-hi.digisle.net (167.216.156.57) 205 ms * 147 ms 8 * s2/2-decker-hi.digisle.net (167.216.156.57) 152 ms * 9 s2/2-decker-hi.digisle.net (167.216.156.57) 148 ms * 159 ms 10 * s2/2-decker-hi.digisle.net (167.216.156.57) 148 ms * 11 s2/2-decker-hi.digisle.net (167.216.156.57) 177 ms * 161 ms ... thnx in adv. tatsuya = = = = = = 電話 03-3239-0607 fax 03-3239-2609 business network telecom http://www.giganet.net

1 0

Re: Local Exchanges?
by Steven Huter 10 Mar '98

10 Mar '98

Joel Sadler wrote: > b. If there is no such list, I'd really like to get it started. The Exchange Point info Bill Manning maintains also includes local IXs in Asia, Africa, Middle East, ALyC, etc. It would be more helpful to just contribute to keeping those all of those pages current. Regards, Steve Huter, NSRC http://nsrc.org/

2 1

Routing policies
by Ben Buxton 09 Mar '98

09 Mar '98

As some of you may not be aware, several traditional class A address ranges have been allocated to various NICs who are then sub-allocating them in blocks of /19. One of these is 61/8. I've been allocated one of these (68.8.0/19), and have been trying to get it routed properly on the net. However numerous providers filter almost all of the class A space at /8, rendering these allocations fairly useless. I've mailed a couple of providers and they've kindly changed their policies to allow for this. Can all providers please update their filter policies to allow for these /19 chunks? I know there is at least 24/8 and 61/8 but there may be more. Thanks -- Ben Buxton_____________________ o _ _--_|\ ZIP Internet P/L Zip Guy bb(a)zip.com.au /____|___|_)________/______\______________________ Voice: 9270-4777 | . \_.--._* Virtually Dial-in: 9247-7288, 9247-9144 Fax: 92475276 v the best :)

1 0