November 2006 - Test - lists.nanog.org

Anyone from SBC with networking clue available?
by Drew Weaver 15 Nov '06

15 Nov '06

thanks, -Drew

1 0

CWDM equipment (current favorites)
by Deepak Jain 15 Nov '06

15 Nov '06

A few years ago, NANOG had a discussion regarding various CWDM vendors. Repeatedly MRV was brought up as a good option for metro-area LAN type applications. Since then, I have actually touched some of the MRV product line personally and found it (and their customer support)... less than ideal. (not comparing to anyone else, and no one is really ideal). The bigger problem was that the devices seem to be less than intuitive, but rock solid once they are working. (which is what everyone praised them for). We need to place a new order for some new fiber builds and were considering some other vendors. Especially in the nx2.5G and nx10G (are CWDM x-cievers even available in 10G yet?) range. Anyone have any new favorites? I'll be glad to summarize/commiserate. :) Thanks in advance, DJ

6 6

Lucent GBE (4 x VC4) clues needed
by Saku Ytti 15 Nov '06

15 Nov '06

(oops technical question in nanog, wearing my asbestos suit) Consider this topology GSR - 3750 --(GE over 4xVC4) - NSE100 - NSE100 --(GE over 4xVC4) -- 3550 - GSR All other fibres are dark fibres, except marked. When we ping either NSE100 <-> GSR leg, when there is no background traffic there is no packet loss. If there is even few Mbps, lets say 10Mbps of background traffic we get 1-5% packet loss on 1500 bytes, and bit less packet loss on small packets. As background traffic increases packet loss quickly increases. We tried to replace (GSR-3750) with 7600, but same issue persisted. We've measured both Lucent GBE legs with having loop in other end and pushing tests from EXFO and Smartbits gear through the loop, no errors can be detected in RFC tests. There isn't very much that can be configured in the Lucent, and we've tried pretty much every setting. We've tried to set autonego on and off in every gear in the path, without any changes to observed behaviour. We've also tried to use use 1xVC4, without any changes to the behaviour. All VC4's in given leg are using same path. Even though we test the packet loss pinging from router link to router link, same packet loss is experienced for transit traffic also. We've tried to turn PXF off in NSE100. Packets between NSE100 <-> NSE100 over dark fibre are not lost. We're pretty much utterly without clues. All I can think off is some obscure IFG issue, that is, NSE100 would have less than perfect timing for IFG which would confuse Lucent regarding what is part of which frame. Does stuff like this really happen? NSE100 drops bad IP packets in PXF and there is only shared counter, so I can't tell if I get CRC for IP, I just loose the packets. But IS-IS is not handled in PXF, and I get %CLNS-4-LSPCKSUM and %CLNS-3-BADPACKET messages over both Lucent legs, but not between the NSE100's. So I assume the packets are not dropped, but broken. I swear next time I'll complain about some political issue, thanks, -- ++ytti

3 6

RE: IP adresss management verification
by Howard, W. Lee 14 Nov '06

14 Nov '06

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of David Hubbard > Sent: Monday, November 13, 2006 11:42 AM > To: nanog(a)merit.edu > Subject: RE: IP adresss management verification > > What I meant was we require a technical justification to > give a dedicated IP to a customer but many hosts do not, > or they use it as a revenue add by charging for having > a dedicated IP when there's no technical reason for it. > Previously, or maybe still, there was no mandate that web > hosts only assign dedicated IP's when it can be justified. > > David This was the topic of one of the most interesting policies ARIN ever adopted. In 2000, there was a proposal to require web hosting organizations to use virtual hosting (roughly defined as many FQDNs on one IP address), unless indidivual IP addresses were required for documented technical reasons. This proposal predates the online proposal archive, but you can track it on its progression through the Board meetings. http://www.arin.net/meetings/minutes/bot/bot2000_0612.html http://www.arin.net/meetings/minutes/bot/bot2000_1002.html There was community support for the proposal, but strong debate. The Advisory Council found consensus, the Board adopted the proposal, then a few months later suspended the policy. I think this is the only time the Board used its emergency power to set or suspend a policy. http://www.arin.net/meetings/minutes/ARIN_VI/ppm_minutes.html#webhosting On the mailing list, and at the next public policy meeting there was extensive discussion. The Advisory Council took input from the community, and decided that the best policy would be to make it a recommendation. The current policy now reads: When an ISP submits a request for IP address space to be used for IP-based web hosting, it will supply (for informational purposed only) its technical justification for this practice. ARIN will analyze this data continuously, evaluating the need for future policy changes. http://www.arin.net/policy/nrpm.html#four25 To my mind, this is a good example of the ARIN process working well: the community favored a proposal, so it was adopted, but there were significant problems. The Board suspended the policy so the AC could get community feedback, and the policy was changed based on experience. If you have an opinion on this policy, you should say so on the Public Policy Mailing List. http://lists.arin.net/mailman/listinfo/ppml Lee

