- Test - lists.nanog.org

Disaster recovery follow up
by Dom Robinson 01 Oct '01

01 Oct '01

Folks, Having had my own (albeit politically insignificant) email disaster I have lost the dialogue I was in with a number of you further to the previoud posting (below). Could any of you I was in contact with please come back to me resend me your previous emails (and indeed any other comments of input any of you have) to d2(a)d2consulting.co.uk My apologies and thanks in advance, Dom (Previous message inserted) --------- Hey folks. I have been commissioned to research disaster recovery after the effects of Sept 11 on the major IP networks for an article in UK trade Magazine ISP World. Presumably any further dialog may be best kept out of NANOG lists, so please reply direct to me (unless you guys feel discussion here is relevant) at d2(a)d2consulting.co.uk I was wondering if any wizards may have some quotable comments etc as to what (if anything) occurred that day to the Internet, and what was done to rectify any problems... Any feedback would be warmly received, Thanks in advance Dom ------------ Dom Robinson : D2 Consulting ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 'data in motion' ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ IP Distribution Consultancy eMail: d2(a)d2consulting.co.uk www.d2consulting.co.uk

2 1

slightly OT : versign complaint department
by Bohdan Tashchuk 01 Oct '01

01 Oct '01

> i've been trying to add a pgp key to the verisign/netsol database for the > past two weeks. i've sent four messages, opened three web help requests, > and spent three hours on the phone with their helpdesk. they know less > than their customers about their own procedures and web documentation for > adding keys for PGP guardian auth. > i guess this is the problem with government sanctioned monopolies. Heh, heh, you can always complain to ICANN, another govt sanctioned monopoly. The REGISTRY is a monopoly. You have your choice of REGISTRARS. Melbourne IT is the registrar for my two (wow, whoopie!, two) domains. I can access inww.com site thru my browser, using a supposedly "secure" connection. The certificate presented by Melbourne IT is signed by Verisign! :-) It takes me 2 minutes to make a change, not two weeks. Let's not debate the limitations of this alternate security proceedure or this will be more than "slightly" off topic. > i'd like to do something about it. Vote with your dollars and with your feet. Change registrars. I apologize if you *ARE* are a registrar trying to deal with the registry. In that case, bend over and grab your ankles. Because you're getting screwed and there's nothing you can do about it. > does anybody know if there is a formal board or governing group that i can > send my grievances to? For $35 Melbourne IT will solve your problem. :-) Seriously, people, I can't for the life of me understand why anyone continues to do business with NetSol if there are so many better alternatives. Let NetSol execs cry over their $40 stock price, wishing it was back over $200. In the meantime let them know thru their pocketbooks that they should spend less time calculating the value of their stock options and spend more time running their business in a customer friendly manner. If everyone voted with their dollars, then NetSol would quickly improve or VRSN would soon be a $4 stock. Because that's about all it would be worth if their only revenue source was their govt mandated $6 "wholesale" registration fee. BTW I chose Melbourne IT because of their plain language domain name registration agreement. None of this crap about the registrar being able to change the terms at will. Only ICANN can do that to me.

2 1

Static IP use to accelerate
by Hank Nussbacher 01 Oct '01

01 Oct '01

http://www.teledotcom.com/article/TEL20010829S0015 Static Electricity ISPs offer static IP addresses for residential DSL service -Hank

1 0

Re: Long haul latency calculation?
by rs＠seastrom.com 01 Oct '01

01 Oct '01

rs(a)seastrom.com (Robert E. Seastrom) writes: > light. in glass, this is 200 million kilometers per second, plus or 200 million meters (not kilometers) per second. But what's a few orders of magnitude between friends? ---rob

1 0

Re: Long haul latency calculation?
by rs＠seastrom.com 01 Oct '01

01 Oct '01

