September 2001 - Test - lists.nanog.org

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

30 Sep '01

> Can someone who is in favor of implementing filters explain to me why > slicing a /16 into 16 /20's is any different than slicing a /20 into 16 > /24's? with the understanding that i'm explaining why MIBH did it rather than explaining why you should do it (if indeed you should, which is not even a conversation i could find myself in), the reasoning is/was as follows. there has to be a limit. that's all. that's the full extent of the reasoning. some limit has to be chosen, because without limits, human nature kicks in and "the people" start voting themselves bread and circuses. i'm not interested in going down that path because it's a recipe for _finding_ the limits of the global routing system, both in table size and in delta volume. (we'd find it when the 200,000th /32 was injected, and by that time it would be hard to reverse course.) so there's going to be a limit. the number of routes allowed into a router shall be non-infinite. that limit can be selenforced in a number of ways: 1. total number of routes 2. total number of routes per peer 3. prefix length now, #1 would just be too unpredictable. which routes were present would depend on what order the peers came up. so, one day, some routes, the next day, some different routes. #2 is in fact in wide use, but as an error ceiling to keep a peer from accidentally sending you a full table rather than as a way to apportion a router's resources. in a world which (clearly!) wants me to store 200,000 /32's, though, it's difficult to imagine how #2 helps prevent this. #3 is a gross hack which happens to have the nice properties of "predictable" (one day's routes will be much like another day's routes) and "minimal impact" (the long prefixes i'm throwing away almost always have shorter "covering" routes). and, #3 is negotiable per peer. abovenet allows its peers to send long prefixes because this makes "longest exit" possible. (this might or might not cause abovenet some scalability problems, but it's their decision and will impact noone except them and their customers.) some of you know that i had some involvement in both MIBH and abovenet and may be thinking of asking why these networks had different prefix filtering policies. two answers: MIBH wasn't a global network so "longest exit" wasn't going to be possible in any case; and MIBH didn't own any GSR's. > If the thought is "you're given a /20, i only want to see a /20.." then > why doesn't "you're given a /18, I only want to see a /18" also apply? because there's got to be some limit. if you want to set that limit at "you were given a /24 so i don't want to see any /28's from you", then fine. but obviously some trial and error has gone on here, and the folks who have prefix filters have set them so that (a) any longer and there'd be too many routes, and (b) any shorter and there'd be too much nonreachability. this is one of nature's equilibriums. it has shifted back and forth over time. the filter lengths verio is using are obviously in verio's best interests or they would have different ones. > I don't have any hard evidence to know how much of an impact this > actually has, but I would be very interested to see how many more specific > /19's and /20's exist in a "verio-filtered" table that were allocated as > /16's and shorter. i'm pretty sure verio has a looking-glass instance, so you can find out.

8 10

What's really going on in Lower Manhattan
by Mike Moglin 30 Sep '01

30 Sep '01

Ok I'm a totally confused person right about now, my company has several circuits that we are being told by Verizon have been declared non repairable and that we need to order new, but on the same note they are carrying on about having restored service to most customers? Do they consider telling people to order new circuits as repaired?? Secondly we carry 2 DSL connections one with AT&T and one with UUNET, both of them claim that Covad is the problem, yet Covad right on their web site is boasting that service to NYC has been restored. When confronted they say "It's a Verizon issue". Does anyone know what is really going on?

4 3

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 29 Sep '01

29 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