- Test - lists.nanog.org

NANOG 24 (Miami) Meeting Updates
by Carol Wadsworth 21 Jan '02

21 Jan '02

NANOG 24 Meeting Updates A partial list of presentation topics for NANOG 24, February 10-12, in Miami is now posted on the web: http://www.nanog.org/mtg-0202/topics.html For additional meeting information, please see: http://www.nanog.org/mtg-0202/index.html For those of you who have registered to attend the meeting, we look forward to seeing you in Miami and would like to remind you about two upcoming deadlines: January 24 -- the NANOG room block at the hotel expires. For reservation information, please see: http://www.nanog.org/mtg-0202/hotel.html January 25 -- if your registration fee is unpaid by this date, the fee increases $50. To check on your payment status, please reference the attendee list at: http://www.nanog.org/mtg-0202/attendee.list.html See you there!

1 0

state of the art in router configuration
by Ratul Mahajan 21 Jan '02

21 Jan '02

after a study on bgp misconfiguration (http://www.cs.washington.edu/homes/ratul/bgp/index.html) i am beginning to wonder what the state of the art in router configuration is. a quick search on the web did not yield anything interesting. thoughts on the matter from guys who configure routers would be appreciated. 1. how do most operators configure their bgp (text editor or some high-level configuration tool)? 2. are there "configuration checkers" out there that would check whether an operator has not made a common error while modifying configuration? 3. when misconfigurations do happen, how are they detected? thanks, -- ratul

2 1

[OT] Routeing `listeners' for BGP and ISIS
by Richard Mortier 21 Jan '02

21 Jan '02

Hi, I believe this is appropriate for the NANOG list according to the AUP; my apologies if it isn't or if you receive multiple copies. I'd like to announce the release of `PyRT' the `Python Routeing Toolkit' available at http://www.sprintlabs.com/Department/IP-Interworking/Routing/PyRT/index.html >From the web-page: "The Python Routeing Toolkit (`PyRT') enables routeing information in a network to be collected. The purpose of this software is to enable routeing information in a network to be collected. This package currently supports BGPv4 and ISIS and will dump MRTD format files. It also supports parsing of MRTD TABLE_DUMP files (as available from, eg., RouteViews and RIPE/RIS). A number of utilities for manipulating these dumps are also provided." Information is collected by forming adjacencies with a router, and then acting as a `passive' router (ie. no routes are injected). It is released under the GPLv2 and was developed as part of work done at Sprint ATL, Burlingame CA. -- Richard Mortier ---------------------- ----------------- ---- Intern, 1 Aug--28 Feb, mort(a)sprintlabs.com ----- Sprint ATL, Burlingame, CA mort(a)ieee.org ----- http://www.cl.cam.ac.uk/~rmm1002/

2 1

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

20 Jan '02

On 1/17/2002 at 14:21:59 -0800, Jake Khuon said: > As for propogation of the bad prefix... well that soapbox has worn paint on > top. If people aren't going to bother following specs in the first place > I'm not sure a new spec will solve anything. 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. -Dave

4 3

Re: Persistent BGP peer flapping - do you care?
by Susan Hares 19 Jan '02

19 Jan '02

vijay: What else causes repeative peer bounces other than the broken prefix? sue PS - I'm away from work from now until Monday morning.. At 05:42 PM 1/17/2002 -0500, Vijay Gill wrote: >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? >The nlri may have gotten corrupted on the wire or between the interface >and the processor (parity error, or some sort of corruption on the bus). >Given that case, in an update, I am not sure you can make a determination >of what is good nlri and selectively propogate and process those. See also >meltdowns circa nov 1998. > >/vijay

3 2

Perhaps OT: Thoughts on venture technology
by Christopher J. Wolff 19 Jan '02

19 Jan '02

Dear List, Allow me a moment to state, mainly, that the NANOG group reprents a far greater aggregate of technological intellectual property than could ever be assembled in any tight-knit telecom or dot-com operation. And, That many of us, according to human nature, have dreams and desires that may be fettered by the boundaries of our corporations, or fettered by the lack of corporation (my condolences to those who have experienced the impact of downsizing). Therefore, I would like to share my recent epiphany. My partners and I founded Broadband Laboratories to act as the foundation to incubate our bleeding-edge technological dreams into a production quality reality. My thought was to open up the "Laboratory" function to teams of NANOG members coordinated to develop, from soup to nuts, selected technology projects proposed by other NANOG members. At this juncture I would like to offer coordination of project management, datacenter, and connectivity resources for selected technology projects. A great example would involve distilling interdisciplinary teams of NANOG members to pursue several development projects. The compensation plan is a straightforward joint venture. You commit X resources with an agreed-upon cash value. I commit X resources with an agreed-upon cash value. If this is a "for profit" project, any proceeds generated by the project are returned to cover our pre-negotiated costs. Any profits generated by the project are split evenly as our reward. If this opportunity interests you, please drop me a note. If you are not interested, thank you for letting me take a moment out of your day. Regards, Christopher J. Wolff, VP, CIO Broadband Laboratories http://www.bblabs.com

1 0

Persistent BGP peer flapping - do you care?
by Susan Hares 19 Jan '02

19 Jan '02

NANOG -- We are finalizing a revision of the BGP specification. It is in last call for your new BGP specification. This BGP revision is to match the bgp in deployment. One part of the specification remains, a fix for a problem called "persistent bgp flapping". We urgently need input from nanog folks on what is deployed. Here's the description "presistent bgp flapping" from the BGP specification: >If a BGP speaker detects an error, it shuts down the connection >and changes its state to Idle. Getting out of the Idle state >requires generation of the Start event. If such an event is >generated automatically, then persistent BGP errors may result >in persistent flapping of the speaker. 1) Do any of the ISPs see the persistent bgp peer flapping now? Does anyone from the ISP community ever experience anything like this BGP persistent peer flapping? The solution is to have an exponential backoff in the rate of sending the Opens. If you have seen this, how many routers did this persistent bgp peer flapping impact? (Can you give a % of your routers or a total number)? How often does this impact your routers? 2) Is this feature on in your machine by default? If not, do you configure the exponential rates? 3)Do you track if your routers are in this state? How do you track if your routers are in this state? Sue Hares

7 8

The Cidr Report
by CIDR Report 19 Jan '02

19 Jan '02

This is an auto-generated mail on Fri Jan 18 23:00:00 PST 2002 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. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. 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 GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 18Jan02 0) General Status Table History ------------- Date Prefixes 040102 104733 050102 104575 060102 105090 070102 105136 150102 104579 160102 104712 170102 104584 180102 104688 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 12251 Number of ASes announcing only one prefix: 7411 (4204 cidr, 3207 classful) Largest number of cidr routes: 732 announced by AS701 Largest number of classful routes: 1380 announced by AS701 1) Gains by aggregating at the origin AS level --- 18Jan02 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1172 901 271 23.1% Telstra Pty Ltd AS701 1380 1147 233 16.9% UUNET Technologies, Inc. AS4151 287 155 132 46.0% USDA AS577 321 197 124 38.6% Bell Advanced Communications Inc. AS16473 198 77 121 61.1% Bell South AS7018 810 695 115 14.2% AT&T AS6595 169 61 108 63.9% DoD Education Activity Network As AS705 288 185 103 35.8% UUNET Technologies, Inc. AS852 401 302 99 24.7% Telus Advanced Communications AS17557 179 83 96 53.6% Pakistan Telecom AS19632 95 13 82 86.3% Metropolis Intercom S.A. AS2048 185 105 80 43.2% State of Louisiana AS1239 469 389 80 17.1% Sprint AS12302 110 31 79 71.8% MobiFon S.A. AS7046 305 227 78 25.6% UUNET Technologies, Inc. AS4755 224 152 72 32.1% Videsh Sanchar Nigam Ltd. Autonom AS703 284 222 62 21.8% UUNET Technologies, Inc. AS3464 160 98 62 38.8% Alabama SuperComputer Network AS724 217 158 59 27.2% DLA Systems Automation Center AS4200 110 53 57 51.8% Apex Global Information Services, AS16758 63 6 57 90.5% IKON Office Solutions AS4323 381 325 56 14.7% Time Warner Communications, Inc. AS226 145 89 56 38.6% Los Nettos AS6471 121 66 55 45.5% ENTEL CHILE S.A. AS3908 316 261 55 17.4% Supernet, Inc. AS19834 63 8 55 87.3% NetForce, Inc. AS7303 104 51 53 51.0% Telecom Argentina Stet-France Tel AS2149 315 262 53 16.8% Performance Systems, Inc. AS13999 66 14 52 78.8% Mega Cable S.A. de C.V. AS1 496 445 51 10.3% BBN Planet Total 53624 41950 11674 21.8% 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

