January 2002 - Test - lists.nanog.org

BBC on ICANN (probably very old news)
by Peter Galbavy 15 Jan '02

15 Jan '02

http://news.bbc.co.uk/hi/english/sci/tech/newsid_1761000/1761362.stm For those interested on the UK/EU media view. Sorry if this is non-operational. I am not really keeping up with ICANN stuff myself anymore. Peter

1 0

Request for info: DSL test gear
by Tim Irwin 15 Jan '02

15 Jan '02

Hey, folks - One of my counterparts asked me if I could post the following to the list to see if anyone else has experience with a product or a combination of products that meet(s) the following criteria. Spirent (Smartbits) xDSL test gear is already a consideration... looking for anything else in the marketplace. Contact me off-list if so desired... I'm just the messenger though. Thanks, Tim <----begin forwarded request----> We are looking to do this type of testing. Is there one or combination of tools that can do this? Most of this? Looking for suggestions. DSL Test System requirements: -Interfaces: ATM, Ethernet, DS3, OC3, OC12, 10/100 -Generate approximately 32,000 PPP sessions -Bi-directional traffic -PPP throughput tests -L2TP emulation (both LAC and LNS) -Ability to perform L2TP conformance test as per RFC 2661 -Simulate user traffic and session turn up rates -Full negotiation of the IP and PPP parameters -Ability to vary the rate of the PPP session startup -Ability to see the sessions and associated users or IP addresses -Take measurements while generating the L2TP tunnels and PPP sessions -Generate PPPoE sessions through the L2TP tunnels -Generate PPPoA sessions using AAL5 and RFC1483 -Generate PPPoEoA sessions using AAL5 and RFC1483 <----end forwarded request----> -- Tim Irwin, Sr. Engineer Architecture & Engineering BellSouth.net, Inc. e-mail: tim(a)eng.bellsouth.net office: 678.441.7951 "The plain and simple truth is rarely plain and never simple." --Oscar Wilde

1 0

Re: router startup behavior
by Lincoln Dale 15 Jan '02

15 Jan '02

unlikely. "route-filtering", "BGP" and "route announcement" all go hand-in-hand. all are control-plane functions. for router-vendors that matter, i doubt that the behavior you describe occurs. the most likely cause would be one of: (a) a bug. (but if it is there, i'm surprised it isn't causing more stress/oscillation) (b) people changing route-policy. ie. it isn't "router starting up" but more likely someone going "route-map FOO deny 20"; "no match ...", "match ...". (c) script used to configure router(s) adds a 'network' statement prior to trimming route-filters (d) too many people experimenting with route-injectors on that live-production- network-known-as-the-internet. cheers, lincoln. At 01:10 PM 14/01/2002 -0800, Ratul Mahajan wrote: >to the best of my knowledge, here is what is happening. > >1. router starts rebooting >2. there are routes in the routing table, some of which are not to >be announce according to filters >3. bgp sessions comes up; the filters have not yet taken effect >4. start announcing routes >5. filters come up >6. the router realizes that it made a mistake and withdraws the routes not >meant to be announced. > >i should also point out that all such incident are not 1000 router. most >of them are 20-50, but i have seen non-trivial number of ~100 prefixes, >and a couple more than that. > > -- ratul > >On Mon, 14 Jan 2002, Ratul Mahajan wrote: > > > > > > > at university of washington, we are doing a measurement study of bgp > > misconfiguration > > (http://www.cs.washington.edu/homes/ratul/bgp/index.html) > > > > one of the things we found is that there are a lot of announcements of > > more-specifics that come and go within a matter of 2-5 minutes. > > > > by talking to the operators involved in these incidents, we found that > > most of these are caused when the router is rebooted (intentionally or > > not). while some operators were aware of this side effect, most were not, > > and were taken by surprise that they just injected anywhere from 1-1000 > > routes into BGP only to withdraw them a couple of minutes later. > > > > i would like to understand this behavior better. is this behavior > > vendor-specific (cisco?) or pervasive? is there a configuration style that > > causes or avoids this "spill-over"? > > > > my understanding is limited to this happens when the bgp session comes up > > too soon, before the filters have taken effect. could someone familiar > > with router internals shed some light on it? > > > > the problem is limited to route origination only, or also propagation? > > in other words, can a router propagate a route it should not while > > starting up because export filters are not yet in place? > > > > never ever gotten my hands dirty into router configuration; your input > > would be invaluable. > > > > thanks, > > -- ratul > > > > > >

