- NANOG - lists.nanog.org

Re: Collecting Stories
by snash＠lightning.net 27 Oct '98

27 Oct '98

> 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. Date: Tue, 27 Oct 1998 14:32:51 PDT Well there was that one time Reid had me bent over the 7200 and I broke it.

4 3

Re: test
by John Fraizer 27 Oct '98

27 Oct '98

At 02:59 PM 10/26/98 -0800, you wrote: >Other lessons learned, > Linux won't route between multiple NICs, using multiple aliases, > even with ip-forwarding enabled. Someone needs to tell one of our routers this. It has been routing between multiple NICs for well over a year without any problem. ------- John Fraizer | __ _ The System Administrator | / / (_)__ __ ____ __ | The choice mailto:root@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

3 2

Re: Is Qwest leaking routes?
by Sean Donelan 27 Oct '98

27 Oct '98

spork(a)inch.COM (Charles Sprickman) writes: >> >Yes, it appears Qwest was leaking routes, but they are fixing it... > >Am I just silly to assume that it shouldn't take so long for such >well-funded companies to communicate with each other? AS286 is EUNet, >right? This all started sometime yesterday... I still see this: > >BGP routing table entry for 206.97.128.0/19, version 10233204 >Paths: (1 available, best #1) > 3847 1239 1800 209 286 3561 > 207.240.48.45 from 207.240.48.45 (207.240.48.1) > Origin IGP, localpref 100, valid, external, best Have you tried asking your upstream, Sprint (AS 1239) why they are still listening to, and re-announcing the route? Was it the old cisco bug, where routes sometimes get stuck in the route table due to dropping the withdrawl? Or some other reason? As part of the post-mortum, was everyone able to easily reach the correct people at the responsible NOC's of other providers to resolve this problem? I've been told in the past there are no communication difficulties between the billion dollar providers, and bi-lateral processes work well. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

Re: Lucent WaveLAN PC Cards?
by Brent Sweeny 27 Oct '98

27 Oct '98

and on the subject of 802.11 wireless, does anyone know of 802.11 PCCards with drivers for Linux? We haven't been able to find any. thanks/ Brent Sweeny sweeny(a)indiana.edu Indiana University }> Does anyone know it there will be support for the new 802.11 2.4GHz WaveLAN }> cards at the Atlanta NANOG or only the older, non 802.11 compliant ones? }> }> Either way, can someone recommend a clueful wholesale distributor (or worst }> case, "retail" dealer) of the Lucent WaveLAN hardware so that I can buy an }> appropriate PC card before I come? }> }> Regards, }> }> -- }> Wayne D. Correia Critical Path Inc. main: +1.415.808.8800 }> CTO <wayne(a)cp.net> San Francisco, CA 94105 fax: +1.415.826.6100

1 0

Re: Is Qwest leaking routes?
by Sean Donelan 27 Oct '98

27 Oct '98

>Yes, it appears Qwest was leaking routes, but they are fixing it... Its always so much fun to watch billion dollar companies dance around the issues. Qwest's spokesperson could not confirm nor deny any problem, and even if such a problem existed considered it a confidential matter. On the other hand, C&W received top billing on the news story, probally because they were one of the few providers to actually give any information to the public and reporters. Grrr. I'm not a big fan of C&W, what are your peering requirements this week?; but I don't like to see providers getting zinged for being open about network issues. However the root cause is a very old issue. It takes two to create a route leak. One to announce the erroronous route, and one to listen to the erronous route. The proper router filters on either side of the connection would mitigate the problem. Everyone knows the basic issues. 1) cisco routers can't hold the extremely large access-lists required to fully filter peer-to-peer connections between large providers. 2) some providers don't make available the information needed to accurately verify their routing information. 3) review the archives. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 2

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