"Christopher Wolff" <chris(a)bblabs.com> writes: > Dear Nanog: > I was wondering if there is a benchmark for long-haul circuit > latency... For example if I had a T1 circuit with 2900 miles > between the two end-points (and assuming the provider is best case > scenario) can I do something like (miles*latencyfactor) = 5 ms for > 2900 miles? it's gonna be a lot more than 5ms for 2900 miles. muxes and bit regens introduce a tiny amount of delay. there's delay for clocking the packet onto and off of the circuit (which becomes less significant as the speed of the circuit goes up, but is still a couple of milliseconds each way on a t1). remember that airline miles and road miles have nothing to do with circuit miles, and it is not uncommon to see a circuit go from dc to san francisco via new york, chicago, dallas, and los angeles. anyway, on a 2900 mile circuit the big delay factor is the speed of light. in glass, this is 200 million kilometers per second, plus or minus. that means you will never ever ever see less than 23 milliseconds each way. 46 for a ping. i would say that for a t1 circuit between two places 2900 miles apart anything under 70 ms is just dandy. ---rob

1 0

Re: Long haul latency calculation?
by Steven M. Bellovin 01 Oct '01

01 Oct '01

In message <200109301909.AA29032658(a)mail.turbonet.net>, "Christopher Wolff" wri tes: > >Dear Nanog: > >I was wondering if there is a benchmark for long-haul circuit latency... For >example if I had a T1 circuit with 2900 miles between the two end-points (and >assuming the provider is best case scenario) can I do something like (miles*la >tencyfactor) = 5 ms for 2900 miles? It's called "speed of light lag"... If I recall correctly, the speed of light in fiber is about .65c, where c is the speed of light in a vacuum (300,000 km/sec). --Steve Bellovin, http://www.research.att.com/~smb http://www.wilyhacker.com

1 0

Re: Provider Bypass
by Christopher Wolff 01 Oct '01

01 Oct '01

Joe; Thank you for the additional information...this application and information will be quite helpful. I'll run these tests and apply some of the guidance in the network tuning page you forwarded and let you know what happens. Regards, Christopher ---------- Original Message ---------------------------------- From: Joe St Sauver <JOE(a)OREGON.UOREGON.EDU> Date: Sun, 30 Sep 2001 17:38:05 -0700 (PDT) >>two paths one through Phoenix and on= >>e through Houston, and one path can sustain 250KB ftp transfers but t= >>he other only sustains 50kB ftp transfers... > >Based on trips on I10, my recollection is that there's a substantial >distance between the two locations; assuming that distance translates >to increased latency, I wouldn't be surprised to see a difference in >throughput. > >I would suggest tuning the hosts to handle high bandwidth flows per >http://www.psc.edu/networking/perf_tune.html and then running a known- >capable throughput testing program such as iperf >( http://dast.nlanr.net/Projects/Iperf/ ) > >>I would think there is a way for us to static route this traffic thro= >>ugh Phoenix, or hardcode it in the BGP table...I tried a few tweaks w= >>ith no joy. > >I'm assuming you're multihomed to both Phoenix and Houston? Is the issue >inbound or outbound? Depending on the direction, you should be able to >control the traffic using prefix prepending or MEDS, assuming your provider >is willing to play. Sam Halabi's routing book from Cisco Press has nice >examples? > >Or are you trying to do traffic engineering over a single connection, >within your provider's backbone? (If that, I think you're headed for >frustration -- I'd suggest a different NSP :-)) > >Regards, > >Joe >

1 0

Re: Provider Bypass
by Christopher Wolff 01 Oct '01

01 Oct '01

Hi Joe, There is 0% packet loss, but latency is around the 80ms range. The customer is using FTP as their metric for comparison...not great, but considering that our provder has two paths one through Phoenix and one through Houston, and one path can sustain 250KB ftp transfers but the other only sustains 50kB ftp transfers...I would love them to reroute our traffic through Phoenix but am having some political difficulties to overcome. I would think there is a way for us to static route this traffic through Phoenix, or hardcode it in the BGP table...I tried a few tweaks with no joy. Thank you for your input, Christopher ---------- Original Message ---------------------------------- From: Joe St Sauver <JOE(a)OREGON.UOREGON.EDU> Date: Sun, 30 Sep 2001 17:10:26 -0700 (PDT) >Is the throughput you're reporting for a single untuned TCP/IP >stream? If so, the throughput may not be a function of the >backbone through which the traffic is passing. > >Similarly, what's the traffic loss like over the link? If you are >seeing even a tenth of a percent worth of loss, don't expect to >do high bandwidth flows over the link. > >Regards, > >Joe >

1 0

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