1 0

Outage in SF area
by Erich Kuehn 19 Jan '02

19 Jan '02

Has anyone noticed an outage in the SF bay area? I was told by MCI Worldcom that there was a Major Fiber cut in the area that affected mulitple OC-192's and OC-48's can anyone confirm this? Thanks Erich

3 2

Re: Persistent BGP peer flapping - do you care?
by Dickson, Brian 19 Jan '02

19 Jan '02

Here's my two cents... A good rule of thumb (possibly from RFC 822) is, be liberal in what you accept and strict in what you send. When applied to BGP, I would suggest that any implementation should choose a canonical form for constructing updates, but a parser that allows for rule-bending without rule-breaking. On the issue of existing vendor implementations, and how to build the specs to prevent meltdowns: I would suspect that during implementation, brand C routers were the victims during testing, and perhaps the change was made to avoid that happening. The current state of affairs is very much like the classical game-theory "prisoner's dilemna". The new spec should have two goals - discourage any implementation which can lead to meltdowns, and encourage strict adherence to the spec. The latter can be achieved via the former, in fact, if the mechanisms are well chosen. My suggestion would be, rather than a back-off of resetting BGP sessions, that first attempt strict interpretation (to insulate against completely insane routers), and then loose interpretation. The model is "Fool me once, shame on you, fool me twice, shame on me." On first receiving a bad update, reset. If upon re-establishing the session, the same bad update is heard, drop the bad update but keep the session up (along with the messages back, etc.) One additional optional behaviour I would suggest - look at the AS path and/or path length and/or announcing router IP address. If heard from the originator, drop the session (and either keep it down, or try one more time before requiring operator intervention); it may be the case that only these conditions strictly require a reset, and that all other situations may only require the "ignore bad routes" behaviour. Resetting BGP more than a small, finite number of times is, IMHO, a bad idea. After all, BGP is a stateful protocol, and state changes should be triggered deterministically, even if that requires operator input. Brian Dickson Velocita

4 3