September 2002 - Test - lists.nanog.org

Network Routing without Cisco or Juniper?
by Deepak Jain 05 Sep '02

05 Sep '02

It has been a long time since I have seen this thread hashed out, so I figured I'd bring it up publicly. Is anyone comfortable using (in a network with > 5 routers) any non-Cisco or non-Juniper routers for BGP speaking? (Zebra/Gated boxes only count if customer traffic is carried through the device). Historically, some networks have been big fans of Gated boxes and such because they were cheap and scalable to a point. Now many BGP speaking platforms are extremely inexpensive (even from CSCO and JNPR). I was wondering if the consensus has changed. Boxes like Foundry, Extreme, Redback and many others all talk BGP (at least to a first approximation) but is their lack of use in the core/edge/CPE a lack of scale, stability, performance or just interest? Thanks, Deepak

13 15

IRR listing of IANA-reserved, a question..
by John M. Brown 05 Sep '02

05 Sep '02

First, standard disclaimers.. 1. This is a technical email. 2. I'm not speaking for any organization, other than ME. In the last 72 hours I've seen over 3GB of data hit a network I play with with source IP's of IANA-RESERVED space. Various people have reported seeing IANA-RSERVED get announced via BGP at different parts of the net. Various people maintain lists of IANA-RESERVED space and other such "special use or reserved" prefixes. These lists are used by others to generate filters, ACL's and the like. When IANA allocates a new prefix to a RIR, these lists have to be updated manually. Sometime after the space has been put into service and someone complains. Give the above, would it make sense for: A) The IANA to maintain a IRR/RADB type database that would allow for the auto generation of filters and ACL's based *purely* on RESERVED IANA space. No other prefixs would be listed. or B) For one or more of the RIR's (APNIC, ARIN, LACNIC, RIPE, etc) to maintain such a database, again only IANA-RSERVED space. or C) One of the existing well known IRR/RADB's to maintain the db ? If such a database was available, would YOU use it ? Would it help your network operations? Would it be of a possitive or negative nature to your network? Lets try to stay away from the obvious potential flames and other religous statements. Thank you. John Brown Speaking a single person

11 17

Equinix and Big 7??
by sgorman1＠gmu.edu 04 Sep '02

04 Sep '02

The latest Cooke Report made the following statement: "They are, he says, the Internet Core Networks that announced anonymously on December 5, 2001 their decision to move their peering to Equinix Exchanges. He identifies them as UUNET, Sprint, Cable and Wireless, Genuity, Level 3, Qwest, and AT&T." I was wondering if anyone could verify these seven networks moving their collective peering to Equinix and if so any specifics. Previous posts in the archive on participants at Equinix do not seem to bear this out. Any feedback is greatly appreciated. Thanks, sean

1 0

follow-up IANA-RESERVED IRR
by John M. Brown 04 Sep '02

04 Sep '02

A good number of private replies from people and their "day job" addresses. Most have asked for prior permission before quoting them. In general, three default-free global backbone providers stated they would love to see something like this available, from IANA is the prefered answer. Some would like to see more than just IANA address information, and other contend that would be a can of worms and opens some risk issues. It seems that there is general support and that people would use such a service if available and reliable. If you have comments on this, and can post publicly, please do. Thank you john brown speaking for himself

3 4

RE: AT&T NYC
by Martin, Christian 04 Sep '02

04 Sep '02

