- Test - lists.nanog.org

Re: test
by Roeland M.J. Meyer 27 Oct '98

27 Oct '98

At 09:39 PM 10/25/98 -0800, Brian Reid wrote: >> Shall I resend them? Best...\Stef > >Yes. They are lost in the aether. After a few daze at reduced service, MHSC is now fully operational once more. In a nut-shell, we lost our main switch (we have a switched 10baseT/100baseTX LAN). Lesson learned, never buy LinkSys ever again. Good product, lousy warranty RMA service (went down last Wed, didn't get replacement until this morning <sigh>) Other lessons learned, building static routes for 16 multi-tiered sub-nets, under pressure, sux big ones! Building and learning gated-3.5.9 can not be done in 24-hours. Linux won't route between multiple NICs, using multiple aliases, even with ip-forwarding enabled. ___________________________________________________ Roeland M.J. Meyer, ISOC (InterNIC RM993) e-mail: <mailto:rmeyer@mhsc.com>rmeyer(a)mhsc.com Internet phone: hawk.mhsc.com Personal web pages: <http://www.mhsc.com/~rmeyer>www.mhsc.com/~rmeyer Company web-site: <http://www.mhsc.com/>www.mhsc.com/ ___________________________________________ I bet the human brain is a kludge. -- Marvin Minsky

2 1

B8ZS DS3??? HUH??
by Martin, Christian 27 Oct '98

27 Oct '98

All, We have a DS1 line down, that is the result of a line cut along a DS3 trunk. Apparenty, the cut is either so bad, or so hard to reach, that we are getting an ETR of 2 days+. This is not my problem, however. When asked about rerouting, one of the Telco techs stated that they couldn't reroute right away, becasue the DS3 is not provisioned for B8ZS. To which I replied, "So. I didn't know any DS3 used B8ZS line coding." Anyway, my question is this: Is there a DS3 signalling standard that would call for B8ZS instead of B3ZS? And if so, what difference would it make if the coding were coming in as B8ZS, AMI, 4B/5B, NRZI, etc - it still needs to be demuxed back into the original signal, to terminate in the switch, right? Besides, I would think channelized DS1s riding a DS3 would already have been ones-density ensured, so any ones-density scheme on a channelized DS3 seems moot. If I am wrong, however, let me know so I can explain this to my techs for future reference. Thanks! Chris

1 0

Collecting Stories
by Jason Weisberger 27 Oct '98

27 Oct '98

Simple request, if you have time. Collecting stories and instances where you were too tired, intoxicated, inebriated, confused, distracted or otherwise temporarily rendered unqualified to touch that router or switch - but went ahead and did it anyways. Successes and failures welcome. Please send them directly to me, -- Jason Weisberger Chief Technology Officer SoftAware, Inc. 310/305-0275

3 4

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

27 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