- Test - lists.nanog.org

Re: uunet outage?
by John Neiberger 17 Jan '02

17 Jan '02

I'm not sure about uunet, but Sprint is having some issues in Seattle and Tacoma. I just had to shut down our connection to them to stabilize things on our end. John ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag ---- On Thu, 17 Jan 2002, Dan Hollis (goemon(a)anime.net) wrote: > > Anyone seeing uunet outage in the last half hour or something? > We are seeing huge routing problems. > > -Dan > -- > [-] Omae no subete no kichi wa ore no mono da. [-] > > >

2 1

Re: Persistent BGP peer flapping - do you care?
by Dave Israel 17 Jan '02

17 Jan '02

On 1/17/2002 at 17:42:53 -0500, Vijay Gill said: > On Thu, 17 Jan 2002, Dave Israel wrote: > > > It's a question of robustness; if the new spec includes a way to be > > tolerant of how the spec is (or can be) commonly abused, then the > > followers of the spec will not be at the mercy of those who deviate. > > > > In this case, I think that having the option to keep a session that > > gives bad routes up, and just dropping the route, is a good answer. > > That would allow the user to determine which is preferable for a given > > peer: possible corruption or certain disconnection. > > If you have a "bad route" how do you know the rest of the update is good? You don't. That's why I suggested an option. If you're talking about somebody who lives in the core, then you probably never want to trust somebody who hands you a bad update. If, however, you're on the edge, you might decide to keep trying to talk to somebody who hands you a bad update, at least until the error rate reaches some threshold (or the other router goes down in flames), rather than turn off what may be your only remaining connectivity and sulk alone in your corner. -Dave

1 0

802.1x supplicant settings in XP
by Aaron Shively 17 Jan '02

17 Jan '02

Is anyone familiar with the 802.1x client in WinXP enough to know exaclty what username/password pair it is trying to pass to the server? I have been testing this out on an HP switch, with the switch itself set up as the authenticating server. I have been unsuccessful getting authentication, and have tried setting up the switch with a username/password for both accounts (administrator and myself) on my XP machine. If the supplicant is not using either of these, what is it using? The computer name? There is no password associated with that. Thanks.

1 0

Methods for managing large customer/internal mgmt ACLs?
by Roland Dobbins 17 Jan '02

17 Jan '02

I'd be grateful for insight into what tools/methods are being used out there for managing and deploying large numbers of large customer and/or internal management ACLs, specfically for Cisco devices. Is vi/RCS/tftp the most common toolset, or is anyone using the Cisco ACLM (I doubt the latter, but thought I'd ask, anyway) or other systems? Thanks in advance . . . -- ------------------------------------------------------------ Roland Dobbins <mordant(a)gothik.org> // 408.859.4137 voice

2 1

RE: Growing DoS attacks
by LeBlanc, Jason 16 Jan '02

16 Jan '02

Get in touch with these guys, ask about SLT Director: Radware, Inc. http://www.radware.com Jason Harrison, Regional Sales Manager - Northern California 721 Emerson Court San Jose, CA 95126 voice: 408.279.2310; fax: 408.279.2510 > -----Original Message----- > From: Pascal Gloor [mailto:pascal.gloor@spale.com] > Sent: Wednesday, January 16, 2002 3:13 PM > To: nanog(a)nanog.org > Subject: Re: Growing DoS attacks > > > > > Since years, IRC (users and/or servers) gets dDoS... We also > see a grow of > the dDoS attacks. For example on Undernet some servers get > attacked every > day with 100+Mbps for a few minutes, and sometimes for long > long hours... > Those attacks are usually comming from users - IRC Operators > conflicts, > those users think they may ask anything to an OPER with the > power of a dDoS. > We try to provide a free service, and all of us know how it > is hard to get a > host with good connectivity for free and on the other side we > see those > young 'script kiddies' playing around with hundreds of > compromised hosts > like a game and they have no idea how much it costs to all > the flooded > networks... Unlikely I have to say that most of these 'script > kiddies' are > from Romania. I dont know why it's so many times comming from them.... > > If you run an well dDoS'ed IRC Server on your network I have > a solution for > you... not the best one, but still technically working.. > > get a /24 (be carefull that there is no bigger network > announced which would > include it!!! i mean like if you get 10.10.10/24, 10/8 would > include it) > > Get a box, and run Zebra BGPD, which will announce that /24 > to your network. > Then do a script which monitors the traffic to the irc > server, and on a > certain threshold, kill BGPD. wait a certain time, like > 15minutes or so, and > restart BGPD. It would be nice to check the traffic every > minute and if 2 > consecutive checks are positive kill bgpd. That mean that you > may be able > to STOP dDoS to irc servers within 2-3 minutes... > > just my 0.00001 EUR > > Cheers.. > Pascal >

