- Test - lists.nanog.org

Atlas of Cyberspace
by Hank Nussbacher 30 Sep '01

30 Sep '01

http://www.kitchin.org/atlas/index.html An interesting new coffee table book for all uber-geeks. -Hank

1 0

ASIS: Telco Jeopardy
by Sean Donelan 30 Sep '01

30 Sep '01

The American Society for Industrial Security (www.asisonline.org) is holding their annual meeting in San Antonio, TX this week. In addition to their usual sessions, they have educational sessions on subjects such as security in telco/carrier hotel buildings. As you might suspect, after September 11, a lot more people have questions about security of carrier hotels. This would be a good forum for anyone with equipment in, or who operates a carrier hotel, to get their questions answered. I'll be in San Antonio for the meeting. If anyone else is in town for the ASIS meeting, drop me a note.

1 0

BGP tables, PC hardware, et al.
by Joel Baker 30 Sep '01

30 Sep '01

>From my (operational) experience: CPU load to import a full table from ground zero, on router hardware: 100% "" "" "" "" , on server hardware: <2% Main problem with using server hardware (and I am not talking about a Linux box on a Taiwanese manufacturer, here; I'm talking hardware considered by the majority of successful businesses to be stable enough to support their core applications): Lack of stable and useable routing software. Zebra: OSPF is twitchy, BGP is either great or takes > 1 hour to converge a full table, with no clear reason why, and it does not support anything but Linux/Intel sanely, yet. GateD public: No reflector code. End of story. GateD private: Segfaults & other fun games, unresponsive support, closed code. MRTD: (As far as I can tell) requires injection of full routing table into kernel routes for base OS, no sane way to turn this off, support for non-BGP protocols is spotty at best. Anyone able to significantly disprove one of the above, or provide another package that does not have the problems, would have my deep and abiding gratitude, because this issue is rather active in my current work-life. -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer(a)lightbearer.com http://users.lightbearer.com/lucifer/

6 7

Re: Verio Peering Question
by Bohdan Tashchuk 30 Sep '01

30 Sep '01

> multihoming is a necessary property of a scalable IP economy. actually, > provider independence is necessary, multihoming is just a means to that end. > if you don't think there are more than 1.3M entities worldwide who would pay > a little extra for provider independence, then you don't understand what's > happened to *.COM over the last 10 years. in that case i'll simply ask you > to take my word for it -- you make 1.3M slots available, they'll fill up. I'm an "entity" that would be willing to pay extra for provider independence for my home /32 address. Globally, there are probably more than 1.3M individuals (ie, "entities" like me) that want to do that. All the "old" companies who've been on the Internet for years have all the IP address space they need. For example the parent company of the subsidiary I work for has at least 3 class B addresses, which we use internally. And yet the several thousand IP addresses in my subsidiary all NAT thru firewall with a very small number of externally visible IP addresses when accessing the internet at large. What a waste of IP space. These old companies, ISPs, NSPs, etc. have all the IP numbers they need. They got theirs and they don't give a f*ck that it's really hard for new companies to get anywhere near the equivalent. In the meantime it's DAMN difficult for new companies, especially smaller ones, to multihome. I still don't see any good solutions to that problem. What I would do if I were desperate and starting a company is to pay someone for their old pre-CIDR /24 address. As you say, everyone will route those. What's the going rate for a routeable class C?

2 1

Re: Verio Peering Question
by Paul Vixie 29 Sep '01

29 Sep '01

> Frankly, I'd rather have tons of OC-3 to diverse backbones, but > my point is that not everyone wants to multihome. That's what the people who killed A6 said, too. However, there's this other question: how many more people would multihome if it weren't so difficult to get portable address space? (Hint: see *.COM.)

2 1

Re: The backbone that sucks least?
by Paul Vixie 29 Sep '01

29 Sep '01

> > Do they manage tickets with Keystone? I've heard you mention > > that as a decent trouble ticket system in the past. UUNET has some kind of localized commercial hybrid tracking system, it doesn't look like Keystone from my outsider (former customer) perspective. I really liked Keystone while it was growing. > Keystone is, unfortunatly, indisputably dead at the moment. White > Pajama Software bought it from Stonekeep, and promptedly turfed it in > favor of their homegrown software. The source is "available", but it > was never released under any kind of OSS license, so you're stuck with > the last "official" release (which, while usable, still had tons of > bugs and usability issues), and there's no active development going > on right now. I've seen nothing I like better, warts and all. I guess if there were a standard database schema and interchange format for trouble tickets, so that folks could choose their front end and back end systems from different sources (and maybe for different strengths), a lot of duplicate effort could still be avoided.(*) (*) I only said that to make Jerry and DRC <winge>. IRTS 'til it hurts, man.

2 1

Rethinking emergency response: Vunerable bunkers
by Sean Donelan 29 Sep '01

29 Sep '01

Now that a little time has passed, people are starting to evaluated how well things worked, or didn't. Since I used to design high-availability sites, this article about how well the NYC emergency operations center worked caught my eye. http://www.nytimes.com/2001/09/29/nyregion/29BUNK.html (nyt has restored their requirement for registration) Before the next NANOG, I would still like to hear from ISPs with facilities in the region about how well the Internet and communications infrastructure worked, and any suggestions they may have for changes. The biggest danger I see looming on the horizon is the secrecy will lead to groupthink, and some very bad decisions. While there is no need to tell people your secret PIN, sharing "lessons learned" can help make the entire system more robust. Or if you didn't learn a lesson, what worked. Also, if anyone needs someone to review their colo or provider's facilities, I'm available. I have the bad feeling, the amount of snake oil will rise.

1 0

Can't access puffin.external.hp.com, www.alphalinux.org and www.parisc-linux.rog - pointers wanted
by thunder7＠xs4all.nl 29 Sep '01

29 Sep '01

:traceroute puffin.external.hp.com traceroute to puffin.external.hp.com (192.25.206.4), 30 hops max, 40 byte packets 1 gates.of.nowhere (192.168.0.1) 0 ms 0 ms 0 ms 2 s-isdn46.s340.xs4all.net (194.109.103.186) 26 ms 21 ms 21 ms 3 194.109.103.254 (194.109.103.254) 24 ms 23 ms 22 ms 4 ge-0-2-0.6.xr1.s340.xs4all.net (194.109.7.33) 24 ms 22 ms 22 ms 5 ge-1-3-0.xr1.pbw.xs4all.net (194.109.5.21) 23 ms 27 ms 24 ms 6 r17-PO9-0-0.asd-KQ1.NL.KPNQwest.net (134.222.199.61) 38 ms 34 ms 32 ms 7 r1-PO3-0.obl-KQ1.NL.kpnqwest.net (134.222.224.25) 34 ms 35 ms 37 ms 8 r1-PO2-0.wdc.US.kpnqwest.net (134.222.229.222) 118 ms 123 ms 119 ms 9 wdc-brdr-03.inet.qwest.net (205.171.24.113) 123 ms 120 ms 114 ms 10 wdc-core-01.inet.qwest.net (205.171.24.37) 119 ms 114 ms 110 ms 11 dca-core-02.inet.qwest.net (205.171.8.209) 117 ms 116 ms 119 ms 12 atl-core-02.inet.qwest.net (205.171.8.153) 137 ms 144 ms 135 ms 13 atl-edge-17.inet.qwest.net (205.171.21.186) 134 ms 134 ms 132 ms 14 65.112.33.30 (65.112.33.30) 138 ms 139 ms 127 ms 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * : Uh-oh, not good. I've seen this for the past week. I've searched the web for places to report this, but I can't find any (read: I don't know what to search for). Idem for www.parisc-linux.org and www.alphalinux.org. Could some of you kind gentle(wo)men please tell me something like 'search google for foobar' or 'read comp.os.routing-problems.for.dummies' so I can get this solved? My provider isn't making much haste on this one, and I'm cut off from cvs :-( Thanks, and sorry for the interruption, Jurriaan

2 1

The Cidr Report
by CIDR Report 29 Sep '01

29 Sep '01

This is an auto-generated mail on Fri Sep 28 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. 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 28Sep01 0) General Status Table History ------------- Date Prefixes 210901 103625 220901 103684 230901 103666 240901 103680 250901 103629 260901 103632 270901 104968 280901 104483 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 82.105.0.0/16 from AS3269 *** Bogus 82.105.128.0/17 from AS3269 AS Summary ---------- Number of ASes in routing system: 11715 Number of ASes announcing only one prefix: 6979 (3955 cidr, 3024 classful) Largest number of cidr routes: 855 announced by AS701 Largest number of classful routes: 1389 announced by AS701 1) Gains by aggregating at the origin AS level --- 28Sep01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1262 961 301 23.9% Telstra Pty Ltd AS4151 299 171 128 42.8% USDA AS16473 201 76 125 62.2% Bell South AS577 306 187 119 38.9% Bell Advanced Communications Inc. AS13999 132 16 116 87.9% Mega Cable S.A. de C.V. AS6595 170 60 110 64.7% DoD Education Activity Network As AS4293 376 267 109 29.0% Cable & Wireless USA AS2048 209 115 94 45.0% State of Louisiana AS6429 195 102 93 47.7% AT&T Chile Internet S.A. AS4755 213 131 82 38.5% Videsh Sanchar Nigam Ltd. Autonom AS12302 98 28 70 71.4% MobiFon S.A. AS1239 471 402 69 14.6% Sprint AS4200 142 74 68 47.9% Apex Global Information Services, AS6471 128 63 65 50.8% ENTEL CHILE S.A. AS17557 128 65 63 49.2% Pakistan Telecom AS3464 157 96 61 38.9% Alabama SuperComputer Network AS19632 67 9 58 86.6% Metropolis Intercom S.A. AS16758 63 6 57 90.5% IKON Office Solutions AS209 303 248 55 18.2% Qwest AS3908 283 230 53 18.7% Supernet, Inc. AS11686 160 107 53 33.1% Education Networks of America AS226 145 93 52 35.9% Los Nettos AS17561 113 62 51 45.1% Internet service provision to Wes AS1 533 482 51 9.6% BBN Planet AS4323 247 197 50 20.2% Time Warner Communications, Inc. AS306 59 10 49 83.1% National Guard Bureau AS637 104 56 48 46.2% Department of Navy AS10620 68 21 47 69.1% TVCABLE BOGOTA AS1913 151 105 46 30.5% Defense Logistics Agency AS15290 244 199 45 18.4% AT&T Canada IES 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