1 0

router startup behavior
by Ratul Mahajan 15 Jan '02

15 Jan '02

at university of washington, we are doing a measurement study of bgp misconfiguration (http://www.cs.washington.edu/homes/ratul/bgp/index.html) one of the things we found is that there are a lot of announcements of more-specifics that come and go within a matter of 2-5 minutes. by talking to the operators involved in these incidents, we found that most of these are caused when the router is rebooted (intentionally or not). while some operators were aware of this side effect, most were not, and were taken by surprise that they just injected anywhere from 1-1000 routes into BGP only to withdraw them a couple of minutes later. i would like to understand this behavior better. is this behavior vendor-specific (cisco?) or pervasive? is there a configuration style that causes or avoids this "spill-over"? my understanding is limited to this happens when the bgp session comes up too soon, before the filters have taken effect. could someone familiar with router internals shed some light on it? the problem is limited to route origination only, or also propagation? in other words, can a router propagate a route it should not while starting up because export filters are not yet in place? never ever gotten my hands dirty into router configuration; your input would be invaluable. thanks, -- ratul

5 5

RE: router startup behavior
by Randy Bush 14 Jan '02

14 Jan '02

> a fix might be to not advertise any routes to a BGP peer until you > receive all the routes that peer has to send you. that will *greatly* reduce the garbage in the global routing table. to zero, in fact. and, of course, we can not know when a peer has sent all the routes it has to send to you. randy

4 4

AS109 - Contact
by German Martinez 14 Jan '02

14 Jan '02

Anyone with access to AS109 routers that can contact me off-line ? thank you German Martinez ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * THE DILBERT FUTURE * * Thriving on Stupidity in the 21st Century * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Internet capacity will increase indefinitely to keep up with the egos of the people using it"

1 0

RE: router startup behavior
by Paul Donner 14 Jan '02

14 Jan '02

how long would you wait for? At 03:32 PM 1/14/2002, David Schwartz wrote: >On Mon, 14 Jan 2002 13:28:42 -0600, Steve Naslund wrote: > > >Here is my best guess as to what you are seeing. Most likely a large CIDR > >block is announced by a service provider A. A small CIDR block is given to > >a customer who is connected to multiple service providers and thus running > >BGP. Now the more specific route is announced by service provider B, he > >does not own the block but is announcing it on behalf of service provider As > >customer. What is happening is that the customer has a line or router > >failure and that withdraws their more specific announcement from service > >provider B. Since the service provider A is announcing a supernet route he > >now becomes the only route for that block. > > If that's the problem, a fix might be to not advertise any routes > to a BGP >peer until you receive all the routes that peer has to send you. I think it's >elegant that when two routers connect, neither sends any routes to the other >until each has received all the routes the other has to send. Very Zen, don't >you think? > > DS

1 0

RE: router startup behavior
by Steve Naslund 14 Jan '02

14 Jan '02

Sorry, didn't get your first message clear in my head. The next question I would have is what do the routes look like. To get that many routes for a couple of class Cs, the router's BGP must be really broke. I would try to look at router type and software version and see if there is a correlation there. I would then try Cisco's web site to see what the known BGP issues are for that IOS version. The bug toolkit has a lot of resolved BGP bugs but you need to know the version and platform in order to get a better search. You usually need a support contract to get to this area but you might be able to talk them into helping you or having one of the service providers submit the problem as a trouble case. Can you provide a sample of the routing table during the bad advertisements ? Steve > -----Original Message----- > From: Stephen J. Wilcox [mailto:steve@opaltelecom.co.uk] > Sent: Monday, January 14, 2002 1:53 PM > To: Ratul Mahajan; Steve Naslund > Subject: RE: router startup behavior > > > > that doesnt fit with the sequence of events outlined below > > ie > reboot > 1000+ routes appear > 1000+ routes removed > > you are saying > > line failure > 1000+ routes removed > line recovery > 1000+ routes appear > > and the numbers ie 1-1000 seems very high for this small provider with one > or two class Cs at a maximum > > On Mon, 14 Jan 2002, Steve Naslund wrote: > > > > > Here is my best guess as to what you are seeing. Most likely a > large CIDR > > block is announced > > by a service provider A. A small CIDR block is given to a > customer who is > > connected to multiple > > service providers and thus running BGP. Now the more specific route is > > announced by service provider B, > > he does not own the block but is announcing it on behalf of > service provider > > As customer. What is happening is that the customer has a line > or router > > failure and that withdraws their more specific announcement from service > > provider B. Since the service provider A is announcing a > supernet route he > > now becomes the only route > > for that block. > > > > +++++++++++++++++++++++++++++++ > > Steven Naslund > > Network Engineering Manager > > Hosting.com - Chicago > > +++++++++++++++++++++++++++++++ > > > > > -----Original Message----- > > > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > > > Ratul Mahajan > > > Sent: Monday, January 14, 2002 12:54 PM > > > To: nanog(a)merit.edu > > > Subject: router startup behavior > > > > > > > > > > > > > > > at university of washington, we are doing a measurement study of bgp > > > misconfiguration > > > (http://www.cs.washington.edu/homes/ratul/bgp/index.html) > > > > > > one of the things we found is that there are a lot of announcements of > > > more-specifics that come and go within a matter of 2-5 minutes. > > > > > > by talking to the operators involved in these incidents, we found that > > > most of these are caused when the router is rebooted (intentionally or > > > not). while some operators were aware of this side effect, > most were not, > > > and were taken by surprise that they just injected anywhere > from 1-1000 > > > routes into BGP only to withdraw them a couple of minutes later. > > > > > > i would like to understand this behavior better. is this behavior > > > vendor-specific (cisco?) or pervasive? is there a > configuration style that > > > causes or avoids this "spill-over"? > > > > > > my understanding is limited to this happens when the bgp > session comes up > > > too soon, before the filters have taken effect. could someone familiar > > > with router internals shed some light on it? > > > > > > the problem is limited to route origination only, or also propagation? > > > in other words, can a router propagate a route it should not while > > > starting up because export filters are not yet in place? > > > > > > never ever gotten my hands dirty into router configuration; your input > > > would be invaluable. > > > > > > thanks, > > > -- ratul > > > > > > > > > > > > -- > Stephen J. Wilcox > IP Services Manager, Opal Telecom > http://www.opaltelecom.co.uk/ > Tel: 0161 222 2000 > Fax: 0161 222 2008 > >

1 0

Zywall / smurf amplifier
by Avleen Vig 14 Jan '02

14 Jan '02

Morning all, If there is a 'competant' technical support representative from ZyXEL on this list could you please contact me? As far as I'm able to tell, your ZyWALL 10 firewall+router combo by default[1] acts as a Smurf Amplifier, and I cannot disable directed IP broadcasting[2]. Or if anyone knows how to disable directed IP broadcasting on this equipment I'd appreciate an email. Kindest regards, Avleen Vig [1] I run the SAFE project at the address below. The information I've received is from someone with the above equipment who is having this problem, and having the usual amount of luck with tech support depts. [2] Very bad ;) -- Avleen Vig Smurf Amplifier Finding Executive: http://www.ircnetops.org/smurf Currently looking for work: http://www.silverwraith.com/resume.html

1 0

SSL for IRR queries?
by Tony Tauber 14 Jan '02

14 Jan '02

If there's a desire to trust information garnered from the Internet Routing Registry (eg. RADB, RIPE), it would seem that one would like a way to verify the server responding to queries. Is there a way to query the database using SSL or something else which can use digital certificates or other manner of keys which can be verified somewhat out-of-band? It would seem that it wouldn't be such a big deal to offer this capability not in lieu of, but just in addition to, the current "whois" protocol. No changes ought to be needed to the database language or back-end. Speaking of back-end, though, is there any verification that goes on in the mirroring process? Any comments or information are appreciated. Thanks, Tony

4 4