July 2000 - Test - lists.nanog.org

How many nexuses would it take?
by Sean Donelan 28 Jul '00

28 Jul '00

I took a stab at estimating what it would take to knock out the top 4% of ASNs on the Internet, thus meeting Tu's threshold for partitioning the net. Of course, to really determine this requires perfect knowledge, and at least some NDA information from the providers involved. My rough estimate is 60 different physical locations worldwide would need to be destroyed. But I suspect congestive collapse would occur after 20 different physical locations were destroyed. This assumes you went after the nexus(es?) of the Net. You could possibly isolate the requisite nexuses, without destroying them. But knowing those locations requires a level of knowledge about the physical overlap between providers I don't have. I think there is a substantial physical overlap between providers' right of ways, so I wouldn't be suprised if the same level of effort to destroy the connectivity of the top 4% of the providers damaged the top 25% (SWAG) since many of the 'tier 2,' and even 'tier 3' providers co-locate in the same physical locations as the top 4%. But I have no proof, only a educated guess. >From the studies I know about, disrupting national telephone service would require less effort. A logical attack on the net would require substitutionally less effort. This also assumes a static network. Network operators could substantially increase the number of peering locations and ASN interconnectivity in response. Those shadow connections and locations I spoke about. Unlike telephone switches, backbone routers are very fungible. So its not inconceivable, some new connectivity between ASNs would rapidly appear in places where there wasn't any before. A lot of Tier 2 and Tier 3 providers are multi-homed, but don't currently provide transit between backbones. This is an administrative policy, not a physical restriction. It is possible for substantial additional inter-ASN connectivity to be brought up very quickly, assuming you had enough remaining communications to coordinate it. Is the shadow connectivity of tier 2 and tier 3 providers enough to invalidate the theory the Internet as a scale-free network? I don't know. On Wed, 26 July 2000, Dave Crocker wrote: > The proffered theory is that a small number of nexus points that form an > essential core. Take out that small number and the remaining alternate > paths won't be sufficient. > > 25 is probably a large number, never mind one or two orders of magnitude more. > > Some effort at figuring out how many (and which) would have to be > simultaneously removed strikes me as a worthy exercise, to make sure that > the number is high (and the specific sights are well enough protected.) > > Perhaps it's already been done and the results kept quiet. That's fine. > > As long as the fragility is nowhere near as extreme as the article implies.

1 0

Reminder - RIPE NCC - change in size of minimum allocation
by Joao Luis Silva Damas 28 Jul '00

28 Jul '00

Allocation policy change reminder: As of 1st August 2000 (next Monday), the RIPE NCC will apply the change in policy agreed during the last RIPE meeting by which the size of MINIMUM allocation will be a /20. Allocations of this size will initially be made from CIDR block 217/8. If you use prefix length filtering in your routers, please take this into consideration. For a complete list of default allocation sizes you can read RIPE document "Size of smallest allocations in CIDR blocks allocated by the RIPE NCC", available at http://www.ripe.net/ripe/docs/internet-registries.html Regards, Joao Damas Head of External Services RIPE NCC

1 0

above.net <=> bbnplanet.net?
by Jeff.Hodges＠kingsmountain.com 28 Jul '00

28 Jul '00

I have a (possibly naive) question.. The peering between above.net <=> bbnplanet.net seems to have (at least)two states.. (1) "abysmal" (500..800 ms latecies) : 9 dfw-lax-oc3.dfw.above.net (208.184.102.154) 59.474 ms 59.657 ms 59.794 ms 10 s3-0-6.crtntx1-cr1.bbnplanet.net (4.24.104.21) 758.127 ms 745.747 ms 741.110 ms : (2) "tolerable" (50..100 ms latencies) : 8 lax-sjc-oc3.lax.above.net (216.200.0.165) 16.479 ms 16.523 ms 16.183 ms 9 dfw-lax-oc3.dfw.above.net (208.184.102.154) 61.052 ms 58.664 ms 59.898 ms 10 s3-0-6.crtntx1-cr1.bbnplanet.net (4.24.104.21) 62.212 ms 67.094 ms 65.389 ms : ..with it being in state#1 for days at a time, and then suddenly being in state #2 for a while (a few hours to a day or so). This has been going on for months at least. Anybody have any idea what's up here? Has anyone else noticed this? today it exhibited a new state #3 for several hours: "near-death" (2000..3000+ ms latencies), after thankfully being in state #2 for a few hours. *sigh*. Isn't this affecting at least a few other folks? thanks, JeffH

1 0

NOC number for HP.
by Neil J. McRae 27 Jul '00

27 Jul '00