Re: The Gorgon's Knot. Was: Re: Verio Peering Question
by smd＠clock.org 29 Sep '01

29 Sep '01

| Gimme a break. Arm, leg, neck, spine or ego? | s/the Sprint sales guy calls him and/he calls a Sprint sales guy who/ Clearly you have never ever tried to buy Internet stuff from Sprint! | This would cause depletion of address space faster. That sky hasn't fallen yet, despite the warnings since 1995. | This does not address performance issues. Nobody's perfect. | > 3. the maximum 254 things in the /24 can be renumbered | > into small ISP's PA space and announced to UUWHO | > with a constraining (set of) community(ies) | > | > (NAT, incidentally, was also invented to make renumbering easier) | | All this does is swap the problem around, not solve it. It does: traffic follows the aggregate to some part of the network that knows the secret exception and uses it, even though it does not tell the rest of the world it is doing so. This network either needs to be big, or it needs to leak a constrained more specific out to some of its neighbours, which is a harder problem. Essentially you are creating a wormhole, by analogy with a black hole. "Ad hoc confederation of wormholers" either knows the more specific prefix or follows the PI aggregate around to the small provider, depending on connectivity. Everyone else only knows the PI aggregate and follows that. If the following lands on any "ad hoc confederation of wormholers" router, it follows the privately-known more specific. Geoff Huston has been talking about a community which is useful for doing the most common case of this kind of "ad hoc confederation"-making, even though it's designed to deal with traffic engineering: "announce this longer prefix to everyone receiving money from me". | Why bother, when ISP-X down the street will "just do it"? ... which is ineffectual if people are doing filtering or progressive flap dampening. Sean.

2 1