1 0

RE: router startup behavior
by Borchers, Mark 16 Jan '02

16 Jan '02

> > Just guessing - you're seeing these events between midnight > > and 5 am? > > Hm, couldn't reist this one: "which time zone"? > > Just hinting that even though it's that time interval in the US, local > time is different in other places around the world, so if this is > causing disturbance, others are probably being hit in their working > hours. Heh, the "perpetual global maintenance window syndrome", eh? A very useful concept... > Besides, I was under the impression that to activate a new outbound > roting policy on a Cisco, you could just modify / replace it, but that > you would still have to do > > router#clear ip bgp xxx soft out > > to activate it. This means that the policy for an existing peer can > be modified without having to remove the peering and reenable it > shortly thereafter (something which would cause needless route > flapping). Somewhat true. The new policy would not be applied to routes that were already in the table, but would be applied to any adds/withdrawals that occur once the policy changes are placed in the configuration. This fact has a synergistic effect when you're making changes that affect lots of sessions. So a policy change made a significant time before a clear or soft clear could in fact result in flaps. Also consider: there are a lot of routers using traditional ACL's in their policies (as opposed to things like prefix-lists which have more granular editing features) which would necessitate removing the ACL completely and rewriting it with updated lines. Due to the above, a potential for leaks exists unless the session is either shutdown or deleted while acl's are being modified. If the sequence of events in a configuration script is not well thought out, the result could be what Ratul has observed in his study. > > Regards, > > - Håvard >

1 0

RE: router startup behavior
by Borchers, Mark 16 Jan '02

16 Jan '02

> the most likely cause would be one of: <items deleted for brevity> > (c) script used to configure router(s) adds a 'network' > statement prior to trimming route-filters Yeah, (c) seems most likely to me. Ratul, a script like this or some variant could cause what you are seeing: config-router# no neighbor <a> config-router# no neighbor <b> config-router# no neighbor <c> (script to rewrite filters executes) config-router# neighbor <a> remote-as <x> config-router# neighbor <a> remote-as <y> config-router# neighbor <a> remote-as <z> (sessions start coming up) config-router# neighbor <a> route-map <A> out config-router# neighbor <b> route-map <B> out config-router# neighbor <c> route-map <C> out config-router# Ctrl-Z # clear ip bgp external soft out Just guessing - you're seeing these events between midnight and 5 am? > 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 > > > > > > > > > >

2 1

The Cidr Report
by Tony Bates 16 Jan '02

16 Jan '02