1 0

RE: IP adresss management verification
by David Hubbard 14 Nov '06

14 Nov '06

From: Michael.Dillon(a)btradianz.com > > SSL is a technical justification for separate IP > addresses for web hosts. Virtual servers is another > technical justification for assigning multiple IP > addresses to a single physical server. What I meant was we require a technical justification to give a dedicated IP to a customer but many hosts do not, or they use it as a revenue add by charging for having a dedicated IP when there's no technical reason for it. Previously, or maybe still, there was no mandate that web hosts only assign dedicated IP's when it can be justified. David

6 6

Re: IP adresss management verification
by Bill Stewart 14 Nov '06

14 Nov '06

On 11/13/06, chuck goolsbee <chucklist(a)forest.net> wrote: > It pisses me off to no end when a sales guy comes to me with a > request from a customer for a /20 for a half-rack of web servers. The > justification ALWAYS comes down to this inane "search engine > optimization" pipe dream. =\ No, no, it's absolutely true, and you can tell them so, and of course you can't provision the space without the customer filling out the ARIN paperwork to justify it and sending you a copy so you know what they're really trying to do. The one customer in 32768 who actually needs it will have enough clue to be able to fill out the forms, and the rest of them will spend a month trying to figure out why they' keep getting rejected. Meanwhile, get them some IPv6 address space, so they'll be cutting edge... once Google starts crawling the IPv6 web. [Sorry - I just get really annoyed when I'm trying to look for some topic for which the SEOs and phishers have polluted the web space with bogus material trying to drag traffic to their site by pretending to offer the real content.] ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.

1 0

RE: MCI < - > Savvis in Chicago
by Wallace Keith 13 Nov '06

13 Nov '06

Similar- Boston to Chicago MCI- seeing high latency 6 3 ms 3 ms 3 ms 544.at-5-0-0.xr1.bos4.alter.net [152.63.24.222] 7 3 ms 3 ms 3 ms 0.so-4-0-0.xl1.bos4.alter.net [152.63.16.121] 8 91 ms 95 ms 95 ms 0.so-7-0-0.XL1.CHI6.ALTER.NET [152.63.65.161] 9 93 ms 95 ms 92 ms pos6-0.gw6.chi6.alter.net [152.63.68.97] 10 94 ms 81 ms 83 ms netlogic-gw.customer.alter.net [157.130.101.2] 11 87 ms 80 ms 89 ms 206-80-93-67.chi.netlogic.net [206.80.93.67] Trace complete. H:\> ________________________________ From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Mike Hammett Sent: Monday, November 13, 2006 3:14 PM To: nanog(a)nanog.org Subject: MCI < - > Savvis in Chicago Anyone else seeing this? [root@ds00209 mhammett]# tcptraceroute 206.80.93.67 4569 Selected device eth0, address 205.218.65.34, port 54461 for outgoing packets Tracing the path to 206.80.93.67 on TCP port 4569, 30 hops max 1 205.138.198.193 0.444 ms 0.322 ms 0.319 ms 2 bpr2-ge-6-2-0-302.chicagoequinix.savvis.net (208.174.225.201) 0.411 ms 0.348 ms 0.330 ms 3 bpr1-ae0.ChicagoEquinix.savvis.net (208.174.226.85) 0.370 ms 0.403 ms 0.403 ms 4 208.174.226.26 30.460 ms 30.159 ms 29.601 ms 5 0.so-5-3-0.XL2.CHI2.ALTER.NET (152.63.64.58) 29.147 ms 28.063 ms 30.176 ms 6 0.so-6-0-0.XL2.CHI6.ALTER.NET (152.63.65.126) 32.394 ms 35.813 ms 35.976 ms 7 POS7-0.GW6.CHI6.ALTER.NET (152.63.68.189) 37.018 ms 36.800 ms 37.723 ms 8 netlogic-gw.customer.alter.net (157.130.101.2) 38.169 ms 41.228 ms 37.870 ms 9 206-80-93-67.chi.netlogic.net (206.80.93.67) [closed] 35.334 ms 33.460 ms 34.075 ms ---- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

