October 1998 - Test - lists.nanog.org

globecomm
by william＠pacific.net.ph 26 Oct '98

26 Oct '98

Hi guys! Since I opened the topic here, I'd like to end it too. Iname has already contacted me on this and has shed light on the matter. For all those who posted here or privately, thank you. :) William

1 0

RE: Clue's for Clue-less
by Martin, Christian 26 Oct '98

26 Oct '98

> somewhat unilaterally denying prefixes without verification of the > > validity of their origin...Hmm, lets see...AS 1 sending the 4.0.0.0 > > netblock across a direct peering point, but it get's nicked > because of > > max-prefix, so it comes across through a multihomed > downstream and all > > of a sudden, sorry little multihomed downstream is carrying > 200 Megs of > > BBN transit. Oops! > > > > So, why would a multi-homed *downstream* be sending you > *upstream* routes .... Hrrrmmmmm ? > > > ;) > Poor filtering practices. As filter-lists grow in size and complexity, and the AS lists grow, there is the potential for leaks. All it takes is for and inexperienced/tired/clueless operator to turn up a T1 session with a multihomed downstream peer, and neglect the filter-list on their inbound updates. Then, considering that any other peer that advertises an AS that is two hops away has the same preference configured all the way through, we're talking router ID here. The OC3 session that is prefered doesn't see the routes, but they are coming in from other places, including the T1. bgp always-compare-med can help, but not everyone uses it. This can be bad. What I would like to see, though, is where the cutoff point takes place. Is it on updates, or insertions into the table? If it were updates, this would be horrible. So if the table is being pruned, where is it starting?

2 1

CW....also CNN
by noc＠nso.org 26 Oct '98

26 Oct '98

7 6

Re: CW....also CNN
by Scott Gifford 26 Oct '98

26 Oct '98

We saw these same problems this morning, on some addresses that are multihomed to CW and UUNet. UUNet recommended we announce our addresses with longer prefixes for a few minutes, then withdraw the announcements. Don't know why it worked, but it did... Anyways, might be worth a try if you're getting hosed by this. -------Scott. >> Traffic from me to best.com looks like: >> >> traceroute to shell4.ba.best.com (206.184.139.135), 30 hops max, 40 byte packets >> 1 eth-0.cisco-1.intur.net (206.97.151.1) 2.106 ms 2.073 ms 2.088 ms >> 2 border1-serial3-0.Dallas.cw.net (204.70.115.41) 72.321 ms 16.649 ms 203.451 ms >> 3 core1-fddi-0.Dallas.cw.net (204.70.114.17) 4.789 ms 5.113 ms 10.839 ms >> 4 bordercore1.SanFrancisco.cw.net (166.48.12.1) 72.705 ms 42.307 ms 41.859 ms >> 5 best-internet.SanFrancisco.cw.net (166.48.13.250) 1001.36 ms 1052.2 ms 1010.41 ms >> 6 core1-hssi8-0-0.mv.best.net (206.86.228.89) 979.218 ms 1007.01 ms 1000.45 ms >> 7 shell4.ba.best.com (206.184.139.135) 1013.52 ms * 1018.15 ms > > This is still quest yes, the routes are getting from qwest to sprint >then going on to uu.net.. it looks like its only happening in la tho.. maybe >a bad filter? > > At this time I'm not seeing anyone leaking routes to me, including >sprint. > >-- >Steven O. Noble -- Sr. Backbone Engineer, Exodus Communications (EXDS) > -- Work:408.346.2333 -- > All my love to the Canadian Mooing Frog. >

1 0

RE: Clue's for Clue-less
by Martin, Christian 26 Oct '98

26 Oct '98

I agree that core stability is of utmost importance, but by randomly and somewhat unilaterally denying prefixes without verification of the validity of their origin...Hmm, lets see...AS 1 sending the 4.0.0.0 netblock across a direct peering point, but it get's nicked because of max-prefix, so it comes across through a multihomed downstream and all of a sudden, sorry little multihomed downstream is carrying 200 Megs of BBN transit. Oops! I would think that the only thing that this command protects is routers with slim memory profiles. Core routers should let the BGP decision process clean the routes, although I do get scared when 10,000 new routes appear over the weekend. After this weekends fiasco, I can see your reasons, though. Maybe RSNG is useful after all... Chris > -----Original Message----- > From: Richard Irving [mailto:rirving@onecall.net] > Sent: Monday, October 26, 1998 4:27 PM > To: Martin, Christian > Cc: 'nanog(a)merit.edu' > Subject: Re: Clue's for Clue-less > > > No proof one way, or the other, Martin.... > > The only neighbors I lost on this one, dumped something > they shouldn't..... If someone de-aggregates a /16, > it fires off alarms.... Although these may be valid advertisements, > We have opted for the "safe, rather than sorry" perspective. > (Besides, the alarms *assure* prompt attention) > > Running the internet requires a certain degree of Altruism. > One should set policies that *protect* the core, rather than one's > own....... ;) > > Doing other than this will result in a global internet > that is not reliable...And we all lose. > > "The good of the many, outweigh the desires of the few" > > (No matter *how* expensive a tie they wear ;) > > PS: 11.2.xx and higher have this command... > > > Martin, Christian wrote: > > > > Richard Irving Wrote: > > > To "You Know Who You Are": > > > > > > Since some of the filtering policies on the core *seem* to > > > not benefit the Internet as a whole... (or is that Hole ? ;) > > > > > > May I suggest one that does: > > > > > > neighbor WWW.XXX.YYY.ZZZ maximum-prefix XXXXX > > > > > > It has a way of dropping "clue-nots"..... When > > > they demonstrate said title..... > > > > > > Your clueful attention appreciated. > > > > > > Signed, > > > > > > One *URKED* Core Operator. > > > > > > > What if it has a way of dropping big blocks? From what I've seen n > > sniffer traces, it depends on how the routes are stored in > the BGP table > > that determines how they are advertised. This may have the > effect of > > sinking large, valid netblocks. Unless you've seen otherwise... > > > > -Chris >

