May 2008 - Test - lists.nanog.org

Re: [NANOG] Comcast latency
by Tim Thompson 13 May '08

13 May '08

> Tim Thompson wrote: >> Here, in New England, I normally see 20% packet loss between Comcast >> and Level3 in NewYork using MTR. It has been as high as 60% in the >> past so this is an improvement. >> James Michael Keller wrote: > Remember that a number of ISP's 'core' routers are going to have ICMP > rate limits in place when one of their interfaces is the target. While > you may see high packet loss across an ISP link, unless you are getting > similar numbers from all hops past that point you aren't looking at real > packet loss, since the transit packets are getting through fine. It's > just the routers themselves that are ignoring requests or discarding > responses in favor of pushing routed packets. Yes, the routers after Level3's edge router don't show similar packet loss, so this must be the edge router just de-prioritizing ICMP. Thank you for pointing out my mistake. -Tim

25 33

[NANOG] [NANOG-announce] Mail List Committee announcement
by Philip Smith 13 May '08

13 May '08

Dear all, The Steering Committee has unanimously agreed to start afresh with the composition of the Mail List Committee. There has been a long term, and ongoing, conflict within the MLC that had made it essentially dysfunctional. The SC would be derelict in our duty to allow this to continue any longer. The Merit representative on the MLC, Sue Joiner, will continue on the team, with Steve Feldman (the SC rep to the MLC) providing interim support pending appointment of the new MLC. The call for volunteers for the new MLC will be sent out tomorrow, Wednesday 14th, with the new MLC being appointed by Friday 30th. Best wishes, philip (for the SC) -- _______________________________________________ NANOG-announce mailing list NANOG-announce(a)nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

[NANOG] Sprintlink ATL->MCO?
by Alan Halachmi 12 May '08

12 May '08

I'm seeing a significant slowdown between Atlanta and Orlando. Anyone else? 1 ... 2 ... 3 ... 4 ... 5 ... 6 POS5-1.GW4.NYC4.ALTER.NET (157.130.14.177) 10 ms 15 ms 33 ms 7 146.at-2-0-0.XR3.NYC4.ALTER.NET (152.63.25.98) 26 ms 4 ms 4 ms 8 0.so-4-0-2.XL3.NYC4.ALTER.NET (152.63.17.29) 3 ms 3 ms 3 ms 9 0.ge-6-1-0.BR3.NYC4.ALTER.NET (152.63.3.166) 4 ms 3 ms 4 ms 10 sl-crs2-nyc-0-1-2-0.sprintlink.net (144.232.18.237) 4 ms 23 ms 17 ms 11 sl-crs1-pen-0-4-5-0.sprintlink.net (144.232.20.142) 21 ms 27 ms 23 ms 12 sl-bb21-rly-15-0.sprintlink.net (144.232.20.208) 25 ms 24 ms 17 ms 13 sl-bb21-dc-5-0-0.sprintlink.net (144.232.8.164) 31 ms 33 ms 28 ms 14 sl-crs1-dc-0-4-0-0.sprintlink.net (144.232.15.13) 45 ms 54 ms 50 ms 15 sl-crs1-atl-0-8-0-1.sprintlink.net (144.232.8.146) 291 ms 283 ms 285 ms 16 sl-bb21-orl-2-0.sprintlink.net (144.232.20.87) 500 ms 525 ms * 17 sl-bb20-orl-15-0.sprintlink.net (144.232.0.98) 489 ms 489 ms 489 ms 18 sl-gw12-orl-8-0.sprintlink.net (144.232.2.178) 487 ms 486 ms 486 ms Best, Alan

2 1

[NANOG] Fire at 250 Williams St. in Atlanta
by Mike Lockhart 12 May '08

12 May '08

Just got this from InterNAP: Hello, This is notification of a fire in progress in the ACS building at 250 Williams Street in Atlanta. The building is currently being evacuated. The fire is not in the datacenter and will have no impact on services or equipment in the datacenter. Internap ticket 274786 If you have any questions or concerns please contact us at noc(a)internap.com or call 877-843-4662. Thanks, Ryan Luetkenhoelter NOC Customer Care Associate Internap Network Operations Center NOC(a)Internap.com 1-877-THE-INOC(843-4662) US 00800-468-37627 UK

1 0

[NANOG] Lofgren has introduced Net Neutrality bill
by Owen DeLong 12 May '08

12 May '08

http://thomas.loc.gov/cgi-bin/query/z?c110:H.R.5994: Overall, I think it's actually pretty good. Paragraph 28(a)(2) and especially when combined with 28(d)(2) have some interesting potential unintended consequences, but, overall, it's short, to the point, and, well written legislation in my opinion. Owen

2 1

[NANOG] Broken Link
by Owen DeLong 12 May '08

12 May '08

Apparently Thomas doesn't let you just publish a link to bills... The link I published doesn't work. There is also another net neutrality bill which would create a major FCC process around the idea of evaluating net neutrality. Both bills probably have some merit. To best read them, I suggest going to the link I sent, then, click "Thomas Home". From there, search for Bill Number. The bill number I sent earlier was H.R. 5994. The other bill is H.R. 5353. Owen

2 1

Re: [NANOG] Sprintlink ATL->MCO?
by Thiago Modelli 12 May '08

12 May '08

