January 2002 - Test - lists.nanog.org

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 18 Jan '02

18 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 18 Jan '02

18 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

Re: recommendation for open source based
by Miquel van Smoorenburg 18 Jan '02

18 Jan '02

In article <cistron.3C48A376.F350C16C(a)unitedlayer.com>, Arman <arman(a)unitedlayer.com> wrote: >solution for customer data and trouble ticketing system. >I have already used Request Tracker. Version 2? It's much better. Mike.

1 0

RE: Outage in SF area
by Adam Herscher 18 Jan '02

18 Jan '02

Apparently there was an XO fiber cut around 3:30PM Pacific time. I know of at least a few InterNAP circuits in the Fremont/San Jose area that were affected.. Rgds, Adam -----Original Message----- From: Erich Kuehn [mailto:ekuehn@bbcominc.com] Sent: Friday, January 18, 2002 4:16 PM To: 'nanog(a)merit.edu' Subject: Outage in SF area 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

1 0

Configuring multi-home failover
by Mike Stubbers 18 Jan '02

18 Jan '02

I am wanting to configure a secondary ISP to be used as fail over only for our primary. At this point both ISP's come into the same 7500 router and I have an established BGP session with our primary provider. Can those of you doing this already tell me the optimum way to set this up? Is this best done on my end or by having my secondary discover our disappearance and begin announcing? New territory for me so BGP configuration examples are welcome. Regards, Mike Stubbers Network Analyst Supervisor, SCP Information Technology Services University of Idaho mikest(a)uidaho.edu

4 4

FW: router startup behavior
by Borchers, Mark 18 Jan '02

18 Jan '02

Forwarded to the list: -----Original Message----- Subject: RE: router startup behavior On Tue, 15 Jan 2002, Borchers, Mark wrote: Mark, I don't have nanog post so, if you could pass this along for me, I believe that it may be "obvious" advice and it seems that the obvious is what escapes us most often. > 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 > config-router# no neighbor <c> > (script to rewrite filters executes) > config-router# neighbor <a> remote-as <x> > config-router# neighbor remote-as <y> > config-router# neighbor <c> remote-as <z> > (sessions start coming up) > config-router# neighbor <a> route-map <A> out > config-router# neighbor route-map 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? > > Wouldn't it be wiser to do the following: config-router# no neighbor <a> config-router# no neighbor config-router# no neighbor (script to rewrite filters executes) config-router# neighbor <a> remote-as <x> config-router# neighbor <a> shutdown config-router# neighbor remote-as <y> config-router# neighbor shutdown config-router# neighbor <c> remote-as <z> config-router# neighbor <c> shutdown config-router# neighbor <a> route-map <A> out config-router# neighbor route-map out config-router# neighbor <c> route-map <C> out config-router# no neighbor <a> shutdown config-router# no neighbor shutdown config-router# no neighbor <c> shutdown config-router# Ctrl-Z # clear ip bgp external soft out This way, the neighbor has much less time to come up without filters since we're immediately putting it in admin idle after naming it. --- John Fraizer EnterZone, Inc

4 4

need routed configuration help
by Alex Melkomukov 18 Jan '02

18 Jan '02

Hello everyone. I'm not sure if this is the correct list, but I was informed that this list is where all of the routing experts can be found, so I am sending this plea for help to this list. Basically, I need to confirm some configuration information and make sure I've set up everything properly. I am seeing some very strange behavior and need to rule out local misconfiguration as the cause. I am not a routing expert, so I need confirmation. We had to configure a customer's server to function in a co-location facility (not of our choosing) that has a gateway IP address that is outside of the locally defined network block (Class C). The OS is FreeBSD 4.4. I did some digging and discovered that I needed to enable 'routed' and create some static routes to the gateway IP outside of the local network block to be able to reach the Internet. I uncommented the defaultrouter="5.6.7.1" entry (IP has been changed to protect parties involved) in the rc.conf file and added the router_enable="YES" entry. I then added the following entries to the rc.local file: route add default -interface 1.2.3.100 -netmask 255.255.255.252 route add -net 5.6.7.1 -interface 1.2.3.100 -netmask 255.255.255.252 route add default 5.6.7.1 I came up with these routes by trial and error, and am not convinced that these are the correct entries to use. I can reach the Internet and the nameserver (which is also outside of the local network block), and can ping and traceroute without any problems. But,... every once in a while certain programs start timing out and/or take a really long time to respond (to the point of failure due to time-out on the other end). Some of these programs are telnet, ssh, ftp, radius. Other programs/protocols (such as http traffic) do not display the same behavior. So, I am seeking advice on how to configure static routes correctly and/or if some other issues may be causing this strange, intermitten behavior. Please let me know if I implemented this incorrectly... am __________________________________________________________________ Alex Melkomukov amelkomukov(a)navi.net Navi.Net http://www.navi.net 618 NW Glisan St., Ste. 101 voice 503-517-8866 Portland, OR 97209 USA fax 503-517-8868 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3 2