Does anyone have a NOC contact for Hewlett Packard? Some of our downstreams can't reach the MX for hp.com and I've had nothing useful from the numbers listed at Netsol or ARIN. Regards, Neil. -- Neil J. McRae C O L T I N T E R N E T neil(a)COLT.NET "In this world there's two kinds of people my friend: Those with loaded guns and those who dig. You dig?"

1 0

summary Re: replacement for Patton 2715 (G.703->V.35) ?
by Jim Mercer 27 Jul '00

27 Jul '00

as a summary, here are the pointers i was given for what other people are using in production: DL085E http://www.quickeagle.com/products/t1e1/soloe1.html SAT3000 http://www.dataman.nl/products/NETW/scitec1.htm GM-H http://www.pandatel.de/content/products?nummer=17&sb=tele FCD-20 http://www.rad.com/products/family/fcd-20/fcd-20.htm On Thu, Jul 27, 2000 at 10:59:38AM +0100, Ryan O`Connell wrote: > It's possible to do G.703 on the Cisco directly. What cards are you using? my last attempt to do exactly that failed. i was using a Cisco 3620 with a ethernet/dual-WAN card. in the dual WAN ports i had a dual-integrated-T1 and an integrated-E1. in the end (after 5 days of cisco attempting the same configuration in a lab), it was determined that they did not have an IOS that supported that configuration. cisco was somewhat confused by my requirement for T1 and E1 in the same router, but, well, that was my requirement. i believe that the reason was that the E1 card was designed to work with a channelized circuit (ie. we could not turn off framing on the E1). the dual T1 card was designed for VOIP and needed extra hardware to just do straight T1 data (???). cisco has since come out with a WAN-G703 card, which purportedly does a raw E1, but given past experience, i would prefer to go external unless i have lots of time to play around with different IOS, etc. (unfortunately not the case with this project). we decided in the last project and for this project to use a 4 port serial card on the cisco and use external equipment. i guess my one big misunderstanding is that T1 is to E1 what V.35 is to X.21. i hadn't realized that X.21 appears to be the preferred interface outside north america, but it does explain the puzzled look on various technicians faces. 8^) -- [ Jim Mercer jim(a)reptiles.org +1 416 410-5633 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]

1 0

RE: replacement for Patton 2715 (G.703->V.35) ?
by Gullerud, Lars Erik 27 Jul '00

27 Jul '00

On 26/07/2000, Jim Mercer wrote: >i'm in north america, so i don't have much experience to draw on for E1 gear. ... >can i get a short list of recommended E1 -> V.35 converters? We generally stick to one of these boxes for G.703 to V.35/X.21 conversion: Tellabs MartisDXX STU-2304 Pandatel GM-H or GM-F There are lots of other equipment out there, but these are the ones we have the best experiences with. Of course, it's easier to do G.703 directly on the router... :) Regards, Lars Erik

1 0

Re: Sonet protection usage
by Danny McPherson 27 Jul '00

27 Jul '00

> Are many ISPs taking advantage of SONET APS protection > to provide port or router redundancy on short (metro-area) > circuits? Or is it more typical to get two circuits and > load-share? Or just not bother? I know of a few providers that use inter-router APS to protect against router and ADM trib port (mainly router) failures in the core. The optical network side is protected by BLSR or the like. The optical protection options still seem to be much more cost-effective then simply provisioning parallel (but presumably diverse) links between two locations, not to mention that if some load-balancing schema is employed one needs to consider accommodating additional propagation delay incurred on the less optimal path (an ideal application for CoS & TE, perhaps). Inter-router APS proves itself especially useful on trans-oceanic circuits where simply acquiring additional capacity often isn't a viable option, nor is allowing some really expensive circuit to sit idle for 5 or 10 minutes while a router boots and becomes synchronized. As you can imagine, there are lots of interesting issues with inter-router APS and IGP interaction, most of which seem to cast a considerable shadow on its value when considering network availability and convergence in the event of failures. Intra-router APS is much more appealing, assuming stateful port mirroring is implemented, though it doesn't address the main concern of protecting against router failures. Of course, it's definitely better than simply selecting an alternative, presumably less optimal network path simply because a local router becomes unavailable. -danny

6 7

Re: Internet FUD Abound
by Sean Donelan 27 Jul '00

27 Jul '00