> >BGP is not a bug-free protocol. > >BGP is the easiest protocol to *debug* when the problem shows up. > >BGP does not help to accidently affect *unaffected* paths when >a problem shows up. While there is a recursion issue in the BGP<->IGP scenario, BGP would be just as "broke" if the only path between two nodes (and whatever nodes are behind them) had their BGP session removed. Misconfigurations do not imply bad network designs. Bugs are bugs (whether they be OSPF or ISIS or BGP). We have seen RSVP/SNMP/NTP/.*P bugs break routers. I also would think that it is a bit of a stretch to criticize the design of the largest networks in the world, which, were it not for bugs here and there, are running just fine. Further, and I think this is what is troubling people here, is how, without IBGP mesh reduction mechanisms, you could build a non-fully meshed network without an IGP and static routes? The only way this is possible is via a combination of meshing, confeds, and route-reflectors, the latter two which are busted by design. If you are building fully meshed networks, then they are small. And one last comment - ISIS is the easiest protocol to troubleshoot IMO. Even RIP is harder because of all the silly holddowns and poison-reverses, etc. BGP is pretty straightforward as well, but there is a lot in the sauce that you need to know from vendor to vendor, etc. With ISIS, you have one DB (or 2), 1 LSP per router, 1 decision point. Finally, you seem to have a problem with dependencies and recursion, philosophically. This surprises me from someone who I know writes code. Do you not use functions? Pointers? What you have said is that a program that breaks because one function relied on another (that failed) is a broken design. My .02 chris > >It looks like everyone forgot the reason for this discussion >to begin with. It is the outage caused by a mistake on a >single router that affected parts of the network that were >*NOT* affected by the original mess. > >Please not that this discussion tends to get restarted >whenever we have a real OSPF (or ISIS) caused mess. > > >Alex >

2 1

NANOG 26 Meeting Information
by Carol Wadsworth 04 Sep '02

04 Sep '02

*****NANOG 26 Meeting Information***** Registration is now open for the 26th Meeting of the North American Network Operators' Group (NANOG). The meeting will be hosted by the University of Oregon and Sprint. The NANOG 26 meeting (October 27-29) will be held back-to-back with the ARIN X meeting (October 30-November 1) at the Eugene Hilton and Conference Center in Eugene, Oregon. Meeting Information: http://www.nanog.org/mtg-0210/index.html Online Registration Form: https://www.merit.edu/nanog/registration.form.html Hotel Information (special NANOG rate expires Oct. 5): http://www.nanog.org/mtg-0210/hotel.html Call for Presentations (deadline September 16): http://www.nanog.org/mtg-0210/call26.html Hope to see you there!

1 0

Re: Network Routing without Cisco or Juniper?
by Miquel van Smoorenburg 04 Sep '02

04 Sep '02

In article <cistron.20020904074946.GA84187(a)dataloss.nl>, Peter van Dijk <peter(a)dataloss.nl> wrote: >On Wed, Sep 04, 2002 at 03:39:25AM -0400, Deepak Jain wrote: >[snip] >> Boxes like Foundry, Extreme, Redback and many others all talk BGP >> (at least to a first approximation) but is their lack of use in >> the core/edge/CPE a lack of scale, stability, performance or just >> interest? > >One Dutch ISP that shall remain unnamed (and is not one I work for or >have worked for) deployed Extreme on AMS-IX, with Extreme's BGP >implementation. > >It broke horribly. The Extreme BGP implementation, instead of sending >their peers just their own prefixes, would send each peer *all* >prefixes and then withdraw all but their own networks. However, doing >this with tens of peers at the same time was too much for the Extreme >itself, which died. OTOH, I know of other ISPs also present on the AMS-IX that have been using Extreme switches to connect to the AMS-IX and their upstreams without any of those problems. Their network has been very stable for over a year now, I think. It's even a fault-tolerant setup with VRRP. Cistron IP is using a Foundry switch right now as core router. You can't get a BGP/OSPF router with lots of GigE and 10/100 interfaces for that price over at C or J .. We had some problems with instability at first, but with recent firmware everything runs just fine. We have several full BGP upstreams and over a hundred of AMS-IX peers (at GigE) and it works fine. On of the nicest things is that the box boots in 15 seconds or so and even with >100 BGP sessions coming up simultaneously it's still fast - a Cisco would take minutes to get all BGP sessions up, the Foundry does it in mere seconds. Mike.

1 0