2 1

MCI < - > Savvis in Chicago
by Mike Hammett 13 Nov '06

13 Nov '06

Anyone else seeing this? [root@ds00209 mhammett]# tcptraceroute 206.80.93.67 4569 Selected device eth0, address 205.218.65.34, port 54461 for outgoing packets Tracing the path to 206.80.93.67 on TCP port 4569, 30 hops max 1 205.138.198.193 0.444 ms 0.322 ms 0.319 ms 2 bpr2-ge-6-2-0-302.chicagoequinix.savvis.net (208.174.225.201) 0.411 ms 0.348 ms 0.330 ms 3 bpr1-ae0.ChicagoEquinix.savvis.net (208.174.226.85) 0.370 ms 0.403 ms 0.403 ms 4 208.174.226.26 30.460 ms 30.159 ms 29.601 ms 5 0.so-5-3-0.XL2.CHI2.ALTER.NET (152.63.64.58) 29.147 ms 28.063 ms 30.176 ms 6 0.so-6-0-0.XL2.CHI6.ALTER.NET (152.63.65.126) 32.394 ms 35.813 ms 35.976 ms 7 POS7-0.GW6.CHI6.ALTER.NET (152.63.68.189) 37.018 ms 36.800 ms 37.723 ms 8 netlogic-gw.customer.alter.net (157.130.101.2) 38.169 ms 41.228 ms 37.870 ms 9 206-80-93-67.chi.netlogic.net (206.80.93.67) [closed] 35.334 ms 33.460 ms 34.075 ms ---- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

2 1

RFC2827-bis comments solicitation
by Fergie 13 Nov '06

13 Nov '06

First, sorry for any duplicates, but we wanted to reach all interested parties. After several discussions with many different folks last week at IETF 67 in San Diego, as well as various people over the course of the past few months, Dan Senie and I have decided to undertake an effort to "update" RFC2827/BCP38 [1]. I know that I'm not the only person who has heard various discussions in the past couple of years that concluded that (paraphrased), "BCP38 needs to be updated." Now is your chance to speak up. :-) We would very much like to solicit comments & suggestions from the community-at-large on areas where you feel BCP38 is lacking, or in areas where you feel it does not properly address with regards to prohibiting source-spoofed traffic from any given administrative network boundary, given that some technical aspects of the Internet may have changed since it's publication. While we acknowledge that a uniform application of a source address verification architecture/ingress filtering scheme will not mitigate _all_ "unwanted traffic" [2] in the Internet, it will most certainly address the issue of hosts which attempt to source-spoof traffic into the Internet. I have not set up a mailing list for this yet, but if there is enough discussion/input, I will make an effort to do so (or perhaps the SAVA mailing list [3] might be a good place for discussion). In the interim, you can contact me or Dan directly: Paul Ferguson: fergdawg(at)netzero.net Dan Senie: dts(at)senie.com Thanks, fergie & dan p.s. Also, for anyone who might be interesting in related work, there is an effort to bring some additional work into the IETF called SAVA, or Source Address Validation Architecture [4]. [1] http://www.rfc-editor.org/rfc/rfc2827.txt [2] http://www.iab.org/about/workshops/unwantedtraffic/index.html [3] http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava [4] http://www.nrc.tsinghua.edu.cn/pipermail/sava/2006-September/000004.html -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

RE: IP adresss management verification
by David Hubbard 13 Nov '06

13 Nov '06

From: chuck goolsbee > > ** I assume it is myth, but I've never heard anyone from Google make > any statements that definitively debunks it. Debunking this pervasive > among webmasters and "SEO Experts" myth sure would be a very UN-evil > thing to do if true (Hint hint you Google-folk!) > Actually they did, once, in an obscure place: http://interviews.slashdot.org/interviews/02/07/03/1352239.shtml Whenever I refer customers to that, they just tell me oh, that's from 2002, my SEO person knows that Google penalizes for sharing IP's now. I guess Google needs a time stamped banner on their site that says "As of <time>, we do not penalize for sharing IP's." so SEO 'experts' can't argue it. David

1 0