2 1

Re: cw/mci meltdown @ mae-west san fransisco?
by Jay Stewart 26 Oct '98

26 Oct '98

I'm noticing similar problems this AM with CW's backbone starting at bloomington heading back east to DC. Can anyone (preferrably from CW) provide a tidbit of information on what is happening, or when this will be fixed? Jay Stewart Vice President Olympia Networking Services http://www.olywa.net 15 * 1002 ms * core3-hssi3-0.Bloomington.cw.net [206.157.77.41] 16 1612 ms * * bordercore2.WashingtonEast.cw.net [166.48.246.1] 17 * 1081 ms * healthscribe-inc.WashingtonEast.cw.net [166.48.26.158] 18 * * * Request timed out. 19 1181 ms 1082 ms * 208.138.226.13 20 1442 ms 1172 ms * 208.138.226.13 21 1082 ms 1131 ms * 208.138.226.13 22 * 1131 ms * 208.138.226.13 23 1091 ms 1202 ms * 208.138.226.13 24 * * 1162 ms 208.138.226.13 -----Original Message----- From: Dan Hollis <goemon(a)sasami.anime.net> To: 'nanog(a)merit.edu' <nanog(a)merit.edu> Date: Sunday, October 25, 1998 7:58 PM Subject: cw/mci meltdown @ mae-west san fransisco? >So anyone know what the deal is with the cw/mci meltdown at mae-west san >fransisco since approximately Oct 25 19:00 PST? > >Anything going through borderx1-fddi-1.SanFrancisco.cw.net, >core4.SanFrancisco.cw.net core6.SanFrancisco.cw.net, >core7.SanFrancisco.cw.net, mae-west6-nap.SanFrancisco.cw.net etc are >totally melty. > >Anything through sacramento appears fine. > >-Dan > >

2 1

RE: Clue's for Clue-less
by Martin, Christian 26 Oct '98

26 Oct '98

Richard Irving Wrote: > To "You Know Who You Are": > > Since some of the filtering policies on the core *seem* to > not benefit the Internet as a whole... (or is that Hole ? ;) > > May I suggest one that does: > > neighbor WWW.XXX.YYY.ZZZ maximum-prefix XXXXX > > It has a way of dropping "clue-nots"..... When > they demonstrate said title..... > > Your clueful attention appreciated. > > Signed, > > One *URKED* Core Operator. > What if it has a way of dropping big blocks? From what I've seen n sniffer traces, it depends on how the routes are stored in the BGP table that determines how they are advertised. This may have the effect of sinking large, valid netblocks. Unless you've seen otherwise... -Chris

2 1

RE: CW....also CNN
by Dave Cooper 26 Oct '98

26 Oct '98

We are still seeing this issue with quite a few routes: i.e. Nasdaq's blocks BGP routing table entry for 206.99.224.0/19, version 768117 Paths: (1 available, best #1) 1239 1800 209 286 3561, (received & used) 207.173.112.14 (metric 33) from 207.173.112.14 Origin IGP, localpref 80, valid, internal, best beauty... Dave Cooper electric lightwave, inc. -----Original Message----- From: steve(a)altrina.exodus.net [SMTP:steve@altrina.exodus.net] Sent: Monday, October 26, 1998 2:44 PM To: nanog(a)merit.edu Subject: Re: CW....also CNN FYI I did not mean to imply that uu.net was leaking routes if people misread me, the issue (which I've confirmed with uu.net at this time) is that sprint is leaking the routes from AS209 to them. They are not passing the routes any further. Hopefully the issue will be resolved soon. -Steve -- Steven O. Noble -- Sr. Backbone Engineer, Exodus Communications (EXDS) -- Work:408.346.2333 -- All my love to the Canadian Mooing Frog.

1 0

Re: CW....also CNN
by steve＠altrina.exodus.net 26 Oct '98

26 Oct '98

FYI I did not mean to imply that uu.net was leaking routes if people misread me, the issue (which I've confirmed with uu.net at this time) is that sprint is leaking the routes from AS209 to them. They are not passing the routes any further. Hopefully the issue will be resolved soon. -Steve -- Steven O. Noble -- Sr. Backbone Engineer, Exodus Communications (EXDS) -- Work:408.346.2333 -- All my love to the Canadian Mooing Frog.

1 0

Clue's for Clue-less
by Richard Irving 26 Oct '98

26 Oct '98

To "You Know Who You Are": Since some of the filtering policies on the core *seem* to not benefit the Internet as a whole... (or is that Hole ? ;) May I suggest one that does: neighbor WWW.XXX.YYY.ZZZ maximum-prefix XXXXX It has a way of dropping "clue-nots"..... When they demonstrate said title..... Your clueful attention appreciated. Signed, One *URKED* Core Operator.

1 0