Yes, there's a fiber cut that sprint is trying to route arround. We are being impacted too. --T ----- Original Message ----- From: Alan Halachmi <alan(a)halachmi.net> To: nanog(a)nanog.org <nanog(a)nanog.org> Sent: Mon May 12 12:18:51 2008 Subject: [NANOG] Sprintlink ATL->MCO? I'm seeing a significant slowdown between Atlanta and Orlando. Anyone else? 1 ... 2 ... 3 ... 4 ... 5 ... 6 POS5-1.GW4.NYC4.ALTER.NET (157.130.14.177) 10 ms 15 ms 33 ms 7 146.at-2-0-0.XR3.NYC4.ALTER.NET (152.63.25.98) 26 ms 4 ms 4 ms 8 0.so-4-0-2.XL3.NYC4.ALTER.NET (152.63.17.29) 3 ms 3 ms 3 ms 9 0.ge-6-1-0.BR3.NYC4.ALTER.NET (152.63.3.166) 4 ms 3 ms 4 ms 10 sl-crs2-nyc-0-1-2-0.sprintlink.net (144.232.18.237) 4 ms 23 ms 17 ms 11 sl-crs1-pen-0-4-5-0.sprintlink.net (144.232.20.142) 21 ms 27 ms 23 ms 12 sl-bb21-rly-15-0.sprintlink.net (144.232.20.208) 25 ms 24 ms 17 ms 13 sl-bb21-dc-5-0-0.sprintlink.net (144.232.8.164) 31 ms 33 ms 28 ms 14 sl-crs1-dc-0-4-0-0.sprintlink.net (144.232.15.13) 45 ms 54 ms 50 ms 15 sl-crs1-atl-0-8-0-1.sprintlink.net (144.232.8.146) 291 ms 283 ms 285 ms 16 sl-bb21-orl-2-0.sprintlink.net (144.232.20.87) 500 ms 525 ms * 17 sl-bb20-orl-15-0.sprintlink.net (144.232.0.98) 489 ms 489 ms 489 ms 18 sl-gw12-orl-8-0.sprintlink.net (144.232.2.178) 487 ms 486 ms 486 ms Best, Alan _______________________________________________ NANOG mailing list NANOG(a)nanog.org http://mailman.nanog.org/mailman/listinfo/nanog This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are the intended recipient, you must treat the information in confidence and in accordance with all laws related to the privacy and confidentiality of such information. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies of this email, including all attachments. Intervoice, Inc. 17811 Waterview Parkway Dallas, TX 75252 USA Intervoice Limited, Registered in England and Wales with number 2601740, 50 Park Road, Gatley, Cheshire, SK8 4HZ. VAT Number: 560421375 Intervoice GmbH, Hagenauer Straße 55, 65203 Wiesbaden, Sitz der Gesellschaft: Wiesbaden, Handelsregister: HRB 8186 (Amtsgericht Wiesbaden), Geschäftsführer: Wayne Barclay, Steffen Selbmann

1 0

Re: [NANOG] Microsoft.com PMTUD black hole?
by Nathan Anderson/FSR 12 May '08

12 May '08

Valdis.Kletnieks(a)vt.edu wrote: > The usual case where you get screwed over is when the router trying to toss > the ICMP FRAG NEEDED is *behind* the ICMP-munching firewall. And in case (2), > you still can't assume that path MTU == local MTU, because your local MTU is > likely 1500, and the fragging router often trying to stuff your 1500 byte > packet down an PPPoE tunnel that's got an MTU of 1492.... Yes, but my point was precisely that one OR the other side (server OR client) is going to NOT have the ICMP-munching firewall in between itself and the "RITM" as I have affectionately been calling it (although it is definitely possible that there are two ICMP-munchers on either side of the RITM). And case #2 is exactly what is occurring right now _anyway_: hosts assume that path MTU == local MTU even if there is already an active PMTU cache entry from a recent earlier communication with the remote host. So I don't see how making that assumption _after_ making an honest attempt at actively determining whether or not it is actually the case is any more broken than they way things are already being done. The problem is that, as I realized at the end of the message you quoted, there are potentially multiple paths between the same two hosts, and the path that the packet takes in one direction is not guaranteed to be the same path that the packet takes in the opposite direction. -- Nathan Anderson First Step Internet, LLC nathana(a)fsr.com

3 3

[NANOG] Nortel Core Switching Experience
by James Baldwin 12 May '08

12 May '08

Would anyone be willing to share their experience with Nortel as a core switch platform off list? I am building out a small campus core and have received proposal with dual ERS 8300s at the core but I have no experience, anecdotal or otherwise, with Nortel in a switching capacity. I'll be happy to provide more information regarding our environment and other systems we're looking into. Thanks James Baldwin

1 0

[NANOG] FUS for IP space fragmentation (Re: fair warning: less than 1000 days left to IPv4 exhaustion)
by Edward B. DREGER 10 May '08

10 May '08

Talk of IPv6 space hoarding and fragmentation. Ughh. Perhaps we can avoid repeating IPv4 mistakes with IPv6. Exponential problems need linear solutions. The method for handing out blocks is flawed. There's no need for linear stride-N allocations, assuming that a highly-sparse array is acceptable. Allocate thus: 1. At start of 0b/1 2. At start of 1b/1 3. At start of 01b/2 4. At start of 11b/2 5. At start of 001b/3 6. At start of 101b/3 7. At start of 011b/3 8. At start of 111b/3 (and so forth) Allocate on /1 boundaries as many times as possible... then /2... followed by /3... next /4... et cetera. Let each allocation be long enough to contain sufficient address space; the space to the right is reserved for growth. Different networks will grow at different speeds. That is handled by allocating from "largest available /N" instead of "next /N in sequence", and tends to keep new allocations away from rapidly-growing ones. Fragmentation is drastically reduced. Allocating more space is a simple matter of "grow right", reducing the "hoard as much as possible because new space is a pain" mentality. Wait... we've had this discussion before: http://www.merit.edu/mail.archives/nanog/2006-03/msg00183.html Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc(a)brics.com -*- jfconmaapaq(a)intc.net -*- sam(a)everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.

2 2