- Test - lists.nanog.org

Re: Linux router (don't laugh) WAS:Re: test
by John Fraizer 28 Oct '98

28 Oct '98

It's a pentium 150 with 64Mb. Overkill for memory: [root@core0-eth0]:~ # free total used free shared buffers cached Mem: 63184 7720 55464 6228 1092 3520 -/+ buffers/cache: 3108 60076 Swap: 68508 0 68508 At 05:37 PM 10/27/98 -0500, William F. Maton wrote: >On Tue, 27 Oct 1998, John Fraizer wrote: > >> Routing 3 /24's and a /26 using 3 3c905's. eth0 goes to the cisco->world. >> eth1, eth1:0 and eth1:1 go to an ethernet switch that is serving machines >> from the three /24's. eth2 goes to a hub for one of our co-location clients. >> >> Attached is an mrtg graph from someone decided to throw about 8MB of >> garbage our way for a few hours. This little linux router just sat there >> and idled through it. > >John, > What kind of CPU/box is that? > >wfms > > ------- John Fraizer | __ _ The System Administrator | / / (_)__ __ ____ __ | The choice mailto:John.Fraizer@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

1 0

Route Leaks
by Jeffrey S. Young 28 Oct '98

28 Oct '98

It would seem that the routes that leaked into the routing system with an AS path: origin 3561 286 209... are mostly withdrawn and now under control. There may be a number of routes that persist and we feel that the best way to clear them out is to concentrate on them on a case-by-case basis. The (Cisco suggested) workaround to quickly remove these routes even though they have been withdrawn from BGP at their insertion point is to announce more specifics from the origin AS. Rather than burden the routing system with additional, unnecessary more specific routes from AS 3561, we would like to hear from other providers or from the owners of these routes. If you're seeing routes with the above AS path or if your network is currently routing through this path please contact us. You can send mail to trouble(a)cw.net to coordinate. If you choose to copy nanog that's ok. Now, that said. This particular problem has plagued the Internet, hitting us as a community a number of times this calendar year. On the nanog list we've discussed filtering, we've pointed out how particular providers are unaffected, but as yet we are all still vulnerable. The Cable & Wireless network filters routes from customers based on routing registry entries. We believe that this is the best defense against unintentional routing leaks, it protects us and our peers from our customers. We realize that not everyone in the industry agrees with us :-). We realize that many that agree with us would find it nearly impossible to implement such a system. I'd like to propose a simple solution to the class of route leak we've recently seen. I'd like to encourage our peers to put a simple filter in place. If you peer with AS 3561, please do not accept any route with AS 3561 in the path from either your customers or your other peers. We already do this for a number of networks, without commenting on the size or importance of any of them, they are just networks that we only expect to hear on specific peering links. I still believe that the way to a more stable routing system is through route registries and filtering. I don't believe that any of us can rest easy (whether or not our networks were affected by the current leak) until we fix the system. For my own selfish interests, please, filter on my AS number.

2 1

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

28 Oct '98

11.1-20CC also has this feature. -Chris > -----Original Message----- > From: Richard Irving [mailto:rirving@onecall.net] > Sent: Tuesday, October 27, 1998 11:02 PM > To: Sharif Torpis; nanog(a)merit.edu > Subject: Re: Clue's for Clue-less > > > Sharif Torpis wrote: > > > > this must be an 11.2 thing? > > > Unknown... > Have you ever met an 11.1.xx technician *not* > wearing synthetics to test it ? > > :) > > > > > Richard Irving wrote: > > > > > > It is built into IOS.... As you approach the ceiling, it > sends out an > > > SNMP log alert. > > > > > > Now, how I select the number is confidential.... > > > > > > Ok. I will give you a hint.... I bring up the original sessions, > > > and confirm integrity... > > > > > > Then I look at the routes, size and count. > > > > > > Then in the dark of the moon, wearing *no* synthetics, > > > facing *magnetic* north... I devine the target number. > > > > > > In other words... It is a judgement call... > > > > > > Downstreams are easier. They must file routes with me, > before I route > > > them. I filter to the prefix. > > > > > > Consider this merely another fall back mechanism to the > general IOPS > > > model. > > > > > > Sharif Torpis wrote: > > > > > > > > can u elaborate on the detection mechanism for setting off such > > > > alarms? do u look at % change in total routes in core > of internet? > > > > e.g. sunday saw a change of 55k -> 60k which is ~10% > change ... or do > > > > u look at specific blocks that should not be > deaggregated and catch > > > > them if they are deaggregated ... thanks > > > > > > > > Richard Irving wrote: > > > > > > > > > > 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) > > > > > > > > > > PS: 11.2.xx and higher have this command... >

1 0

Re: Clue's for Clue-less
by Richard Irving 28 Oct '98

28 Oct '98

Sharif Torpis wrote: > > this must be an 11.2 thing? > Unknown... Have you ever met an 11.1.xx technician *not* wearing synthetics to test it ? :) > Richard Irving wrote: > > > > It is built into IOS.... As you approach the ceiling, it sends out an > > SNMP log alert. > > > > Now, how I select the number is confidential.... > > > > Ok. I will give you a hint.... I bring up the original sessions, > > and confirm integrity... > > > > Then I look at the routes, size and count. > > > > Then in the dark of the moon, wearing *no* synthetics, > > facing *magnetic* north... I devine the target number. > > > > In other words... It is a judgement call... > > > > Downstreams are easier. They must file routes with me, before I route > > them. I filter to the prefix. > > > > Consider this merely another fall back mechanism to the general IOPS > > model. > > > > Sharif Torpis wrote: > > > > > > can u elaborate on the detection mechanism for setting off such > > > alarms? do u look at % change in total routes in core of internet? > > > e.g. sunday saw a change of 55k -> 60k which is ~10% change ... or do > > > u look at specific blocks that should not be deaggregated and catch > > > them if they are deaggregated ... thanks > > > > > > Richard Irving wrote: > > > > > > > > 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) > > > > > > > > PS: 11.2.xx and higher have this command...

1 0

Re: root name servers
by Sean Donelan 27 Oct '98

27 Oct '98

noc(a)nso.ORG (Network Operations Center) writes: >anybody knows the physical location >of all root name servers, or a pointer ? The precise physical location (e.g. room number and rack) of all the root name servers is not generally available public information. It isn't "classified" information in the military sense, but some people get nervous nonetheless. Anyone who has been around the Net for a while will pick up that information eventually. A list of the general physical location (e.g. city and organization) can be found at <http://www.nic.mil/DNS/root-server.html>. It isn't precisely accurate, but I don't know if it is deliberate deception, or just an Oops, close enough for government work. It doesn't include the more recent root-servers servers at LINX and WIDE. However, as the last few attempts by NSI proved, geographic location isn't as important as network topology. Putting a GTLD name server in London doesn't do any good if its network connectivity sucks. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

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