final note on cookreport/ bill woodcock peering discussion
by Gordon Cook 03 Sep '02

03 Sep '02

I am leaving at 6 am in the morning for a small internet meeting in massachusetts. I am unlikely to see my email again until saturday morning. We have had eight different requests to join the discussion since my post this afternoon. Since the mail list is running on bill's woodcock's machine, it is only reasonable that he be the gatekeeper on additions to the list at this point. However he is at APIA in Japan right now and will not be back in the US for a bit more than another week. if I understand the situation correctly he will need to relay list addition requests to a colleague in California. If some folk do get added between now and the weekend please introduce yourselves to the list. Agenda I intend to publish an issue with list discussion around October 1. although since I let list members have a week to review a prepub draft and ask for edits correctionss etc, the current discussion will need to wrap up in the sept 23-25th time frame. But since the subject may change and evolve i am open to keeping the discussion going for a LOT LOT LONGER either on bills server or in another venue. I will be out of the country trekking near mount everest from October 15th until November 10th. The issue published about Oct 1 will be the December issue. I estimate that january will come out about december 1. If a discussion is continuing on line in october and november, it can certainly do so in my absence. I'd like to thank everyone for their help. I hope that we can document in considerable detail the changing economics, policy, politics and technologies of interconnection. -- ======================================================== The COOK Report on Internet, 431 Greenway Ave, Ewing, NJ 08618 USA (609) 882-2572 (phone & fax) cook(a)cookreport.com Subscription info & prices at http://cookreport.com/subscriptions.shtml Summary of content for 10 years at http://cookreport.com/past_issues.shtml Economics of Peering, Transit & IXs Part One - November issue available at http://cookreport.com/11.08.shtml ========================================================

1 0

economics of peering and transit -- long interview with Bill Woodcock and others
by Gordon Cook 03 Sep '02

03 Sep '02

I have just published part one of a two part issue on the economics of peering and transit and IX's. Included is a two part interview with Bill Woodcock who elaborates in great detail on the peering and transit methodology that he has been presenting at the last couple of Nanog meetings. Also included are four tables with January 31 2002 Netflow data from Zocalo. The tables are generated with software done for Zocalo at Agilent by Alex Tudor. Bill goes through each table and explains the meaning of the data. This includes an explanation of Synthetic Path Analysis in tables 3 and 4 which as I understand it is really the first published explanation of this approach. The interviews with Bill explain over all how ISPs can begun to mold tools into a bandwidth cost management system. My November issue also includes a long and detailed over view of the nasty consequences of the current Tier One oligopoly. The overview is an essay by Farooq Hussain in which he identifies the Internet Core backbones (see December 5, 2001 announcement of Equinix's Internet Core Service) as UUNET, Level 3, Qwest, ATT, Sprint, Cable & Wireless and Genuity. Andrew Odlyzko adds comments. Thanks to Zocalo I am running a private mail list where discussion of the Woodcock and related methodology, exchanges, peering, bandwidth cost and the like is on going. In addition to Bill Woodcock active participants include Avi Freedman, Phil Weller (Fast net CTO), Mike Hughes, Alex Tudor, Stephen Stuart, Phillip Smith, Farooq Hussain, Andrew Odlyzko and Keith Mitchell. If there are other Peering Coordinators here (or folk playing that role) who would like to contribute to the discussion (warning ....it is for publication) please email woody@pchnet and cook(a)cookreport.com stating the nature of you interest. Results of these discussions and other data will come out round about October 1. For the table of contents, complete introduction and Andrew Odlyzko's comments please visit http://cookreport.com/11.08.shtml -- ======================================================== The COOK Report on Internet, 431 Greenway Ave, Ewing, NJ 08618 USA (609) 882-2572 (phone & fax) cook(a)cookreport.com Subscription info & prices at http://cookreport.com/subscriptions.shtml Summary of content for 10 years at http://cookreport.com/past_issues.shtml Economics of Peering, Transit & IXs Part One - November issue available at http://cookreport.com/11.08.shtml ========================================================