This is an auto-generated mail on Fri May 25 23:00:00 PDT 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 25May01 0) General Status Table History ------------- Date Prefixes 040501 104512 050501 104646 060501 104816 070501 106340 080501 105979 230501 101875 240501 101755 250501 101869 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 80.9.0.0/18 from AS3215 *** Bogus 80.9.128.0/18 from AS3215 *** Bogus 80.64.0.0/20 from AS3246 *** Bogus 80.64.128.0/20 from AS20751 *** Bogus 80.64.224.0/20 from AS3259 *** Bogus 80.65.128.0/20 from AS9057 *** Bogus 80.65.224.0/20 from AS13193 *** Bogus 80.66.32.0/20 from AS702 *** Bogus 80.66.128.0/20 from AS1239 *** Bogus 80.67.0.0/20 from AS20750 *** Bogus 80.67.32.0/20 from AS20752 *** Bogus 218.2.0.0/15 from AS4134 *** Bogus 218.4.0.0/16 from AS4134 *** Bogus 218.6.128.0/17 from AS4134 AS Summary ---------- Number of ASes in routing system: 10851 Number of ASes announcing only one prefix: 6431 (3657 cidr, 2774 classful) Largest number of cidr routes: 975 announced by AS701 Largest number of classful routes: 1409 announced by AS701 1) Gains by aggregating at the origin AS level --- 25May01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1391 1031 360 25.9% TELSTRA-AS AS13999 103 11 92 89.3% autonomous system number assigned AS11252 91 33 58 63.7% autonomous system number assigned AS226 150 93 57 38.0% Los Nettos AS16758 63 6 57 90.5% autonomous system number assigned AS2149 320 265 55 17.2% PSINET-2 AS1 592 539 53 9.0% GTE Internetworking AS11686 143 91 52 36.4% Education Networks of America AS10692 66 14 52 78.8% DLS Internet Services AS10692 AS17561 111 60 51 45.9% UNKNOWN AS13544 69 22 47 68.1% autonomous system number assigned AS11774 74 28 46 62.2% AS 11774 Object AS1267 67 25 42 62.7% Infostrada S.p.A. AS1237 94 52 42 44.7% KISTI AS1239 441 400 41 9.3% SprintLink Backbone AS12235 48 7 41 85.4% Cove Software Systems Inc AS2652 113 75 38 33.6% Government of Canada (GENet) back AS209 263 226 37 14.1% Qwest Communications AS19834 49 12 37 75.5% autonomous system number assigned AS18447 46 9 37 80.4% autonomous system number assigned AS13345 67 30 37 55.2% autonomous system number assigned AS14 51 15 36 70.6% Columbia University in the City o AS12302 63 28 35 55.6% MobiFon S.A. AS2007 153 119 34 22.2% Infonet Services Corporation AS11507 87 53 34 39.1% TouchAmerica Montana AS10620 52 18 34 65.4% autonomous system number assigned AS11311 42 9 33 78.6% autonomous system number assigned AS10479 40 7 33 82.5% ITESM-Rectoria Zona Norte AS1913 115 83 32 27.8% autonomous system number assigned AS11859 45 13 32 71.1% autonomous system number assigned For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

4 3

Re: router startup behavior
by Danny McPherson 16 Jan '02

16 Jan '02

> > The routers in question run a BGP redistribution process every > 60 seconds and it just happened to run (quite often) just as > filters were being rewritten, resulting in "the gunk" not being > tagged as "keep internal" and therefore being advertised > externally. A subsequent run of the BGP process realized a > policy was in place withdrew the routes. I should clarify here: A subsequent run of the BGP resdistribution process with the newly rewritten policy in place resulted in the routes being tagged with the appropriate "keep internal" community and "re- advertised". Upon receipt of the now tagged routes, routers that had previously announced the untagged routes withdrew them (per egress policy specification). -danny

1 0

Re: router startup behavior
by Danny McPherson 16 Jan '02

16 Jan '02

I've actually seen this behavior (more specifics being leaked and then promptly withdrawn), though the trigger wasn't quite so obvious. It turned out what was happening is that a bunch of gunk was being redistributed into BGP and tagged with "keep internal" communities to avoid advertisement to EBGP peers. Implicit policy was being applied at the domain egress such that if the "keep internal" community values weren't present the routes were by default advertised externally. In addition, BGP policies (i.e., prefix filters) that identified "keep internal" address space (and pretty much everything else, for that matter) were being rewritten every night on every BGP router in the network (regardless of change). The routers in question run a BGP redistribution process every 60 seconds and it just happened to run (quite often) just as filters were being rewritten, resulting in "the gunk" not being tagged as "keep internal" and therefore being advertised externally. A subsequent run of the BGP process realized a policy was in place withdrew the routes. The symptoms were somewhat random as the leaked routes varied from day to day, depending on which routers throughout the domain happened to have a BGP redistribution process collide with a policy rewrite -- but all in all, in a large network it seemed to occur on at least a couple of routers every night. My conclusions: o Redistributing into BGP can get ugly and should be avoided o Blindly rewriting policies (or any configuration elements) that haven't changed is bad o Implicit route advertisement policies are bad -danny

1 0