On Wed, 26 July 2000, Scott Marcus wrote: > Sean, I don't think that they were arguing that EVERY failure would cause > this kind of collapse. They were saying that a scale-free system might be > particularly vulnerable to a systematic attempt to cripple its most > critical elements. A failure of a single public NAP is probably well below > that threshhold. I agree the failure of a single public NAP is below the threshhold stated in the article. But I think we can use data from actual failures at NAPs to help with the forcast. One interesting, and I think important piece of missing data is when a major NAP does fail new paths become visible in the network. The physical destruction of a NAP eliminates some paths, but I'm not sure how well the NLANR data really shows what happens with the connectivity. Of course the 'new' physical paths aren't created out of thin air. They are just lost in the shadows behind the hot glare of the big pipes. An open question is there enough shadow paths in the Internet to heal it, or are we just talking about degrees until total failure. I'm not sure the article author's took this into account. Secondly, must of the popular discussion (i.e. comments from the FBI's National Information Protection Center, SRI's Atomic Tangerine, etc) has used the article to support the theory the net is very vulnerable to terroristic attacks. However, destroying 2.5% of the nodes in the Internet is a big number. Its not just a matter of blowing up a parking garage outside Washington DC, a Gigaswitch in San Jose, etc. Launching a coordinated attack against 25, 250, 2500 different physical locations worldwide is hard for even an organized military operation. If terrorists blew up the top 2.5% of the largest cities in the USA, would the country would break up into feudal segements. I don't know. I agree things would be very grim if 2.5% of the cities were destroyed. But that is not small terroristic attack. I don't think the article supports the notion the Internet is exceptionally vulnerable to physical attack by terrorists. Actually, I think the article supports exactly the opposite view, it takes a rather large physical attack to partition the net. On the other hand, I think the current operational practices make the net less resiliant to certain forms of attack. But that is a different discussion.

2 1

RE: whois databases and null fields
by Carter, Gregory 27 Jul '00

27 Jul '00

-----BEGIN PGP SIGNED MESSAGE----- Just thought you all might be interested to know that these null fields that are showing up may seem innocent but they are affecting some other registrars. I had a customer use my company to transfer their domain names from NSI, out of the three domain names only one of them successfully sent him the admin contact email address the OpenSRS confirmation. Unfortunately I had to wait another 3 to 4 days before the requests expired so that they could be sent again. Wanted to give you all a heads up for those of you that use the OpenSRS system. I haven't heard any reports of any other registrars having this problem but still worth keeping a close eye on. Greg +(gcarter(a)infoDNS.com)-------------------------------------------------+ | infoDNS http://www.infodns.com/ | | Senior Network Administrator bits/keyID 1024/7DF9C285 | | Register your domain name today for only $25/yr. | +--------[ DC 50 57 59 C3 76 46 E8 EB 75 A8 94 FE 96 9E D3 ]----------+ - -----Original Message----- From: Nathan Lane [mailto:nathan@terminus.com] Sent: Wednesday, July 26, 2000 7:24 PM To: nanog(a)merit.edu Subject: Re: whois databases and null fields A few nights ago it was worse. Instead of nulls, the registrar fields were incorrect indicating a completely different server and registrar (many of which did not exist or were non-functional.) The registrant and nameservers appeared correctly. Hopefully they will become driven to operational excellence and I've seen a few steps that way, but money, not process and service, seems to be driving them for the short term. - -Nathan Lane Network Engineer -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.3 iQCVAwUBOX+2YW2piax9+cKFAQHZewQAnjcx9XWb4JvnPWtX7Y+ht8mzw5LERD4h e165qqSPaMvsmlTgPREozx1komeSZwyvRuR33qfkxxuJFhCehWmOpaBCVPIDxNcX KBDPml34XFt8wHNoHGyysGXBwsz1sjeuLGxqSTgauki5OaHpAT3DTd9LhX9wN67/ sWdLURDuViE= =AgDS -----END PGP SIGNATURE-----

1 0

whois databases and null fields
by Timothy Brown 26 Jul '00

26 Jul '00

Hey, folks. Maybe a dumb question. How does any registrant with null fields for their contact data manage to modify their registry records, outside of sending a letter on their company letterhead? For that matter, how do they get bills from the aforementioned registry? :) -- Registrant: Apple Computer, Inc. (APPLE-DOM) 1 Infinite Loop Cupertino, CA 95014 Domain Name: APPLE.COM Administrative Contact: [No name] (NA4189-ORG) [No mailbox] [No address] [No phone] Technical Contact, Zone Contact: [No name] (KE557) [No mailbox] [No address] [No phone] Billing Contact: [No name] (BC478-ORG) [No mailbox] [No address] [No phone] Record last updated on 11-Jul-2000. Record expires on 20-Feb-2001. Record created on 19-Feb-1987. Database last updated on 26-Jul-2000 20:11:40 EDT. Domain servers in listed order: NSERVER.APPLE.COM 17.254.0.50 NSERVER2.APPLE.COM 17.254.0.59 NSERVER.EURO.APPLE.COM 194.151.19.41 NSERVER.ASIA.APPLE.COM 203.120.14.5 -- Timothy Brown tcb(a)ga.prestige.net

4 3