2 1

RE: AT&T NYC
by Frank Scalzo 03 Sep '02

03 Sep '02

Whoops! 2 hours to find routers w/o an IGP tsk tsk. Dear AT&T IP Services Customer, Please be advised of the following: Date: 8/28/02 Customer Care TT#: 1070909 Start of Impairment: 14:56 ET End of Impairment: 16:52 ET On behalf of AT&T, we would like to extend our apologies for any inconveniences to your business caused by the service impairment and delay in restoring your service. AT&T IP Services customers with traffic routed through our Chicago backbone routers may have been affected by this impairment. Our Network Engineers found that OSPF* network statements were missing from two backbone routers, causing the routing issues that customers were experiencing. AT&T Network Engineers manually reloaded the OSPF network statements and then proceeded to reboot the routers in order for the changes to take effect. The network statements were mistakenly deleted during a routine configuration update to our backbone routers. Management has been made aware of these findings and appropriate actions will be taken to ensure this situation does not re-occur. Prior reported information was leading the AT&T Network Engineers to believe that there were issues with the route reflectors being out of synch. However, this was only symptomatic of the problem stated above. In other words, due to the missing network statements, the route reflectors were not advertising certain networks; therefore traffic was not properly routed. It is AT&T’s goal to provide the highest level of service to our customers. We appreciate your business and look forward to continuing our relationship in the future. *Routing protocol (Open Shortest Path First) Depending on the particular IP access services to which you are subscribed you may also find additional information as it becomes available at: AT&T MIS: https://mis-att.bus.att.com/ AT&T VPNS: http://www.vpn.att.net If you require further information, please feel free to contact AT&T at: AT&T MIS: 1-888-613-6330 AT&T VPNS: 1-888-613-6501 Thank you for using AT&T. Sincerely, The AT&T Customer Care Team -----Original Message----- From: Matt Levine [mailto:matt@deliver3.com] Sent: Wed 8/28/2002 6:21 PM To: Mike Tancsa Cc: Wes Bachman; nanog(a)merit.edu Subject: Re: AT&T NYC On Wednesday, August 28, 2002, at 04:17 PM, Mike Tancsa wrote: > > > route-server.ip.att.net is not currently reachable, but AS15290's > router server is for those who want a view on things... Interestingly enough, ATT is announcing 12.0.0.0/23 to BBN (and nobody else, including AS7018 internal).. > > route-server.east.attcanada.com. > and > route-server.west.attcanada.com. > > which come in handy :-) > > ---Mike > > At 04:11 PM 28/08/2002 -0400, Mike Tancsa wrote: > > >> I am seeing this as well. One of my upstreams (AT&T Canada- 15290) >> has connections with AT&T US (7018) in Chicago and Vancouver. >> Chicago seems to have disappeared for me and all traffic bound via >> that path is going via Vancouver now. >> >> ---Mike >> >> At 02:52 PM 28/08/2002 -0500, Wes Bachman wrote: >> >>> Bryan, >>> >>> There is a known AT&T outage in Chicago currently. Could this be >>> effecting you in some way? >>> >>> -Wes >>> >>> On Wed, 2002-08-28 at 14:44, Bryan Heitman wrote: >>> > >>> > Anyone seeing any problems with ATT in new york? >>> > >>> > >>> > Best regards, >>> > >>> > >>> > Bryan Heitman >>> > Interland, Inc. >>> -- >>> Wes Bachman >>> System & Network Administration, Software Development >>> Leepfrog Technologies, Inc. >>> wbachman(a)leepfrog.com > > -- Matt Levine @Home: matt(a)deliver3.com @Work: matt(a)eldosales.com ICQ : 17080004 AIM : exile GPG : http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0D04CF "The Trouble with doing anything right the first time is that nobody appreciates how difficult it was." -BIX

26 63