From mansaxel at besserwisser.org Mon Dec 1 03:58:11 2008 From: mansaxel at besserwisser.org (=?UTF-8?Q?M=C3=A5ns_Nilsson?=) Date: Mon, 01 Dec 2008 10:58:11 +0100 Subject: an over-the-top data center In-Reply-To: References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <49305CFB.9070703@vaxination.ca> <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> <20081201035010.GH78345@burnout.tpb.net> Message-ID: <84E9903D44E8EB2D4B96964B@rasmus.kthnoc.net> --On s?ndag, s?ndag 30 nov 2008 23.05.01 -0500 "Patrick W. Gilmore" wrote: > On Nov 30, 2008, at 10:50 PM, Niels Bakker wrote: >>> I was going to say 'this probably hinders customers adoption at >>> NetNod', but I know for a fact the "probably" is superfluous. > I didn't say it would stop everyone. Of course some people will not be > deterred, but some absolutely have. In Sweden, the reason to not choose NetNod (and to go with the smaller exchangepoints) is price and only price. No swedish ISP I know of has stated that the fact that the Stokab fibre is bought by the IXP and not the ISP is a problem per se. Some might have a better wholesale deal than NetNod has but that is still just about price. The alternative IPXen were started for two reasons, 1. Price. At the time the first one got going NetNod was running OC48 SRP as its fabric. (Anyone remember that technology?). The price of SRP technology was simply too high for many small players, and required Cisco gear, etc. 2. Convenience and reduced marginal cost, ie. #1 again. Since the first alternative (SOL-IX) was and is distributed, really small ASes could join for the price of a patch cable and an interface. > Now compare that to forcing every single participant to use unknown fiber > paths into an unknown facility. When are these fibers groomed, and onto > which unknown paths? Which fiber maintenance schedules might impact me > without my knowledge? Which construction projects elsewhere in the city > might take me down and there's no way for me to even predict that? Etc., > etc. The fiber paths into these facilities are national security issues. Expect them to be guarded accordingly (as in running them in specially blasted tunnels 30-60 meters down in the ground for the last aggregated path to the facility). I have not experienced more unpredictability nor more outages because Netnod buys the cable than when the ISP does. Same cable. And Stokab does indeed know where the cables are. > I would prefer to take my chances with the known quantity, > thankyouverymuch. Feel free to do with your network as you please. Just because you know where the cable is the backhoes won?t find it? -- M?ns Nilsson M A C H I N A I'll eat ANYTHING that's BRIGHT BLUE!! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From patrick at ianai.net Mon Dec 1 08:08:09 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 1 Dec 2008 09:08:09 -0500 Subject: an over-the-top data center In-Reply-To: <84E9903D44E8EB2D4B96964B@rasmus.kthnoc.net> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <49305CFB.9070703@vaxination.ca> <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> <20081201035010.GH78345@burnout.tpb.net> <84E9903D44E8EB2D4B96964B@rasmus.kthnoc.net> Message-ID: <37F77B99-B3D9-421D-AA04-DAEBCF94F9BC@ianai.net> On Dec 1, 2008, at 4:58 AM, M?ns Nilsson wrote: > --On s?ndag, s?ndag 30 nov 2008 23.05.01 -0500 "Patrick W. Gilmore" > wrote: > In Sweden, the reason to not choose NetNod (and to go with the smaller > exchangepoints) is price and only price. No swedish ISP I know of has > stated that the fact that the Stokab fibre is bought by the IXP and > not the > ISP is a problem per se. Some might have a better wholesale deal than > NetNod has but that is still just about price. I don't think any IXP can become a significant player on the Internet today by only attracting participants from the country in question. The Internet is not bound by political borders. (Usually. :) >> Now compare that to forcing every single participant to use unknown >> fiber >> paths into an unknown facility. When are these fibers groomed, and >> onto >> which unknown paths? Which fiber maintenance schedules might >> impact me >> without my knowledge? Which construction projects elsewhere in the >> city >> might take me down and there's no way for me to even predict that? >> Etc., >> etc. > > The fiber paths into these facilities are national security issues. > Expect > them to be guarded accordingly (as in running them in specially > blasted > tunnels 30-60 meters down in the ground for the last aggregated path > to the > facility). I have not experienced more unpredictability nor more > outages > because Netnod buys the cable than when the ISP does. Same cable. And > Stokab does indeed know where the cables are. I'm glad to hear the fibers seem to be stable. Past performance is no guarantee of future profits and all that, but it is good to know care has been taken in the past. As for the blasting of tunnels and national security angle, this is an IXP, not nuclear missile launch control. It should not be your only vector to get bits from point A to B. And if it is, then you have a larger problem than worrying about the facility withstanding physical attack. And no, attaching to multiple NetNod nodes is not a solution, since only Stockholm has a large number of participants. End of day, an IXP is not some magical thing. It is an ethernet switch allowing multiple networks to exchange traffic more easily than direct interconnection - and that is all it should be. It should not be mission critical. Treating it as such raises the cost, and therefore barrier to entry, which lowers its value. -- TTFN, patrick From randy at psg.com Mon Dec 1 08:12:01 2008 From: randy at psg.com (Randy Bush) Date: Mon, 01 Dec 2008 23:12:01 +0900 Subject: an over-the-top data center In-Reply-To: <37F77B99-B3D9-421D-AA04-DAEBCF94F9BC@ianai.net> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <49305CFB.9070703@vaxination.ca> <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> <20081201035010.GH78345@burnout.tpb.net> <84E9903D44E8EB2D4B96964B@rasmus.kthnoc.net> <37F77B99-B3D9-421D-AA04-DAEBCF94F9BC@ianai.net> Message-ID: <4933F0B1.3020505@psg.com> > I don't think any IXP can become a significant player on the Internet > today by only attracting participants from the country in question. netnod is very successful. i guess they must operate from more than sweden, then, eh? engineers judge by results, not word count. randy From patrick at ianai.net Mon Dec 1 08:27:19 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 1 Dec 2008 09:27:19 -0500 Subject: an over-the-top data center In-Reply-To: <4933F0B1.3020505@psg.com> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <49305CFB.9070703@vaxination.ca> <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> <20081201035010.GH78345@burnout.tpb.net> <84E9903D44E8EB2D4B96964B@rasmus.kthnoc.net> <37F77B99-B3D9-421D-AA04-DAEBCF94F9BC@ianai.net> <4933F0B1.3020505@psg.com> Message-ID: On Dec 1, 2008, at 9:12 AM, Randy Bush wrote: >> I don't think any IXP can become a significant player on the Internet >> today by only attracting participants from the country in question. > > netnod is very successful. i guess they must operate from more than > sweden, then, eh? NetNod is successful. Very is a matter of opinion. As for "operate from more than sweden", that is trivial to confirm by looking at their member list. So now that we have agreed, did you have a point, or just want to run up your word count? > engineers judge by results, not word count. Wow, Randy, we are in agreement again. To be clear, are you suggesting IXPs consider hiding their switches, forcing you to use a single fiber providers, not allowing anyone to know the path, etc.? I want to be sure I understand what you mean, since "engineers" like to make serious points, not flippant sound bites. -- TTFN, patrick From randy at psg.com Mon Dec 1 08:30:29 2008 From: randy at psg.com (Randy Bush) Date: Mon, 01 Dec 2008 23:30:29 +0900 Subject: an over-the-top data center In-Reply-To: References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <49305CFB.9070703@vaxination.ca> <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> <20081201035010.GH78345@burnout.tpb.net> <84E9903D44E8EB2D4B96964B@rasmus.kthnoc.net> <37F77B99-B3D9-421D-AA04-DAEBCF94F9BC@ianai.net> <4933F0B1.3020505@psg.com> Message-ID: <4933F505.8090300@psg.com> some go to sweden for the weather. some go for netnode. netnode does not go to them. and yes, netnod is bunkered up the ying yang. qed. randy From patrick at ianai.net Mon Dec 1 08:34:59 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 1 Dec 2008 09:34:59 -0500 Subject: an over-the-top data center In-Reply-To: <4933F505.8090300@psg.com> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <49305CFB.9070703@vaxination.ca> <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> <20081201035010.GH78345@burnout.tpb.net> <84E9903D44E8EB2D4B96964B@rasmus.kthnoc.net> <37F77B99-B3D9-421D-AA04-DAEBCF94F9BC@ianai.net> <4933F0B1.3020505@psg.com> <4933F505.8090300@psg.com> Message-ID: <634A51D5-E5CC-497E-81B1-D642E71735B5@ianai.net> On Dec 1, 2008, at 9:30 AM, Randy Bush wrote: > some go to sweden for the weather. some go for netnode. netnode does > not go to them. and yes, netnod is bunkered up the ying yang. qed. By your logic, every IXP which has any participants is a good model and cannot be improved. An obvious logical fallacy. One could assume this means you have no clue what you are talking about, but I will give you the benefit of the doubt. IOW: You are only interested in your word count. QED. -- TTFN, patrick From randy at psg.com Mon Dec 1 08:38:19 2008 From: randy at psg.com (Randy Bush) Date: Mon, 01 Dec 2008 23:38:19 +0900 Subject: an over-the-top data center In-Reply-To: <634A51D5-E5CC-497E-81B1-D642E71735B5@ianai.net> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <49305CFB.9070703@vaxination.ca> <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> <20081201035010.GH78345@burnout.tpb.net> <84E9903D44E8EB2D4B96964B@rasmus.kthnoc.net> <37F77B99-B3D9-421D-AA04-DAEBCF94F9BC@ianai.net> <4933F0B1.3020505@psg.com> <4933F505.8090300@psg.com> <634A51D5-E5CC-497E-81B1-D642E71735B5@ianai.net> Message-ID: <4933F6DB.3070304@psg.com> hint: your continued ad homina do not help your argument > By your logic, every IXP which has any participants is a good model and > cannot be improved. the criterion you set was success, not perfection. netnod is quite successful. is this discussion successful? i think not. good bye and good night. randy From mansaxel at besserwisser.org Mon Dec 1 10:06:46 2008 From: mansaxel at besserwisser.org (=?UTF-8?Q?M=C3=A5ns_Nilsson?=) Date: Mon, 01 Dec 2008 17:06:46 +0100 Subject: an over-the-top data center In-Reply-To: <37F77B99-B3D9-421D-AA04-DAEBCF94F9BC@ianai.net> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <49305CFB.9070703@vaxination.ca> <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> <20081201035010.GH78345@burnout.tpb.net> <84E9903D44E8EB2D4B96964B@rasmus.kthnoc.net> <37F77B99-B3D9-421D-AA04-DAEBCF94F9BC@ianai.net> Message-ID: <1EF5A80BBAAC8DA3299E017A@rasmus.kthnoc.net> --On m?ndag, m?ndag 1 dec 2008 09.08.09 -0500 "Patrick W. Gilmore" wrote: > I don't think any IXP can become a significant player on the Internet > today by only attracting participants from the country in question. The > Internet is not bound by political borders. (Usually. :) There is a significant amount of traffic being exchanged between swedish operators on Netnod. It might be the case that the broadband penetration in Sweden justifies the establishment of local IXPen. This is however irrelevant to the discussion at hand -- or did you think about some kind of issue with connectivity from Stockholm and abroad? At least 3-4 providers sell connectivity into Stockholm on own fiber paths. Is Netnod useless to you because you are not one of them? > As for the blasting of tunnels and national security angle, this is an > IXP, not nuclear missile launch control. It should not be your only > vector to get bits from point A to B. And if it is, then you have a > larger problem than worrying about the facility withstanding physical > attack. It is an optimisation, a very well engineered one. > And no, attaching to multiple NetNod nodes is not a solution, since only > Stockholm has a large number of participants. Probably true for international clients. Less so for Swedish ISPen. > End of day, an IXP is not some magical thing. It is an ethernet switch > allowing multiple networks to exchange traffic more easily than direct > interconnection - and that is all it should be. It should not be mission > critical. Treating it as such raises the cost, and therefore barrier to > entry, which lowers its value. You did not answer my question on usability of fiber based on amount of knowledge about where it is. -- M?ns Nilsson M A C H I N A There's a little picture of ED MCMAHON doing BAD THINGS to JOAN RIVERS in a $200,000 MALIBU BEACH HOUSE!! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From patrick at ianai.net Mon Dec 1 10:53:58 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 1 Dec 2008 11:53:58 -0500 Subject: an over-the-top data center In-Reply-To: <1EF5A80BBAAC8DA3299E017A@rasmus.kthnoc.net> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <49305CFB.9070703@vaxination.ca> <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> <20081201035010.GH78345@burnout.tpb.net> <84E9903D44E8EB2D4B96964B@rasmus.kthnoc.net> <37F77B99-B3D9-421D-AA04-DAEBCF94F9BC@ianai.net> <1EF5A80BBAAC8DA3299E017A@rasmus.kthnoc.net> Message-ID: On Dec 1, 2008, at 11:06 AM, M?ns Nilsson wrote: >> End of day, an IXP is not some magical thing. It is an ethernet >> switch >> allowing multiple networks to exchange traffic more easily than >> direct >> interconnection - and that is all it should be. It should not be >> mission >> critical. Treating it as such raises the cost, and therefore >> barrier to >> entry, which lowers its value. > You did not answer my question on usability of fiber based on amount > of > knowledge about where it is. Of course knowing where the fiber is does not stop the backhoes. It was obvious you were being silly, so I ignored it. By that logic, providers should not check any fiber path they purchase because it will not stop the backhoes. I suspect most providers will continue to buy from multiple providers, check the paths themselves, ensure grooming onto a single path is not a problem, and several other perfectly valid operational best practices which are impossible at NetNod. OTOH: My paragraph above yours is a serious consideration, which you have blithely ignored. As I said before, feel free to use what you please, where you please. Your network, your decision. I frequently do things which would not be considered best practices in certain instances, but that does not make them valid for everyone everywhere, and I would not argue such. -- TTFN, patrick From jerj at coplanar.net Mon Dec 1 10:54:47 2008 From: jerj at coplanar.net (Jeremy Jackson) Date: Mon, 01 Dec 2008 11:54:47 -0500 Subject: an over-the-top data center In-Reply-To: References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <49305CFB.9070703@vaxination.ca> <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> <20081201035010.GH78345@burnout.tpb.net> Message-ID: <1228150487.782.184.camel@ragnarok> On Sun, 2008-11-30 at 23:05 -0500, Patrick W. Gilmore wrote: > Now compare that to forcing every single participant to use unknown > fiber paths into an unknown facility. When are these fibers groomed, > and onto which unknown paths? Which fiber maintenance schedules might > impact me without my knowledge? Which construction projects elsewhere > in the city might take me down and there's no way for me to even > predict that? Etc., etc. > > I would prefer to take my chances with the known quantity, > thankyouverymuch. Feel free to do with your network as you please. > I wonder if there is a solution, in general to diverse physical routing... if you buy from multiple carriers, they might very well share the same fibre condo, or the same dark fibre vendor. if you buy diversity from one vendor, with only handwaving as the guarantee, you end up with Bell Canada's CO fire a couple years ago, that took down things which were *supposed* to be redundant. What are people's experience with knowing the physical routing? NetNod may be over-the-top secrecy wise, but are *any* carriers/facility providers any more "free" with information about the details of where their infrastructure is that supports the services you are buying? It seems the general practice is to claim everything is on a need-to-know basis, with the unspoken/unwritten caveat that nobody's needs will ever be considered valid? -- Jeremy Jackson Coplanar Networks (519)489-4903 http://www.coplanar.net jerj at coplanar.net From danny at tcb.net Mon Dec 1 12:27:30 2008 From: danny at tcb.net (Danny McPherson) Date: Mon, 1 Dec 2008 11:27:30 -0700 Subject: an over-the-top data center In-Reply-To: <20081128083433.0e18c7e2@cs.columbia.edu> References: <20081128083433.0e18c7e2@cs.columbia.edu> Message-ID: <7A8D1E7B-78E9-4629-A0F6-72BFFE7B019C@tcb.net> On Nov 28, 2008, at 6:34 AM, Steven M. Bellovin wrote: > http://royal.pingdom.com/2008/11/14/the-worlds-most-super-designed-data-center-fit-for-a-james-bond-villain/ > (No, I don't know if it's real or not.) I recall visiting something of this sort a couple years back.. On a related noted, some have professed that adapting old ships into data centers would provide eco-friendly secure data center solutions. I wonder if "pirates" were listed anywhere in their business plan... -danny From mansaxel at besserwisser.org Mon Dec 1 12:32:11 2008 From: mansaxel at besserwisser.org (=?UTF-8?Q?M=C3=A5ns_Nilsson?=) Date: Mon, 01 Dec 2008 19:32:11 +0100 Subject: an over-the-top data center In-Reply-To: References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <49305CFB.9070703@vaxination.ca> <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> <20081201035010.GH78345@burnout.tpb.net> <84E9903D44E8EB2D4B96964B@rasmus.kthnoc.net> <37F77B99-B3D9-421D-AA04-DAEBCF94F9BC@ianai.net> <1EF5A80BBAAC8DA3299E017A@rasmus.kthnoc.net> Message-ID: <71876B4AAECEBC2121E4DE5C@rasmus.kthnoc.net> --On m?ndag, m?ndag 1 dec 2008 11.53.58 -0500 "Patrick W. Gilmore" wrote: > On Dec 1, 2008, at 11:06 AM, M?ns Nilsson wrote: > >>> End of day, an IXP is not some magical thing. It is an ethernet >>> switch >>> allowing multiple networks to exchange traffic more easily than >>> direct >>> interconnection - and that is all it should be. It should not be >>> mission >>> critical. Treating it as such raises the cost, and therefore >>> barrier to >>> entry, which lowers its value. Yes. I do not disagree. The alternates that popped up and made Netnod switch to Ethernet from SRP were most welcome. SRR mode on that ring was not funny, btw. > Of course knowing where the fiber is does not stop the backhoes. It was > obvious you were being silly, so I ignored it. Ok. Indeed. > By that logic, providers > should not check any fiber path they purchase because it will not stop > the backhoes. I suspect most providers will continue to buy from > multiple providers, check the paths themselves, ensure grooming onto a > single path is not a problem, and several other perfectly valid > operational best practices which are impossible at NetNod. Netnod with the help of Stokab can guarantee that the two paths to switches A and B are diverse. It is a normal requirement one can make (at a cost, but that is to be expected) when sourcing Stokab fibre. They know where their stuff is and understand the importance of getting it properly separated. Other providers in Sweden are similar. I have no reason not to trust them, having seen the inside of several large calls for tender on dispersed path plants, with fibre paths well documented. That the path of the last mile to the cave is hidden and secret is a very small problem. > OTOH: My paragraph above yours is a serious consideration, which you have > blithely ignored. Not so anymore, if I've understood correctly. Drop this dead horse? -- M?ns Nilsson M A C H I N A Hello, GORRY-O!! I'm a GENIUS from HARVARD!! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jfmezei at vaxination.ca Mon Dec 1 13:05:34 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Mon, 01 Dec 2008 14:05:34 -0500 Subject: an over-the-top data center In-Reply-To: <37F77B99-B3D9-421D-AA04-DAEBCF94F9BC@ianai.net> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <49305CFB.9070703@vaxination.ca> <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> <20081201035010.GH78345@burnout.tpb.net> <84E9903D44E8EB2D4B96964B@rasmus.kthnoc.net> <37F77B99-B3D9-421D-AA04-DAEBCF94F9BC@ianai.net> Message-ID: <4934357E.7030502@vaxination.ca> Patrick W. Gilmore wrote: > End of day, an IXP is not some magical thing. It is an ethernet > switch allowing multiple networks to exchange traffic more easily than > direct interconnection - and that is all it should be. It should not > be mission critical. Treating it as such raises the cost, and > therefore barrier to entry, which lowers its value. Exchange points are often located in the same building as a carrier hotel which houses infrastructure for many ISPs and many transit providers. If you consider the internet is used only by teenage males to learn about female anatomy (pictures and movies), then your statement is acceptable. But with the Internet now used for serious applications, the focus point of a carrier hotel and exchange becomes much more mission critical. Ane because it is a focus point, it becomes much harder to have redundancy in the buildings (to provide for disaster tolerance). So the natural avenue is to strenghten/re-inforce your one central building. But availability s measured by the weakest link. You can have a bunker data centre like the one shown in this thread, but if, at the end of the day, all of a city's fibre links to the rest of the world follow the same railway track right of way to exit the city (and cross the same bridges) , then you still have a weak spot and central points of failure. From lyndon at orthanc.ca Mon Dec 1 13:19:43 2008 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Mon, 1 Dec 2008 11:19:43 -0800 Subject: an over-the-top data center In-Reply-To: <7A8D1E7B-78E9-4629-A0F6-72BFFE7B019C@tcb.net> References: <20081128083433.0e18c7e2@cs.columbia.edu> <7A8D1E7B-78E9-4629-A0F6-72BFFE7B019C@tcb.net> Message-ID: <08A31BEE-F5A7-4B31-9A09-1E9F2A8E1B3A@orthanc.ca> On 1-Dec-08, at 10:27 AM, Danny McPherson wrote: > On a related noted, some have professed that adapting old > ships into data centers would provide eco-friendly secure > data center solutions. Your data connection to shore is going to be tenuous at best. One good blow strong enough to make you drag anchor and you kiss goodbye your fibre trunk connection. Putting that back in service is a bit more than a four hour splice job. An alternative would be to run a microwave link to shore, but I'm not sure I would want to bet the farm on the mechanics necessary to keep the dish aligned. And what do you do when it's time to haul out and paint the bottom?!? Then there is the matter of power. It wouldn't be very hard to DOS the entire operation by taking out the fuel barges. I suppose you could permanently tie up to a pier, but at that point you're just a building with a leaky basement. I don't see how anyone could claim this is more secure than a purpose-built data centre. (And even at anchor, how do you stop someone from taking you out with something as simple as a drill?) --lyndon (mailing via Wimax from S/V Bandido I, at the dock in Vancouver :-) From patrick at ianai.net Mon Dec 1 13:22:50 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 1 Dec 2008 14:22:50 -0500 Subject: an over-the-top data center In-Reply-To: <4934357E.7030502@vaxination.ca> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <49305CFB.9070703@vaxination.ca> <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> <20081201035010.GH78345@burnout.tpb.net> <84E9903D44E8EB2D4B96964B@rasmus.kthnoc.net> <37F77B99-B3D9-421D-AA04-DAEBCF94F9BC@ianai.net> <4934357E.7030502@vaxination.ca> Message-ID: <450A532C-2419-43E7-A277-CD3F6B1C83A2@ianai.net> On Dec 1, 2008, at 2:05 PM, Jean-Fran?ois Mezei wrote: > Patrick W. Gilmore wrote: > >> End of day, an IXP is not some magical thing. It is an ethernet >> switch allowing multiple networks to exchange traffic more easily >> than >> direct interconnection - and that is all it should be. It should not >> be mission critical. Treating it as such raises the cost, and >> therefore barrier to entry, which lowers its value. > > Exchange points are often located in the same building as a carrier > hotel which houses infrastructure for many ISPs and many transit > providers. > > If you consider the internet is used only by teenage males to learn > about female anatomy (pictures and movies), then your statement is > acceptable. But with the Internet now used for serious applications, > the > focus point of a carrier hotel and exchange becomes much more mission > critical. > > Ane because it is a focus point, it becomes much harder to have > redundancy in the buildings (to provide for disaster tolerance). So > the > natural avenue is to strenghten/re-inforce your one central building. It is not. The Internet can be mission critical. (Well, not really, but it's trying.) And for something mission critical, a single point, no matter how well reinforced, is not good enough. The exchange point should _NOT_ be mission critical. As I explained multiple times in the thread, if that is your only vector, your design is broken. Period. Care to argue otherwise? And if the IXP is not your only vector, if your redundancy is greater than any single building however deeply it is buried, then that IXP / building / vector is not mission critical. Treating it at such raises its price, which raises its barrier of entry, which lowers its utility. Unless you think only NORAD-approved networks should peer? -- TTFN, patrick From patrick at ianai.net Mon Dec 1 13:24:52 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 1 Dec 2008 14:24:52 -0500 Subject: an over-the-top data center In-Reply-To: <08A31BEE-F5A7-4B31-9A09-1E9F2A8E1B3A@orthanc.ca> References: <20081128083433.0e18c7e2@cs.columbia.edu> <7A8D1E7B-78E9-4629-A0F6-72BFFE7B019C@tcb.net> <08A31BEE-F5A7-4B31-9A09-1E9F2A8E1B3A@orthanc.ca> Message-ID: <0F9E7CEE-D5A8-4905-92F5-63D0689D4C30@ianai.net> On Dec 1, 2008, at 2:19 PM, Lyndon Nerenberg wrote: > On 1-Dec-08, at 10:27 AM, Danny McPherson wrote: > >> On a related noted, some have professed that adapting old >> ships into data centers would provide eco-friendly secure >> data center solutions. > > Your data connection to shore is going to be tenuous at best. One > good blow strong enough to make you drag anchor and you kiss goodbye > your fibre trunk connection. Putting that back in service is a bit > more than a four hour splice job. Not if the ship is literally encased in concrete at the shore. Which solves all your other problems as well. There are even examples of actual free-floating ships which have been stable for a decade or more. See the floating casinos in Louisiana, which have been hit by hurricanes, and are still attached to shore by electricity, bits, and physically. -- TTFN, patrick From sethm at rollernet.us Mon Dec 1 13:30:51 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 01 Dec 2008 11:30:51 -0800 Subject: an over-the-top data center In-Reply-To: <0F9E7CEE-D5A8-4905-92F5-63D0689D4C30@ianai.net> References: <20081128083433.0e18c7e2@cs.columbia.edu> <7A8D1E7B-78E9-4629-A0F6-72BFFE7B019C@tcb.net> <08A31BEE-F5A7-4B31-9A09-1E9F2A8E1B3A@orthanc.ca> <0F9E7CEE-D5A8-4905-92F5-63D0689D4C30@ianai.net> Message-ID: <49343B6B.3030909@rollernet.us> Patrick W. Gilmore wrote: > On Dec 1, 2008, at 2:19 PM, Lyndon Nerenberg wrote: >> On 1-Dec-08, at 10:27 AM, Danny McPherson wrote: >> >>> On a related noted, some have professed that adapting old >>> ships into data centers would provide eco-friendly secure >>> data center solutions. >> >> Your data connection to shore is going to be tenuous at best. One good >> blow strong enough to make you drag anchor and you kiss goodbye your >> fibre trunk connection. Putting that back in service is a bit more >> than a four hour splice job. > > Not if the ship is literally encased in concrete at the shore. Which > solves all your other problems as well. > > There are even examples of actual free-floating ships which have been > stable for a decade or more. See the floating casinos in Louisiana, > which have been hit by hurricanes, and are still attached to shore by > electricity, bits, and physically. > The same ones that were moved inland and deposited on top of someone's house? Hardly a good example of stable. http://www.katrina.noaa.gov/helicopter/images/katrina-biloxi-miss-grand-casino2-2005.jpg ~Seth From lyndon at orthanc.ca Mon Dec 1 13:31:24 2008 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Mon, 1 Dec 2008 11:31:24 -0800 Subject: an over-the-top data center In-Reply-To: <0F9E7CEE-D5A8-4905-92F5-63D0689D4C30@ianai.net> References: <20081128083433.0e18c7e2@cs.columbia.edu> <7A8D1E7B-78E9-4629-A0F6-72BFFE7B019C@tcb.net> <08A31BEE-F5A7-4B31-9A09-1E9F2A8E1B3A@orthanc.ca> <0F9E7CEE-D5A8-4905-92F5-63D0689D4C30@ianai.net> Message-ID: <2B7A594B-FC2D-42BC-8A57-BF3EE7A17D38@orthanc.ca> > Not if the ship is literally encased in concrete at the shore. > Which solves all your other problems as well. But that's not a ship, it's a building. > There are even examples of actual free-floating ships which have > been stable for a decade or more. And many counter-examples. --lyndon From kurtis at kurtis.pp.se Mon Dec 1 13:14:20 2008 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 1 Dec 2008 20:14:20 +0100 Subject: an over-the-top data center In-Reply-To: <37F77B99-B3D9-421D-AA04-DAEBCF94F9BC@ianai.net> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <49305CFB.9070703@vaxination.ca> <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> <20081201035010.GH78345@burnout.tpb.net> <84E9903D44E8EB2D4B96964B@rasmus.kthnoc.net> <37F77B99-B3D9-421D-AA04-DAEBCF94F9BC@ianai.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1 dec 2008, at 15.08, Patrick W. Gilmore wrote: > On Dec 1, 2008, at 4:58 AM, M?ns Nilsson wrote: >> --On s?ndag, s?ndag 30 nov 2008 23.05.01 -0500 "Patrick W. Gilmore" >> wrote: > >> In Sweden, the reason to not choose NetNod (and to go with the >> smaller >> exchangepoints) is price and only price. No swedish ISP I know of has >> stated that the fact that the Stokab fibre is bought by the IXP and >> not the >> ISP is a problem per se. Some might have a better wholesale deal than >> NetNod has but that is still just about price. > > I don't think any IXP can become a significant player on the > Internet today by only attracting participants from the country in > question. The Internet is not bound by political borders. > (Usually. :) I am not trying to defend myself here, everyone is entitled to their opinion on which IX model works better than another, but it might be worth pointing something out in the history of Netnod. Because of the fiber monopoly in Stockholm, that pre-dates the estblishment of any neutral co-lo, the Swedish operators built their own datacenters. Therefor, when NEtnod was established, there simply was no single point where the operators could have established the switches. This was *one* of the reasons the bunkers where chosen. Best regards, - - - kurtis - - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkk0M9kACgkQAFdZ6xrc/t4oHgCgq1JRMxde9eWYchUyQvQgnITY PnAAn1K6C5Lird6GWKuPqRSEFfKinjU9 =SA80 - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkk0N4wACgkQAFdZ6xrc/t6OfgCgitw9i+PsfM76nc1UqxAfHNbj PJUAn3jjtA2xQlH/r4LqsXr1KU+N3VVZ =3QNe -----END PGP SIGNATURE----- From kurtis at kurtis.pp.se Mon Dec 1 13:35:36 2008 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 1 Dec 2008 20:35:36 +0100 Subject: an over-the-top data center In-Reply-To: <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <49305CFB.9070703@vaxination.ca> <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> Message-ID: <963948EB-C210-413A-9D91-1DE9A8B437D4@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patrick, On 1 dec 2008, at 02.33, Patrick W. Gilmore wrote: > On Nov 28, 2008, at 4:04 PM, Jean-Fran?ois Mezei wrote: > >> The thing about a carrier hotel is that it cannot be a secret >> location >> since you need to allow various carriers and ISPs to have physical >> access to the building so they can install/manage their >> servers/routers/switches. >> >> The advantage of this swedish data centre is that even if its >> location >> is well known, it is pretty hard to harm the building. You can't >> run a >> truck full of explosives into it for instance. > > Unfortunately, you also cannot run your own fiber there, colo > equipment there, visit it for any reason, etc. for the non-Stockholm locations that is not true. As a matter of fact, you will have to get your own fibers to Netnod there. As for co-lo of equipment, not as easy as in a neutral co-location. As for visits, why would you need to? As for fibers, Stockholm has a fiber monopoloy run by the city of Stockholm. So you would have to buy fibers from that monopoloy in any case. > I was going to say 'this probably hinders customers adoption at > NetNod', but I know for a fact the "probably" is superfluous. That is your judgement. We have seen the largest growth for a long time in the last year. Best regards, - - - kurtis - - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkk0MeMACgkQAFdZ6xrc/t7REACfThTzW+3+mvA0ttvViTTVmMfv qgUAmwQyiuAaB/+vTD9wMtqCq7PDhw0F =ycFe - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkk0PIgACgkQAFdZ6xrc/t727wCgvi0zOw4ivBe7AG98hb+DqoGI qicAn0WKn/yUoqYLln2yP7GuxM16NHzT =7Njx -----END PGP SIGNATURE----- From mike.lyon at gmail.com Mon Dec 1 13:49:10 2008 From: mike.lyon at gmail.com (Mike Lyon) Date: Mon, 1 Dec 2008 11:49:10 -0800 Subject: EIGRP question... Message-ID: <1b5c1c150812011149u4ca4fb54s1acdb49afa18c03b@mail.gmail.com> Howdy, So I am working on an MPLS migration from provider "A" to provider "B" of which both terminate into my core via customer prem routers. I have a single EIGRP process between my core and the two customer prem routers supplied to me by both providers, of which I don't have access to. My question is, I would like to take the routes that come in from the neighbor "A" router and apply some kind of metrics to them so they are not preferred over the routes learned by the provider "B" router. Is this possible or would I need to be running different EIGRP processes between the two customer prem routers and then play around with some redistribution? I am hoping this isn't the case because I don't have access to those CPE routers and redistribution is a nasty thing... Thanks in advance for any enlightnment. Cheers, Mike From jambern at grnoc.iu.edu Mon Dec 1 13:58:46 2008 From: jambern at grnoc.iu.edu (Jeff Ambern) Date: Mon, 01 Dec 2008 14:58:46 -0500 Subject: EIGRP question... In-Reply-To: <1b5c1c150812011149u4ca4fb54s1acdb49afa18c03b@mail.gmail.com> Message-ID: How about setting the bandwidth of the link to provider B higher. Or increasing the delay of the link to provider A? Either of these should work for you. On 12/1/08 2:49 PM, "Mike Lyon" wrote: > Howdy, > > So I am working on an MPLS migration from provider "A" to provider "B" > of which both terminate into my core via customer prem routers. I have > a single EIGRP process between my core and the two customer prem > routers supplied to me by both providers, of which I don't have access > to. My question is, I would like to take the routes that come in from > the neighbor "A" router and apply some kind of metrics to them so they > are not preferred over the routes learned by the provider "B" router. > > Is this possible or would I need to be running different EIGRP > processes between the two customer prem routers and then play around > with some redistribution? I am hoping this isn't the case because I > don't have access to those CPE routers and redistribution is a nasty > thing... > > Thanks in advance for any enlightnment. > > Cheers, > Mike > Jeff From darden at armc.org Mon Dec 1 14:24:30 2008 From: darden at armc.org (Darden, Patrick S.) Date: Mon, 1 Dec 2008 15:24:30 -0500 Subject: EIGRP question... In-Reply-To: <1b5c1c150812011149u4ca4fb54s1acdb49afa18c03b@mail.gmail.com> Message-ID: My first thought for this was: route filtering. My second thought was: use different AS#s. Then I reread your question and thought of something far simpler. It seems to me if you are migrating from provider A to provider B then you should set everything up for B, then shut down the interface to A. If everything works, then you are good, if not then you bring that interface back up in a hurry! Is this more complicated? Are you, for example, moving to B but planning on keeping A as a backup? Or, perhaps your MPLS migration is from non-MPLS to an MPLS based system? So you are keeping A and B? Or perhaps A and B are customers, not really providers? Anyways, not sure of your exact situation, but to answer your question directly: EIGRP uses 5 metrics for weighting paths --delay --bandwidth --reliability --load --MTU It does not use hop count for path weighting. This is a problem, as it would be your easy solution--pretty much auto-solving the condition. 1. You can't really count on delay, and you can't fiddle with it in any easy manner. 2. You could artificially limit bandwidth using your core. I am unsure if this would help you; however, it would answer your stated question. 3. Reliability--calculated dynamically. Not helpful for you. 4. Load--this is the load on the interface I think (0-255). Calculated dynamically. Not helpful for you. 5. MTU--I have no idea how you could use this. Not user configurable in this case, I don't think. I have never used it myself for metrics. It is theoretically used, but never seen it used (in eigrp). Not sure if this helps. --p -----Original Message----- From: Mike Lyon [mailto:mike.lyon at gmail.com] Sent: Monday, December 01, 2008 2:49 PM To: Nanog Mailing list Subject: EIGRP question... Howdy, So I am working on an MPLS migration from provider "A" to provider "B" of which both terminate into my core via customer prem routers. I have a single EIGRP process between my core and the two customer prem routers supplied to me by both providers, of which I don't have access to. My question is, I would like to take the routes that come in from the neighbor "A" router and apply some kind of metrics to them so they are not preferred over the routes learned by the provider "B" router. Is this possible or would I need to be running different EIGRP processes between the two customer prem routers and then play around with some redistribution? I am hoping this isn't the case because I don't have access to those CPE routers and redistribution is a nasty thing... Thanks in advance for any enlightnment. Cheers, Mike From lowen at pari.edu Mon Dec 1 15:03:39 2008 From: lowen at pari.edu (Lamar Owen) Date: Mon, 1 Dec 2008 16:03:39 -0500 Subject: an over-the-top data center In-Reply-To: <7A8D1E7B-78E9-4629-A0F6-72BFFE7B019C@tcb.net> References: <20081128083433.0e18c7e2@cs.columbia.edu> Message-ID: <200812011603.39893.lowen@pari.edu> On Monday 01 December 2008 13:27:30 Danny McPherson wrote: > On a related noted, some have professed that adapting old > ships into data centers would provide eco-friendly secure > data center solutions. You mean something akin to Sealand's HavenCo? Yes, I know that's an old fort, and not a ship, but a similar concept at least. From smb at cs.columbia.edu Mon Dec 1 15:34:26 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Mon, 1 Dec 2008 16:34:26 -0500 Subject: an over-the-top data center In-Reply-To: <200812011603.39893.lowen@pari.edu> References: <20081128083433.0e18c7e2@cs.columbia.edu> <200812011603.39893.lowen@pari.edu> Message-ID: <20081201163426.2499b65c@cs.columbia.edu> On Mon, 1 Dec 2008 16:03:39 -0500 Lamar Owen wrote: > On Monday 01 December 2008 13:27:30 Danny McPherson wrote: > > On a related noted, some have professed that adapting old > > ships into data centers would provide eco-friendly secure > > data center solutions. > > You mean something akin to Sealand's HavenCo? Yes, I know that's an > old fort, and not a ship, but a similar concept at least. > > HavenCo, which ran a datacenter on the "nation" of Sealand, is no longer operating there: http://www.theregister.co.uk/2008/11/25/havenco/ --Steve Bellovin, http://www.cs.columbia.edu/~smb From martin at airwire.ie Mon Dec 1 15:53:26 2008 From: martin at airwire.ie (Martin List-Petersen) Date: Mon, 01 Dec 2008 21:53:26 +0000 Subject: an over-the-top data center In-Reply-To: <20081201163426.2499b65c@cs.columbia.edu> References: <20081128083433.0e18c7e2@cs.columbia.edu> <200812011603.39893.lowen@pari.edu> <20081201163426.2499b65c@cs.columbia.edu> Message-ID: <49345CD6.9080405@airwire.ie> Steven M. Bellovin wrote: > > HavenCo, which ran a datacenter on the "nation" of Sealand, is > no longer operating there: > http://www.theregister.co.uk/2008/11/25/havenco/ > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > If you do a bit more research on that one, it never got to a serious point. They had one 802.11b onto the platform and never got very far with it. No fiber and no redundancy. However the idea was a bit of a novelty, because it's claimed to be sovereign territory. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From yahoo at jimpop.com Mon Dec 1 15:55:09 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Mon, 1 Dec 2008 16:55:09 -0500 Subject: an over-the-top data center In-Reply-To: <20081201163426.2499b65c@cs.columbia.edu> References: <20081128083433.0e18c7e2@cs.columbia.edu> <200812011603.39893.lowen@pari.edu> <20081201163426.2499b65c@cs.columbia.edu> Message-ID: <7ff145960812011355m30f43b16u9918598bf1ae2a4@mail.gmail.com> On Mon, Dec 1, 2008 at 16:34, Steven M. Bellovin wrote: > HavenCo, which ran a datacenter on the "nation" of Sealand, is > no longer operating there: Which is the same story for most (if not all) of these hype-driven "bullet-proof" data centers. I recall a .com CEO espousing the capabilities of his datacenter-inside-an-old-bank-vault to prevent DoS attacks such as the one that had hit Yahoo! the week before. I must say that the provided dinner, drinks and Hummer Limo ride, to the DC, made the humor of the CEO more enjoyable. Sadly a lot of older pensioners were eating his every word. At that time I worked for an equipment/services reseller and I persisted quietly, as best I could, to save some people's life savings. I felt like a diver witnessing a herring infused shark fest. -Jim P. From lowen at pari.edu Mon Dec 1 15:55:18 2008 From: lowen at pari.edu (Lamar Owen) Date: Mon, 1 Dec 2008 16:55:18 -0500 Subject: an over-the-top data center In-Reply-To: <20081201163426.2499b65c@cs.columbia.edu> References: <20081128083433.0e18c7e2@cs.columbia.edu> Message-ID: <200812011655.19182.lowen@pari.edu> On Monday 01 December 2008 16:34:26 Steven M. Bellovin wrote: > On Mon, 1 Dec 2008 16:03:39 -0500 > Lamar Owen wrote: > > You mean something akin to Sealand's HavenCo? Yes, I know that's an > > old fort, and not a ship, but a similar concept at least. > HavenCo, which ran a datacenter on the "nation" of Sealand, is > no longer operating there: > http://www.theregister.co.uk/2008/11/25/havenco/ Which shows how well the concept works; which is why I mentioned it.... From jfmezei at vaxination.ca Mon Dec 1 17:14:08 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Mon, 01 Dec 2008 18:14:08 -0500 Subject: an over-the-top data center In-Reply-To: <2008120114230243patrick@ianai.net> References: <2008120114230243patrick@ianai.net> Message-ID: <49346FC0.4090102@vaxination.ca> patrick at ianai.net wrote: > The Internet can be mission critical. (Well, not really, but it's =20 > trying.) And for something mission critical, a single point, no =20 > matter how well reinforced, is not good enough. It may not be "mission critical" for any one particular client, but when you bundle all of the separate non critical applications on the net, the impact of downtime on the population becomes important enough to be seen as "critical". Think about airlines expecting passengers to check-in via the internet more and more so that they can reduce staff at airports. > The exchange point should _NOT_ be mission critical. As I explained =20 > multiple times in the thread, if that is your only vector, your design =20= > is broken. Period. Care to argue otherwise? Fair enough. However, in a particular city, you may have difficulty finding multiple different transit providers whose fiber trunks are truly differently routed. It is bad enough that different transit providers may share the same dark fibre cable out of the city. Very large cities such as New York may make it much easier to find truly independant transit links. But for small, medium cities, it becomes harder (especially if geography limits the number of truly separate links). In the end, to form a truly redundant service, you probably need to have a presence in multiple cities, each with its own carrier hotel. And at that point, each carrier hotel need not be "mission critical" because you can continue service from another city. But even if you have backup, you still want the carrier hotels to be robust. And if you can't afford to have data centres/networks in different cities, you do want to have a robust interconnect to the internet. Consider the number of small/medium size ISPs whose infrastructrure is located at the carrier hotel where the local exchange resides. To them, the availability of services at that carrier hotel is mission critical because their bueiness depends on it, and they can't afford to be in multiple locations. From deepak at ai.net Mon Dec 1 17:19:14 2008 From: deepak at ai.net (Deepak Jain) Date: Mon, 1 Dec 2008 18:19:14 -0500 Subject: an over-the-top data center In-Reply-To: <20081128083433.0e18c7e2@cs.columbia.edu> References: <20081128083433.0e18c7e2@cs.columbia.edu> Message-ID: Apologies to the list. I didn't know whether to fork this into a couple of replies, or just run with it. I chose the latter. 1) This datacenter is only 12,000 sq ft. (submessage: who cares?) 2) The generators are underground. A leak in their exhaust system kills everyone -- worse, a leak in their fuel tank or filler lines (when being filled from above) could do the same. Yes, you could address this with alarms (provided they work and are tested, etc). 3) No one cares if the server farm is blast proof (it isn't), if the connectivity in/out of it gets blasted (submessage: silos were meant to deliver one thing, datacenters aren't in the same operational model once they need connectivity to the outside world) 4) With all of that fog and plant life, I wonder how they critically manage humidity. [Or if they even do]. ---- To the question of carrier hotels and their supposed secrecy, etc. If you need connectivity to multiple providers, those providers know where the buildings are, and presumably so do most of their employees. If 500,000 people (say the top 10 companies together) know where the building is, it's not a secret. ** Carrier hotels aren't meant to be more secure than the lines coming into them. Those lines are coming in on unsecured poles, manholes and the rest. Their most dramatic failure modes are pretty obvious if not well-studied. Internet "security" [as in resilience] is built on the concept of a point-of-view of connectivity with multiple failures and routing around them -- NOT sacred nodes that cannot fail or universal end-to-end reachability. Internet "security" [as in integrity] is not something that's been proven on the Internet yet [general case, please no banter about encryption/quantum oscillation, etc]. Lots of people have already said this is dull -- it is, it is also a nice set of pictures. ** Submitted without proof. This covers all the buildings that make claims about not having their name on the door and have loading docks with no security on them. (you know who you are). Deepak From nanog-post at rsuc.gweep.net Mon Dec 1 17:36:27 2008 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Mon, 1 Dec 2008 18:36:27 -0500 Subject: an over-the-top data center In-Reply-To: References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <49305CFB.9070703@vaxination.ca> <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> <20081201035010.GH78345@burnout.tpb.net> <84E9903D44E8EB2D4B96964B@rasmus.kthnoc.net> <37F77B99-B3D9-421D-AA04-DAEBCF94F9BC@ianai.net> Message-ID: <20081201233626.GA78139@gweep.net> On Mon, Dec 01, 2008 at 08:14:20PM +0100, Kurt Erik Lindqvist wrote: [snip] > On 1 dec 2008, at 15.08, Patrick W. Gilmore wrote: [snip] > >I don't think any IXP can become a significant player on the > >Internet today by only attracting participants from the country in > >question. The Internet is not bound by political borders. > >(Usually. :) Despite the huge amount of "content which transcends the language barrier" [tip of the hat wbn], it is worth noting that there is a non-trivial amount of language-/culture-specific traffic that doesn't need or want to traverse globally (viz massive IXes & large xTTH deplyoments in otherwise 'small' countries). Sometimes that maps near to the political boundaries. Joe [by all means, do not take this as a SPoF endorsement] -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From randy at psg.com Mon Dec 1 17:47:08 2008 From: randy at psg.com (Randy Bush) Date: Tue, 02 Dec 2008 08:47:08 +0900 Subject: an over-the-top data center In-Reply-To: <20081201233626.GA78139@gweep.net> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <49305CFB.9070703@vaxination.ca> <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> <20081201035010.GH78345@burnout.tpb.net> <84E9903D44E8EB2D4B96964B@rasmus.kthnoc.net> <37F77B99-B3D9-421D-AA04-DAEBCF94F9BC@ianai.net> <20081201233626.GA78139@gweep.net> Message-ID: <4934777C.2040706@psg.com> > Despite the huge amount of "content which transcends the language > barrier" [tip of the hat wbn], it is worth noting that there is > a non-trivial amount of language-/culture-specific traffic that > doesn't need or want to traverse globally (viz massive IXes & large > xTTH deplyoments in otherwise 'small' countries). Sometimes that > maps near to the political boundaries. slide 6 of course, these data are a bit long in the tooth randy From dr at kyx.net Mon Dec 1 18:23:50 2008 From: dr at kyx.net (Dragos Ruiu) Date: Mon, 1 Dec 2008 16:23:50 -0800 Subject: an over-the-top data center In-Reply-To: References: <20081128083433.0e18c7e2@cs.columbia.edu> <1944.76.118.12.107.1227929030.squirrel@webmail6.pair.com> Message-ID: On 28-Nov-08, at 7:35 PM, Gadi Evron wrote: > On Fri, 28 Nov 2008, Howard C. Berkowitz wrote: >>> >> It seems that all these cases are more under the bottom than over >> the top. >> > > Every couple of years there is a story about some anti virus > company, data center, or whatever running out of an old nuclear > bunker/military base/middle of no where. It is exciting the first > few times. Hey I'll defend the interest in this one. They at least have cool architecture. And to all the folks debating the form of security, let me also remind that massive redundancy always provides even more security than one very, very, hard point. cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques Vancouver, Canada March 16-20 2009 http://cansecwest.com London, U.K. May 27/28 2009 http://eusecwest.com pgpkey http://dragos.com/ kyxpgp From yamasaki at nic.ad.jp Mon Dec 1 19:31:43 2008 From: yamasaki at nic.ad.jp (Shin Yamasaki) Date: Tue, 02 Dec 2008 10:31:43 +0900 Subject: RADB service outage Message-ID: <49348FFF.3070703@nic.ad.jp> Hi, It seems Merit's RADB service is not working. Both Web and command-line accesses aren't available. On the Web, it only returns the following string: "Number of objects found: 1" On the command-line, nothing is returned. Not only us but also other folks here in Japan are affected. If someone from Merit sees this, please take a look at the system and take appropriate action. Thank you in advance, -- Shin Yamasaki Japan Network Information Center (JPNIC) From swmike at swm.pp.se Tue Dec 2 00:49:04 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 2 Dec 2008 07:49:04 +0100 (CET) Subject: an over-the-top data center In-Reply-To: References: <20081128083433.0e18c7e2@cs.columbia.edu> Message-ID: On Mon, 1 Dec 2008, Deepak Jain wrote: > 3) No one cares if the server farm is blast proof (it isn't), if the > connectivity in/out of it gets blasted (submessage: silos were meant to > deliver one thing, datacenters aren't in the same operational model once > they need connectivity to the outside world) It's much easier to restore fiber connectivity in a time of crisis than it is to source hardware manufacturered at the other end of the world and have this set up properly. I do think there is value in keeping the hw safer than the connectivity to the outside. I bet the military or emergency services can establish a 10km fiber stretch in a few hours. Replacing some telecom hw and set it up from scratch would probably take weeks (I'm not talking about a single router here). -- Mikael Abrahamsson email: swmike at swm.pp.se From mansaxel at besserwisser.org Tue Dec 2 03:33:30 2008 From: mansaxel at besserwisser.org (=?UTF-8?Q?M=C3=A5ns_Nilsson?=) Date: Tue, 02 Dec 2008 10:33:30 +0100 Subject: an over-the-top data center In-Reply-To: References: <20081128083433.0e18c7e2@cs.columbia.edu> Message-ID: <5592ADF0540BB6CA88FDADF3@rasmus.kthnoc.net> --On m?ndag, m?ndag 1 dec 2008 18.19.14 -0500 Deepak Jain wrote: > 1) This datacenter is only 12,000 sq ft. (submessage: who cares?) For some things, it is OK. It is not the only one, only the best marketed one. > 2) The generators are underground. A leak in their exhaust system kills > everyone -- worse, a leak in their fuel tank or filler lines (when being > filled from above) could do the same. Yes, you could address this with > alarms (provided they work and are tested, etc). The original design and purpose required internal gensets. Keeping them inside is still important for a number of reasons. This is the Baltic, not San Diego. Rain, fog, snow, etc. Both intake and exhaust are normally coupled to the outside via boulder-blocked blasted tunnels, so the gas path is not connected to the inside. > 3) No one cares if the server farm is blast proof (it isn't), if the > connectivity in/out of it gets blasted (submessage: silos were meant to > deliver one thing, datacenters aren't in the same operational model once > they need connectivity to the outside world) See what Mikael wrote. > 4) With all of that fog and plant life, I wonder how they critically > manage humidity. [Or if they even do]. I have been told by people who have been working with the construction of this very site that it is an unusually dry cave. It is pretty high up by Stockholm standards, which helps. -- M?ns Nilsson M A C H I N A if it GLISTENS, gobble it!! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From paul at blacknight.com Tue Dec 2 04:25:01 2008 From: paul at blacknight.com (Paul Kelly :: Blacknight) Date: Tue, 2 Dec 2008 10:25:01 +0000 Subject: Yahoo! Mail admin? Message-ID: Hi There, Any yahoo! Mail server admins on list? Can you ping me? Paul Paul Kelly Technical Director Blacknight Internet Solutions ltd Hosting, Colocation, Dedicated servers IP Transit Services Tel: +353 (0) 59 9183072 Lo-call: 1850 929 929 DDI: +353 (0) 59 9183091 e-mail: paul at blacknight.ie web: http://www.blacknight.ie Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park, Sleaty Road, Graiguecullen, Carlow, Ireland Company No.: 370845 From paul.cosgrove at heanet.ie Tue Dec 2 05:18:56 2008 From: paul.cosgrove at heanet.ie (Paul Cosgrove) Date: Tue, 02 Dec 2008 11:18:56 +0000 Subject: an over-the-top data center In-Reply-To: References: <20081128083433.0e18c7e2@cs.columbia.edu> Message-ID: <493519A0.5090702@heanet.ie> Mikael Abrahamsson wrote: > On Mon, 1 Dec 2008, Deepak Jain wrote: > >> 3) No one cares if the server farm is blast proof (it isn't), if the >> connectivity in/out of it gets blasted (submessage: silos were meant >> to deliver one thing, datacenters aren't in the same operational >> model once they need connectivity to the outside world) > > It's much easier to restore fiber connectivity in a time of crisis > than it is to source hardware manufacturered at the other end of the > world and have this set up properly. I do think there is value in > keeping the hw safer than the connectivity to the outside. > > I bet the military or emergency services can establish a 10km fiber > stretch in a few hours. Replacing some telecom hw and set it up from > scratch would probably take weeks (I'm not talking about a single > router here). > Hi Mikael, The speed with which fibre can be pulled will very much depend on the available paths and other resources. It may be that the previous path of the damaged fibre may now be blocked or otherwise unavailable such that construction work is required. As you say it is likely to be more difficult to recover from a problem at a datacentre due to the greater potential for damage and diversity of resources required. The point has already been made that not all customers may be able to avail of site resilience due to the associated cost, and so may be reliant on the one datacentre. In addition one thing which I do not think has been mentioned is that damage to a building may make the site unsafe and possibly injure staff; perhaps causing planning, coordination and implementation of site recovery to be considerably more complicated than simply replacing equipment. Most customers would not be willing to pay extra to get hardened datacentres, so despite the complexities of recovery Deepak is largely right when he said that no one cares about blast proof server farms, at least in the peaceful parts of the world. Paul. From nanog at ian.co.uk Tue Dec 2 06:15:39 2008 From: nanog at ian.co.uk (Ian Mason) Date: Tue, 2 Dec 2008 12:15:39 +0000 Subject: an over-the-top data center In-Reply-To: <08A31BEE-F5A7-4B31-9A09-1E9F2A8E1B3A@orthanc.ca> References: <20081128083433.0e18c7e2@cs.columbia.edu> <7A8D1E7B-78E9-4629-A0F6-72BFFE7B019C@tcb.net> <08A31BEE-F5A7-4B31-9A09-1E9F2A8E1B3A@orthanc.ca> Message-ID: <72576A4D-DB9E-481B-85BE-9BB3BBF50784@ian.co.uk> On 1 Dec 2008, at 19:19, Lyndon Nerenberg wrote: > > An alternative would be to run a microwave link to shore, but I'm > not sure I would want to bet the farm on the mechanics necessary to > keep the dish aligned. > Actually this is pretty straightforward. Systems exist for getting rock steady film from moving helicopters and I'm sure that a system that can keep a camera aimed at a point can do the same for a microwave dish. Ian From jerj at coplanar.net Tue Dec 2 10:19:36 2008 From: jerj at coplanar.net (Jeremy Jackson) Date: Tue, 02 Dec 2008 11:19:36 -0500 Subject: an over-the-top data center In-Reply-To: <5592ADF0540BB6CA88FDADF3@rasmus.kthnoc.net> References: <20081128083433.0e18c7e2@cs.columbia.edu> <5592ADF0540BB6CA88FDADF3@rasmus.kthnoc.net> Message-ID: <1228234776.782.227.camel@ragnarok> On Tue, 2008-12-02 at 10:33 +0100, M?ns Nilsson wrote: > > 4) With all of that fog and plant life, I wonder how they critically > > manage humidity. [Or if they even do]. > > I have been told by people who have been working with the construction of > this very site that it is an unusually dry cave. It is pretty high up by > Stockholm standards, which helps. > Seems like dry-ice was used to make the "tropical fog" in the photos, not water poured over hot rocks like a sauna/bath house. -- Jeremy Jackson Coplanar Networks (519)489-4903 http://www.coplanar.net jerj at coplanar.net From dgolding at t1r.com Tue Dec 2 10:50:23 2008 From: dgolding at t1r.com (Daniel Golding) Date: Tue, 2 Dec 2008 11:50:23 -0500 Subject: an over-the-top data center In-Reply-To: <49305CFB.9070703@vaxination.ca> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <49305CFB.9070703@vaxination.ca> Message-ID: <3B980743-C1EA-4387-B1C9-EEE84252D7A8@t1r.com> On Nov 28, 2008, at 4:04 PM, Jean-Fran?ois Mezei wrote: > M?ns Nilsson wrote: > >> Exactly where is of course known in the business, but not so well >> that it >> is OK to post their locations on Nanog. > > The problem with this mentality is that it does not deter those > wishing > to do harm to the data centre or corporation. > There are in fact, numerous public information sources and commercial databases that list every major and minor colocation and datacenter in the world. Please do not assume that folks don't know where you are peering - they have street addresses, postal codes, satellite photos, and the name of the guard at the door. - Daniel Golding From dgolding at t1r.com Tue Dec 2 10:54:24 2008 From: dgolding at t1r.com (Daniel Golding) Date: Tue, 2 Dec 2008 11:54:24 -0500 Subject: an over-the-top data center In-Reply-To: <20081128083433.0e18c7e2@cs.columbia.edu> References: <20081128083433.0e18c7e2@cs.columbia.edu> Message-ID: <660149DD-0670-4D02-953A-16F4D2BA9539@t1r.com> On Nov 28, 2008, at 8:34 AM, Steven M. Bellovin wrote: > http://royal.pingdom.com/2008/11/14/the-worlds-most-super-designed-data-center-fit-for-a-james-bond-villain/ > (No, I don't know if it's real or not.) > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > It has become de rigeur in some parts of the colocation and wholesale datacenter space to have a media puff-piece done on your new datacenter. Typically, that puff-piece is full of hyperbole and contains lots of power and efficiency numbers that don't add up. The tech media is a willing participant and, while they don't know any better, they don't make the effort to pick up the phone and ask someone who might know a bit more than they do. The classier datacenter providers generally don't do this stuff. For one thing, its an absolute waste of time - it generates a lot of worthless and time wasting leads for your sales force. Daniel Golding From kurtis at kurtis.pp.se Tue Dec 2 11:44:55 2008 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 2 Dec 2008 18:44:55 +0100 Subject: an over-the-top data center In-Reply-To: <4934777C.2040706@psg.com> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <49305CFB.9070703@vaxination.ca> <7BC8AF1F-F91E-44C8-808F-D8DC14C30898@ianai.net> <20081201035010.GH78345@burnout.tpb.net> <84E9903D44E8EB2D4B96964B@rasmus.kthnoc.net> <37F77B99-B3D9-421D-AA04-DAEBCF94F9BC@ianai.net> <20081201233626.GA78139@gweep.net> <4934777C.2040706@psg.com> Message-ID: <5A16CF08-FFDA-451D-9DED-80191108B813@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2 dec 2008, at 00.47, Randy Bush wrote: >> Despite the huge amount of "content which transcends the language >> barrier" [tip of the hat wbn], it is worth noting that there is >> a non-trivial amount of language-/culture-specific traffic that >> doesn't need or want to traverse globally (viz massive IXes & large >> xTTH deplyoments in otherwise 'small' countries). Sometimes that >> maps near to the political boundaries. > > slide 6 > > of course, these data are a bit long in the tooth I most say I agree with Randy, already in 2001 I had a presentation (that Randy and those of you at RIPE in Dubai saw a copy of in EIX-WG) based on data from the KPNQwest network - where we saw that data had shifted from 80% US based to 80% national or regional. This was a clear change in traffic patterns all across Europe, at least from the data that I saw then. And keep in mind that this was before p2p skewed the data of user behavior. I have been arguing for the theory that 1. Dense exchange of traffic in Europe early on came as a result of a) Dereguation in the telco market b) Unwillingess to pay the "big US telcos" for exchange of local/ european traffic 2. The dense exchange of traffic made local services more viable and attractive 3. (2) Helped local(-language) services develop 4. (3) Helped the development of broadband adoption I do realize that the above is a huge simplification (And the slide set is much longer, and the paper will be even longer), but there are still lessons to be learnt in how the local language services and dense peering developed in Europe. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkk1dBcACgkQAFdZ6xrc/t66+wCdFttkZsBxN7UuHlIS8x3jWFE1 3E8An2mfO++tc2BjO918KDf7yq0XVMJo =D078 -----END PGP SIGNATURE----- From ccariffe at gmail.com Tue Dec 2 12:06:54 2008 From: ccariffe at gmail.com (Chris Cariffe) Date: Tue, 2 Dec 2008 10:06:54 -0800 Subject: qwest/cogent/sprint Message-ID: anyone else feeling this? http://www.internethealthreport.com/Main.aspx?Destination=Sprint From anarcat at anarcat.ath.cx Tue Dec 2 12:26:51 2008 From: anarcat at anarcat.ath.cx (The Anarcat) Date: Tue, 2 Dec 2008 13:26:51 -0500 Subject: an over-the-top data center In-Reply-To: <1228234776.782.227.camel@ragnarok> References: <20081128083433.0e18c7e2@cs.columbia.edu> <5592ADF0540BB6CA88FDADF3@rasmus.kthnoc.net> <1228234776.782.227.camel@ragnarok> Message-ID: <20081202182651.GC6687@mumia.anarcat.ath.cx> On Tue, Dec 02, 2008 at 11:19:36AM -0500, Jeremy Jackson wrote: > Seems like dry-ice was used to make the "tropical fog" in the photos, > not water poured over hot rocks like a sauna/bath house. I've tried to avoid stating the obvious reading through all this funny thread, but I can't help it now. Am I the only one thinking that shady lights, tropical fog, creepy tunnels, blue/colored lights, and *waterfalls* are *bad* things in a datacenter? I mean, it make a good movie set, but seriously... I wouldn't want to be looking for that damn blue "locator" LED on that 10th switch with a blue neon light... A. -- In god we trust, others pay cash. - Richard Desjardins, Miami -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From jay at west.net Tue Dec 2 12:39:11 2008 From: jay at west.net (Jay Hennigan) Date: Tue, 02 Dec 2008 10:39:11 -0800 Subject: an over-the-top data center In-Reply-To: <20081202182651.GC6687@mumia.anarcat.ath.cx> References: <20081128083433.0e18c7e2@cs.columbia.edu> <5592ADF0540BB6CA88FDADF3@rasmus.kthnoc.net> <1228234776.782.227.camel@ragnarok> <20081202182651.GC6687@mumia.anarcat.ath.cx> Message-ID: <493580CF.6050805@west.net> The Anarcat wrote: > On Tue, Dec 02, 2008 at 11:19:36AM -0500, Jeremy Jackson wrote: >> Seems like dry-ice was used to make the "tropical fog" in the photos, >> not water poured over hot rocks like a sauna/bath house. > > I've tried to avoid stating the obvious reading through all this funny > thread, but I can't help it now. > > Am I the only one thinking that shady lights, tropical fog, creepy > tunnels, blue/colored lights, and *waterfalls* are *bad* things in a > datacenter? > > I mean, it make a good movie set, but seriously... I wouldn't want to be > looking for that damn blue "locator" LED on that 10th switch with a blue > neon light... Not to mention dry ice = carbon dioxide which isn't particularly healthy for the humans in that enclosed space. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From ccariffe at gmail.com Tue Dec 2 12:45:44 2008 From: ccariffe at gmail.com (Chris Cariffe) Date: Tue, 2 Dec 2008 10:45:44 -0800 Subject: qwest/cogent/sprint In-Reply-To: References: Message-ID: Cogent claims route corruption on a router...it would be nice to see their network status messages keeping in sync with their network. On Tue, Dec 2, 2008 at 10:06 AM, Chris Cariffe wrote: > anyone else feeling this? > http://www.internethealthreport.com/Main.aspx?Destination=Sprint > From braaen at zcorum.com Tue Dec 2 13:25:40 2008 From: braaen at zcorum.com (Brian Raaen) Date: Tue, 2 Dec 2008 14:25:40 -0500 Subject: an over-the-top data center In-Reply-To: <493580CF.6050805@west.net> References: <20081128083433.0e18c7e2@cs.columbia.edu> <20081202182651.GC6687@mumia.anarcat.ath.cx> <493580CF.6050805@west.net> Message-ID: <200812021425.41296.braaen@zcorum.com> Maybe it isn't dry ice.... Maybe it is from liquid oxygen, in which case it better be a smoke free workplace. ---------------------- Brian Raaen Network Engineer braaen at zcorum.com On Tuesday 02 December 2008, Jay Hennigan wrote: > The Anarcat wrote: > > On Tue, Dec 02, 2008 at 11:19:36AM -0500, Jeremy Jackson wrote: > >> Seems like dry-ice was used to make the "tropical fog" in the photos, > >> not water poured over hot rocks like a sauna/bath house. > > > > I've tried to avoid stating the obvious reading through all this funny > > thread, but I can't help it now. > > > > Am I the only one thinking that shady lights, tropical fog, creepy > > tunnels, blue/colored lights, and *waterfalls* are *bad* things in a > > datacenter? > > > > I mean, it make a good movie set, but seriously... I wouldn't want to be > > looking for that damn blue "locator" LED on that 10th switch with a blue > > neon light... > > Not to mention dry ice = carbon dioxide which isn't particularly healthy > for the humans in that enclosed space. > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > > From tme at multicasttech.com Tue Dec 2 14:15:11 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 2 Dec 2008 15:15:11 -0500 Subject: an over-the-top data center In-Reply-To: <200812021425.41296.braaen@zcorum.com> References: <20081128083433.0e18c7e2@cs.columbia.edu> <20081202182651.GC6687@mumia.anarcat.ath.cx> <493580CF.6050805@west.net> <200812021425.41296.braaen@zcorum.com> Message-ID: On Dec 2, 2008, at 2:25 PM, Brian Raaen wrote: > Maybe it isn't dry ice.... Maybe it is from liquid oxygen, in which > case it > better be a smoke free workplace. > This is of course off-off-topic, but I would suspect the room temperature ultrasonic misters, not dry ice or wood smoke. Regards Marshall > > ---------------------- > > Brian Raaen > Network Engineer > braaen at zcorum.com > > > > On Tuesday 02 December 2008, Jay Hennigan wrote: >> The Anarcat wrote: >>> On Tue, Dec 02, 2008 at 11:19:36AM -0500, Jeremy Jackson wrote: >>>> Seems like dry-ice was used to make the "tropical fog" in the >>>> photos, >>>> not water poured over hot rocks like a sauna/bath house. >>> >>> I've tried to avoid stating the obvious reading through all this >>> funny >>> thread, but I can't help it now. >>> >>> Am I the only one thinking that shady lights, tropical fog, creepy >>> tunnels, blue/colored lights, and *waterfalls* are *bad* things in a >>> datacenter? >>> >>> I mean, it make a good movie set, but seriously... I wouldn't want >>> to be >>> looking for that damn blue "locator" LED on that 10th switch with >>> a blue >>> neon light... >> >> Not to mention dry ice = carbon dioxide which isn't particularly >> healthy >> for the humans in that enclosed space. >> >> -- >> Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net >> Impulse Internet Service - http://www.impulse.net/ >> Your local telephone and internet company - 805 884-6323 - WB6RDV >> >> > > > From jeffshultz at wvi.com Tue Dec 2 14:27:40 2008 From: jeffshultz at wvi.com (Jeff Shultz) Date: Tue, 02 Dec 2008 12:27:40 -0800 Subject: an over-the-top data center In-Reply-To: References: <20081128083433.0e18c7e2@cs.columbia.edu> <20081202182651.GC6687@mumia.anarcat.ath.cx> <493580CF.6050805@west.net> <200812021425.41296.braaen@zcorum.com> Message-ID: <49359A3C.20509@wvi.com> Marshall Eubanks wrote: > > > On Dec 2, 2008, at 2:25 PM, Brian Raaen wrote: > >> Maybe it isn't dry ice.... Maybe it is from liquid oxygen, in which >> case it >> better be a smoke free workplace. >> > > This is of course off-off-topic, but I would suspect the room > temperature ultrasonic > misters, not dry ice or wood smoke. > I'd be more worried about the artificial waterfalls... the sound of flowing water has an established physiological effect..... Um... where's the bathroom? -- Jeff Shultz From gherbert at retro.com Tue Dec 2 14:20:19 2008 From: gherbert at retro.com (George William Herbert) Date: Tue, 02 Dec 2008 12:20:19 -0800 Subject: an over-the-top data center In-Reply-To: References: <20081128083433.0e18c7e2@cs.columbia.edu> <20081202182651.GC6687@mumia.anarcat.ath.cx> <493580CF.6050805@west.net> <200812021425.41296.braaen@zcorum.com> Message-ID: <200812022020.mB2KKJ7B003690@kw.retro.com> Marshall wrote: >This is of course off-off-topic, but I would suspect the room >temperature ultrasonic >misters, not dry ice or wood smoke. > >Regards >Marshall Concur. As anyone who works with air conditioning knows, ultrasonic are the low maintenance option for your humidifier units anyways. A lot of your datacenters have those 8-) There are also doors between the plants and NOC and the server rooms ... Having them external to the AC and pumping visible fog out into the room instead of invisible into the air feeds is unusual, but if the resulting humidity (in the NOC, not the server rooms) is normal it's no big deal. You can have the floor covered in an inch of water and the air be perfectly safe humidity for systems (just don't drop a live power cable in the water...). I wouldn't do this personally, but if done right it should be safe. -george william herbert gherbert at retro.com From bpfankuch at cpgreeley.com Tue Dec 2 14:44:36 2008 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Tue, 2 Dec 2008 13:44:36 -0700 Subject: an over-the-top data center In-Reply-To: <49359A3C.20509@wvi.com> References: <20081128083433.0e18c7e2@cs.columbia.edu> <20081202182651.GC6687@mumia.anarcat.ath.cx> <493580CF.6050805@west.net> <200812021425.41296.braaen@zcorum.com> <49359A3C.20509@wvi.com> Message-ID: <01759D50DC387C45A018FE1817CE27D7540379FA4C@CPExchange1.cpgreeley.com> I would agree with the psychological effects. That would be a downside to working in a place that aside from that is so unbelievably kickass. -----Original Message----- From: Jeff Shultz [mailto:jeffshultz at wvi.com] Sent: Tuesday, December 02, 2008 1:28 PM To: NANOG list Subject: Re: an over-the-top data center Marshall Eubanks wrote: > > > On Dec 2, 2008, at 2:25 PM, Brian Raaen wrote: > >> Maybe it isn't dry ice.... Maybe it is from liquid oxygen, in which >> case it >> better be a smoke free workplace. >> > > This is of course off-off-topic, but I would suspect the room > temperature ultrasonic > misters, not dry ice or wood smoke. > I'd be more worried about the artificial waterfalls... the sound of flowing water has an established physiological effect..... Um... where's the bathroom? -- Jeff Shultz From bygg at cafax.se Tue Dec 2 21:50:17 2008 From: bygg at cafax.se (Johnny Eriksson) Date: Tue, 2 Dec 2008 21:50:17 WET Subject: an over-the-top data center In-Reply-To: Your message of Tue, 02 Dec 2008 12:20:19 -0800 Message-ID: > Marshall wrote: > >This is of course off-off-topic, but I would suspect the room > >temperature ultrasonic > >misters, not dry ice or wood smoke. > > > >Regards > >Marshall > > Concur. > > As anyone who works with air conditioning knows, ultrasonic are > the low maintenance option for your humidifier units anyways. > A lot of your datacenters have those 8-) > > There are also doors between the plants and NOC and the server > rooms ... > > Having them external to the AC and pumping visible fog out into > the room instead of invisible into the air feeds is unusual, but > if the resulting humidity (in the NOC, not the server rooms) > is normal it's no big deal. You can have the floor covered in > an inch of water and the air be perfectly safe humidity for > systems (just don't drop a live power cable in the water...). > > I wouldn't do this personally, but if done right it should be safe. This discussion about plants, waterfalls and humidity is getting more and more off-tropic... > -george william herbert > gherbert at retro.com --Johnny From gherbert at retro.com Tue Dec 2 14:44:09 2008 From: gherbert at retro.com (George William Herbert) Date: Tue, 02 Dec 2008 12:44:09 -0800 Subject: an over-the-top data center In-Reply-To: References: Message-ID: <200812022044.mB2KiAcH004040@kw.retro.com> Johnny writes: >This discussion about plants, waterfalls and humidity is getting more >and more off-tropic... Humidity is not off topic for a general or specific datacenter conversation - it's a fairly routine issue in facilities. NANOG isn't facilities focused but I think that it comes up enough (we're not hosting routers in closets anymore) that it's legit for some discussion. The plants and waterfalls is probably drifting a bit far afield, though... -george william herbert gherbert at retro.com From ljb at merit.edu Tue Dec 2 14:57:15 2008 From: ljb at merit.edu (Larry Blunk) Date: Tue, 02 Dec 2008 15:57:15 -0500 Subject: RADB service outage In-Reply-To: <49348FFF.3070703@nic.ad.jp> References: <49348FFF.3070703@nic.ad.jp> Message-ID: <4935A12B.2080806@merit.edu> Apologies for the RADB downtime. Service was down from roughly 7:45PM - 8:51PM EST last night. We've been having some issues due to heavy querying from a PlanetLab project and are currently working with them to resolve the issue. -Larry Blunk Merit Network Shin Yamasaki wrote: > Hi, > > It seems Merit's RADB service is not working. > > Both Web and command-line accesses aren't available. On the Web, it > only returns the following string: "Number of objects found: 1" On the > command-line, nothing is returned. > > Not only us but also other folks here in Japan are affected. > > If someone from Merit sees this, please take a look at the system and > take appropriate action. > > Thank you in advance, > > From jgoltz at mail.nih.gov Tue Dec 2 15:08:42 2008 From: jgoltz at mail.nih.gov (Goltz, Jim (NIH/CIT) [E]) Date: Tue, 2 Dec 2008 16:08:42 -0500 Subject: an over-the-top data center In-Reply-To: References: <20081128083433.0e18c7e2@cs.columbia.edu> <20081202182651.GC6687@mumia.anarcat.ath.cx> <493580CF.6050805@west.net> <200812021425.41296.braaen@zcorum.com> Message-ID: > From: Marshall Eubanks [mailto:tme at multicasttech.com] > Sent: Tuesday, December 02, 2008 15:15 > > This is of course off-off-topic, but I would suspect the room > temperature ultrasonic > misters, not dry ice or wood smoke. Still off-topic, but I hope they used distilled water. If the water has a medium to high mineral content ("hard" water), the miniscule droplets produced by ultrasonic misters evaporate quickly into microscopic dust motes, small enough to evade most filtering systems. (This data center actually reminds me of the old Kon-Tiki movie theater in Dayton, OH.) -- Jim Goltz CIT/DCSS/HSB/ASIG 12/2216 DCSS Firewall group on-call: 240-338-2103 From charles at thewybles.com Tue Dec 2 15:11:51 2008 From: charles at thewybles.com (Charles Wyble) Date: Tue, 02 Dec 2008 13:11:51 -0800 Subject: an over-the-top data center In-Reply-To: <200812022044.mB2KiAcH004040@kw.retro.com> References: <200812022044.mB2KiAcH004040@kw.retro.com> Message-ID: <4935A497.2020203@thewybles.com> George William Herbert wrote: > Johnny writes: > >> This discussion about plants, waterfalls and humidity is getting more >> and more off-tropic... >> > > Humidity is not off topic for a general or specific datacenter > conversation - it's a fairly routine issue in facilities. > *woosh* tropic... not topic. It's a joke. :) From hcb at netcases.net Tue Dec 2 15:12:59 2008 From: hcb at netcases.net (Howard C. Berkowitz) Date: Tue, 2 Dec 2008 16:12:59 -0500 (EST) Subject: an over-the-top data center In-Reply-To: <200812022044.mB2KiAcH004040@kw.retro.com> References: <200812022044.mB2KiAcH004040@kw.retro.com> Message-ID: <3209.76.118.12.107.1228252379.squirrel@webmail6.pair.com> George William Herbert wrote: > > Johnny writes: >>This discussion about plants, waterfalls and humidity is getting more >>and more off-tropic... > > Humidity is not off topic for a general or specific datacenter > conversation - it's a fairly routine issue in facilities. > > NANOG isn't facilities focused but I think that it comes up > enough (we're not hosting routers in closets anymore) that it's > legit for some discussion. > > The plants and waterfalls is probably drifting a bit far afield, > though... > Perhaps not as far as one might think. I once had to work with a large data center, which was having a huge condensation and eventual corrosion problem on one side of the room. No one had made the connection that it was a shared wall with the main building atrium, which had an indoor waterfall that made quite an evaporative cooler. Extra wall insulation solved the problem. From gherbert at retro.com Tue Dec 2 15:06:47 2008 From: gherbert at retro.com (George William Herbert) Date: Tue, 02 Dec 2008 13:06:47 -0800 Subject: an over-the-top data center In-Reply-To: <4935A497.2020203@thewybles.com> References: <200812022044.mB2KiAcH004040@kw.retro.com> <4935A497.2020203@thewybles.com> Message-ID: <200812022106.mB2L6lTt004350@kw.retro.com> >>> This discussion about plants, waterfalls and humidity is getting more >>> and more off-tropic... >> >> Humidity is not off topic for a general or specific datacenter >> conversation - it's a fairly routine issue in facilities. > >*woosh* > >tropic... not topic. It's a joke. :) D'oh. Serves me right for trying to reply on NANOG while composing and sending a politically sensitive nastygram to (vendor redacted) service and escalation. -george From chucklist at forest.net Tue Dec 2 15:21:39 2008 From: chucklist at forest.net (chuck goolsbee) Date: Tue, 2 Dec 2008 13:21:39 -0800 Subject: an over-the-top data center In-Reply-To: <49359A3C.20509@wvi.com> References: <20081128083433.0e18c7e2@cs.columbia.edu> <20081202182651.GC6687@mumia.anarcat.ath.cx> <493580CF.6050805@west.net> <200812021425.41296.braaen@zcorum.com> <49359A3C.20509@wvi.com> Message-ID: <20081202132139662573.d52d4040@forest.net> Speaking as a Datacenter Manager who (believe it or not) at one time was an Art Director, I have to say that the "ambience" in those photographs, in the form of fog, odd/colored lighting, etc. was certainly created at the time of the photo shoot by an Art Director ... with delusions (illusions) of grandeur in mind. I imagine that were any of us to visit the site in question on a normal working day we'd find no such special effects and it would look, other than the granite walls, not too different from any other datacenter, or NOC. _________________________________________ chuck goolsbee - fully RFC 1925 compliant From nick at foobar.org Tue Dec 2 15:49:00 2008 From: nick at foobar.org (Nick Hilliard) Date: Tue, 02 Dec 2008 21:49:00 +0000 Subject: an over-the-top data center In-Reply-To: <20081202132139662573.d52d4040@forest.net> References: <20081128083433.0e18c7e2@cs.columbia.edu> <20081202182651.GC6687@mumia.anarcat.ath.cx> <493580CF.6050805@west.net> <200812021425.41296.braaen@zcorum.com> <49359A3C.20509@wvi.com> <20081202132139662573.d52d4040@forest.net> Message-ID: <4935AD4C.10000@foobar.org> chuck goolsbee wrote: > would look, other than the granite walls On the subject of suitability problems, unless there is good air circulation in these bunkers from the outside, radon seepage from the surrounding granite has the potential to cause a lot of health problems for any unlucky punter who happens to work in there, although it's unlikely that it would have any effect on any equipment housed in the facility. Having said that, radon seems to be a well known problem in Stockholm and I've no doubt that they took measures to deal with it. Nick From deepak at ai.net Tue Dec 2 15:57:56 2008 From: deepak at ai.net (Deepak Jain) Date: Tue, 2 Dec 2008 16:57:56 -0500 Subject: an over-the-top data center In-Reply-To: References: <20081128083433.0e18c7e2@cs.columbia.edu> Message-ID: > I bet the military or emergency services can establish a 10km fiber > stretch in a few hours. Replacing some telecom hw and set it up from > scratch would probably take weeks (I'm not talking about a single > router > here). But we aren't talking about the military here, are we? We are talking about an ISP on an ISP forum. Deepak From charles at thewybles.com Tue Dec 2 16:11:11 2008 From: charles at thewybles.com (Charles Wyble) Date: Tue, 02 Dec 2008 14:11:11 -0800 Subject: an over-the-top data center In-Reply-To: References: <20081128083433.0e18c7e2@cs.columbia.edu> Message-ID: <4935B27F.2030307@thewybles.com> Deepak Jain wrote: >> I bet the military or emergency services can establish a 10km fiber >> stretch in a few hours. Replacing some telecom hw and set it up from >> scratch would probably take weeks (I'm not talking about a single >> router >> here). >> > > But we aren't talking about the military here, are we? We are talking about an ISP on an ISP forum. > Yes.... but in a disaster scenario where critical communication links are down the military would respond and reestablish the links, if for nothing else to re establish situational awareness for themselves. From deepak at ai.net Tue Dec 2 16:18:39 2008 From: deepak at ai.net (Deepak Jain) Date: Tue, 2 Dec 2008 17:18:39 -0500 Subject: an over-the-top data center In-Reply-To: <4935B27F.2030307@thewybles.com> References: <20081128083433.0e18c7e2@cs.columbia.edu> <4935B27F.2030307@thewybles.com> Message-ID: > > But we aren't talking about the military here, are we? We are talking > about an ISP on an ISP forum. > > > > Yes.... but in a disaster scenario where critical communication links > are down the military would respond and reestablish the links, if for > nothing else to re establish situational awareness for themselves. This is getting off-topic in a big way, but I can pretty much assure you that the US military isn't going to be re-establishing ISP circuits for the military's situational awareness. I can't speak of the Swedish military. In most countries with a big-bad-military, the most the military will do is allow the commercial entities to expedite their own repairs and perhaps bypass certain permit requirements -- which is as it should be. If this is the reason to build a bomb proof datacenter, I encourage all my competitors to do so. Someone said it earlier, its far cheaper, and far more reliable to be massively redundant than super hardened in one (or a few) locations. If you think you can't afford the former, but can get the latter, you don't understand what you are solving for. Deepak From jgreco at ns.sol.net Tue Dec 2 16:38:09 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 2 Dec 2008 16:38:09 -0600 (CST) Subject: Followup on Cogent/Sprint Message-ID: <200812022238.mB2Mc9dB098275@aurora.sol.net> While the recent Cogent/Sprint debate was largely fact-free, I'm following this up with an article that has some facts. http://www.forbes.com/technology/2008/12/01/cogent-sprint-regulation-tech-enter-cz_sw_1202cogent.html Given that there is a substantial operational impact to events such as this, I believe that this is relevant enough to post here. I would expect most people would rather see discussion happen elsewhere. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From Valdis.Kletnieks at vt.edu Tue Dec 2 16:47:32 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 02 Dec 2008 17:47:32 -0500 Subject: an over-the-top data center In-Reply-To: Your message of "Tue, 02 Dec 2008 13:26:51 EST." <20081202182651.GC6687@mumia.anarcat.ath.cx> References: <20081128083433.0e18c7e2@cs.columbia.edu> <5592ADF0540BB6CA88FDADF3@rasmus.kthnoc.net> <1228234776.782.227.camel@ragnarok> <20081202182651.GC6687@mumia.anarcat.ath.cx> Message-ID: <62020.1228258052@turing-police.cc.vt.edu> On Tue, 02 Dec 2008 13:26:51 EST, The Anarcat said: > Am I the only one thinking that shady lights, tropical fog, creepy > tunnels, blue/colored lights, and *waterfalls* are *bad* things in a > datacenter? Well, across the hall we have: Photo-op version: http://www.vtnews.vt.edu/story.php?relyear=2006&itemno=621 Production version: http://www.arc.vt.edu/images/upgrade/IMG_2434.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From jerj at coplanar.net Tue Dec 2 17:20:40 2008 From: jerj at coplanar.net (Jeremy Jackson) Date: Tue, 02 Dec 2008 18:20:40 -0500 Subject: an over-the-top data center In-Reply-To: <4935AD4C.10000@foobar.org> References: <20081128083433.0e18c7e2@cs.columbia.edu> <20081202182651.GC6687@mumia.anarcat.ath.cx> <493580CF.6050805@west.net> <200812021425.41296.braaen@zcorum.com> <49359A3C.20509@wvi.com> <20081202132139662573.d52d4040@forest.net> <4935AD4C.10000@foobar.org> Message-ID: <1228260040.782.251.camel@ragnarok> On Tue, 2008-12-02 at 21:49 +0000, Nick Hilliard wrote: > chuck goolsbee wrote: > > would look, other than the granite walls > > On the subject of suitability problems, unless there is good air > circulation in these bunkers from the outside, radon seepage from the > surrounding granite has the potential to cause a lot of health problems for > any unlucky punter who happens to work in there, although it's unlikely > that it would have any effect on any equipment housed in the facility. So control systems in nuclear power plants don't need any extra shielding to prevent "glitches"? From castellan2004-nsm at yahoo.com Tue Dec 2 19:19:50 2008 From: castellan2004-nsm at yahoo.com (Subba Rao) Date: Tue, 2 Dec 2008 17:19:50 -0800 (PST) Subject: Tcpdump data collection Message-ID: <952973.15796.qm@web30804.mail.mud.yahoo.com> Hello, I want to collect data on a network and map the data flow and system/port traffic. There are 2 scenarios of data collection here.? The first is to collect IP traffic only.? In this method I do not want the data portion of the IP packet (need IP address, source/destination ports etc). The second is to collect traffic that will show all the routing protocols (non-IP) used on this network.? Today while collecting the data, I saw several HSRP packets.? I don't know what portion of the packet is sufficient to capture for this purpose. I used the "-s 0" option on tcpdump which captures the whole packet.? That is making the dump file large.? Any help with the filters is appreciated to capture the non-data portion of the packets. Thank you in advance. Subba Rao From nanog at daork.net Tue Dec 2 19:33:13 2008 From: nanog at daork.net (Nathan Ward) Date: Wed, 3 Dec 2008 14:33:13 +1300 Subject: Tcpdump data collection In-Reply-To: <952973.15796.qm@web30804.mail.mud.yahoo.com> References: <952973.15796.qm@web30804.mail.mud.yahoo.com> Message-ID: <8AC1044E-4C96-4749-8F9F-267D140E44C4@daork.net> On 3/12/2008, at 2:19 PM, Subba Rao wrote: > Hello, > > I want to collect data on a network and map the data flow and system/ > port traffic. There are 2 scenarios of data collection here. The > first is to collect IP traffic only. In this method I do not want > the data portion of the IP packet (need IP address, source/ > destination ports etc). > > The second is to collect traffic that will show all the routing > protocols (non-IP) used on this network. Today while collecting the > data, I saw several HSRP packets. I don't know what portion of the > packet is sufficient to capture for this purpose. > > I used the "-s 0" option on tcpdump which captures the whole > packet. That is making the dump file large. Any help with the > filters is appreciated to capture the non-data portion of the packets. > > Thank you in advance. I strongly recommend having a look through this to find out what rules you want (ie. plain English): http://www.networksorcery.com/enp/default1002.htm Then, go about mapping them in to tcpdump/pcap/bpf/whatever filter format, a quick Google suggests this as a good resource: http://www.whitehats.ca/main/members/Malik/malik_tcpdump_filters/malik_tcpdump_filters.html You might also consider using netflow instead of tcpdump, there are lots of tools available for processing netflow data in ways that are useful to network operators. -- Nathan Ward From hhoffman at ip-solutions.net Tue Dec 2 20:32:04 2008 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Tue, 02 Dec 2008 21:32:04 -0500 Subject: Tcpdump data collection In-Reply-To: <952973.15796.qm@web30804.mail.mud.yahoo.com> References: <952973.15796.qm@web30804.mail.mud.yahoo.com> Message-ID: <1228271524.9229.1.camel@sniper> Check out argus http://www.qosient.com/argus/ It can do exactly what you what. Cheers, Harry On Tue, 2008-12-02 at 17:19 -0800, Subba Rao wrote: > Hello, > > I want to collect data on a network and map the data flow and system/port traffic. There are 2 scenarios of data collection here. The first is to collect IP traffic only. In this method I do not want the data portion of the IP packet (need IP address, source/destination ports etc). > > The second is to collect traffic that will show all the routing protocols (non-IP) used on this network. Today while collecting the data, I saw several HSRP packets. I don't know what portion of the packet is sufficient to capture for this purpose. > > I used the "-s 0" option on tcpdump which captures the whole packet. That is making the dump file large. Any help with the filters is appreciated to capture the non-data portion of the packets. > > Thank you in advance. > > Subba Rao From securinate at gmail.com Tue Dec 2 21:08:13 2008 From: securinate at gmail.com (Chris Mills) Date: Tue, 2 Dec 2008 22:08:13 -0500 Subject: Tcpdump data collection In-Reply-To: <952973.15796.qm@web30804.mail.mud.yahoo.com> References: <952973.15796.qm@web30804.mail.mud.yahoo.com> Message-ID: Maybe ntop? http://www.ntop.org/overview.html -Chris On Tue, Dec 2, 2008 at 8:19 PM, Subba Rao wrote: > Hello, > > I want to collect data on a network and map the data flow and system/port > traffic. There are 2 scenarios of data collection here. The first is to > collect IP traffic only. In this method I do not want the data portion of > the IP packet (need IP address, source/destination ports etc). > > The second is to collect traffic that will show all the routing protocols > (non-IP) used on this network. Today while collecting the data, I saw > several HSRP packets. I don't know what portion of the packet is sufficient > to capture for this purpose. > > I used the "-s 0" option on tcpdump which captures the whole packet. That > is making the dump file large. Any help with the filters is appreciated to > capture the non-data portion of the packets. > > Thank you in advance. > > Subba Rao > From kin-wei.lee at hp.com Tue Dec 2 21:47:53 2008 From: kin-wei.lee at hp.com (Lee, Steven (NSG Malaysia)) Date: Wed, 3 Dec 2008 03:47:53 +0000 Subject: Recommendation of Tools Message-ID: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> Hi all, do you have any recommended tools that can measure latency/delay hop by hop basis? Preferable the tools can measure the running (live) traffic. Regards, Steven Lee From andy-nanog at bash.sh Tue Dec 2 22:23:47 2008 From: andy-nanog at bash.sh (Andrew Mulholland) Date: Tue, 2 Dec 2008 23:23:47 -0500 Subject: Recommendation of Tools In-Reply-To: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> References: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> Message-ID: On Tue, Dec 2, 2008 at 10:47 PM, Lee, Steven (NSG Malaysia) < kin-wei.lee at hp.com> wrote: > Hi all, do you have any recommended tools that can measure latency/delay > hop by hop basis? Preferable the tools can measure the running (live) > traffic. > mtr ? - http://www.bitwizard.nl/mtr/ its an ncurses app.. output like to: Host Loss% Snt Last Avg Best Wrst StDev 1. 89.202.212.124 0.0% 7 0.4 0.5 0.4 0.6 0.0 2. xe-7-1-0-0.ams-koo-score-1-re0.i 0.0% 7 0.3 2.9 0.2 18.9 7.0 3. po1.ccr01.ams03.atlas.cogentco.c 0.0% 6 1.3 3.8 1.3 16.0 6.0 4. te2-4.3490.ccr01.ams03.atlas.cog 0.0% 6 1.1 1.1 1.1 1.2 0.0 5. te2-3.mpd02.lon01.atlas.cogentco 0.0% 6 8.0 9.9 7.9 19.6 4.7 6. te9-3.ccr02.jfk02.atlas.cogentco 0.0% 6 91.9 91.9 91.8 91.9 0.0 7. te8-3.ccr01.dca01.atlas.cogentco 0.0% 6 92.0 95.0 91.7 111.2 7.9 8. te9-1.ccr02.dca01.atlas.cogentco 0.0% 6 92.1 92.2 92.1 92.4 0.1 9. vl3896.na32.b001806-1.dca01.atla 0.0% 6 92.3 93.1 92.3 94.1 0.7 10. 38.104.30.102 0.0% 6 92.0 92.0 92.0 92.1 0.1 11. www.joost.com 0.0% 6 92.0 91.9 91.8 92.0 0.1 thanks Andrew > Regards, > Steven Lee > > > From bdfleming at kanren.net Tue Dec 2 22:58:38 2008 From: bdfleming at kanren.net (Brad Fleming) Date: Tue, 2 Dec 2008 22:58:38 -0600 Subject: Recommendation of Tools In-Reply-To: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> References: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> Message-ID: perfSONAR is another, more long term solution for performance monitoring (if that's what you happen to be looking for). http://www.internet2.edu/performance/pS-PS/ -- Brad Fleming Network Engineer Kansas Research and Education Network Office: 785-856-9800 x.222 Moblie: 785-865-7231 NOC: 866-984-3662 On Dec 2, 2008, at 9:47 PM, Lee, Steven (NSG Malaysia) wrote: > Hi all, do you have any recommended tools that can measure latency/ > delay hop by hop basis? Preferable the tools can measure the running > (live) traffic. > > Regards, > Steven Lee > > > From pekkas at netcore.fi Wed Dec 3 00:52:40 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 3 Dec 2008 08:52:40 +0200 (EET) Subject: Recommendation of Tools In-Reply-To: References: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> Message-ID: On Tue, 2 Dec 2008, Andrew Mulholland wrote: > On Tue, Dec 2, 2008 at 10:47 PM, Lee, Steven (NSG Malaysia) < > kin-wei.lee at hp.com> wrote: > >> Hi all, do you have any recommended tools that can measure latency/delay >> hop by hop basis? Preferable the tools can measure the running (live) >> traffic. >> > > mtr ? - http://www.bitwizard.nl/mtr/ FWIW, Mtr measures latency/delay and loss based on ICMP messages heard back from the routers on path. As a result, in almost all cases, the real hop-by-hop latency of actual end-to-end data packets is better than it can report. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From tehno.signup at gmail.com Wed Dec 3 00:54:34 2008 From: tehno.signup at gmail.com (Tehno Mage) Date: Wed, 3 Dec 2008 08:54:34 +0200 Subject: Recommendation of Tools In-Reply-To: References: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> Message-ID: I don't know if it helps, but anyways. There is another tool called Iperf ( http://sourceforge.net/projects/iperf ). It's usually used to report bandwidth between two hops which you define, but it can be also used to measure jitter, datagram loss, and a lot of other things, one in all it's very handy if you want to get some idea regarding the network performance. On Wed, Dec 3, 2008 at 8:52 AM, Pekka Savola wrote: > On Tue, 2 Dec 2008, Andrew Mulholland wrote: > >> On Tue, Dec 2, 2008 at 10:47 PM, Lee, Steven (NSG Malaysia) < >> kin-wei.lee at hp.com> wrote: >> >> Hi all, do you have any recommended tools that can measure latency/delay >>> hop by hop basis? Preferable the tools can measure the running (live) >>> traffic. >>> >>> >> mtr ? - http://www.bitwizard.nl/mtr/ >> > > FWIW, Mtr measures latency/delay and loss based on ICMP messages heard back > from the routers on path. As a result, in almost all cases, the real > hop-by-hop latency of actual end-to-end data packets is better than it can > report. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > From aawolfe at gmail.com Wed Dec 3 01:08:09 2008 From: aawolfe at gmail.com (aawolfe at gmail.com) Date: Wed, 03 Dec 2008 07:08:09 +0000 Subject: Recommendation of Tools Message-ID: <0016361e7d943a5ebb045d1f1bf3@google.com> On Dec 3, 2008 1:52am, Pekka Savola wrote: > On Tue, 2 Dec 2008, Andrew Mulholland wrote: > > > On Tue, Dec 2, 2008 at 10:47 PM, Lee, Steven (NSG Malaysia) > kin-wei.lee at hp.com> wrote: > > > > > Hi all, do you have any recommended tools that can measure latency/delay > > hop by hop basis? Preferable the tools can measure the running (live) > > traffic. > > > > > > > mtr ? - http://www.bitwizard.nl/mtr/ > > > > > FWIW, Mtr measures latency/delay and loss based on ICMP messages heard back from the routers on path. As a result, in almost all cases, the real hop-by-hop latency of actual end-to-end data packets is better than it can report. > > tcptraceroute is handy for looking at what's going on with tcp http://michael.toren.net/code/tcptraceroute/ > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George RR Martin: A Clash of Kings > > > From hank at efes.iucc.ac.il Wed Dec 3 01:26:19 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 03 Dec 2008 09:26:19 +0200 Subject: Recommendation of Tools In-Reply-To: References: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> Message-ID: <5.1.0.14.2.20081203092338.00b2c640@efes.iucc.ac.il> At 11:23 PM 02-12-08 -0500, Andrew Mulholland wrote: >On Tue, Dec 2, 2008 at 10:47 PM, Lee, Steven (NSG Malaysia) < >kin-wei.lee at hp.com> wrote: > > > Hi all, do you have any recommended tools that can measure latency/delay > > hop by hop basis? Preferable the tools can measure the running (live) > > traffic. > > > >mtr ? - http://www.bitwizard.nl/mtr/ > >its an ncurses app.. output like to: This and others mentioned here by other posters can all be found (once again) at: http://kb.pert.geant2.net/PERTKB/MeasurementTools Not all tools are listed on that page. You need to go into the specific sub-pages: http://kb.pert.geant2.net/PERTKB/TracerouteLikeTools http://kb.pert.geant2.net/PERTKB/BandwidthMeasurementTools Regards, Hank From tony at lava.net Wed Dec 3 03:09:05 2008 From: tony at lava.net (Antonio Querubin) Date: Tue, 2 Dec 2008 23:09:05 -1000 (HST) Subject: Recommendation of Tools In-Reply-To: References: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> Message-ID: On Wed, 3 Dec 2008, Pekka Savola wrote: > FWIW, Mtr measures latency/delay and loss based on ICMP messages heard back > from the routers on path. As a result, in almost all cases, the real > hop-by-hop latency of actual end-to-end data packets is better than it can > report. mtr has a recently added '-u' option to use UDP instead of ICMP echo requests. -- Antonio Querubin whois: AQ7-ARIN From kuenzler at init7.net Wed Dec 3 03:55:41 2008 From: kuenzler at init7.net (Fredy Kuenzler) Date: Wed, 03 Dec 2008 10:55:41 +0100 Subject: Recommendation of Tools In-Reply-To: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> References: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> Message-ID: <4936579D.6080309@init7.net> Lee, Steven (NSG Malaysia) schrieb: > Hi all, do you have any recommended tools that can measure > latency/delay hop by hop basis? Preferable the tools can measure the > running (live) traffic. Try Smokeping for long-term latency stats: http://oss.oetiker.ch/smokeping/ Fredy From pekkas at netcore.fi Wed Dec 3 05:00:12 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 3 Dec 2008 13:00:12 +0200 (EET) Subject: Recommendation of Tools In-Reply-To: References: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> Message-ID: On Tue, 2 Dec 2008, Antonio Querubin wrote: > On Wed, 3 Dec 2008, Pekka Savola wrote: >> FWIW, Mtr measures latency/delay and loss based on ICMP messages heard >> back from the routers on path. As a result, in almost all cases, the real >> hop-by-hop latency of actual end-to-end data packets is better than it can >> report. > > mtr has a recently added '-u' option to use UDP instead of ICMP echo > requests. But that doesn't change the gist of my message: it's still relying on ICMP ttl exceeded messages sent by the routers on the path to check the delays etc. As such it suffers from basically the same limitations as ICMP probing. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jfmezei at vaxination.ca Wed Dec 3 09:47:28 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Wed, 03 Dec 2008 10:47:28 -0500 Subject: an over-the-top data center In-Reply-To: <20081128212449.GB67666@infiltrated.net> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <49306074.2070408@gmail.com> <20081128212449.GB67666@infiltrated.net> Message-ID: <4936AA10.2040705@vaxination.ca> pardon me for resurrecting this topic... For sites that are built in caves, how do they deal with cabling ? In the pretty pictures of the swedish site, there didn't seem to be an obvious raised floor. And it appeared to be solid concrete floor between the wings containing the systems. And no massive cable risers or suspended cable paths. It is all nice if neat, but in real life, wouldn't they need to be stringing tons and tons of cable ? Or it is a case of the pretty pictures with the fog having been taken with empty racks, before the data centre was outfitted with real equipment and now, there would be cables everywhere ? From ml at t-b-o-h.net Wed Dec 3 10:20:19 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H) Date: Wed, 3 Dec 2008 11:20:19 -0500 (EST) Subject: MetroOptical - Anyone know of them? Message-ID: <200812031620.mB3GKJoq099557@vjofn.tucs-beachin-obx-house.com> Hi Guys, We saw them (metrooptical.com) mentioned in Capacity Magazine, but trying to do any other investigation ends up flat. Website hosted at Godaddy, NIC records give a PO Box (So does the website), etc. Anyone know anything about them? Offlists appreciated. Tuc From Christine.Lane at motricity.com Wed Dec 3 11:21:31 2008 From: Christine.Lane at motricity.com (Christine Lane) Date: Wed, 3 Dec 2008 09:21:31 -0800 Subject: Recommendation of Tools In-Reply-To: <5.1.0.14.2.20081203092338.00b2c640@efes.iucc.ac.il> References: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net><084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> <5.1.0.14.2.20081203092338.00b2c640@efes.iucc.ac.il> Message-ID: <5BB22A7F2BFB4043B0AB892C799F9F9D01EBE546@SYSWPREXCH1BV.corp.local> A tool which I have heard of is Chariot. I have not used this tool myself and am not aware of its capabilities. I would be interested if anyone else has heard of it and can make any sort of recommendation. Christine -----Original Message----- From: Hank Nussbacher [mailto:hank at efes.iucc.ac.il] Sent: Tuesday, December 02, 2008 11:26 PM To: Andrew Mulholland; nanog at nanog.org Subject: Re: Recommendation of Tools At 11:23 PM 02-12-08 -0500, Andrew Mulholland wrote: >On Tue, Dec 2, 2008 at 10:47 PM, Lee, Steven (NSG Malaysia) < >kin-wei.lee at hp.com> wrote: > > > Hi all, do you have any recommended tools that can measure latency/delay > > hop by hop basis? Preferable the tools can measure the running (live) > > traffic. > > > >mtr ? - http://www.bitwizard.nl/mtr/ > >its an ncurses app.. output like to: This and others mentioned here by other posters can all be found (once again) at: http://kb.pert.geant2.net/PERTKB/MeasurementTools Not all tools are listed on that page. You need to go into the specific sub-pages: http://kb.pert.geant2.net/PERTKB/TracerouteLikeTools http://kb.pert.geant2.net/PERTKB/BandwidthMeasurementTools Regards, Hank From mansaxel at besserwisser.org Wed Dec 3 11:29:54 2008 From: mansaxel at besserwisser.org (=?UTF-8?Q?M=C3=A5ns_Nilsson?=) Date: Wed, 03 Dec 2008 18:29:54 +0100 Subject: an over-the-top data center In-Reply-To: <4936AA10.2040705@vaxination.ca> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <49306074.2070408@gmail.com> <20081128212449.GB67666@infiltrated.net> <4936AA10.2040705@vaxination.ca> Message-ID: <856D13BAE9ED1428A49242F1@rasmus.kthnoc.net> --On onsdag, onsdag 3 dec 2008 10.47.28 -0500 Jean-Fran?ois Mezei wrote: > > pardon me for resurrecting this topic... > > For sites that are built in caves, how do they deal with cabling ? Like any datacenter. Raceways on top of racks or under the floor. _Proper_ datacentres in caves (like, those made to actually be safe against all those DHS-funding movie plots) consist of a pretty standard CO building built inside a cave. Of course, there are a number of extras like EMP, gas and blast barriers, but they normally are outside the house. Pionen (the site that trigered this offtopic thread) is a showoff, not correctly expanded from the design originally made by those people who know about blast waves and such. > In the pretty pictures of the swedish site, there didn't seem to be an > obvious raised floor. There is a raised floor, iirc. -- M?ns Nilsson M A C H I N A Did an Italian CRANE OPERATOR just experience uninhibited sensations in a MALIBU HOT TUB? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jtodd at loligo.com Wed Dec 3 11:53:51 2008 From: jtodd at loligo.com (John Todd) Date: Wed, 3 Dec 2008 11:53:51 -0600 Subject: TRIP deployment? In-Reply-To: <00163630ee1d9c1ea3045c70ee1c@google.com> References: <00163630ee1d9c1ea3045c70ee1c@google.com> Message-ID: [sorry for late reply - .us Thanksgiving plus LIFO mailing list reading creates posting latency] On Nov 24, 2008, at 9:20 AM, cayle.spandon at gmail.com wrote: > I'm not sure if this is the right mailing list for this question: > how widely is TRIP (Telephone Routing over IP [RFC3219]) deployed / > used in current networks? There was a reference stack made in the Vovida package for TRIP, but in my experiments with it a number of years ago I was unable to implement it in any satisfactory way, and the code was far from complete. There was a TRIP commercial implementation in the Acme Packet SBC (Session Border Controller) equipment, and one in the Jasomi SBC IIRC, but I don't know what the status of those two stacks is today or if anyone uses them. I've never seen TRIP offered as a peering method in any exchange of any sort, so the short answer to your question as far as I know is "There is no significant use of TRIP today." This is a shame, since it seems like it would be useful. My belief is that there are significant economic dis-incentives for E.164 interconnection that are easily implemented and which create fluid, low-cost (or zero-cost) marketplaces for minutes, and I will not discuss the obvious opponents to such marketplaces. E.164-based ENUM is another casualty of that economic structure as it is inextricably linked to political decisions. There are additional problems with large-scale distributed routing of E.164 numbers as the trust model for number ownership is difficult to manage (the root cause of so many problems) and routing failures are much more operationally painful and difficult to resolve during unexpected failures. I'd be happy to be proven wrong on my assumption that TRIP is not used - does anyone have evidence of TRIP being used in readily-joinable federations, either in conjunction with geographic layer 3 peering fabrics or otherwise? Despite the failure of TRIP to catch on, there was some use that has come out of RFC3219 (TRIP). The ITAD concept, which defines an IANA- allocated unique identifier to telephony entities in other use cases. An ITAD is much like an ASN, except 32 bits, and currently zero-cost. The freenum.org project uses ITADs as part of a lookup mechanism based on ENUM-like DNS methods, in effect creating a phone keypad-friendly, IP communications-focused alternative to the normal E.164 phone numbers that are the standard for PSTN dialing. This moves quickly out of typical NANOG charter areas, but is worth mentioning as ITAD resources are being used to uniquely identify worldwide telephony networks that are layered on top of existing IP networks. As of 2008-12-03, the ITAD number space of the next assignment block will cross into the four-digit range. (full disclosure: I manage the Freenum project, so I'll be biased and suggest that anyone who manages any sort of IP-based telephony system with public inbound SIP capability should examine this - it's trivial to set up.) Other routing or routing-like protocols for telephony you might find interesting include OSP (Open Settlement Protocol), DUNDI (Distributed Universal Number DIscovery), and ENUM (ENUM). Each protocol has niche areas in which they are used for different purposes, but none have been overwhelmingly successful in a public setting, though ENUM has been very successful in "private" interconnects and mildly successful in some locations which have enlightened and technically educated national regulators. North America is not implementing ENUM in any public manner at this time to my knowledge. References: http://www.freenum.org/ http://www.ietf.org/rfc/rfc3219.txt http://www.iana.org/assignments/trip-parameters/ http://www.vovida.org/protocols/downloads/trip/ (death via Cisco?) http://www.voip-info.org/wiki-DUNDi http://www.voip-info.org/wiki-OSP http://www.voip-info.org/wiki-ENUM JT From list-only at dnz.se Wed Dec 3 12:01:37 2008 From: list-only at dnz.se (=?ISO-8859-1?Q?Anders_Lindb=E4ck?=) Date: Wed, 3 Dec 2008 19:01:37 +0100 Subject: Recommendation of Tools In-Reply-To: References: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> Message-ID: <943AC9CD-ABC3-406D-9799-E1B3664A3123@dnz.se> Mtr is even less usefull then that, in its default mode it does a traceroute and then proceeds to ICMP Ping flood each IP in the list generated by the traceroute, the result is usually completly useless on WAN topologies due to asym-routing, ICMP node protections by carriers and punting etc.. And using UDP will not really provide better results due to the same thing, and IIRC Cisco from 12.0 has a standard setting of no more then 1 ICMP Unreach per 500ms.. ------------------------------ Anders Lindb?ck anders.lindback at dnz.se On 3 dec 2008, at 12.00, Pekka Savola wrote: > On Tue, 2 Dec 2008, Antonio Querubin wrote: >> On Wed, 3 Dec 2008, Pekka Savola wrote: >>> FWIW, Mtr measures latency/delay and loss based on ICMP messages >>> heard >>> back from the routers on path. As a result, in almost all >>> cases, the real >>> hop-by-hop latency of actual end-to-end data packets is better >>> than it can >>> report. >> >> mtr has a recently added '-u' option to use UDP instead of ICMP >> echo requests. > > But that doesn't change the gist of my message: it's still relying > on ICMP ttl exceeded messages sent by the routers on the path to > check the delays etc. As such it suffers from basically the same > limitations as ICMP probing. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > From aaronh at bind.com Wed Dec 3 13:43:37 2008 From: aaronh at bind.com (Aaron Hughes) Date: Wed, 3 Dec 2008 11:43:37 -0800 Subject: Peering Personals BoF NANOG45, Attention Peering Coordinators Message-ID: <20081203194337.GF27841@trace.bind.com> Attention Peering Coordinators, NANOG45 is approaching quickly and it's time to get our Peering Personals participants lined up for the Peering BoF. Peering Personals is part of the Peering BoF (Birds Of a Feather) session and provides a forum for Peering Coordinators to meet each other with the goal of establishing peering relationships. Participating Peering Coordinators will complete and email the form below to the Peering BOF moderator in advance of the BOF. Peering Coordinators will have ~two minutes at the BOF to introduce themselves, their networks, where they currently peer and where they intend to be peering in the next several months, a little bit about what they require of potential peers and what they are looking for in a peering candidate. Peering Coordinators who would like to participate in Peering Introductions should e-mail the following information to aaronh at bind.com with the subject of "NANOG 45 Peering BOF" no later than Dec 31, 2008.: Name: _____________________ Company:__________________ AS#: _____________________ Email Address: ________________ Peering Locations Today: __________________ Peering Locations in the next 3-6 months: ________________ Is your network more Content-Heavy or Access-Heavy ? Do you source/sink more than 5Gbps of traffic? Do you require Contracts for Peering? Do you have an "Open Peering Policy (meaning you will peer with anyone in any single location), "Selective Peering Policy (meaning you will peer but have some prerequisites that must be met first)?, or "Restrictive Peering Policy (meaning you generally will not peer with anybody else)?" If you have any questions, don't hesitate to send me an e-mail. Cheers, Aaron -- Aaron Hughes aaronh at bind.com (703) 244-0427 Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 http://www.bind.com/ From mansaxel at besserwisser.org Wed Dec 3 13:45:25 2008 From: mansaxel at besserwisser.org (=?UTF-8?Q?M=C3=A5ns_Nilsson?=) Date: Wed, 03 Dec 2008 20:45:25 +0100 Subject: an over-the-top data center In-Reply-To: <856D13BAE9ED1428A49242F1@rasmus.kthnoc.net> References: <1853173528-1227890515-cardhu_decombobulator_blackberry.rim.net-470969029-@bxe312.bisx.prod.on.blackberry> <200811281710.14397.simonw@zynet.net> <49306074.2070408@gmail.com> <20081128212449.GB67666@infiltrated.net> <4936AA10.2040705@vaxination.ca> <856D13BAE9ED1428A49242F1@rasmus.kthnoc.net> Message-ID: <78D0A72317FF7C7200CED081@rasmus.kthnoc.net> --On onsdag, onsdag 3 dec 2008 18.29.54 +0100 M?ns Nilsson wrote: >> In the pretty pictures of the swedish site, there didn't seem to be an >> obvious raised floor. > > There is a raised floor, iirc. There is a raised floor. Have a look at -- M?ns Nilsson M A C H I N A I brought my BOWLING BALL -- and some DRUGS!! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From MBraun at firstam.com Wed Dec 3 13:56:50 2008 From: MBraun at firstam.com (Braun, Mike) Date: Wed, 3 Dec 2008 11:56:50 -0800 Subject: Recommendation of Tools In-Reply-To: <943AC9CD-ABC3-406D-9799-E1B3664A3123@dnz.se> References: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> <943AC9CD-ABC3-406D-9799-E1B3664A3123@dnz.se> Message-ID: If the question is to measure hop by hop latency from source to destination, perhaps across routers you don't manage, how can this be done without using the ICMP time exceeded messages? End to end latency is easily done with Smokeping and the use of TCP (SYN, SYN ACK, ACK, RST) and them timestamp it. This gives you a very clear idea on application latency on any tcp port. Hop by hop is a different story and the only option I know of is with the reliance on the ICMP mechanism. One additional question on this; how do you measure hop by hop when the path dynamically changes, and then record the path change (time/date and the differences in latency on the new path)? Mike -----Original Message----- From: Anders Lindb?ck [mailto:list-only at dnz.se] Sent: Wednesday, December 03, 2008 10:02 AM To: Pekka Savola Cc: nanog at nanog.org Subject: Re: Recommendation of Tools Mtr is even less usefull then that, in its default mode it does a traceroute and then proceeds to ICMP Ping flood each IP in the list generated by the traceroute, the result is usually completly useless on WAN topologies due to asym-routing, ICMP node protections by carriers and punting etc.. And using UDP will not really provide better results due to the same thing, and IIRC Cisco from 12.0 has a standard setting of no more then 1 ICMP Unreach per 500ms.. ------------------------------ Anders Lindb?ck anders.lindback at dnz.se On 3 dec 2008, at 12.00, Pekka Savola wrote: > On Tue, 2 Dec 2008, Antonio Querubin wrote: >> On Wed, 3 Dec 2008, Pekka Savola wrote: >>> FWIW, Mtr measures latency/delay and loss based on ICMP messages >>> heard >>> back from the routers on path. As a result, in almost all >>> cases, the real >>> hop-by-hop latency of actual end-to-end data packets is better >>> than it can >>> report. >> >> mtr has a recently added '-u' option to use UDP instead of ICMP >> echo requests. > > But that doesn't change the gist of my message: it's still relying > on ICMP ttl exceeded messages sent by the routers on the path to > check the delays etc. As such it suffers from basically the same > limitations as ICMP probing. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > -- THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE INTENDED SOLELY FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY CONTAIN CONFIDENTIAL, PROPRIETARY OR PRIVILEGED INFORMATION. IF YOU ARE NOT THE ADDRESSEE INDICATED IN THIS MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FILES TRANSMITTED HEREWITH. IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF IT FROM YOUR SYSTEM. From larryd at iservetech.com Wed Dec 3 14:36:36 2008 From: larryd at iservetech.com (Larry Daberko) Date: Wed, 3 Dec 2008 15:36:36 -0500 Subject: Yahoo DNS broken? Message-ID: <8C9EEC938968834395746CB30847EAF11A9E31@iserve-exchg.iservetech.local> I am unable to resolve www.yahoo.com. Tracing DNS back from the root servers shows that www.yahoo.com is a CNAME to www.wa1.b.yahoo.com and there are no A records for that hostname. Anyone have more details or a Yahoo contact? I'm unable to get to their webpage as it is :-) -Larry Daberko iServe Technologies $ dig @ns1.yahoo.com www.yahoo.com ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.yahoo.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56431 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.yahoo.com. IN A ;; ANSWER SECTION: www.yahoo.com. 300 IN CNAME www.wa1.b.yahoo.com. ;; AUTHORITY SECTION: wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. ;; ADDITIONAL SECTION: yf1.yahoo.com. 1800 IN A 68.142.254.15 yf2.yahoo.com. 1800 IN A 68.180.130.15 ;; Query time: 15 msec ;; SERVER: 68.180.131.16#53(68.180.131.16) ;; WHEN: Wed Dec 3 15:34:09 2008 ;; MSG SIZE rcvd: 123 but looking up the host itself gives no answer $ dig @ns1.yahoo.com www.wa1.b.yahoo.com ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.wa1.b.yahoo.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34875 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.wa1.b.yahoo.com. IN A ;; AUTHORITY SECTION: wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. ;; ADDITIONAL SECTION: yf1.yahoo.com. 1800 IN A 68.142.254.15 yf2.yahoo.com. 1800 IN A 68.180.130.15 ;; Query time: 15 msec ;; SERVER: 68.180.131.16#53(68.180.131.16) ;; WHEN: Wed Dec 3 15:35:07 2008 ;; MSG SIZE rcvd: 105 From cmills at accessdc.com Wed Dec 3 14:40:14 2008 From: cmills at accessdc.com (Mills, Charles) Date: Wed, 3 Dec 2008 15:40:14 -0500 Subject: Yahoo DNS broken? In-Reply-To: <8C9EEC938968834395746CB30847EAF11A9E31@iserve-exchg.iservetech.local> References: <8C9EEC938968834395746CB30847EAF11A9E31@iserve-exchg.iservetech.local> Message-ID: <58E0B21FC367B24485855A1DBD96B0BB11C05161@adc-prd-exch1.internal.accessdc.com> Their other pages (finance.yahoo.com) and such seem to resolve ok. Wondering if it isn't part of a bigger problem because I got a complaint that many sites Were unreachable for a bit. Chuck Charles L. Mills Senior Network Engineer Access Data Corporation / Pittsburgh, PA 15238 (412) 968-4024 / FAX: (412) 967-9504 cmills at accessdc.com / http://www.accessdc.com Hosting, Colocation, D-R and Managed Services -----Original Message----- From: Larry Daberko [mailto:larryd at iservetech.com] Sent: Wednesday, December 03, 2008 3:37 PM To: nanog at nanog.org Subject: Yahoo DNS broken? I am unable to resolve www.yahoo.com. Tracing DNS back from the root servers shows that www.yahoo.com is a CNAME to www.wa1.b.yahoo.com and there are no A records for that hostname. Anyone have more details or a Yahoo contact? I'm unable to get to their webpage as it is :-) -Larry Daberko iServe Technologies $ dig @ns1.yahoo.com www.yahoo.com ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.yahoo.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56431 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.yahoo.com. IN A ;; ANSWER SECTION: www.yahoo.com. 300 IN CNAME www.wa1.b.yahoo.com. ;; AUTHORITY SECTION: wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. ;; ADDITIONAL SECTION: yf1.yahoo.com. 1800 IN A 68.142.254.15 yf2.yahoo.com. 1800 IN A 68.180.130.15 ;; Query time: 15 msec ;; SERVER: 68.180.131.16#53(68.180.131.16) ;; WHEN: Wed Dec 3 15:34:09 2008 ;; MSG SIZE rcvd: 123 but looking up the host itself gives no answer $ dig @ns1.yahoo.com www.wa1.b.yahoo.com ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.wa1.b.yahoo.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34875 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.wa1.b.yahoo.com. IN A ;; AUTHORITY SECTION: wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. ;; ADDITIONAL SECTION: yf1.yahoo.com. 1800 IN A 68.142.254.15 yf2.yahoo.com. 1800 IN A 68.180.130.15 ;; Query time: 15 msec ;; SERVER: 68.180.131.16#53(68.180.131.16) ;; WHEN: Wed Dec 3 15:35:07 2008 ;; MSG SIZE rcvd: 105 This e-mail message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this e-mail message in error, please notify the sender immediately by telephone or e-mail and destroy the original message without making a copy. Thank you. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message. From nanog at mattelmore.com Wed Dec 3 14:40:25 2008 From: nanog at mattelmore.com (Matthew Elmore) Date: Wed, 3 Dec 2008 14:40:25 -0600 Subject: Comcast DNS Message-ID: Anyone else having problems doing recursive lookups on Comcast's DNS servers? From dave at stayonline.com Wed Dec 3 14:42:50 2008 From: dave at stayonline.com (Dave Larter) Date: Wed, 3 Dec 2008 15:42:50 -0500 Subject: Yahoo DNS broken? In-Reply-To: <8C9EEC938968834395746CB30847EAF11A9E31@iserve-exchg.iservetech.local> References: <8C9EEC938968834395746CB30847EAF11A9E31@iserve-exchg.iservetech.local> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB397555@MERCURY.socrdu.com> Yes, www.yahoo.com is unreachable for me too, but mail.yahoo.com and login.yahoo.com are up. -----Original Message----- From: Larry Daberko [mailto:larryd at iservetech.com] Sent: Wednesday, December 03, 2008 3:37 PM To: nanog at nanog.org Subject: Yahoo DNS broken? I am unable to resolve www.yahoo.com. Tracing DNS back from the root servers shows that www.yahoo.com is a CNAME to www.wa1.b.yahoo.com and there are no A records for that hostname. Anyone have more details or a Yahoo contact? I'm unable to get to their webpage as it is :-) -Larry Daberko iServe Technologies $ dig @ns1.yahoo.com www.yahoo.com ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.yahoo.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56431 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.yahoo.com. IN A ;; ANSWER SECTION: www.yahoo.com. 300 IN CNAME www.wa1.b.yahoo.com. ;; AUTHORITY SECTION: wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. ;; ADDITIONAL SECTION: yf1.yahoo.com. 1800 IN A 68.142.254.15 yf2.yahoo.com. 1800 IN A 68.180.130.15 ;; Query time: 15 msec ;; SERVER: 68.180.131.16#53(68.180.131.16) ;; WHEN: Wed Dec 3 15:34:09 2008 ;; MSG SIZE rcvd: 123 but looking up the host itself gives no answer $ dig @ns1.yahoo.com www.wa1.b.yahoo.com ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.wa1.b.yahoo.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34875 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.wa1.b.yahoo.com. IN A ;; AUTHORITY SECTION: wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. ;; ADDITIONAL SECTION: yf1.yahoo.com. 1800 IN A 68.142.254.15 yf2.yahoo.com. 1800 IN A 68.180.130.15 ;; Query time: 15 msec ;; SERVER: 68.180.131.16#53(68.180.131.16) ;; WHEN: Wed Dec 3 15:35:07 2008 ;; MSG SIZE rcvd: 105 From nanog at daork.net Wed Dec 3 14:41:10 2008 From: nanog at daork.net (Nathan Ward) Date: Thu, 4 Dec 2008 09:41:10 +1300 Subject: Yahoo DNS broken? In-Reply-To: <8C9EEC938968834395746CB30847EAF11A9E31@iserve-exchg.iservetech.local> References: <8C9EEC938968834395746CB30847EAF11A9E31@iserve-exchg.iservetech.local> Message-ID: There is no A records, correct. There is a CNAME though: www.wa1.b.yahoo.com. 45 IN CNAME www- real.wa1.b.yahoo.com. www-real.wa1.b.yahoo.com. 45 IN A 209.131.36.158 On 4/12/2008, at 9:36 AM, Larry Daberko wrote: > I am unable to resolve www.yahoo.com. Tracing DNS back from the root > servers shows that www.yahoo.com is a CNAME to www.wa1.b.yahoo.com and > there are no A records for that hostname. > > Anyone have more details or a Yahoo contact? I'm unable to get to > their > webpage as it is :-) > > -Larry Daberko > iServe Technologies > > > > > $ dig @ns1.yahoo.com www.yahoo.com > > ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.yahoo.com > ; (1 server found) > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56431 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;www.yahoo.com. IN A > > ;; ANSWER SECTION: > www.yahoo.com. 300 IN CNAME www.wa1.b.yahoo.com. > > ;; AUTHORITY SECTION: > wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. > wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. > > ;; ADDITIONAL SECTION: > yf1.yahoo.com. 1800 IN A 68.142.254.15 > yf2.yahoo.com. 1800 IN A 68.180.130.15 > > ;; Query time: 15 msec > ;; SERVER: 68.180.131.16#53(68.180.131.16) > ;; WHEN: Wed Dec 3 15:34:09 2008 > ;; MSG SIZE rcvd: 123 > > > but looking up the host itself gives no answer > > > $ dig @ns1.yahoo.com www.wa1.b.yahoo.com > > ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.wa1.b.yahoo.com > ; (1 server found) > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34875 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;www.wa1.b.yahoo.com. IN A > > ;; AUTHORITY SECTION: > wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. > wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. > > ;; ADDITIONAL SECTION: > yf1.yahoo.com. 1800 IN A 68.142.254.15 > yf2.yahoo.com. 1800 IN A 68.180.130.15 > > ;; Query time: 15 msec > ;; SERVER: 68.180.131.16#53(68.180.131.16) > ;; WHEN: Wed Dec 3 15:35:07 2008 > ;; MSG SIZE rcvd: 105 > > > > !DSPAM:22,4936edf127844578318734! > > -- Nathan Ward From erik_list at caneris.com Wed Dec 3 14:41:39 2008 From: erik_list at caneris.com (Erik (Caneris)) Date: Wed, 3 Dec 2008 15:41:39 -0500 Subject: Yahoo DNS broken? In-Reply-To: References: <8C9EEC938968834395746CB30847EAF11A9E31@iserve-exchg.iservetech.local>, Message-ID: Seems to be back up now. -- Erik Caneris Tel: 647-723-6365 Fax: 647-723-5365 Toll-free: 1-866-827-0021 www.caneris.com ________________________________________ From: Larry Daberko [larryd at iservetech.com] Sent: Wednesday, December 03, 2008 3:36 PM To: nanog at nanog.org Subject: Yahoo DNS broken? I am unable to resolve www.yahoo.com. Tracing DNS back from the root servers shows that www.yahoo.com is a CNAME to www.wa1.b.yahoo.com and there are no A records for that hostname. Anyone have more details or a Yahoo contact? I'm unable to get to their webpage as it is :-) -Larry Daberko iServe Technologies From michael at rancid.berkeley.edu Wed Dec 3 14:46:20 2008 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Wed, 03 Dec 2008 12:46:20 -0800 Subject: Yahoo DNS broken? In-Reply-To: <8C9EEC938968834395746CB30847EAF11A9E31@iserve-exchg.iservetech.local> References: <8C9EEC938968834395746CB30847EAF11A9E31@iserve-exchg.iservetech.local> Message-ID: <4936F01C.4050501@rancid.berkeley.edu> On 12/03/08 12:36, Larry Daberko wrote: > I am unable to resolve www.yahoo.com. Tracing DNS back from the root > servers shows that www.yahoo.com is a CNAME to www.wa1.b.yahoo.com and > there are no A records for that hostname. > > Anyone have more details or a Yahoo contact? I'm unable to get to their > webpage as it is :-) > > -Larry Daberko > iServe Technologies > > > > > $ dig @ns1.yahoo.com www.yahoo.com > > ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.yahoo.com > ; (1 server found) > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56431 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;www.yahoo.com. IN A > > ;; ANSWER SECTION: > www.yahoo.com. 300 IN CNAME www.wa1.b.yahoo.com. > > ;; AUTHORITY SECTION: > wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. > wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. > > ;; ADDITIONAL SECTION: > yf1.yahoo.com. 1800 IN A 68.142.254.15 > yf2.yahoo.com. 1800 IN A 68.180.130.15 > > ;; Query time: 15 msec > ;; SERVER: 68.180.131.16#53(68.180.131.16) > ;; WHEN: Wed Dec 3 15:34:09 2008 > ;; MSG SIZE rcvd: 123 > > > but looking up the host itself gives no answer > > > $ dig @ns1.yahoo.com www.wa1.b.yahoo.com > > ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.wa1.b.yahoo.com > ; (1 server found) > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34875 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;www.wa1.b.yahoo.com. IN A > > ;; AUTHORITY SECTION: > wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. > wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. > > ;; ADDITIONAL SECTION: > yf1.yahoo.com. 1800 IN A 68.142.254.15 > yf2.yahoo.com. 1800 IN A 68.180.130.15 Well, since ns1.yahoo.com isn't authoritative for wa1.b.yahoo.com, then I wouldn't expect it to have the answer. Trying yf1.yahoo.com: > dig www.wa1.b.yahoo.com. @yf1.yahoo.com ; <<>> DiG 9.4.2-P1 <<>> www.wa1.b.yahoo.com. @yf1.yahoo.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31055 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.wa1.b.yahoo.com. IN A ;; ANSWER SECTION: www.wa1.b.yahoo.com. 60 IN CNAME www-real.wa1.b.yahoo.com. www-real.wa1.b.yahoo.com. 60 IN A 209.131.36.158 ;; Query time: 3 msec ;; SERVER: 68.142.254.15#53(68.142.254.15) ;; WHEN: Wed Dec 3 12:55:24 2008 ;; MSG SIZE rcvd: 76 It's a chain of CNAME records, which isn't very nice, but isn't technically illegal. In most cases, it's resolvable. Not what I would do for a globally-reachable revenue-generating service, but I am sure they have their reasons. michael From mike at sentex.net Wed Dec 3 14:47:07 2008 From: mike at sentex.net (Mike Tancsa) Date: Wed, 03 Dec 2008 15:47:07 -0500 Subject: Yahoo DNS broken? In-Reply-To: <58E0B21FC367B24485855A1DBD96B0BB11C05161@adc-prd-exch1.int ernal.accessdc.com> References: <8C9EEC938968834395746CB30847EAF11A9E31@iserve-exchg.iservetech.local> <58E0B21FC367B24485855A1DBD96B0BB11C05161@adc-prd-exch1.internal.accessdc.com> Message-ID: <200812032047.mB3KlHoQ011867@lava.sentex.ca> At 03:40 PM 12/3/2008, Mills, Charles wrote: >Their other pages (finance.yahoo.com) and such seem to resolve ok. > >Wondering if it isn't part of a bigger problem because I got a complaint >that many sites >Were unreachable for a bit. www.yahoo.com seems to be a CNAME for wa1.b.yahoo.com and delegated to ... ;; Received 201 bytes from 192.41.162.30#53(L.GTLD-SERVERS.NET) in 39 ms www.yahoo.com. 300 IN CNAME www.wa1.b.yahoo.com. wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. ;; Received 123 bytes from 68.180.131.16#53(ns1.yahoo.com) in 27 ms % host yf1.yahoo.com yf1.yahoo.com has address 68.142.254.15 Neither yf1.yahoo.com nor yf2 are responding to queries for me, but I can reach them 0[granite]% time host wa1.b.yahoo.com 68.142.254.15 ;; connection timed out; no servers could be reached 0.002u 0.000s 0:10.00 0.0% 0+0k 0+0io 0pf+0w 1[granite]% % ping -c 1 yf1.yahoo.com PING yf1.yahoo.com (68.142.254.15): 56 data bytes 64 bytes from 68.142.254.15: icmp_seq=0 ttl=56 time=28.282 ms --- yf1.yahoo.com ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 28.282/28.282/28.282/0.000 ms ---Mike From kyle at geekmedic.us Wed Dec 3 14:47:44 2008 From: kyle at geekmedic.us (Kyle Rollin) Date: Wed, 3 Dec 2008 15:47:44 -0500 Subject: Yahoo DNS broken? In-Reply-To: <8B79B73777E7D544A24BEB8FC50D35DB397555@MERCURY.socrdu.com> References: <8C9EEC938968834395746CB30847EAF11A9E31@iserve-exchg.iservetech.local> <8B79B73777E7D544A24BEB8FC50D35DB397555@MERCURY.socrdu.com> Message-ID: <001701c95588$6583f5f0$308be1d0$@us> Interesting, as my nslookup.. > www.yahoo.com Server: ns1.hostremote.net Address: 66.187.130.31 Non-authoritative answer: Name: www.yahoo-ht3.akadns.net Address: 209.191.93.52 Aliases: www.yahoo.com And yes, I can hit http://www.yahoo.com in a web browser. Works for me. -Kyle -----Original Message----- From: Dave Larter [mailto:dave at stayonline.com] Sent: Wednesday, December 03, 2008 3:43 PM To: Larry Daberko; nanog at nanog.org Subject: RE: Yahoo DNS broken? Yes, www.yahoo.com is unreachable for me too, but mail.yahoo.com and login.yahoo.com are up. -----Original Message----- From: Larry Daberko [mailto:larryd at iservetech.com] Sent: Wednesday, December 03, 2008 3:37 PM To: nanog at nanog.org Subject: Yahoo DNS broken? I am unable to resolve www.yahoo.com. Tracing DNS back from the root servers shows that www.yahoo.com is a CNAME to www.wa1.b.yahoo.com and there are no A records for that hostname. Anyone have more details or a Yahoo contact? I'm unable to get to their webpage as it is :-) -Larry Daberko iServe Technologies $ dig @ns1.yahoo.com www.yahoo.com ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.yahoo.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56431 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.yahoo.com. IN A ;; ANSWER SECTION: www.yahoo.com. 300 IN CNAME www.wa1.b.yahoo.com. ;; AUTHORITY SECTION: wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. ;; ADDITIONAL SECTION: yf1.yahoo.com. 1800 IN A 68.142.254.15 yf2.yahoo.com. 1800 IN A 68.180.130.15 ;; Query time: 15 msec ;; SERVER: 68.180.131.16#53(68.180.131.16) ;; WHEN: Wed Dec 3 15:34:09 2008 ;; MSG SIZE rcvd: 123 but looking up the host itself gives no answer $ dig @ns1.yahoo.com www.wa1.b.yahoo.com ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.wa1.b.yahoo.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34875 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.wa1.b.yahoo.com. IN A ;; AUTHORITY SECTION: wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. ;; ADDITIONAL SECTION: yf1.yahoo.com. 1800 IN A 68.142.254.15 yf2.yahoo.com. 1800 IN A 68.180.130.15 ;; Query time: 15 msec ;; SERVER: 68.180.131.16#53(68.180.131.16) ;; WHEN: Wed Dec 3 15:35:07 2008 ;; MSG SIZE rcvd: 105 From cat at reptiles.org Wed Dec 3 14:47:59 2008 From: cat at reptiles.org (Cat Okita) Date: Wed, 3 Dec 2008 15:47:59 -0500 (EST) Subject: Yahoo DNS broken? In-Reply-To: References: <8C9EEC938968834395746CB30847EAF11A9E31@iserve-exchg.iservetech.local> Message-ID: <20081203154735.R45081@gecko.reptiles.org> Looks like some of akamai's nameservers have misplaced themselves and yahoo. cheers! On Thu, 4 Dec 2008, Nathan Ward wrote: > There is no A records, correct. > There is a CNAME though: > www.wa1.b.yahoo.com. 45 IN CNAME www-real.wa1.b.yahoo.com. > www-real.wa1.b.yahoo.com. 45 IN A 209.131.36.158 > > On 4/12/2008, at 9:36 AM, Larry Daberko wrote: > >> I am unable to resolve www.yahoo.com. Tracing DNS back from the root >> servers shows that www.yahoo.com is a CNAME to www.wa1.b.yahoo.com and >> there are no A records for that hostname. >> >> Anyone have more details or a Yahoo contact? I'm unable to get to their >> webpage as it is :-) >> >> -Larry Daberko >> iServe Technologies >> >> >> >> >> $ dig @ns1.yahoo.com www.yahoo.com >> >> ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.yahoo.com >> ; (1 server found) >> ;; global options: printcmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56431 >> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 >> ;; WARNING: recursion requested but not available >> >> ;; QUESTION SECTION: >> ;www.yahoo.com. IN A >> >> ;; ANSWER SECTION: >> www.yahoo.com. 300 IN CNAME www.wa1.b.yahoo.com. >> >> ;; AUTHORITY SECTION: >> wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. >> wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. >> >> ;; ADDITIONAL SECTION: >> yf1.yahoo.com. 1800 IN A 68.142.254.15 >> yf2.yahoo.com. 1800 IN A 68.180.130.15 >> >> ;; Query time: 15 msec >> ;; SERVER: 68.180.131.16#53(68.180.131.16) >> ;; WHEN: Wed Dec 3 15:34:09 2008 >> ;; MSG SIZE rcvd: 123 >> >> >> but looking up the host itself gives no answer >> >> >> $ dig @ns1.yahoo.com www.wa1.b.yahoo.com >> >> ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.wa1.b.yahoo.com >> ; (1 server found) >> ;; global options: printcmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34875 >> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 >> ;; WARNING: recursion requested but not available >> >> ;; QUESTION SECTION: >> ;www.wa1.b.yahoo.com. IN A >> >> ;; AUTHORITY SECTION: >> wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. >> wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. >> >> ;; ADDITIONAL SECTION: >> yf1.yahoo.com. 1800 IN A 68.142.254.15 >> yf2.yahoo.com. 1800 IN A 68.180.130.15 >> >> ;; Query time: 15 msec >> ;; SERVER: 68.180.131.16#53(68.180.131.16) >> ;; WHEN: Wed Dec 3 15:35:07 2008 >> ;; MSG SIZE rcvd: 105 >> >> >> >> !DSPAM:22,4936edf127844578318734! >> >> > > -- > Nathan Ward > > > > ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." From pstewart at nexicomgroup.net Wed Dec 3 14:48:38 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Wed, 3 Dec 2008 15:48:38 -0500 Subject: Yahoo DNS broken? In-Reply-To: References: <8C9EEC938968834395746CB30847EAF11A9E31@iserve-exchg.iservetech.local> Message-ID: <89D27DE3375BB6428DDCC2927489826A01CC60B9@nexus.nexicomgroup.net> I talked to Yahoo! NOC a little while ago and they are working on the issue - definitely DNS related and appears to possibly be east coast only.... details are vague but they are aware of it and no ETA yet... Paul -----Original Message----- From: Nathan Ward [mailto:nanog at daork.net] Sent: Wednesday, December 03, 2008 3:41 PM To: nanog list Subject: Re: Yahoo DNS broken? There is no A records, correct. There is a CNAME though: www.wa1.b.yahoo.com. 45 IN CNAME www- real.wa1.b.yahoo.com. www-real.wa1.b.yahoo.com. 45 IN A 209.131.36.158 On 4/12/2008, at 9:36 AM, Larry Daberko wrote: > I am unable to resolve www.yahoo.com. Tracing DNS back from the root > servers shows that www.yahoo.com is a CNAME to www.wa1.b.yahoo.com and > there are no A records for that hostname. > > Anyone have more details or a Yahoo contact? I'm unable to get to > their > webpage as it is :-) > > -Larry Daberko > iServe Technologies > > > > > $ dig @ns1.yahoo.com www.yahoo.com > > ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.yahoo.com > ; (1 server found) > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56431 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;www.yahoo.com. IN A > > ;; ANSWER SECTION: > www.yahoo.com. 300 IN CNAME www.wa1.b.yahoo.com. > > ;; AUTHORITY SECTION: > wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. > wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. > > ;; ADDITIONAL SECTION: > yf1.yahoo.com. 1800 IN A 68.142.254.15 > yf2.yahoo.com. 1800 IN A 68.180.130.15 > > ;; Query time: 15 msec > ;; SERVER: 68.180.131.16#53(68.180.131.16) > ;; WHEN: Wed Dec 3 15:34:09 2008 > ;; MSG SIZE rcvd: 123 > > > but looking up the host itself gives no answer > > > $ dig @ns1.yahoo.com www.wa1.b.yahoo.com > > ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.wa1.b.yahoo.com > ; (1 server found) > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34875 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;www.wa1.b.yahoo.com. IN A > > ;; AUTHORITY SECTION: > wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. > wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. > > ;; ADDITIONAL SECTION: > yf1.yahoo.com. 1800 IN A 68.142.254.15 > yf2.yahoo.com. 1800 IN A 68.180.130.15 > > ;; Query time: 15 msec > ;; SERVER: 68.180.131.16#53(68.180.131.16) > ;; WHEN: Wed Dec 3 15:35:07 2008 > ;; MSG SIZE rcvd: 105 > > > > !DSPAM:22,4936edf127844578318734! > > -- Nathan Ward ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From ff30751 at verizon.net Wed Dec 3 14:49:09 2008 From: ff30751 at verizon.net (Ed Trdina) Date: Wed, 03 Dec 2008 15:49:09 -0500 Subject: Yahoo DNS broken? In-Reply-To: <8B79B73777E7D544A24BEB8FC50D35DB397555@MERCURY.socrdu.com> References: <8C9EEC938968834395746CB30847EAF11A9E31@iserve-exchg.iservetech.local> <8B79B73777E7D544A24BEB8FC50D35DB397555@MERCURY.socrdu.com> Message-ID: It's working for me on my Verizon FIOS connection. Is it yet another geolocation issue? My yahoo resolves to www.yahoo-ht3.akadns.net 209.191.93.52 Ed -----Original Message----- From: Dave Larter [mailto:dave at stayonline.com] Sent: Wednesday, December 03, 2008 3:43 PM To: Larry Daberko; nanog at nanog.org Subject: RE: Yahoo DNS broken? Yes, www.yahoo.com is unreachable for me too, but mail.yahoo.com and login.yahoo.com are up. -----Original Message----- From: Larry Daberko [mailto:larryd at iservetech.com] Sent: Wednesday, December 03, 2008 3:37 PM To: nanog at nanog.org Subject: Yahoo DNS broken? I am unable to resolve www.yahoo.com. Tracing DNS back from the root servers shows that www.yahoo.com is a CNAME to www.wa1.b.yahoo.com and there are no A records for that hostname. Anyone have more details or a Yahoo contact? I'm unable to get to their webpage as it is :-) -Larry Daberko iServe Technologies $ dig @ns1.yahoo.com www.yahoo.com ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.yahoo.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56431 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.yahoo.com. IN A ;; ANSWER SECTION: www.yahoo.com. 300 IN CNAME www.wa1.b.yahoo.com. ;; AUTHORITY SECTION: wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. ;; ADDITIONAL SECTION: yf1.yahoo.com. 1800 IN A 68.142.254.15 yf2.yahoo.com. 1800 IN A 68.180.130.15 ;; Query time: 15 msec ;; SERVER: 68.180.131.16#53(68.180.131.16) ;; WHEN: Wed Dec 3 15:34:09 2008 ;; MSG SIZE rcvd: 123 but looking up the host itself gives no answer $ dig @ns1.yahoo.com www.wa1.b.yahoo.com ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.wa1.b.yahoo.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34875 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.wa1.b.yahoo.com. IN A ;; AUTHORITY SECTION: wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. ;; ADDITIONAL SECTION: yf1.yahoo.com. 1800 IN A 68.142.254.15 yf2.yahoo.com. 1800 IN A 68.180.130.15 ;; Query time: 15 msec ;; SERVER: 68.180.131.16#53(68.180.131.16) ;; WHEN: Wed Dec 3 15:35:07 2008 ;; MSG SIZE rcvd: 105 From larryd at iservetech.com Wed Dec 3 14:50:02 2008 From: larryd at iservetech.com (Larry Daberko) Date: Wed, 3 Dec 2008 15:50:02 -0500 Subject: Yahoo DNS broken? In-Reply-To: <001701c95588$6583f5f0$308be1d0$@us> Message-ID: <8C9EEC938968834395746CB30847EAF11A9E36@iserve-exchg.iservetech.local> Yes, I am now seeing the akadns.net address. Looks like went through some fluctuation there, but the site is back up for me now. There is also a report on the outages list. -Larry Daberko -----Original Message----- From: Kyle Rollin [mailto:kyle at geekmedic.us] Sent: Wednesday, December 03, 2008 3:48 PM To: 'Dave Larter'; Larry Daberko; nanog at nanog.org Subject: RE: Yahoo DNS broken? Interesting, as my nslookup.. > www.yahoo.com Server: ns1.hostremote.net Address: 66.187.130.31 Non-authoritative answer: Name: www.yahoo-ht3.akadns.net Address: 209.191.93.52 Aliases: www.yahoo.com And yes, I can hit http://www.yahoo.com in a web browser. Works for me. -Kyle -----Original Message----- From: Dave Larter [mailto:dave at stayonline.com] Sent: Wednesday, December 03, 2008 3:43 PM To: Larry Daberko; nanog at nanog.org Subject: RE: Yahoo DNS broken? Yes, www.yahoo.com is unreachable for me too, but mail.yahoo.com and login.yahoo.com are up. -----Original Message----- From: Larry Daberko [mailto:larryd at iservetech.com] Sent: Wednesday, December 03, 2008 3:37 PM To: nanog at nanog.org Subject: Yahoo DNS broken? I am unable to resolve www.yahoo.com. Tracing DNS back from the root servers shows that www.yahoo.com is a CNAME to www.wa1.b.yahoo.com and there are no A records for that hostname. Anyone have more details or a Yahoo contact? I'm unable to get to their webpage as it is :-) -Larry Daberko iServe Technologies $ dig @ns1.yahoo.com www.yahoo.com ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.yahoo.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56431 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.yahoo.com. IN A ;; ANSWER SECTION: www.yahoo.com. 300 IN CNAME www.wa1.b.yahoo.com. ;; AUTHORITY SECTION: wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. ;; ADDITIONAL SECTION: yf1.yahoo.com. 1800 IN A 68.142.254.15 yf2.yahoo.com. 1800 IN A 68.180.130.15 ;; Query time: 15 msec ;; SERVER: 68.180.131.16#53(68.180.131.16) ;; WHEN: Wed Dec 3 15:34:09 2008 ;; MSG SIZE rcvd: 123 but looking up the host itself gives no answer $ dig @ns1.yahoo.com www.wa1.b.yahoo.com ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.wa1.b.yahoo.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34875 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.wa1.b.yahoo.com. IN A ;; AUTHORITY SECTION: wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. ;; ADDITIONAL SECTION: yf1.yahoo.com. 1800 IN A 68.142.254.15 yf2.yahoo.com. 1800 IN A 68.180.130.15 ;; Query time: 15 msec ;; SERVER: 68.180.131.16#53(68.180.131.16) ;; WHEN: Wed Dec 3 15:35:07 2008 ;; MSG SIZE rcvd: 105 From dave at stayonline.com Wed Dec 3 14:56:35 2008 From: dave at stayonline.com (Dave Larter) Date: Wed, 3 Dec 2008 15:56:35 -0500 Subject: Yahoo DNS broken? In-Reply-To: <001701c95588$6583f5f0$308be1d0$@us> References: <8C9EEC938968834395746CB30847EAF11A9E31@iserve-exchg.iservetech.local> <8B79B73777E7D544A24BEB8FC50D35DB397555@MERCURY.socrdu.com> <001701c95588$6583f5f0$308be1d0$@us> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB397562@MERCURY.socrdu.com> Yes, I did nslookup and got responses but wouldn't come up in my browser, also to add it seems to be working now. -----Original Message----- From: Kyle Rollin [mailto:kyle at geekmedic.us] Sent: Wednesday, December 03, 2008 3:48 PM To: Dave Larter; 'Larry Daberko'; nanog at nanog.org Subject: RE: Yahoo DNS broken? Interesting, as my nslookup.. > www.yahoo.com Server: ns1.hostremote.net Address: 66.187.130.31 Non-authoritative answer: Name: www.yahoo-ht3.akadns.net Address: 209.191.93.52 Aliases: www.yahoo.com And yes, I can hit http://www.yahoo.com in a web browser. Works for me. -Kyle -----Original Message----- From: Dave Larter [mailto:dave at stayonline.com] Sent: Wednesday, December 03, 2008 3:43 PM To: Larry Daberko; nanog at nanog.org Subject: RE: Yahoo DNS broken? Yes, www.yahoo.com is unreachable for me too, but mail.yahoo.com and login.yahoo.com are up. -----Original Message----- From: Larry Daberko [mailto:larryd at iservetech.com] Sent: Wednesday, December 03, 2008 3:37 PM To: nanog at nanog.org Subject: Yahoo DNS broken? I am unable to resolve www.yahoo.com. Tracing DNS back from the root servers shows that www.yahoo.com is a CNAME to www.wa1.b.yahoo.com and there are no A records for that hostname. Anyone have more details or a Yahoo contact? I'm unable to get to their webpage as it is :-) -Larry Daberko iServe Technologies $ dig @ns1.yahoo.com www.yahoo.com ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.yahoo.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56431 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.yahoo.com. IN A ;; ANSWER SECTION: www.yahoo.com. 300 IN CNAME www.wa1.b.yahoo.com. ;; AUTHORITY SECTION: wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. ;; ADDITIONAL SECTION: yf1.yahoo.com. 1800 IN A 68.142.254.15 yf2.yahoo.com. 1800 IN A 68.180.130.15 ;; Query time: 15 msec ;; SERVER: 68.180.131.16#53(68.180.131.16) ;; WHEN: Wed Dec 3 15:34:09 2008 ;; MSG SIZE rcvd: 123 but looking up the host itself gives no answer $ dig @ns1.yahoo.com www.wa1.b.yahoo.com ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.wa1.b.yahoo.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34875 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.wa1.b.yahoo.com. IN A ;; AUTHORITY SECTION: wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. ;; ADDITIONAL SECTION: yf1.yahoo.com. 1800 IN A 68.142.254.15 yf2.yahoo.com. 1800 IN A 68.180.130.15 ;; Query time: 15 msec ;; SERVER: 68.180.131.16#53(68.180.131.16) ;; WHEN: Wed Dec 3 15:35:07 2008 ;; MSG SIZE rcvd: 105 From mpetach at netflight.com Wed Dec 3 15:16:13 2008 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 3 Dec 2008 13:16:13 -0800 Subject: Yahoo DNS broken? In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01CC60B9@nexus.nexicomgroup.net> References: <8C9EEC938968834395746CB30847EAF11A9E31@iserve-exchg.iservetech.local> <89D27DE3375BB6428DDCC2927489826A01CC60B9@nexus.nexicomgroup.net> Message-ID: <63ac96a50812031316m23b9de6exd4fa70fd5f80a41@mail.gmail.com> On 12/3/08, Paul Stewart wrote: > I talked to Yahoo! NOC a little while ago and they are working on the > issue - definitely DNS related and appears to possibly be east coast > only.... details are vague but they are aware of it and no ETA yet... > > Paul Yes; actively being worked on; Juniper T1600 went kablooie, and when it went away, anycasted DNS went haywire as well; still digging into it more; yes, this is primarily affecting traffic coming through Ashburn, VA. No, I don't have an answer on specifically what happened; yes, we're aware of the issue and have put workarounds in place; you should be back up and functional for the moment, though not in an optimal state. Matt And no, I'm not speaking authoritatively for anything or anyone at the moment, so treat this with a few grains of salt. > > > -----Original Message----- > From: Nathan Ward [mailto:nanog at daork.net] > Sent: Wednesday, December 03, 2008 3:41 PM > To: nanog list > Subject: Re: Yahoo DNS broken? > > There is no A records, correct. > There is a CNAME though: > www.wa1.b.yahoo.com. 45 IN CNAME www- > real.wa1.b.yahoo.com. > www-real.wa1.b.yahoo.com. 45 IN A 209.131.36.158 > > On 4/12/2008, at 9:36 AM, Larry Daberko wrote: > > > I am unable to resolve www.yahoo.com. Tracing DNS back from the root > > servers shows that www.yahoo.com is a CNAME to www.wa1.b.yahoo.com and > > there are no A records for that hostname. > > > > Anyone have more details or a Yahoo contact? I'm unable to get to > > their > > webpage as it is :-) > > > > -Larry Daberko > > iServe Technologies > > > > > > > > > > $ dig @ns1.yahoo.com www.yahoo.com > > > > ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.yahoo.com > > ; (1 server found) > > ;; global options: printcmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56431 > > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 > > ;; WARNING: recursion requested but not available > > > > ;; QUESTION SECTION: > > ;www.yahoo.com. IN A > > > > ;; ANSWER SECTION: > > www.yahoo.com. 300 IN CNAME www.wa1.b.yahoo.com. > > > > ;; AUTHORITY SECTION: > > wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. > > wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. > > > > ;; ADDITIONAL SECTION: > > yf1.yahoo.com. 1800 IN A 68.142.254.15 > > yf2.yahoo.com. 1800 IN A 68.180.130.15 > > > > ;; Query time: 15 msec > > ;; SERVER: 68.180.131.16#53(68.180.131.16) > > ;; WHEN: Wed Dec 3 15:34:09 2008 > > ;; MSG SIZE rcvd: 123 > > > > > > but looking up the host itself gives no answer > > > > > > $ dig @ns1.yahoo.com www.wa1.b.yahoo.com > > > > ; <<>> DiG 9.4.2 <<>> @ns1.yahoo.com www.wa1.b.yahoo.com > > ; (1 server found) > > ;; global options: printcmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34875 > > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 > > ;; WARNING: recursion requested but not available > > > > ;; QUESTION SECTION: > > ;www.wa1.b.yahoo.com. IN A > > > > ;; AUTHORITY SECTION: > > wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. > > wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. > > > > ;; ADDITIONAL SECTION: > > yf1.yahoo.com. 1800 IN A 68.142.254.15 > > yf2.yahoo.com. 1800 IN A 68.180.130.15 > > > > ;; Query time: 15 msec > > ;; SERVER: 68.180.131.16#53(68.180.131.16) > > ;; WHEN: Wed Dec 3 15:35:07 2008 > > ;; MSG SIZE rcvd: 105 > > > > > > > > !DSPAM:22,4936edf127844578318734! > > > > > > -- > Nathan Ward > > > > > > > > > > > ---------------------------------------------------------------------------- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." > > From list-only at dnz.se Wed Dec 3 16:14:23 2008 From: list-only at dnz.se (=?ISO-8859-1?Q?Anders_Lindb=E4ck?=) Date: Wed, 3 Dec 2008 23:14:23 +0100 Subject: Recommendation of Tools In-Reply-To: References: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> <943AC9CD-ABC3-406D-9799-E1B3664A3123@dnz.se> Message-ID: <8EEE1F49-FC4B-49CF-878C-87D2CD967832@dnz.se> Well, to be somewhat cynical about it, you don't. Either you have an SLA with a delay component, if that is the case the delay is either end-to-end if everything is in the same AS, or host-to-border if the other end is in some other AS. If this is the case you would already have an agreed upon measuretool (ex. SLA probes) and specified measuring points. If you dont have a specified delay clause in your SLA then it is best effort and irrelevant, in either case the hop by hop delay seen is academic at best.. So as long as your delay is lower then specified by the SLA the only result from trying to be "smart" and complaining about large hop to hop delay is that the engineer you talk to will call you names after he/she hangs up, or if it is over it is still very little/nothing you can do but wait and let the carrier engineers fix it. ------------------------------ Anders Lindb?ck anders.lindback at dnz.se On 3 dec 2008, at 20.56, Braun, Mike wrote: > If the question is to measure hop by hop latency from source to > destination, perhaps across routers you don't manage, how can this > be done without using the ICMP time exceeded messages? End to end > latency is easily done with Smokeping and the use of TCP (SYN, SYN > ACK, ACK, RST) and them timestamp it. This gives you a very clear > idea on application latency on any tcp port. Hop by hop is a > different story and the only option I know of is with the reliance > on the ICMP mechanism. One additional question on this; how do you > measure hop by hop when the path dynamically changes, and then > record the path change (time/date and the differences in latency on > the new path)? > > Mike > > -----Original Message----- > From: Anders Lindb?ck [mailto:list-only at dnz.se] > Sent: Wednesday, December 03, 2008 10:02 AM > To: Pekka Savola > Cc: nanog at nanog.org > Subject: Re: Recommendation of Tools > > Mtr is even less usefull then that, in its default mode it does a > traceroute and then proceeds to ICMP Ping flood each IP in the list > generated by the traceroute, the result is usually completly useless > on WAN topologies due to asym-routing, ICMP node protections by > carriers and punting etc.. > > And using UDP will not really provide better results due to the same > thing, and IIRC Cisco from 12.0 has a standard setting of no more > then 1 ICMP Unreach per 500ms.. > > ------------------------------ > Anders Lindb?ck > anders.lindback at dnz.se > > > On 3 dec 2008, at 12.00, Pekka Savola wrote: > >> On Tue, 2 Dec 2008, Antonio Querubin wrote: >>> On Wed, 3 Dec 2008, Pekka Savola wrote: >>>> FWIW, Mtr measures latency/delay and loss based on ICMP messages >>>> heard >>>> back from the routers on path. As a result, in almost all >>>> cases, the real >>>> hop-by-hop latency of actual end-to-end data packets is better >>>> than it can >>>> report. >>> >>> mtr has a recently added '-u' option to use UDP instead of ICMP >>> echo requests. >> >> But that doesn't change the gist of my message: it's still relying >> on ICMP ttl exceeded messages sent by the routers on the path to >> check the delays etc. As such it suffers from basically the same >> limitations as ICMP probing. >> >> -- >> Pekka Savola "You each name yourselves king, yet the >> Netcore Oy kingdom bleeds." >> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >> > > > -- > > THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE > INTENDED SOLELY FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY > CONTAIN CONFIDENTIAL, PROPRIETARY OR PRIVILEGED INFORMATION. IF > YOU ARE NOT THE ADDRESSEE INDICATED IN THIS MESSAGE (OR RESPONSIBLE > FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, > USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FILES TRANSMITTED > HEREWITH. IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CONTACT THE > SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF IT > FROM YOUR SYSTEM. > From andre at operations.net Wed Dec 3 16:34:33 2008 From: andre at operations.net (Andre Gironda) Date: Wed, 3 Dec 2008 15:34:33 -0700 Subject: Recommendation of Tools In-Reply-To: <943AC9CD-ABC3-406D-9799-E1B3664A3123@dnz.se> References: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> <943AC9CD-ABC3-406D-9799-E1B3664A3123@dnz.se> Message-ID: <2fd9390e0812031434v7a1a1fd4n845e1d645ad384e4@mail.gmail.com> On Wed, Dec 3, 2008 at 11:01 AM, Anders Lindb?ck wrote: > And using UDP will not really provide better results due to the same thing, > and IIRC Cisco from 12.0 has a standard setting of no more then 1 ICMP > Unreach per 500ms.. then connect to a udp service with something like nsping From garmitage at swin.edu.au Wed Dec 3 16:40:14 2008 From: garmitage at swin.edu.au (grenville armitage) Date: Thu, 04 Dec 2008 09:40:14 +1100 Subject: Recommendation of Tools In-Reply-To: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> References: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> Message-ID: <49370ACE.50302@swin.edu.au> Lee, Steven (NSG Malaysia) wrote: > Hi all, do you have any recommended tools that can measure latency/delay hop by hop basis? Preferable the tools can measure the running (live) traffic. > > Regards, > Steven Lee Not necessarily hop-by-hop, and measures RTT rather than one-way delay, but if you can packet-sniff at two points in your network our SPP (Synthetic Packet Pairs) tool for passive round trip time estimation might be of interest - http://caia.swin.edu.au/tools/spp/documentation.html Key benefits - you don't need tight clock synchronisation between measurement points, and you can measure RTT using existing traffic flowing across your network (no additional traffic needs to be injected). Key downside - its a research project, only tested under FreeBSD, and may be entirely unsuitable :) cheers, gja From nick at foobar.org Wed Dec 3 16:54:08 2008 From: nick at foobar.org (Nick Hilliard) Date: Wed, 03 Dec 2008 22:54:08 +0000 Subject: Recommendation of Tools In-Reply-To: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> References: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> Message-ID: <49370E10.2040901@foobar.org> Lee, Steven (NSG Malaysia) wrote: > Hi all, do you have any recommended tools that can measure latency/delay > hop by hop basis? Preferable the tools can measure the running (live) > traffic. Tools like smokeping, mtr, traceroute and all that will give you highly skewed results, whose accuracy will usually depend entirely on how busy the CPU is which responds to host IP packets (whether icmp, udp or even tcp). As most large routers push everything through hardware, if you measure your hop latency using inline router response times, your results will be trash. If you want to do this properly, you will need to install dedicated measurement hosts hanging off each router and measure response times to them instead. RIPE TTM boxes are pretty good for this: http://www.ripe.net/ttm/ Nick From Skywing at valhallalegends.com Wed Dec 3 17:10:36 2008 From: Skywing at valhallalegends.com (Skywing) Date: Wed, 3 Dec 2008 17:10:36 -0600 Subject: Recommendation of Tools Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BEF937A2CA@caralain.haven.nynaeve.net> The problem is return path ICMP time exceeded from intermediate hops, and not the response from the final destination. ? S -----Original Message----- From: Andre Gironda Sent: Wednesday, December 03, 2008 16:35 To: nanog at nanog.org Subject: Re: Recommendation of Tools On Wed, Dec 3, 2008 at 11:01 AM, Anders Lindb?ck wrote: > And using UDP will not really provide better results due to the same thing, > and IIRC Cisco from 12.0 has a standard setting of no more then 1 ICMP > Unreach per 500ms.. then connect to a udp service with something like nsping From andre at operations.net Wed Dec 3 17:11:40 2008 From: andre at operations.net (Andre Gironda) Date: Wed, 3 Dec 2008 16:11:40 -0700 Subject: Recommendation of Tools In-Reply-To: <49370E10.2040901@foobar.org> References: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> <49370E10.2040901@foobar.org> Message-ID: <2fd9390e0812031511i69927a3dnc66045166a6d590a@mail.gmail.com> On Wed, Dec 3, 2008 at 3:54 PM, Nick Hilliard wrote: > If you want to do this properly, you will need to install dedicated > measurement hosts hanging off each router and measure response times to > them instead. RIPE TTM boxes are pretty good for this: > http://www.ripe.net/ttm/ tcptrace.org is also passive From tony at lava.net Wed Dec 3 18:56:15 2008 From: tony at lava.net (Antonio Querubin) Date: Wed, 3 Dec 2008 14:56:15 -1000 (HST) Subject: Recommendation of Tools In-Reply-To: <49370ACE.50302@swin.edu.au> References: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> <49370ACE.50302@swin.edu.au> Message-ID: Lee, Steven (NSG Malaysia) wrote: > Hi all, do you have any recommended tools that can measure latency/delay > hop by hop basis? Preferable the tools can measure the running (live) > traffic. One other freeware/open-source tool you might want to look at is pchar which attempts to characterize available bandwidth on each link. Antonio Querubin whois: AQ7-ARIN From marc at let.de Wed Dec 3 19:10:11 2008 From: marc at let.de (Marc Manthey) Date: Thu, 4 Dec 2008 02:10:11 +0100 Subject: Recommendation of Tools In-Reply-To: References: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> <49370ACE.50302@swin.edu.au> Message-ID: <792C540D-070B-4BB3-BDF2-CD0FB25ABD37@let.de> Am 04.12.2008 um 01:56 schrieb Antonio Querubin: > Lee, Steven (NSG Malaysia) wrote: >> Hi all, do you have any recommended tools that can measure latency/ >> delay hop by hop basis? Preferable the tools can measure the >> running (live) traffic. > > One other freeware/open-source tool you might want to look at is > pchar which attempts to characterize available bandwidth on each link. intersting never heard of ;) -- pchar sends probe packets into the network of varying sizes and analyzes ICMP messages produced by intermediate routers, or by the target host. By measuring the response time for packets of different sizes, pchar can estimate the bandwidth and fixed round-trip delay along the path. pchar varies the TTL of the outgoing packets to get responses from different intermediate routers. It can use UDP or ICMP packets as probes; either or both might be useful in different situations. http://www.kitchenlab.org/www/bmah/Software/pchar/README -- thanks !!! -- Marc Manthey 50672 K?ln - Germany Hildeboldplatz 1a Tel.:0049-221-3558032 Mobil:0049-1577-3329231 mail: marc at let.de PGP/GnuPG: 0x1ac02f3296b12b4d jabber :marc at kgraff.net IRC: #opencu freenode.net twitter: http://twitter.com/macbroadcast web: http://www.let.de Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. From hank at efes.iucc.ac.il Wed Dec 3 23:58:51 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 04 Dec 2008 07:58:51 +0200 Subject: Yahoo DNS broken? In-Reply-To: <20081203154735.R45081@gecko.reptiles.org> References: <8C9EEC938968834395746CB30847EAF11A9E31@iserve-exchg.iservetech.local> Message-ID: <5.1.0.14.2.20081204075504.00b27410@efes.iucc.ac.il> At 03:47 PM 03-12-08 -0500, Cat Okita wrote: Can someone from Akamai report as to what happened? I did not see any notice on EdgeControl but I did get email from my auto-alerts set up at Akamai as follows: ------------------------------- NAME: DNS failure TYPE: Origin DNS Failure SERVICE: HTTP Content Delivery START TIME: Wed, Dec 3, 12:42 GMT 2008 STOP TIME: Wed, Dec 3, 12:50 GMT 2008 DATA: CP Code: 32023 CP Code Description: WAA Hits: 53 Errors: 5 Alert Condition (% Errors): 8 Alert Threshold: 1 Edge IP: 0.0.0.0 DESCRIPTION: The Origin DNS Failure Alert indicates errors when Akamai edge servers are unable to reach the origin server because they're unable to resolve the DNS name. -------------------------------- So I'm curious as to what happened. Thanks, Hank >Looks like some of akamai's nameservers have misplaced themselves and yahoo. > >cheers! > >On Thu, 4 Dec 2008, Nathan Ward wrote: >>There is no A records, correct. >>There is a CNAME though: >>www.wa1.b.yahoo.com. 45 IN CNAME www-real.wa1.b.yahoo.com. >>www-real.wa1.b.yahoo.com. 45 IN A 209.131.36.158 >> >>On 4/12/2008, at 9:36 AM, Larry Daberko wrote: >> >>>I am unable to resolve www.yahoo.com. Tracing DNS back from the root >>>servers shows that www.yahoo.com is a CNAME to www.wa1.b.yahoo.com and >>>there are no A records for that hostname. >>>Anyone have more details or a Yahoo contact? I'm unable to get to their >>>webpage as it is :-) >>>-Larry Daberko >>>iServe Technologies From mmc at internode.com.au Thu Dec 4 00:47:34 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Thu, 4 Dec 2008 17:17:34 +1030 Subject: an over-the-top data center In-Reply-To: References: <20081128083433.0e18c7e2@cs.columbia.edu> <1944.76.118.12.107.1227929030.squirrel@webmail6.pair.com> Message-ID: <012ECC45-CCF1-4213-B9C1-E301B79CD8E5@internode.com.au> Gadi, I can't help that you need a few nights away in a lovely Swiss Hotel in order to help those cynical thoughts lift: http://www.news.com.au/travel/story/0,28318,24732642-5014090,00.html :-) MMC On 29/11/2008, at 2:05 PM, Gadi Evron wrote: > On Fri, 28 Nov 2008, Howard C. Berkowitz wrote: >>> >> It seems that all these cases are more under the bottom than over >> the top. >> > > Every couple of years there is a story about some anti virus > company, data center, or whatever running out of an old nuclear > bunker/military base/middle of no where. It is exciting the first > few times. > > Gadi. > -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks From fergdawgster at gmail.com Thu Dec 4 00:59:00 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 3 Dec 2008 22:59:00 -0800 Subject: Telecom Collapse? Message-ID: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I deliberated for a while on whether to send this, or not, but I figure it might be of interest to this community: http://techliberation.com/2008/12/04/telecom-collapse/ - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJN3+vq1pz9mNUZTMRApD5AKCQZPe5Nctn2OkE4kVWiZ7y7rJ4qwCgsQn6 nCNVbqAfPfALdEtbU2p1fg0= =/pUF -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From alex at corp.nac.net Thu Dec 4 01:06:45 2008 From: alex at corp.nac.net (Alex Rubenstein) Date: Thu, 4 Dec 2008 02:06:45 -0500 Subject: Telecom Collapse? In-Reply-To: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> Message-ID: > I deliberated for a while on whether to send this, or not, but I figure > it might be of interest to this community: > > http://techliberation.com/2008/12/04/telecom-collapse/ Good god. If there is even the mention of a LEC bailout, I am going to go insane and probably shoot someone (those who know me know this is a actual possibility). If the phone companies had actually focused on providing good, competitive service, this would have never happened. Instead, they spent money and time on figuring out ways to screw with their competition, and have legislation passed that protects them. People (at least the ones I know) are fed up with dealing with these companies, and many people I know don't have land lines and never intend on having them again. Let them collapse. It's good for them, us, and the capitalist in you and me. Go buy a cell phone, and have a coke. From mike.lyon at gmail.com Thu Dec 4 01:10:57 2008 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 3 Dec 2008 23:10:57 -0800 Subject: Telecom Collapse? In-Reply-To: References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> Message-ID: <1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> That makes two of us... Anyways, for residential VOIP, where are we these days with E911? Are providers like Vonage and such providing reliable E911 when people call 911? That is one of the major problems I see with the residential realm going with VOIP offerings... -Mike On Wed, Dec 3, 2008 at 11:06 PM, Alex Rubenstein wrote: > >> I deliberated for a while on whether to send this, or not, but I figure >> it might be of interest to this community: >> >> http://techliberation.com/2008/12/04/telecom-collapse/ > > Good god. If there is even the mention of a LEC bailout, I am going to go insane and probably shoot someone (those who know me know this is a actual possibility). > > If the phone companies had actually focused on providing good, competitive service, this would have never happened. Instead, they spent money and time on figuring out ways to screw with their competition, and have legislation passed that protects them. > > People (at least the ones I know) are fed up with dealing with these companies, and many people I know don't have land lines and never intend on having them again. > > Let them collapse. It's good for them, us, and the capitalist in you and me. Go buy a cell phone, and have a coke. > > > > From jgreco at ns.sol.net Thu Dec 4 06:19:59 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 4 Dec 2008 06:19:59 -0600 (CST) Subject: an over-the-top data center In-Reply-To: <012ECC45-CCF1-4213-B9C1-E301B79CD8E5@internode.com.au> from "Matthew Moyle-Croft" at Dec 04, 2008 05:17:34 PM Message-ID: <200812041219.mB4CJxUP054722@aurora.sol.net> > Gadi, > I can't help that you need a few nights away in a lovely Swiss Hotel > in order to help those cynical thoughts lift: > > http://www.news.com.au/travel/story/0,28318,24732642-5014090,00.html That looks too noisy. This seems to be a little more upscale. http://www.budgettravel.com/bt-srv/gallery/0803_WeirdestHotels/index.html?jumpToPic=2 Interesting places: http://www.budgettravel.com/bt-dyn/content/article/2008/02/19/AR2008021901535.html So, an interesting question to contemplate. Apparently some hotels have figured out different angles. Is there a point at which business will start looking at other models for hosting purposes? We already have cloud computing, fe. With data center prices skyrocketing, it would seem that there might be some advantages, at least in some cases, to looking at alternatives. I know that we find our Equinix rack space very expensive, and that some of the things we do just aren't worth $50/month/RU or whatever it is we're paying. Putting low bandwidth, less critical resources elsewhere seems to be a generally good idea. What workable options exist? We have some clients that have always maintained their own small server rooms on-site and never gave up on bringing in bandwidth on T1 or whatever, and this strategy seems to have worked out for them in the long run, as they've kept resources on- site. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From rlahti at glcom.net Thu Dec 4 06:47:03 2008 From: rlahti at glcom.net (Russell J. Lahti) Date: Thu, 4 Dec 2008 07:47:03 -0500 Subject: Telecom Collapse? In-Reply-To: <1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> Message-ID: That is the one and only thing keeping a land line at my home. I have two young children, and I need to be sure that if something were to ever happen that: 1.) The phone would work even if the power was out, or the Internet connectivity was flaking out. 2.) 911 would function exactly the way it is supposed to, and not be routed to some 3rd party call center which could potentially delay a response. I haven't found the power to be reliable, and the cable Internet tends to go down when the power goes out. There's always cellular, but then you have to depend on there being someone with a cell phone around to make the call, and my kids aren't to the age yet that I would want them toting around their own cell phones. As long as my POTS line is more reliable than VoIP, I'll probably keep it. -Russell > -----Original Message----- > From: Mike Lyon [mailto:mike.lyon at gmail.com] > Sent: Thursday, December 04, 2008 2:11 AM > To: Alex Rubenstein > Cc: nanog at nanog.org > Subject: Re: Telecom Collapse? > > That makes two of us... > > Anyways, for residential VOIP, where are we these days with > E911? Are providers like Vonage and such providing reliable > E911 when people call 911? That is one of the major problems > I see with the residential realm going with VOIP offerings... > > -Mike > > > On Wed, Dec 3, 2008 at 11:06 PM, Alex Rubenstein > wrote: > > > >> I deliberated for a while on whether to send this, or not, but I > >> figure it might be of interest to this community: > >> > >> http://techliberation.com/2008/12/04/telecom-collapse/ > > > > Good god. If there is even the mention of a LEC bailout, I > am going to go insane and probably shoot someone (those who > know me know this is a actual possibility). > > > > If the phone companies had actually focused on providing > good, competitive service, this would have never happened. > Instead, they spent money and time on figuring out ways to > screw with their competition, and have legislation passed > that protects them. > > > > People (at least the ones I know) are fed up with dealing > with these companies, and many people I know don't have land > lines and never intend on having them again. > > > > Let them collapse. It's good for them, us, and the > capitalist in you and me. Go buy a cell phone, and have a coke. > > > > > > > > > > From tme at multicasttech.com Thu Dec 4 06:55:48 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 4 Dec 2008 07:55:48 -0500 Subject: Telecom Collapse? In-Reply-To: References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> Message-ID: <5556F486-E3E6-4A38-90D9-819839C8AA16@multicasttech.com> On Dec 4, 2008, at 7:47 AM, Russell J. Lahti wrote: > That is the one and only thing keeping a land line at my home. I > have two young children, and I need to be sure that if something > were to ever happen that: 1.) The phone would work even if the > power was out, or the Internet connectivity was flaking out. > 2.) 911 would function exactly the way it is supposed to, and > not be routed to some 3rd party call center which could potentially > delay a response. > > I haven't found the power to be reliable, and the cable Internet > tends to go down when the power goes out. There's always cellular, > but then you have to depend on there being someone with a cell phone Also, where I live, if the power goes out hard (for example, during the last Hurricane), the cell phone will not have service either. Regards Marshall > > around to make the call, and my kids aren't to the age yet that I > would want them toting around their own cell phones. As long as > my POTS line is more reliable than VoIP, I'll probably keep it. > > -Russell > > > >> -----Original Message----- >> From: Mike Lyon [mailto:mike.lyon at gmail.com] >> Sent: Thursday, December 04, 2008 2:11 AM >> To: Alex Rubenstein >> Cc: nanog at nanog.org >> Subject: Re: Telecom Collapse? >> >> That makes two of us... >> >> Anyways, for residential VOIP, where are we these days with >> E911? Are providers like Vonage and such providing reliable >> E911 when people call 911? That is one of the major problems >> I see with the residential realm going with VOIP offerings... >> >> -Mike >> >> >> On Wed, Dec 3, 2008 at 11:06 PM, Alex Rubenstein >> wrote: >>> >>>> I deliberated for a while on whether to send this, or not, but I >>>> figure it might be of interest to this community: >>>> >>>> http://techliberation.com/2008/12/04/telecom-collapse/ >>> >>> Good god. If there is even the mention of a LEC bailout, I >> am going to go insane and probably shoot someone (those who >> know me know this is a actual possibility). >>> >>> If the phone companies had actually focused on providing >> good, competitive service, this would have never happened. >> Instead, they spent money and time on figuring out ways to >> screw with their competition, and have legislation passed >> that protects them. >>> >>> People (at least the ones I know) are fed up with dealing >> with these companies, and many people I know don't have land >> lines and never intend on having them again. >>> >>> Let them collapse. It's good for them, us, and the >> capitalist in you and me. Go buy a cell phone, and have a coke. >>> >>> >>> >>> >> >> > > From pekkas at netcore.fi Thu Dec 4 07:05:50 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 4 Dec 2008 15:05:50 +0200 (EET) Subject: Recommendation of Tools In-Reply-To: <943AC9CD-ABC3-406D-9799-E1B3664A3123@dnz.se> References: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> <943AC9CD-ABC3-406D-9799-E1B3664A3123@dnz.se> Message-ID: On Wed, 3 Dec 2008, Anders Lindb?ck wrote: > Mtr is even less usefull then that, in its default mode it does a traceroute > and then proceeds to ICMP Ping flood each IP in the list generated by the > traceroute, the result is usually completly useless on WAN topologies due to > asym-routing, ICMP node protections by carriers and punting etc.. No, it doesn't try pinging the routers in the middle, at least not anymore (I just re-checked with 0.71 and 0.75). I vaguely recall behaviour like that in the past, however, so it's possible that long time ago mtr did behave that way. > And using UDP will not really provide better results due to the same thing, > and IIRC Cisco from 12.0 has a standard setting of no more then 1 ICMP > Unreach per 500ms.. This is true and the point I was getting at, though I believe the bucket is much larger in any recent software release (also in 12.0 series). Actually, 5 years ago, you could see spot Cisco routers in "traceroute6" because they dropped the rate-limiter didn't respond to the middle packet and it resulted in a star. The rate-limiter has long since been fixed to be more lenient. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jerj at coplanar.net Thu Dec 4 08:22:18 2008 From: jerj at coplanar.net (Jeremy Jackson) Date: Thu, 04 Dec 2008 09:22:18 -0500 Subject: VoIP E911 - was: Telecom Collapse? In-Reply-To: <1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> Message-ID: <1228400538.7244.17.camel@ragnarok> With one provider in Canada at least, the E911 address to phone number registration is a large bureaucratic manual process, likely involving fax machines. Meanwhile, the ILEC presumably has an address in a database for the loop... So, I wonder about more direct access to PSAPs by CLEC, anywhere from dark fibre to database API? On Wed, 2008-12-03 at 23:10 -0800, Mike Lyon wrote: > That makes two of us... > > Anyways, for residential VOIP, where are we these days with E911? Are > providers like Vonage and such providing reliable E911 when people > call 911? That is one of the major problems I see with the residential > realm going with VOIP offerings... > > -Mike -- Jeremy Jackson Coplanar Networks (519)489-4903 http://www.coplanar.net jerj at coplanar.net From cchurc05 at harris.com Thu Dec 4 08:44:23 2008 From: cchurc05 at harris.com (Church, Charles) Date: Thu, 4 Dec 2008 08:44:23 -0600 Subject: Telecom Collapse? In-Reply-To: References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com><1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> Message-ID: In the past, an inactive cell phone could still dial 911. I'm not sure if that's still the case, but it used to be, at least with some carriers. Chuck -----Original Message----- From: Russell J. Lahti [mailto:rlahti at glcom.net] Sent: Thursday, December 04, 2008 7:47 AM To: 'Mike Lyon'; 'Alex Rubenstein' Cc: nanog at nanog.org Subject: RE: Telecom Collapse? That is the one and only thing keeping a land line at my home. I have two young children, and I need to be sure that if something were to ever happen that: 1.) The phone would work even if the power was out, or the Internet connectivity was flaking out. 2.) 911 would function exactly the way it is supposed to, and not be routed to some 3rd party call center which could potentially delay a response. I haven't found the power to be reliable, and the cable Internet tends to go down when the power goes out. There's always cellular, but then you have to depend on there being someone with a cell phone around to make the call, and my kids aren't to the age yet that I would want them toting around their own cell phones. As long as my POTS line is more reliable than VoIP, I'll probably keep it. -Russell > -----Original Message----- > From: Mike Lyon [mailto:mike.lyon at gmail.com] > Sent: Thursday, December 04, 2008 2:11 AM > To: Alex Rubenstein > Cc: nanog at nanog.org > Subject: Re: Telecom Collapse? > > That makes two of us... > > Anyways, for residential VOIP, where are we these days with > E911? Are providers like Vonage and such providing reliable > E911 when people call 911? That is one of the major problems > I see with the residential realm going with VOIP offerings... > > -Mike > > > On Wed, Dec 3, 2008 at 11:06 PM, Alex Rubenstein > wrote: > > > >> I deliberated for a while on whether to send this, or not, but I > >> figure it might be of interest to this community: > >> > >> http://techliberation.com/2008/12/04/telecom-collapse/ > > > > Good god. If there is even the mention of a LEC bailout, I > am going to go insane and probably shoot someone (those who > know me know this is a actual possibility). > > > > If the phone companies had actually focused on providing > good, competitive service, this would have never happened. > Instead, they spent money and time on figuring out ways to > screw with their competition, and have legislation passed > that protects them. > > > > People (at least the ones I know) are fed up with dealing > with these companies, and many people I know don't have land > lines and never intend on having them again. > > > > Let them collapse. It's good for them, us, and the > capitalist in you and me. Go buy a cell phone, and have a coke. > > > > > > > > > > From joshpotter at gmail.com Thu Dec 4 08:47:25 2008 From: joshpotter at gmail.com (Josh Potter) Date: Thu, 4 Dec 2008 08:47:25 -0600 Subject: Telecom Collapse? In-Reply-To: References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> Message-ID: <4a64e2f70812040647l426ddcafie295a02d6fa2a61f@mail.gmail.com> I believe there is a law that requires just that, even if you don't have an active service plan the phone must still be able to access 911. Josh On Thu, Dec 4, 2008 at 8:44 AM, Church, Charles wrote: > In the past, an inactive cell phone could still dial 911. I'm not sure > if that's still the case, but it used to be, at least with some > carriers. > > > Chuck > > -----Original Message----- > From: Russell J. Lahti [mailto:rlahti at glcom.net] > Sent: Thursday, December 04, 2008 7:47 AM > To: 'Mike Lyon'; 'Alex Rubenstein' > Cc: nanog at nanog.org > Subject: RE: Telecom Collapse? > > > That is the one and only thing keeping a land line at my home. I > have two young children, and I need to be sure that if something > were to ever happen that: 1.) The phone would work even if the > power was out, or the Internet connectivity was flaking out. > 2.) 911 would function exactly the way it is supposed to, and > not be routed to some 3rd party call center which could potentially > delay a response. > > I haven't found the power to be reliable, and the cable Internet > tends to go down when the power goes out. There's always cellular, > but then you have to depend on there being someone with a cell phone > around to make the call, and my kids aren't to the age yet that I > would want them toting around their own cell phones. As long as > my POTS line is more reliable than VoIP, I'll probably keep it. > > -Russell > > > > > -----Original Message----- > > From: Mike Lyon [mailto:mike.lyon at gmail.com] > > Sent: Thursday, December 04, 2008 2:11 AM > > To: Alex Rubenstein > > Cc: nanog at nanog.org > > Subject: Re: Telecom Collapse? > > > > That makes two of us... > > > > Anyways, for residential VOIP, where are we these days with > > E911? Are providers like Vonage and such providing reliable > > E911 when people call 911? That is one of the major problems > > I see with the residential realm going with VOIP offerings... > > > > -Mike > > > > > > On Wed, Dec 3, 2008 at 11:06 PM, Alex Rubenstein > > wrote: > > > > > >> I deliberated for a while on whether to send this, or not, but I > > >> figure it might be of interest to this community: > > >> > > >> http://techliberation.com/2008/12/04/telecom-collapse/ > > > > > > Good god. If there is even the mention of a LEC bailout, I > > am going to go insane and probably shoot someone (those who > > know me know this is a actual possibility). > > > > > > If the phone companies had actually focused on providing > > good, competitive service, this would have never happened. > > Instead, they spent money and time on figuring out ways to > > screw with their competition, and have legislation passed > > that protects them. > > > > > > People (at least the ones I know) are fed up with dealing > > with these companies, and many people I know don't have land > > lines and never intend on having them again. > > > > > > Let them collapse. It's good for them, us, and the > > capitalist in you and me. Go buy a cell phone, and have a coke. > > > > > > > > > > > > > > > > > > > > -- Josh Potter From cmadams at hiwaay.net Thu Dec 4 08:48:27 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 4 Dec 2008 08:48:27 -0600 Subject: Telecom Collapse? In-Reply-To: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> Message-ID: <20081204144827.GA827386@hiwaay.net> Once upon a time, Paul Ferguson said: > I deliberated for a while on whether to send this, or not, but I figure it > might be of interest to this community: > > http://techliberation.com/2008/12/04/telecom-collapse/ One thing doesn't make sense in that article: it talks about POTS being subsidized by other services, and people cutting POTS lines. Wouldn't that be _good_ for the companies and their other services? The way the article describes things, fewer POTS lines = smaller subsidies taken from other services = better profits for other services and the company. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From bpfankuch at cpgreeley.com Thu Dec 4 08:53:15 2008 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Thu, 4 Dec 2008 07:53:15 -0700 Subject: VoIP E911 - was: Telecom Collapse? In-Reply-To: <1228400538.7244.17.camel@ragnarok> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> <1228400538.7244.17.camel@ragnarok> Message-ID: <01759D50DC387C45A018FE1817CE27D7540379FC76@CPExchange1.cpgreeley.com> I would agree on that, my voip setup at my house took several faxes back and forth to the provider to get it working right. Then it took a week for the 911 dispatch center to actually see my address as correct when I placed test calls. -----Original Message----- From: Jeremy Jackson [mailto:jerj at coplanar.net] Sent: Thursday, December 04, 2008 7:22 AM To: Mike Lyon Cc: nanog at nanog.org Subject: VoIP E911 - was: Telecom Collapse? With one provider in Canada at least, the E911 address to phone number registration is a large bureaucratic manual process, likely involving fax machines. Meanwhile, the ILEC presumably has an address in a database for the loop... So, I wonder about more direct access to PSAPs by CLEC, anywhere from dark fibre to database API? On Wed, 2008-12-03 at 23:10 -0800, Mike Lyon wrote: > That makes two of us... > > Anyways, for residential VOIP, where are we these days with E911? Are > providers like Vonage and such providing reliable E911 when people > call 911? That is one of the major problems I see with the residential > realm going with VOIP offerings... > > -Mike -- Jeremy Jackson Coplanar Networks (519)489-4903 http://www.coplanar.net jerj at coplanar.net From hescominsoon at emmanuelcomputerconsulting.com Thu Dec 4 09:01:54 2008 From: hescominsoon at emmanuelcomputerconsulting.com (William Warren) Date: Thu, 04 Dec 2008 10:01:54 -0500 Subject: Telecom Collapse? In-Reply-To: <20081204144827.GA827386@hiwaay.net> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <20081204144827.GA827386@hiwaay.net> Message-ID: <4937F0E2.6020906@emmanuelcomputerconsulting.com> Chris Adams wrote: > Once upon a time, Paul Ferguson said: > >> I deliberated for a while on whether to send this, or not, but I figure it >> might be of interest to this community: >> >> http://techliberation.com/2008/12/04/telecom-collapse/ >> > > One thing doesn't make sense in that article: it talks about POTS being > subsidized by other services, and people cutting POTS lines. Wouldn't > that be _good_ for the companies and their other services? The way the > article describes things, fewer POTS lines = smaller subsidies taken > from other services = better profits for other services and the company. > > the lines are still there and still require maintenance so they loose money on it. From tomb at byrneit.net Thu Dec 4 09:15:00 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Thu, 4 Dec 2008 07:15:00 -0800 Subject: Telecom Collapse? In-Reply-To: <5556F486-E3E6-4A38-90D9-819839C8AA16@multicasttech.com> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com><1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> <5556F486-E3E6-4A38-90D9-819839C8AA16@multicasttech.com> Message-ID: <70D072392E56884193E3D2DE09C097A9FA8D@pascal.zaphodb.org> A Marine VHF works under almost any circumstances, and anywhere coastal in the world. You can almost always reach the Coast Guard. >-----Original Message----- >From: Marshall Eubanks [mailto:tme at multicasttech.com] >Sent: Thursday, December 04, 2008 4:56 AM >To: Russell J. Lahti >Cc: nanog at nanog.org; 'Alex Rubenstein' >Subject: Re: Telecom Collapse? > > >On Dec 4, 2008, at 7:47 AM, Russell J. Lahti wrote: > >> That is the one and only thing keeping a land line at my home. I >> have two young children, and I need to be sure that if something >> were to ever happen that: 1.) The phone would work even if the >> power was out, or the Internet connectivity was flaking out. >> 2.) 911 would function exactly the way it is supposed to, and >> not be routed to some 3rd party call center which could potentially >> delay a response. >> >> I haven't found the power to be reliable, and the cable Internet >> tends to go down when the power goes out. There's always cellular, >> but then you have to depend on there being someone with a cell phone > >Also, where I live, if the power goes out hard (for example, during >the last Hurricane), >the cell phone will not have service either. > >Regards >Marshall > >> >> around to make the call, and my kids aren't to the age yet that I >> would want them toting around their own cell phones. As long as >> my POTS line is more reliable than VoIP, I'll probably keep it. >> >> -Russell >> >> >> >>> -----Original Message----- >>> From: Mike Lyon [mailto:mike.lyon at gmail.com] >>> Sent: Thursday, December 04, 2008 2:11 AM >>> To: Alex Rubenstein >>> Cc: nanog at nanog.org >>> Subject: Re: Telecom Collapse? >>> >>> That makes two of us... >>> >>> Anyways, for residential VOIP, where are we these days with >>> E911? Are providers like Vonage and such providing reliable >>> E911 when people call 911? That is one of the major problems >>> I see with the residential realm going with VOIP offerings... >>> >>> -Mike >>> >>> >>> On Wed, Dec 3, 2008 at 11:06 PM, Alex Rubenstein >>> wrote: >>>> >>>>> I deliberated for a while on whether to send this, or not, but I >>>>> figure it might be of interest to this community: >>>>> >>>>> http://techliberation.com/2008/12/04/telecom-collapse/ >>>> >>>> Good god. If there is even the mention of a LEC bailout, I >>> am going to go insane and probably shoot someone (those who >>> know me know this is a actual possibility). >>>> >>>> If the phone companies had actually focused on providing >>> good, competitive service, this would have never happened. >>> Instead, they spent money and time on figuring out ways to >>> screw with their competition, and have legislation passed >>> that protects them. >>>> >>>> People (at least the ones I know) are fed up with dealing >>> with these companies, and many people I know don't have land >>> lines and never intend on having them again. >>>> >>>> Let them collapse. It's good for them, us, and the >>> capitalist in you and me. Go buy a cell phone, and have a coke. >>>> >>>> >>>> >>>> >>> >>> >> >> > From tomb at byrneit.net Thu Dec 4 09:17:01 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Thu, 4 Dec 2008 07:17:01 -0800 Subject: Telecom Collapse? In-Reply-To: <4937F0E2.6020906@emmanuelcomputerconsulting.com> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com><20081204144827.GA827386@hiwaay.net> <4937F0E2.6020906@emmanuelcomputerconsulting.com> Message-ID: <70D072392E56884193E3D2DE09C097A9FA8E@pascal.zaphodb.org> If they had made any decent investment in plant, or had not run the DSL CLECs out of business, they could make money on DSL and Video services, or by leasing the unused copper. There's no sympathy for companies that have been nothing more than obstacles to progress. >-----Original Message----- >From: William Warren >[mailto:hescominsoon at emmanuelcomputerconsulting.com] >Sent: Thursday, December 04, 2008 7:02 AM >To: nanog at nanog.org >Subject: Re: Telecom Collapse? > >Chris Adams wrote: >> Once upon a time, Paul Ferguson said: >> >>> I deliberated for a while on whether to send this, or not, but I >figure it >>> might be of interest to this community: >>> >>> http://techliberation.com/2008/12/04/telecom-collapse/ >>> >> >> One thing doesn't make sense in that article: it talks about POTS >being >> subsidized by other services, and people cutting POTS lines. Wouldn't >> that be _good_ for the companies and their other services? The way >the >> article describes things, fewer POTS lines = smaller subsidies taken >> from other services = better profits for other services and the >company. >> >> >the lines are still there and still require maintenance so they loose >money on it. From jabley at hopcount.ca Thu Dec 4 09:33:01 2008 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 4 Dec 2008 10:33:01 -0500 Subject: Telecom Collapse? In-Reply-To: <4a64e2f70812040647l426ddcafie295a02d6fa2a61f@mail.gmail.com> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> <4a64e2f70812040647l426ddcafie295a02d6fa2a61f@mail.gmail.com> Message-ID: On 2008-12-04, at 09:47, Josh Potter wrote: > I believe there is a law that requires just that, even if you don't > have an > active service plan the phone must still be able to access 911. With GSM phones you don't even need a SIM in the phone to call 911 (and equivalent numbers in other regions). I have two children at home, and I haven't had dial-tone on copper for years. I don't lose any sleep over it; that's just one of a thousand highly-improbable disasters that could happen, albeit one that apparently enjoys better marketing than some. If I *was* concerned, I think I'd buy a cheap GSM handset with no SIM and leave it chained somewhere the kids could find, plugged in. I seem to remember when I *did* have dial-tone from Bell Canada I'd pick up the handset and get dead air a disturbing proportion of the time. The idea that copper wire-line providers are the only ones who can provide stable telephony doesn't ring true, for me. There's a reason why the five nines don't include the last mile. Joe From pstewart at nexicomgroup.net Thu Dec 4 09:43:12 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Thu, 4 Dec 2008 10:43:12 -0500 Subject: Telecom Collapse? In-Reply-To: References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com><1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com><4a64e2f70812040647l426ddcafie295a02d6fa2a61f@mail.gmail.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> Well put Joe... I haven't had a landline in quite a bit neither and rely on VOIP today. This doesn't mean that it's never gone down but for the few times it ever has it has never worried me. There's at least two cell phones in our house whenever the family is home and I have neighbors within quick walking distance. What worries me the most is a power outage longer than say 8 hours. This is the typical battery time at most cell sites, telco remotes and many telco CO's. Beyond those 8 hours, it's quite probable that the site will go down and you'll have no cell or landline anyways. This is purely geographically related as the larger centers have generators attached - one could argue that portable generators would be used to keep these battery sites up but in a large scale outage lasting more than 8 hours I don't know a company out there that has enough portable generators to keep ALL their sites up. Have I seen my cell go down in a power outage? Yes Have I seen my landline go down in a power outage when I had them? Yes Take care, Paul -----Original Message----- From: Joe Abley [mailto:jabley at hopcount.ca] Sent: Thursday, December 04, 2008 10:33 AM To: Josh Potter Cc: nanog at nanog.org Subject: Re: Telecom Collapse? On 2008-12-04, at 09:47, Josh Potter wrote: > I believe there is a law that requires just that, even if you don't > have an > active service plan the phone must still be able to access 911. With GSM phones you don't even need a SIM in the phone to call 911 (and equivalent numbers in other regions). I have two children at home, and I haven't had dial-tone on copper for years. I don't lose any sleep over it; that's just one of a thousand highly-improbable disasters that could happen, albeit one that apparently enjoys better marketing than some. If I *was* concerned, I think I'd buy a cheap GSM handset with no SIM and leave it chained somewhere the kids could find, plugged in. I seem to remember when I *did* have dial-tone from Bell Canada I'd pick up the handset and get dead air a disturbing proportion of the time. The idea that copper wire-line providers are the only ones who can provide stable telephony doesn't ring true, for me. There's a reason why the five nines don't include the last mile. Joe ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From jgreco at ns.sol.net Thu Dec 4 09:43:29 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 4 Dec 2008 09:43:29 -0600 (CST) Subject: Telecom Collapse? In-Reply-To: from "Russell J. Lahti" at Dec 04, 2008 07:47:03 AM Message-ID: <200812041543.mB4FhTsn060600@aurora.sol.net> > That is the one and only thing keeping a land line at my home. I > have two young children, and I need to be sure that if something > were to ever happen that: 1.) The phone would work even if the > power was out, or the Internet connectivity was flaking out. > 2.) 911 would function exactly the way it is supposed to, and > not be routed to some 3rd party call center which could potentially > delay a response. > > I haven't found the power to be reliable, and the cable Internet > tends to go down when the power goes out. There's always cellular, > but then you have to depend on there being someone with a cell phone > around to make the call, and my kids aren't to the age yet that I > would want them toting around their own cell phones. As long as > my POTS line is more reliable than VoIP, I'll probably keep it. Network reliability is certainly one aspect. However, in some areas, copper is being stripped (and I don't mean stolen, though that's a problem too), see the typical Verizon FIOS install for example. The reliability of having a battery-backed CPE of some sort is questionable. In an inside-CPE environment, replacing the battery is a rough proposition. You can't expect customers to do it, look at how hard it is to get smoke detector batteries replaced, and this would be a more complex SLA-alike less frequently. You can't get workers to do it, just think of the logistics. In an outside-CPE environment, you could do it, probably. But then you might well be better off just running DSL to the home and centralizing the battery, and um, does that bring us back to U-verse? (Did I just make an argument for U-verse?) It would be nice to see a program like AT&T Lifeline that was oriented towards maintaining copper for emergency purposes, except that I suspect that this would raise a whole new set of issues, such as periodic testing. Regular use of a landline ensures that it works. This raises other issues as well; E911 services are probably experiencing an ever-higher volume of "test" calls, for example, and testing of copper- only "emergency POTS lines" would raise that further. I suppose this could be addressed with an automated system fronting the 911 call ("You have reached 911. To report an emergency, please press 1 or wait on the line. For test functions, press pound.") I'd personally like that, it would be better for testing purposes. Fun pics: http://www.kramerfirm.com/pictures/thumbnails.php?album=2 VoIP service is dodgy on the end of consumer grade Internet connections, though. Around here, the cable TV tends to fail with the power when the power supply/amps on the poles burn through their batteries in an hour or two. DSL may be a bit better, but since everyone's got a cordless phone that requires AC power, ... Really, I sometimes wonder at how readily accessible 911 really is in a regional crisis. You're probably well-covered if you have VoIP *plus* a cell or POTS, but how many people have actually checked with their 911 dispatch to make sure that their VoIP is registering properly? Given the tendency towards wireless, if you don't have POTS, it may be best to just keep an old cell around without a service plan to be able to dial 911. You can probably even teach the kids how to deal with that, at least once they're old enough to know their home phone and address. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From cmadams at hiwaay.net Thu Dec 4 09:53:49 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 4 Dec 2008 09:53:49 -0600 Subject: Telecom Collapse? In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> References: <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> Message-ID: <20081204155349.GB827386@hiwaay.net> Once upon a time, Paul Stewart said: > What worries me the most is a power outage longer than say 8 hours. > This is the typical battery time at most cell sites, telco remotes and > many telco CO's. Beyond those 8 hours, it's quite probable that the > site will go down and you'll have no cell or landline anyways. The AT&T (BellSouth) remotes around here installed in the last 10 years or so typically have natural gas generators installed, and the COs have a pair of generators for redundancy. Even many of the cell towers have generators. The telco infrastructure is pretty well backed up (I don't know how well tested any of it is of course). On the other hand, it appears that the cable infrastructure doesn't even all have batteries (I know some people whose cable voice and data services blink with the power). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From joshpotter at gmail.com Thu Dec 4 09:55:41 2008 From: joshpotter at gmail.com (Josh Potter) Date: Thu, 4 Dec 2008 09:55:41 -0600 Subject: Telecom Collapse? In-Reply-To: <200812041543.mB4FhTsn060600@aurora.sol.net> References: <200812041543.mB4FhTsn060600@aurora.sol.net> Message-ID: <4a64e2f70812040755q59b7049anbb1032bbc4595de4@mail.gmail.com> People have been digging up fiber thinking it's copper anyways, but yeah that's a big problem. On Thu, Dec 4, 2008 at 9:43 AM, Joe Greco wrote: > > That is the one and only thing keeping a land line at my home. I > > have two young children, and I need to be sure that if something > > were to ever happen that: 1.) The phone would work even if the > > power was out, or the Internet connectivity was flaking out. > > 2.) 911 would function exactly the way it is supposed to, and > > not be routed to some 3rd party call center which could potentially > > delay a response. > > > > I haven't found the power to be reliable, and the cable Internet > > tends to go down when the power goes out. There's always cellular, > > but then you have to depend on there being someone with a cell phone > > around to make the call, and my kids aren't to the age yet that I > > would want them toting around their own cell phones. As long as > > my POTS line is more reliable than VoIP, I'll probably keep it. > > Network reliability is certainly one aspect. > > However, in some areas, copper is being stripped (and I don't mean stolen, > though that's a problem too), see the typical Verizon FIOS install for > example. The reliability of having a battery-backed CPE of some sort is > questionable. In an inside-CPE environment, replacing the battery is a > rough proposition. You can't expect customers to do it, look at how hard > it is to get smoke detector batteries replaced, and this would be a more > complex SLA-alike less frequently. You can't get workers to do it, just > think of the logistics. In an outside-CPE environment, you could do it, > probably. But then you might well be better off just running DSL to the > home and centralizing the battery, and um, does that bring us back to > U-verse? (Did I just make an argument for U-verse?) > > It would be nice to see a program like AT&T Lifeline that was oriented > towards maintaining copper for emergency purposes, except that I suspect > that this would raise a whole new set of issues, such as periodic testing. > Regular use of a landline ensures that it works. > > This raises other issues as well; E911 services are probably experiencing > an ever-higher volume of "test" calls, for example, and testing of copper- > only "emergency POTS lines" would raise that further. I suppose this > could be addressed with an automated system fronting the 911 call ("You > have reached 911. To report an emergency, please press 1 or wait on the > line. For test functions, press pound.") I'd personally like that, it > would be better for testing purposes. > > Fun pics: > > http://www.kramerfirm.com/pictures/thumbnails.php?album=2 > > VoIP service is dodgy on the end of consumer grade Internet connections, > though. Around here, the cable TV tends to fail with the power when the > power supply/amps on the poles burn through their batteries in an hour > or two. DSL may be a bit better, but since everyone's got a cordless > phone that requires AC power, ... > > Really, I sometimes wonder at how readily accessible 911 really is in a > regional crisis. You're probably well-covered if you have VoIP *plus* > a cell or POTS, but how many people have actually checked with their 911 > dispatch to make sure that their VoIP is registering properly? > > Given the tendency towards wireless, if you don't have POTS, it may be > best to just keep an old cell around without a service plan to be able > to dial 911. You can probably even teach the kids how to deal with that, > at least once they're old enough to know their home phone and address. > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] then > I > won't contact you again." - Direct Marketing Ass'n position on e-mail > spam(CNN) > With 24 million small businesses in the US alone, that's way too many > apples. > > -- Josh Potter From cmarlatt at rxsec.com Thu Dec 4 10:04:12 2008 From: cmarlatt at rxsec.com (Chris Marlatt) Date: Thu, 04 Dec 2008 11:04:12 -0500 Subject: Telecom Collapse? In-Reply-To: References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> <4a64e2f70812040647l426ddcafie295a02d6fa2a61f@mail.gmail.com> Message-ID: <4937FF7C.1060605@rxsec.com> Joe Abley wrote: > > I seem to remember when I *did* have dial-tone from Bell Canada I'd pick > up the handset and get dead air a disturbing proportion of the time. The > idea that copper wire-line providers are the only ones who can provide > stable telephony doesn't ring true, for me. There's a reason why the > five nines don't include the last mile. > > > Joe > > Obviously experiences differ. I for one can't remember a single time I've picked up a POTS line and there not be a dial tone. This with living in several different cities along the East Coast. I find it significantly harder for a VOIP service to "guarantee" availability than a traditional POTS service. And for E911 any increased level of guarantee is better. However, for me it is increasingly more frequent that cell calls don't complete on the first try, or there are "bad zones" either at home or at work where having a conversation is impossible. Not a huge issue for normal phone calls but in an emergency who wants to be finding that special place where service is clear and the 911 operator can hear you. Personally I'll keep a POTS line in the home, if for nothing more than emergencies, until VOIP and Cell providers can consistently offer the same level of services I've had with a traditional phone. Regards, Chris From list-only at dnz.se Thu Dec 4 10:05:53 2008 From: list-only at dnz.se (=?ISO-8859-1?Q?Anders_Lindb=E4ck?=) Date: Thu, 4 Dec 2008 17:05:53 +0100 Subject: Recommendation of Tools In-Reply-To: References: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> <943AC9CD-ABC3-406D-9799-E1B3664A3123@dnz.se> Message-ID: On 4 dec 2008, at 14.05, Pekka Savola wrote: > On Wed, 3 Dec 2008, Anders Lindb?ck wrote: >> Mtr is even less usefull then that, in its default mode it does a >> traceroute and then proceeds to ICMP Ping flood each IP in the >> list generated by the traceroute, the result is usually completly >> useless on WAN topologies due to asym-routing, ICMP node >> protections by carriers and punting etc.. > > No, it doesn't try pinging the routers in the middle, at least not > anymore (I just re-checked with 0.71 and 0.75). I vaguely recall > behaviour like that in the past, however, so it's possible that > long time ago mtr did behave that way. > According to the 0.75 sorcecode ICMP is still the default prot used, and the definition of MTR from bitwizards homepage disagress with you: "mtr combines the functionality of the 'traceroute' and 'ping' programs in a single network diagnostic tool. As mtr starts, it investigates the network connection between the host mtr runs on and a user-specified destination host. After it determines the address of each network hop between the machines, it sends a sequence ICMP ECHO requests to each one to determine the quality of the link to each machine. As it does this, it prints running statistics about each machine. For a preview take a look at the screenshots." Even if you use UDP/TCP or whatever, the return packet will be ICMP and that will be ratelimited by any carrier worth there salt... >> And using UDP will not really provide better results due to the >> same thing, and IIRC Cisco from 12.0 has a standard setting of no >> more then 1 ICMP Unreach per 500ms.. > > This is true and the point I was getting at, though I believe the > bucket is much larger in any recent software release (also in 12.0 > series). Actually, 5 years ago, you could see spot Cisco routers > in "traceroute6" because they dropped the rate-limiter didn't > respond to the middle packet and it resulted in a star. The rate- > limiter has long since been fixed to be more lenient. > According to the 12.4T refrence it is still set to 1 packet / 500ms as default, however changes where made to how you can controll this in 12.4(2)T. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ------------------------------ Anders Lindb?ck anders.lindback at dnz.se From cmarlatt at rxsec.com Thu Dec 4 10:06:33 2008 From: cmarlatt at rxsec.com (Chris Marlatt) Date: Thu, 04 Dec 2008 11:06:33 -0500 Subject: Telecom Collapse? In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com><1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com><4a64e2f70812040647l426ddcafie295a02d6fa2a61f@mail.gmail.com> <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> Message-ID: <49380009.8050407@rxsec.com> Paul Stewart wrote: > > There's at least two cell phones in our house whenever the family is > home and I have neighbors within quick walking distance. > That's assuming they're not doing the same thing you are, are home, or are willing to let you borrow their phone. You're assuming a lot. I find it surprising that many people replying haven't kept a 911 only POTS line. Regards, Chris From pbosworth at gmail.com Thu Dec 4 10:13:14 2008 From: pbosworth at gmail.com (Paul Bosworth) Date: Thu, 4 Dec 2008 10:13:14 -0600 Subject: Telecom Collapse? In-Reply-To: <200812041543.mB4FhTsn060600@aurora.sol.net> References: <200812041543.mB4FhTsn060600@aurora.sol.net> Message-ID: <25b132e90812040813nd778bb2tb4ef5fa196986e66@mail.gmail.com> In my experience with a fiber to the home deployment I feel that the trend of moving away from the stability of POTS lines for emergency service is acceptable for most people. Most battery backups allow for around 36 hours of dialtone. The overwhelming majority of power outages last nowhere near this long. In addition, when used for emergencies only, a cellular phone can last for several days. During Hurricane Gustav my home in Baton Rouge was without power for nine days. Between my wife's cellphone and my own we were able to maintain emergency service for the entire duration of the outage. Transitioning off of the POTS grid to newer technologies requires a new approach to how people prepare for and respond to outages and disasters, but I feel that the alternatives to POTS access are acceptible. People generally find a way to be resourceful. During prolonged outages I've had customers who actually hooked up generators to their ONT's to supply their home with not only phone, but internet and video service as well. Of course not everyone has a generator, but the option is still there. During Gustav people lined up at the CVS near my house (which was on generator) to use their electrical outlets to charge their cellphones. These options are of course quite an inconvenience compared to having battery on a POTS line during an outage, but then again maintaining a POTS line just for outages is quite an inconvenience on most peoples' budget, too. -- Paul H Bosworth TraceSecurity CCNP, CCNA, CCDA From a.harrowell at gmail.com Thu Dec 4 10:16:00 2008 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Thu, 4 Dec 2008 16:16:00 +0000 Subject: Telecom Collapse? In-Reply-To: <49380009.8050407@rxsec.com> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> <4a64e2f70812040647l426ddcafie295a02d6fa2a61f@mail.gmail.com> <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> <49380009.8050407@rxsec.com> Message-ID: Solar is civil defence - that goes for Node Bs as well as citizens. In the UK, I have absolutely no confidence in the reliability of our major cable op, because everywhere I go I find their street cabinets broken into, presumably by scum looking for copper (how long will they take to respond to the precipitous drop in metal prices?), which this being DOCSIS it doesn't contain. The BT ones, which are full of copper, seem to be more robust. From smb at cs.columbia.edu Thu Dec 4 10:29:37 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Thu, 4 Dec 2008 11:29:37 -0500 Subject: Telecom Collapse? In-Reply-To: <25b132e90812040813nd778bb2tb4ef5fa196986e66@mail.gmail.com> References: <200812041543.mB4FhTsn060600@aurora.sol.net> <25b132e90812040813nd778bb2tb4ef5fa196986e66@mail.gmail.com> Message-ID: <20081204112937.045436cc@cs.columbia.edu> On Thu, 4 Dec 2008 10:13:14 -0600 "Paul Bosworth" wrote: > In my experience with a fiber to the home deployment I feel that the > trend of moving away from the stability of POTS lines for emergency > service is acceptable for most people. Most battery backups allow for > around 36 hours of dialtone. The overwhelming majority of power > outages last nowhere near this long. In addition, when used for > emergencies only, a cellular phone can last for several days. During > Hurricane Gustav my home in Baton Rouge was without power for nine > days. Between my wife's cellphone and my own we were able to maintain > emergency service for the entire duration of the outage. > Transitioning off of the POTS grid to newer technologies requires a > new approach to how people prepare for and respond to outages and > disasters, but I feel that the alternatives to POTS access are > acceptible. > What about the cell site? See http://www.forbes.com/feeds/ap/2008/12/03/ap5776571.html The Federal Communications Commission said Wednesday its attempt to require backup power for all U.S. cell phone towers is dead for now, but it will take another stab at the issue soon. The agency told a federal appeals court in Washington, D.C., that it will honor a regulator's decision rejecting its proposed requirement. Article Controls The FCC proposed in May 2007 that all cell towers have a minimum of eight hours of backup power, which would switch on if a tower lost its regular energy source. ... --Steve Bellovin, http://www.cs.columbia.edu/~smb From alex at corp.nac.net Thu Dec 4 10:31:46 2008 From: alex at corp.nac.net (Alex Rubenstein) Date: Thu, 4 Dec 2008 11:31:46 -0500 Subject: Telecom Collapse? In-Reply-To: <20081204155349.GB827386@hiwaay.net> References: <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> <20081204155349.GB827386@hiwaay.net> Message-ID: > The AT&T (BellSouth) remotes around here installed in the last 10 years > or so typically have natural gas generators installed, and the COs have > a pair of generators for redundancy. Even many of the cell towers have > generators. The telco infrastructure is pretty well backed up (I don't > know how well tested any of it is of course). > > On the other hand, it appears that the cable infrastructure doesn't even > all have batteries (I know some people whose cable voice and data > services blink with the power). Yes. In my neck of the woods, there have been a countable number of times in the last few years where when you pick up Vzn POTS, you don't get dial tone. Cellular tends to work well. At least, when combined with Glock, I feel safe enough to rely on it for home safety issue (E911). From dts at senie.com Thu Dec 4 10:36:01 2008 From: dts at senie.com (Daniel Senie) Date: Thu, 04 Dec 2008 11:36:01 -0500 Subject: Telecom Collapse? In-Reply-To: <1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> Message-ID: <493806F1.2020308@senie.com> Mike Lyon wrote: > That makes two of us... > > Anyways, for residential VOIP, where are we these days with E911? Are > providers like Vonage and such providing reliable E911 when people > call 911? That is one of the major problems I see with the residential > realm going with VOIP offerings... > Where we are, the SLC units on the telephone poles have batteries. Until very recently, DEAD batteries. We'd lose power, and the POTS line would go out. We've got our own genset and UPSs to bridge the gap, so we kept power, the cable Internet service stayed running, and the Vonage VOIP. The only thing NOT working was POTS. After many calls to Verizon, most of which were met by people telling me I was an idiot, I filed a complaint with the Commonweath and had our police chief file a complaint with the E911 folks he interfaces with. Suddenly, Verizon wanted to help. A manager came out and asked what was up. I suggested he get the batteries changed, and get a program in place to regularly test and replace them. It got done. But for over 3 years, when the power went out, 911 wasn't available. Of course the power usually goes out during bad ice storms, when people are more likely to be hurt. We're going to give up the POTS line because it costs a lot for poor service. Verizon has only themselves to blame. But I do expect them to show up in Washington, DC, since all the other big companies are lining up for their handouts. Politicians say small businesses are the backbone of the economy, but clearly when it comes to buying members of Congress, the big companies have the money to spend. From pbosworth at gmail.com Thu Dec 4 10:45:19 2008 From: pbosworth at gmail.com (Paul Bosworth) Date: Thu, 4 Dec 2008 10:45:19 -0600 Subject: Telecom Collapse? In-Reply-To: <20081204112937.045436cc@cs.columbia.edu> References: <200812041543.mB4FhTsn060600@aurora.sol.net> <25b132e90812040813nd778bb2tb4ef5fa196986e66@mail.gmail.com> <20081204112937.045436cc@cs.columbia.edu> Message-ID: <25b132e90812040845r62778b5rd907a3a86b14714a@mail.gmail.com> Many proposed regulations are struck down before they become required regulation. Just like the FCC mandates that POTS and fiber have guaranteed battery, the FCC will mandate that cellular towers do the same. This is inevitable. The telco industry is notorious for litigating to death anything that will require an increase in operational expenses but inevitably when a service is deemed to be critical to society it has to comply. On a personal note, when I worked in telecom I never once saw a cell tower that was down due to power loss. Every tower I have worked with had some form of power generation, be it natural gas or diesel. In addition, as a cellular service consumer I have also never experienced an outage due to cellular tower power loss. phb What about the cell site? See > http://www.forbes.com/feeds/ap/2008/12/03/ap5776571.html > > The Federal Communications Commission said Wednesday its > attempt to require backup power for all U.S. cell phone towers > is dead for now, but it will take another stab at the issue > soon. > > The agency told a federal appeals court in Washington, D.C., > that it will honor a regulator's decision rejecting its > proposed requirement. Article Controls > > The FCC proposed in May 2007 that all cell towers have a > minimum of eight hours of backup power, which would switch on > if a tower lost its regular energy source. > > ... > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > -- Paul H Bosworth CCNP, CCNA, CCDA From jbates at brightok.net Thu Dec 4 10:46:51 2008 From: jbates at brightok.net (Jack Bates) Date: Thu, 04 Dec 2008 10:46:51 -0600 Subject: Telecom Collapse? In-Reply-To: <20081204155349.GB827386@hiwaay.net> References: <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> <20081204155349.GB827386@hiwaay.net> Message-ID: <4938097B.80601@brightok.net> Chris Adams wrote: > Once upon a time, Paul Stewart said: >> What worries me the most is a power outage longer than say 8 hours. >> This is the typical battery time at most cell sites, telco remotes and >> many telco CO's. Beyond those 8 hours, it's quite probable that the >> site will go down and you'll have no cell or landline anyways. > > The AT&T (BellSouth) remotes around here installed in the last 10 years > or so typically have natural gas generators installed, and the COs have > a pair of generators for redundancy. Even many of the cell towers have > generators. The telco infrastructure is pretty well backed up (I don't > know how well tested any of it is of course). The ILECs that use my service have generators at the large sites and a number of generator trucks to make rounds recharging remote battery systems. Quite a few of them have permanent generators installed to power one or more remotes in the field. Some are still using remote power technologies on their remotes. The storm that blacked out northern Oklahoma a couple of years ago left some towns without services for over a month. The phone system itself was impacted in a few of the ILECs, but they never dropped below 80% and most of that was due to actual line damage, not power. A few of the ILECS effected didn't even blink the entire time. That being said, most small ILECs can cope better with the costs. It's easier to manage < 10 towns than it is to manage 100+ towns. > On the other hand, it appears that the cable infrastructure doesn't even > all have batteries (I know some people whose cable voice and data > services blink with the power). None of the cable services I know of around here can make 8 hours, much less 1-6 weeks. Such outages are rare, but they do happen and Oklahoma takes more than it's fair share. Lots of modems support battery backup, but the cable plant itself is prone to power outages. Jack From alex at corp.nac.net Thu Dec 4 10:54:23 2008 From: alex at corp.nac.net (Alex Rubenstein) Date: Thu, 4 Dec 2008 11:54:23 -0500 Subject: Telecom Collapse? In-Reply-To: <4938097B.80601@brightok.net> References: <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> <20081204155349.GB827386@hiwaay.net> <4938097B.80601@brightok.net> Message-ID: And it gets better: AT&T to reduce workforce by 12,000 - AT&T Inc. will layoff 12,000 of its employees, or 4 percent of its total workforce, in response to recent economic pressures. Sprint/Nextel has had negative net income of $326mm, $829mm, and $505mm for the last three quarters. Verizon seems to be doing alright, about a billion in net income each quarter. GBLX has had negative net income of about $70mm each of the last three quarters. L3 has been doing slightly worse. I am sure Q4 numbers aren't going to be great. I hadn't thought about this, but it's going to be pretty interesting the next year or so. From jabley at hopcount.ca Thu Dec 4 10:54:28 2008 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 4 Dec 2008 11:54:28 -0500 Subject: Telecom Collapse? In-Reply-To: <49380009.8050407@rxsec.com> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com><1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com><4a64e2f70812040647l426ddcafie295a02d6fa2a61f@mail.gmail.com> <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> <49380009.8050407@rxsec.com> Message-ID: <0DD2FBFA-E270-40B2-8454-913DD93672CB@hopcount.ca> On 2008-12-04, at 11:06, Chris Marlatt wrote: > That's assuming they're not doing the same thing you are, are home, or > are willing to let you borrow their phone. You're assuming a lot. I > find > it surprising that many people replying haven't kept a 911 only POTS > line. This is straying far from network operations, but I think 911 generally engenders an unnecessary degree of hysteria. As I suggested before, the marketing of this fear from certain quarters has apparently been quiet effective. The probability of any single individual needing to call 911 is already minute. The probably that all available cell and VoIP services also won't work precisely at the moment that a 911 call needs to be made is even smaller. You're probably more likely to accidentally brutally stab yourself in the neck whilst combing your hair. A sense of perspective in these things can be useful, in my opinion. Cries of "but think of the children!" are merely entertaining, in my opinion. Joe From jbates at brightok.net Thu Dec 4 10:54:35 2008 From: jbates at brightok.net (Jack Bates) Date: Thu, 04 Dec 2008 10:54:35 -0600 Subject: Telecom Collapse? In-Reply-To: <25b132e90812040845r62778b5rd907a3a86b14714a@mail.gmail.com> References: <200812041543.mB4FhTsn060600@aurora.sol.net> <25b132e90812040813nd778bb2tb4ef5fa196986e66@mail.gmail.com> <20081204112937.045436cc@cs.columbia.edu> <25b132e90812040845r62778b5rd907a3a86b14714a@mail.gmail.com> Message-ID: <49380B4B.70604@brightok.net> Paul Bosworth wrote: > On a personal note, when I worked in telecom I never once saw a cell tower > that was down due to power loss. Every tower I have worked with had some > form of power generation, be it natural gas or diesel. In addition, as a > cellular service consumer I have also never experienced an outage due to > cellular tower power loss. The nasty Oklahoma outage a few years ago wiped out cellular big time. In some cases it was due to power loss, in others it was loss of the backend fiber/T1's feeding it. I know one town that lost every service except for POTS, though it didn't help much since people were living elsewhere to stay warm. Of course, life gets fun in rural America. Jack From pbosworth at gmail.com Thu Dec 4 10:59:06 2008 From: pbosworth at gmail.com (Paul Bosworth) Date: Thu, 4 Dec 2008 10:59:06 -0600 Subject: Telecom Collapse? In-Reply-To: <49380B4B.70604@brightok.net> References: <200812041543.mB4FhTsn060600@aurora.sol.net> <25b132e90812040813nd778bb2tb4ef5fa196986e66@mail.gmail.com> <20081204112937.045436cc@cs.columbia.edu> <25b132e90812040845r62778b5rd907a3a86b14714a@mail.gmail.com> <49380B4B.70604@brightok.net> Message-ID: <25b132e90812040859l5fe3fb8ag78b53a77fdf5c611@mail.gmail.com> There will always be exceptions to the rule. Nature can be quite ugly to service infrastructure and the best service providers can do is pull double duty to get services back up as quickly as possible. As you said, cellular was torn up pretty badly, but then again so was the power grid and the hardened POTS infrastructure. You make a good point about the data lines that feed cell towers. Of the cell site outages I have dealt with, every one of them was due to data line loss. phb On Thu, Dec 4, 2008 at 10:54 AM, Jack Bates wrote: > Paul Bosworth wrote: > >> On a personal note, when I worked in telecom I never once saw a cell tower >> that was down due to power loss. Every tower I have worked with had some >> form of power generation, be it natural gas or diesel. In addition, as a >> cellular service consumer I have also never experienced an outage due to >> cellular tower power loss. >> > > The nasty Oklahoma outage a few years ago wiped out cellular big time. In > some cases it was due to power loss, in others it was loss of the backend > fiber/T1's feeding it. I know one town that lost every service except for > POTS, though it didn't help much since people were living elsewhere to stay > warm. > > Of course, life gets fun in rural America. > > Jack > -- Paul H Bosworth CCNP, CCNA, CCDA From Valdis.Kletnieks at vt.edu Thu Dec 4 10:59:19 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 04 Dec 2008 11:59:19 -0500 Subject: Telecom Collapse? In-Reply-To: Your message of "Wed, 03 Dec 2008 22:59:00 PST." <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> Message-ID: <35834.1228409959@turing-police.cc.vt.edu> On Wed, 03 Dec 2008 22:59:00 PST, Paul Ferguson said: > I deliberated for a while on whether to send this, or not, but I figure it > might be of interest to this community: > > http://techliberation.com/2008/12/04/telecom-collapse/ The article goes on to quote some other source regarding Hawaiian Telecom's collapse. The *very first sentence* of the quote: "Customers initially had complained about poor service." I quit reading after that, as I could already see where this was heading. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From jbates at brightok.net Thu Dec 4 11:08:49 2008 From: jbates at brightok.net (Jack Bates) Date: Thu, 04 Dec 2008 11:08:49 -0600 Subject: Telecom Collapse? In-Reply-To: <0DD2FBFA-E270-40B2-8454-913DD93672CB@hopcount.ca> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com><1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com><4a64e2f70812040647l426ddcafie295a02d6fa2a61f@mail.gmail.com> <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> <49380009.8050407@rxsec.com> <0DD2FBFA-E270-40B2-8454-913DD93672CB@hopcount.ca> Message-ID: <49380EA1.5010600@brightok.net> Joe Abley wrote: > This is straying far from network operations, but I think 911 generally > engenders an unnecessary degree of hysteria. As I suggested before, the > marketing of this fear from certain quarters has apparently been quiet > effective. Many will agree with you; unless 911 saved their life. Of course, we could let those people die, I guess. > The probability of any single individual needing to call 911 is already > minute. The probably that all available cell and VoIP services also > won't work precisely at the moment that a 911 call needs to be made is > even smaller. 911 services are heavily used when a geographical area has an emergency, and that emergency usually includes not having power. > You're probably more likely to accidentally brutally stab yourself in > the neck whilst combing your hair. Unless you live in a natural disaster prone location. Or if your grandmother's alert bracelet requires a phone line for notification. > A sense of perspective in these things can be useful, in my opinion. > Cries of "but think of the children!" are merely entertaining, in my > opinion. I agree. Think of the elderly! Think of the "This is where my neighborhood used to be." And not to leave the more stable big cities out, think of the looting and pillaging! That said, I'd keep POTS and Cell available. I don't believe in single homing. ;) Jack From streiner at cluebyfour.org Thu Dec 4 11:13:52 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 4 Dec 2008 12:13:52 -0500 (EST) Subject: Telecom Collapse? In-Reply-To: <20081204112937.045436cc@cs.columbia.edu> References: <200812041543.mB4FhTsn060600@aurora.sol.net> <25b132e90812040813nd778bb2tb4ef5fa196986e66@mail.gmail.com> <20081204112937.045436cc@cs.columbia.edu> Message-ID: On Thu, 4 Dec 2008, Steven M. Bellovin wrote: > What about the cell site? See > http://www.forbes.com/feeds/ap/2008/12/03/ap5776571.html > > The FCC proposed in May 2007 that all cell towers have a > minimum of eight hours of backup power, which would switch on > if a tower lost its regular energy source. Time for Power over Wireless (PoW), I guess... j/k jms From dmm at 1-4-5.net Thu Dec 4 11:18:26 2008 From: dmm at 1-4-5.net (David Meyer) Date: Thu, 4 Dec 2008 09:18:26 -0800 Subject: route-views maintenance Message-ID: <20081204171826.GA15283@1-4-5.net> Folks, We're planning a brief outage on route-views.routeviews.org at 1200 PST today (basically, upgrading processor and memory; thanks Chip Sharp). Thanks, Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From pbosworth at gmail.com Thu Dec 4 11:20:38 2008 From: pbosworth at gmail.com (Paul Bosworth) Date: Thu, 4 Dec 2008 11:20:38 -0600 Subject: Telecom Collapse? In-Reply-To: References: <200812041543.mB4FhTsn060600@aurora.sol.net> <25b132e90812040813nd778bb2tb4ef5fa196986e66@mail.gmail.com> <20081204112937.045436cc@cs.columbia.edu> Message-ID: <25b132e90812040920v5764205crc46c5b192b45d02f@mail.gmail.com> Large scale Tesla coils would be pretty awesome :) On Thu, Dec 4, 2008 at 11:13 AM, Justin M. Streiner wrote: > On Thu, 4 Dec 2008, Steven M. Bellovin wrote: > > What about the cell site? See >> http://www.forbes.com/feeds/ap/2008/12/03/ap5776571.html >> >> The FCC proposed in May 2007 that all cell towers have a >> minimum of eight hours of backup power, which would switch on >> if a tower lost its regular energy source. >> > > Time for Power over Wireless (PoW), I guess... j/k > > jms > > -- Paul H Bosworth CCNP, CCNA, CCDA From web at typo.org Thu Dec 4 11:20:40 2008 From: web at typo.org (Wayne E. Bouchard) Date: Thu, 4 Dec 2008 10:20:40 -0700 Subject: Telecom Collapse? In-Reply-To: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> Message-ID: <20081204172040.GA94137@typo.org> That the old ILECs are having problems due to the fact that few if any of them know how to run a decent business is not exactly news. IMO, it might be best if some of them were finaly placed in the position of figuring out how to come into the 21st century and actually compete for business. But I agree with Alex... If we have another poorly run group of businesses pleading for tax payer money, I think I'm gonna have to go somewhere and lose my mind for a few days. -Wayne On Wed, Dec 03, 2008 at 10:59:00PM -0800, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I deliberated for a while on whether to send this, or not, but I figure it > might be of interest to this community: > > http://techliberation.com/2008/12/04/telecom-collapse/ > > - - ferg > > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.6.3 (Build 3017) > > wj8DBQFJN3+vq1pz9mNUZTMRApD5AKCQZPe5Nctn2OkE4kVWiZ7y7rJ4qwCgsQn6 > nCNVbqAfPfALdEtbU2p1fg0= > =/pUF > -----END PGP SIGNATURE----- > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawgster(at)gmail.com > ferg's tech blog: http://fergdawg.blogspot.com/ --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From mike-nanog at tiedyenetworks.com Thu Dec 4 11:26:05 2008 From: mike-nanog at tiedyenetworks.com (mike) Date: Thu, 04 Dec 2008 09:26:05 -0800 Subject: Telecom Collapse? In-Reply-To: <35834.1228409959@turing-police.cc.vt.edu> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <35834.1228409959@turing-police.cc.vt.edu> Message-ID: <493812AD.7040304@tiedyenetworks.com> For my own $0.02 worth, I would like to point out the kind of engineering that was done during the days of Ma Bell - when it was THE phone company, and had the world in it's pocket - was quite spectacular and resulted in telecommunications systems that largely stood up and continued functioning despite the worst that could be thrown at it. But today, in our competitive (ahem) marketplace, the kinds of resources that made this level of engineering possible on such a wide scale, are no longer economically possible and is only infrequently done. Besides, most people readily accept failure. Except when it hurts them, that is, and then only after the fact is any kind of examination done and possibly steps taken to address the risk. But until then, people want cheap and that's the only selling point that matters. So your cable voip works until it doesn't, and nobody is responsible to you for it not working when you needed it to..... at least it was cheap.... From cowie at renesys.com Thu Dec 4 11:36:32 2008 From: cowie at renesys.com (Jim Cowie) Date: Thu, 4 Dec 2008 12:36:32 -0500 Subject: Telecom Collapse? In-Reply-To: <20081204172040.GA94137@typo.org> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <20081204172040.GA94137@typo.org> Message-ID: <6762a99d0812040936q3308e3e4j9d16aeac87698cec@mail.gmail.com> On Thu, Dec 4, 2008 at 12:20 PM, Wayne E. Bouchard wrote: > That the old ILECs are having problems due to the fact that few if any > of them know how to run a decent business is not exactly news. IMO, it > might be best if some of them were finaly placed in the position of > figuring out how to come into the 21st century and actually compete > for business. I wasn't going to say anything, but as long as you brought it up ... http://www.renesys.com/blog/2008/12/fiber-to-the-home-ideal-econom.shtml Outlandish and bizarre, yes, but perhaps no more so than the other things you read in the papers these days? --jim From list-only at dnz.se Thu Dec 4 11:46:15 2008 From: list-only at dnz.se (=?ISO-8859-1?Q?Anders_Lindb=E4ck?=) Date: Thu, 4 Dec 2008 18:46:15 +0100 Subject: Recommendation of Tools In-Reply-To: References: <084962C061414240A0CDB4BE328A9B2D0BB10BAED8@GVW1100EXC.americas.hpqcorp.net> <943AC9CD-ABC3-406D-9799-E1B3664A3123@dnz.se> Message-ID: On 4 dec 2008, at 17.49, Daniel Hagerty wrote: > =?ISO-8859-1?Q?Anders_Lindb=E4ck?= writes: > >> According to the 0.75 sorcecode ICMP is still the default prot >> used, =20 >> and the definition of MTR from bitwizards homepage disagress with >> you: > > Have you considered checking an actual authority on the subject > matter, like a running copy of mtr examined by a sniffer? > > Yes, ICMP is a default. No, it doesn't try to talk to > intermediates; it does the usual expanding TTL scope thing. > Which changes exactly nothing, but feel free to selectivly quote me out of context all you want. ------------------------------ Anders Lindb?ck anders.lindback at dnz.se From mike.lyon at gmail.com Thu Dec 4 11:47:26 2008 From: mike.lyon at gmail.com (Mike Lyon) Date: Thu, 4 Dec 2008 09:47:26 -0800 Subject: Telecom Collapse? In-Reply-To: <20081204172040.GA94137@typo.org> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <20081204172040.GA94137@typo.org> Message-ID: <1b5c1c150812040947l647ef101of01878ce143a3573@mail.gmail.com> I think we've figured out the next get together for the next nanog. Make sure there is a gun range within an hour drive.... On 12/4/08, Wayne E. Bouchard wrote: > That the old ILECs are having problems due to the fact that few if any > of them know how to run a decent business is not exactly news. IMO, it > might be best if some of them were finaly placed in the position of > figuring out how to come into the 21st century and actually compete > for business. > > But I agree with Alex... If we have another poorly run group of > businesses pleading for tax payer money, I think I'm gonna have to go > somewhere and lose my mind for a few days. > > -Wayne > > On Wed, Dec 03, 2008 at 10:59:00PM -0800, Paul Ferguson wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I deliberated for a while on whether to send this, or not, but I figure >> it >> might be of interest to this community: >> >> http://techliberation.com/2008/12/04/telecom-collapse/ >> >> - - ferg >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: PGP Desktop 9.6.3 (Build 3017) >> >> wj8DBQFJN3+vq1pz9mNUZTMRApD5AKCQZPe5Nctn2OkE4kVWiZ7y7rJ4qwCgsQn6 >> nCNVbqAfPfALdEtbU2p1fg0= >> =/pUF >> -----END PGP SIGNATURE----- >> >> -- >> "Fergie", a.k.a. Paul Ferguson >> Engineering Architecture for the Internet >> fergdawgster(at)gmail.com >> ferg's tech blog: http://fergdawg.blogspot.com/ > > --- > Wayne Bouchard > web at typo.org > Network Dude > http://www.typo.org/~web/ > > -- Sent from my mobile device From martin at airwire.ie Thu Dec 4 11:51:33 2008 From: martin at airwire.ie (Martin List-Petersen) Date: Thu, 04 Dec 2008 17:51:33 +0000 Subject: Telecom Collapse? In-Reply-To: <493806F1.2020308@senie.com> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> <493806F1.2020308@senie.com> Message-ID: <493818A5.8090505@airwire.ie> Daniel Senie wrote: > Mike Lyon wrote: > >> That makes two of us... >> >> Anyways, for residential VOIP, where are we these days with E911? Are >> providers like Vonage and such providing reliable E911 when people >> call 911? That is one of the major problems I see with the residential >> realm going with VOIP offerings... >> > > Where we are, the SLC units on the telephone poles have batteries. Until > very recently, DEAD batteries. We'd lose power, and the POTS line would > go out. We've got our own genset and UPSs to bridge the gap, so we kept > power, the cable Internet service stayed running, and the Vonage VOIP. > The only thing NOT working was POTS. > We run a fixed wireless business and with modern embedded hardware, that is designed to be installed on remote sites, like mast sites, we can for very little money add battery backup for one week (7 days !!) The cost of that is less than $200 pr. site and would power up to 4 routers easily. As the west of Ireland has terrible power in the rural areas (as in daily power cuts), we've implemented the power backup everywhere. A minimum of 2 days. In the regular winterstorms, when tree's fall into our overland telephone cabling, roads get flooded etc., we've had customers telling us, that the only thing that stays working for them, is the broadband from us. Some even ask us, how they can power the kit in an emergency and as our kit runs on anything from 10-28 volt, they can just hook it up to a car battery. As for E911 or similar services, as mentioned before, there is always a cellphone. Any GSM provider is enforced to provide 911/112 services as part of the license, even to phones that have no sim-card in it. And all of the phones allow you to call 911 and 112 without a sim-card. That's for some people, that can't get a phoneline, the only way of having E911/112 services. Pots will often fail during powercuts, especially if you are sitting on a pair gain/multiplexer. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From jgreco at ns.sol.net Thu Dec 4 11:52:24 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 4 Dec 2008 11:52:24 -0600 (CST) Subject: Telecom Collapse? In-Reply-To: <6762a99d0812040936q3308e3e4j9d16aeac87698cec@mail.gmail.com> from "Jim Cowie" at Dec 04, 2008 12:36:32 PM Message-ID: <200812041752.mB4HqPc2066329@aurora.sol.net> > On Thu, Dec 4, 2008 at 12:20 PM, Wayne E. Bouchard wrote: > > That the old ILECs are having problems due to the fact that few if any > > of them know how to run a decent business is not exactly news. IMO, it > > might be best if some of them were finaly placed in the position of > > figuring out how to come into the 21st century and actually compete > > for business. > > I wasn't going to say anything, but as long as you brought it up ... > > http://www.renesys.com/blog/2008/12/fiber-to-the-home-ideal-econom.shtml > > Outlandish and bizarre, yes, but perhaps no more so than the other things > you read in the > papers these days? --jim Yeah, outlandish and bizarre: http://www.newnetworks.com/broadbandscandals.htm We already *PAID* for that system. Well, ownership of strands aside, it would have been similar. And the thing is, years later, we have people coming along and thinking that this is in any way visionary or innovative. (That is NOT meant as an attack on you, the authors at New America, or the idea, but rather an attack on the most fantastic bit of spin and propaganda manipulation that has allowed the ILEC's to get away with this, almost completely unnoticed, so that nobody even remembers what was promised. Can you feel the despair?) So, the question is, how do we reclaim these funds from the ILEC's? Or how do we force the ILEC's to produce the system promised, and release it from their monopolies? In an environment where cities are getting ticked off and deploying fiber (Monticello, MN) and then getting sued for doing so (TDS Telecom) even after the carrier initially refused to do such a deployment, I am really very strongly in favor of this sort of self-determination. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From xenophage0 at gmail.com Thu Dec 4 12:00:32 2008 From: xenophage0 at gmail.com (Jason Frisvold) Date: Thu, 4 Dec 2008 13:00:32 -0500 Subject: Telecom Collapse? In-Reply-To: <20081204172040.GA94137@typo.org> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <20081204172040.GA94137@typo.org> Message-ID: On Dec 4, 2008, at 12:20 PM, Wayne E. Bouchard wrote: > That the old ILECs are having problems due to the fact that few if any > of them know how to run a decent business is not exactly news. IMO, it > might be best if some of them were finaly placed in the position of > figuring out how to come into the 21st century and actually compete > for business. Having finally broken away from the local ILEC and moved to more fertile grounds, I can concur with the above. Concentration these days seems to be on maximizing profit and bonuses for execs while stripping away every possible expense so the books look good and make the company more desirable. One of their latest schemes was to give away additional lines to customers, pumping up the overall access line count. From what I can tell, a higher access line count increases the "worth" of the company. New technology, or, rather, a mandate for new technology was there, but without a decent budget, there is no way to even come close to meeting that mandate. And that's where they remain today. Unfortunately, I think in the end, the company will be sold and the execs will get their big bonuses, but that seems to be the way of things these days. > But I agree with Alex... If we have another poorly run group of > businesses pleading for tax payer money, I think I'm gonna have to go > somewhere and lose my mind for a few days. It wouldn't surprise me in the least if they started begging for a cut. I think everyone these days has bailoutitis.. I'll gladly take a cut.. I'm easy, though. A few million will surely carry me through the next few years.. :) > -Wayne -- Jason 'XenoPhage' Frisvold XenoPhage0 at gmail.com http://blog.godshell.com From rbf+nanog at panix.com Thu Dec 4 13:09:06 2008 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Thu, 4 Dec 2008 13:09:06 -0600 Subject: Telecom Collapse? In-Reply-To: <20081204144827.GA827386@hiwaay.net> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <20081204144827.GA827386@hiwaay.net> Message-ID: <20081204190906.GA11514@panix.com> On Thu, Dec 04, 2008 at 08:48:27AM -0600, Chris Adams wrote: > Once upon a time, Paul Ferguson said: > > I deliberated for a while on whether to send this, or not, but I figure it > > might be of interest to this community: > > > > http://techliberation.com/2008/12/04/telecom-collapse/ > > One thing doesn't make sense in that article: it talks about POTS being > subsidized by other services, and people cutting POTS lines. Wouldn't > that be _good_ for the companies and their other services? The way the > article describes things, fewer POTS lines = smaller subsidies taken > from other services = better profits for other services and the company. The marginal cost of POTS service isn't subsidized by other services; at the margin, POTS is profitable. The subsidy covers some of the fixed costs (but not all of them, some of the fixed costs are covered by POTS revenues). So ... every time a POTS line is taken out, the fixed costs that were being covered by the revenue from that line now have to be covered from somewhere else (= More Subsidy). -- Brett From bburke at merit.edu Thu Dec 4 13:14:57 2008 From: bburke at merit.edu (Betty Burke) Date: Thu, 4 Dec 2008 14:14:57 -0500 (EST) Subject: [NANOG-announce] NANOG45 Update In-Reply-To: <1133524703.565161228417837837.JavaMail.root@crono> Message-ID: <69465594.566131228418097497.JavaMail.root@crono> Hi Everyone:> On behalf of Merit, we look forward to our continued working relationship with the NANOG SC and PC who are working hard to bring a great program to NANOG45. ?Our Host, Terremark, continues to work hard to provide all of the additional support items to make everyone comfortable in Santo Domingo. ?A meeting that is sure to be unique, and one you will not want to miss! The Program Committee has been working very hard, a draft of the complete agenda is expected very early next week. ?A highlight of the agenda topics can be found at: http://nanog.org/meetings/nanog45/agenda.php The attendee list can be found at: https://nanog.merit.edu/registration/attendee.list.epl?MEETING_ID=45 Lastly, take advantage of the early registration fee, do consider getting your registration completed via: https://nanog.merit.edu/registration/ Of additional importance are our NANOG Sponsors. ?We appreciate the current economic impact on budgets. ?However, NANOG continues to be the premier event for national and international network operators, engineers, content providers, and of course the peering community; an event which provides sponsors low cost direct access to customers. ?Send your inquiry to nanong-support at nanog.org. We will work hard to design a NANOG45 package that works for your company and NANOG. ? Look forward to seeing many of you in late January 2009! As always, if you have any questions or concerns, feel free to contact Merit directly via nanog-support at nanog.org or any of the NANOG committees. All best. Betty Merit Network Inc. (734)527-5763 _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From mike at mtcc.com Thu Dec 4 13:18:42 2008 From: mike at mtcc.com (Michael Thomas) Date: Thu, 04 Dec 2008 11:18:42 -0800 Subject: Telecom Collapse? In-Reply-To: <0DD2FBFA-E270-40B2-8454-913DD93672CB@hopcount.ca> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com><1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com><4a64e2f70812040647l426ddcafie295a02d6fa2a61f@mail.gmail.com> <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> <49380009.8050407@rxsec.com> <0DD2FBFA-E270-40B2-8454-913DD93672CB@hopcount.ca> Message-ID: <49382D12.3000400@mtcc.com> Joe Abley wrote: > This is straying far from network operations, but I think 911 generally > engenders an unnecessary degree of hysteria. As I suggested before, the > marketing of this fear from certain quarters has apparently been quiet > effective. > > The probability of any single individual needing to call 911 is already > minute. The probably that all available cell and VoIP services also > won't work precisely at the moment that a 911 call needs to be made is > even smaller. We haven't really had a major catastrophe where we've been totally dependent on IP yet, AFIAK. Maybe all of the qos, call gapping and the rest of the stuff the TDM networks do to deal with disasters will be left in the dustbin of Moore's Law, but maybe they won't. One thing is certain: we'll definitely find out one day, and it's not likely to be from a position of having taken the precautions, congratulating ourselves IMO. Mike From smb at cs.columbia.edu Thu Dec 4 13:28:27 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Thu, 4 Dec 2008 14:28:27 -0500 Subject: Telecom Collapse? In-Reply-To: <49382D12.3000400@mtcc.com> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> <4a64e2f70812040647l426ddcafie295a02d6fa2a61f@mail.gmail.com> <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> <49380009.8050407@rxsec.com> <0DD2FBFA-E270-40B2-8454-913DD93672CB@hopcount.ca> <49382D12.3000400@mtcc.com> Message-ID: <20081204142827.4d558bcb@cs.columbia.edu> On Thu, 04 Dec 2008 11:18:42 -0800 Michael Thomas wrote: > Joe Abley wrote: > > This is straying far from network operations, but I think 911 > > generally engenders an unnecessary degree of hysteria. As I > > suggested before, the marketing of this fear from certain quarters > > has apparently been quiet effective. > > > > The probability of any single individual needing to call 911 is > > already minute. The probably that all available cell and VoIP > > services also won't work precisely at the moment that a 911 call > > needs to be made is even smaller. > > We haven't really had a major catastrophe where we've been totally > dependent on IP yet, AFIAK. Maybe all of the qos, call gapping and > the rest of the stuff the TDM networks do to deal with disasters > will be left in the dustbin of Moore's Law, but maybe they won't. > One thing is certain: we'll definitely find out one day, and it's not > likely to be from a position of having taken the precautions, > congratulating ourselves IMO. > http://www.nap.edu/catalog.php?record_id=10569 is probably worth reading. --Steve Bellovin, http://www.cs.columbia.edu/~smb From Rod.Beck at hiberniaatlantic.com Thu Dec 4 13:36:18 2008 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Thu, 4 Dec 2008 19:36:18 -0000 Subject: [SPAM-HEADER] - Re: Telecom Collapse? - Email has different SMTP TO: and MIME TO: fields in the email addresses References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com><20081204144827.GA827386@hiwaay.net> <20081204190906.GA11514@panix.com> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB9F67D4@bert.HiberniaAtlantic.local> I am not sure. Business lines are significantly higher priced than residential lines and the conventional wisdom was that there is a cross sudsidy. How it shakes out across all phone lines is unclear to me. A lot depends on the economic realism of depreciation schedule. I'm not familiar with how plant is depreciated. An interesting issue related is the book value of assets. Does anyone believe that the book value of telecom assets approximates its market value? In other words, I suspect at least some of the competitive players are insolvent (negative net worth) since their physical assets would only fetch a pittance in a Chapter 7 auction. And yes, I decline to identify specific cases. :) Regards, Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com Wireless: 1-212-444-8829. French Landline: 33+1+4355+8224 French Wireless: 33-6-14-33-48-97. AOL Messenger: GlobalBandwidth rod.beck at hiberniaatlantic.com rodbeck at erols.com ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. From bburke at merit.edu Thu Dec 4 13:42:35 2008 From: bburke at merit.edu (Betty Burke) Date: Thu, 4 Dec 2008 14:42:35 -0500 (EST) Subject: NANOG45 Update In-Reply-To: <49382DD1.2070401@merit.edu> Message-ID: <649668917.570401228419755042.JavaMail.root@crono> Hi Everyone:> On behalf of Merit, we look forward to our continued working relationship with the NANOG SC and PC who are working hard to bring a great program to NANOG45. Our Host, Terremark, continues to work hard to provide all of the additional support items to make everyone comfortable in Santo Domingo. A meeting that is sure to be unique, and one you will not want to miss! The Program Committee has been working very hard, a draft of the complete agenda is expected very early next week. A highlight of the agenda topics can be found at: http://nanog.org/meetings/nanog45/agenda.php The attendee list can be found at: https://nanog.merit.edu/registration/attendee.list.epl?MEETING_ID=45 Lastly, take advantage of the early registration fee, do consider getting your registration completed via: https://nanog.merit.edu/registration/ Of additional importance are our NANOG Sponsors. We appreciate the current economic impact on budgets. However, NANOG continues to be the premier event for national and international network operators, engineers, content providers, and of course the peering community; an event which provides sponsors low cost direct access to customers. Send your inquiry to nanong-support at nanog.org. We will work hard to design a NANOG45 package that works for your company and NANOG. Look forward to seeing many of you in late January 2009! As always, if you have any questions or concerns, feel free to contact Merit directly via nanog-support at nanog.org or any of the NANOG committees. All best. Betty Merit Network Inc. (734)527-5763 From frnkblk at iname.com Thu Dec 4 15:10:29 2008 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 4 Dec 2008 15:10:29 -0600 Subject: Telecom Collapse? In-Reply-To: <20081204144827.GA827386@hiwaay.net> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <20081204144827.GA827386@hiwaay.net> Message-ID: The ILEC is the carrier of last resort. The wireless carrier doesn't have to build coverage everywhere. They don't need to serve that hog barn that requires a 10,000 feet copper loop while playing $17/month. The problem is that whether the take rate for POTS is 75% or 95%, the ILEC still needs to maintain the plant, and capital expenses to maintain the plant are a killer. Either the FCC needs to release ILECs from their coverage obligations so that they can do what CLECs have done and build to the most profitable areas, or subsidize the plant for both POTS and broadband services. Frank -----Original Message----- From: Chris Adams [mailto:cmadams at hiwaay.net] Sent: Thursday, December 04, 2008 8:48 AM To: nanog at nanog.org Subject: Re: Telecom Collapse? Once upon a time, Paul Ferguson said: > I deliberated for a while on whether to send this, or not, but I figure it > might be of interest to this community: > > http://techliberation.com/2008/12/04/telecom-collapse/ One thing doesn't make sense in that article: it talks about POTS being subsidized by other services, and people cutting POTS lines. Wouldn't that be _good_ for the companies and their other services? The way the article describes things, fewer POTS lines = smaller subsidies taken from other services = better profits for other services and the company. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From streiner at cluebyfour.org Thu Dec 4 15:24:06 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 4 Dec 2008 16:24:06 -0500 (EST) Subject: Telecom Collapse? In-Reply-To: References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <20081204144827.GA827386@hiwaay.net> Message-ID: On Thu, 4 Dec 2008, Frank Bulk wrote: > The ILEC is the carrier of last resort. The wireless carrier doesn't have > to build coverage everywhere. They don't need to serve that hog barn that > requires a 10,000 feet copper loop while playing $17/month. They gladly hit you up for an FCC mandated universal service fee on your monthly phone bill precisely to fund those subsidies. I remain unsympathetic to their plight. jms From erik_list at caneris.com Thu Dec 4 15:29:09 2008 From: erik_list at caneris.com (Erik (Caneris)) Date: Thu, 4 Dec 2008 16:29:09 -0500 Subject: Telecom Collapse? In-Reply-To: <49380009.8050407@rxsec.com> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com><1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com><4a64e2f70812040647l426ddcafie295a02d6fa2a61f@mail.gmail.com> <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net>, <49380009.8050407@rxsec.com> Message-ID: I find it amusing that: 1. Many assume one is able to get POTS everywhere 2. How some use the term "POTS" when in reality they're referring to VoIP Pardon the length, but to make the point, here's one of many Canadian examples some of us are intimately familiar with: -Construction conglomerate starts up a CLEC -Construction conglomerate doesn't permit ILEC into new subdivisions it's building in the heart of ILEC's territory, instead all POTS infrastructure including a "new CO" is built by its money-printing press...err, newly registered CLEC, which begins providing voice and data there -ILEC's "mortal enemy", the local cableco, owns minor % of CLEC, and also happens to serve this new subdivision with its cable-based products -A year passes. VoIP over HFC...pardon me, "Digital Cable Phone" is introduced. Cableco buys out remainder of CLEC. -Cableco decides to throw out all the new equipment the CLEC has and begins forced migrations of customers to its VoIP...sorry, "IP Telephony" service over the cable network, refusing new POTS orders -Cableco founder dies...oh wait, that's probably unrelated Often MDUs (residential condominiums typically) here will create exclusive agreements with cablecos and others to provide "POTS" (POTS look-alike is often the result). But wait, cries the poor CLEC, what about my CRTC-given right of access to buildings so I can do the same thing? You don't always have a choice. You just can't get "POTS" in such cases. If a change such as the one described happens, you simply have no choice but to move. The question then is, is the sole alternative equally as reliable? That seems to vary greatly on an individual basis. If I'm just a user plugging in my 1980s Nortel phone into the same RJ-11 jack I had 10 years ago, it still looks like POTS with the same 911 reliability to me, right? Just because my provider runs the largest HFC network in the province, has at most four hours of battery at the nodes and even less at an MTA, isn't a LEC, doesn't have the ability to get anywhere close to interfacing with the PSAP, relies on a third party to do all 911 prov for them, this party happens to be a CLEC of questionable quality and possessing severely broken OSS, doesn't mean that I'm not perfectly safe nor that I can't call this system "POTS", right? How about CLECs who put up a "CO" in the field (and literally in a field!) and have no clue on how to power it in such a way as to prevent 13 hour voice and data outages? That reminds me I still need to request credit for that Sunday in November. If you guys are on nanog and reading this, just send over the $, eh? :) So it can be argued both ways. Ultimately, it all comes down to marketing and hype. With everything going to IP at both the core and edge (yes, I chose the terms deliberately) and analogue-digital-analogue or TDM-IP-TDM-IP conversation happening so many times, the terms "POTS" and "VOIP" are becoming nothing but marketing speak open for abuse. Often, confused by marketing of the "big boys", the end users have no clue what they're using, especially when it's CPE-less like VoIP-behind-POTS or "hosted PBX" or FTTB or cable or even things powered by field equipment. A certain company here tells DSL folks they're on fibre and another one emphasizes to staff to refer to their cable phone service as "it's not VoIP, it's IP telephony" (I'm not kidding). Regards, -- Erik Caneris Tel: 647-723-6365 Fax: 647-723-5365 Toll-free: 1-866-827-0021 www.caneris.com ________________________________________ From: Chris Marlatt [cmarlatt at rxsec.com] Sent: Thursday, December 04, 2008 11:06 AM To: Paul Stewart; nanog at nanog.org Subject: Re: Telecom Collapse? Paul Stewart wrote: > > There's at least two cell phones in our house whenever the family is > home and I have neighbors within quick walking distance. > That's assuming they're not doing the same thing you are, are home, or are willing to let you borrow their phone. You're assuming a lot. I find it surprising that many people replying haven't kept a 911 only POTS line. Regards, Chris From cmarlatt at rxsec.com Thu Dec 4 15:50:26 2008 From: cmarlatt at rxsec.com (Chris Marlatt) Date: Thu, 04 Dec 2008 16:50:26 -0500 Subject: Telecom Collapse? In-Reply-To: References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com><1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com><4a64e2f70812040647l426ddcafie295a02d6fa2a61f@mail.gmail.com> <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net>, <49380009.8050407@rxsec.com> Message-ID: <493850A2.8060904@rxsec.com> Erik (Caneris) wrote: > > So it can be argued both ways. Ultimately, it all comes down to marketing and hype. With everything going to IP at both the core and edge (yes, I chose the terms deliberately) and analogue-digital-analogue or TDM-IP-TDM-IP conversation happening so many times, the terms "POTS" and "VOIP" are becoming nothing but marketing speak open for abuse. Often, confused by marketing of the "big boys", the end users have no clue what they're using, especially when it's CPE-less like VoIP-behind-POTS or "hosted PBX" or FTTB or cable or even things powered by field equipment. A certain company here tells DSL folks they're on fibre and another one emphasizes to staff to refer to their cable phone service as "it's not VoIP, it's IP telephony" (I'm not kidding). > > > Regards, > -- > Erik > Caneris None of the above matters if the supposed POTS lines has a greater availability over the true VOIP phone you use via your residential internet service. If "they" can trick the customer by providing the "analogue-digital-analogue" service so well that the customer doesn't realize it then the originating comment that started this tangent is moot. They are providing a reliable E911 service over IP. If they're not providing a more reliable service than we're back to the same point. E911 over ip (and VOIP) are generally less reliable than true POTS. Regards, Chris From frnkblk at iname.com Thu Dec 4 15:53:10 2008 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 4 Dec 2008 15:53:10 -0600 Subject: Telecom Collapse? In-Reply-To: References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <20081204144827.GA827386@hiwaay.net> Message-ID: They do. But I'm sure you know the FCC has capped some of the funds, with plans to cap more of it. That may be good or bad, depending if you're a wireless or wireline carrier drawing on those funds or not. Frank -----Original Message----- From: Justin M. Streiner [mailto:streiner at cluebyfour.org] Sent: Thursday, December 04, 2008 3:24 PM To: nanog at nanog.org Subject: RE: Telecom Collapse? On Thu, 4 Dec 2008, Frank Bulk wrote: > The ILEC is the carrier of last resort. The wireless carrier doesn't have > to build coverage everywhere. They don't need to serve that hog barn that > requires a 10,000 feet copper loop while playing $17/month. They gladly hit you up for an FCC mandated universal service fee on your monthly phone bill precisely to fund those subsidies. I remain unsympathetic to their plight. jms From lorell at hathcock.org Thu Dec 4 15:57:22 2008 From: lorell at hathcock.org (Lorell Hathcock) Date: Thu, 4 Dec 2008 15:57:22 -0600 Subject: Telecom Collapse? In-Reply-To: References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <20081204144827.GA827386@hiwaay.net> Message-ID: <02f401c9565b$49a6f160$dcf4d420$@org> The classic problem of the ILECs is that they have a government backed monopoly on the local loops everywhere and they leverage that monopoly to compete with companies that don't have government backing. For my $0.02,there are two good options. 1. Eliminate the FCC Universal Service/Coverage funds and let that farmer pay the full rates for connecting his hog barn. (If we had pursued this option years ago, wireless would be much more mature and ubiquitous by now.) 2. Have the government meddle with the ILECs... er, ILEC (singular) and divide the local loops into a different company that provides a platform for selling standardized products and services at wholesale rates to all CLECs. This resulting company would not be allowed to sell to end users just registered CLECs. I hate government created monopolies. It is obvious to the rest of the world that the US does not follow our own principles of "democracy". (More correctly it should be termed a "republic"). With corporate commercial welfare rampant, the free market does not exist. Lorell Hathcock -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Thursday, December 04, 2008 3:10 PM To: 'Chris Adams'; nanog at nanog.org Subject: RE: Telecom Collapse? The ILEC is the carrier of last resort. The wireless carrier doesn't have to build coverage everywhere. They don't need to serve that hog barn that requires a 10,000 feet copper loop while playing $17/month. The problem is that whether the take rate for POTS is 75% or 95%, the ILEC still needs to maintain the plant, and capital expenses to maintain the plant are a killer. Either the FCC needs to release ILECs from their coverage obligations so that they can do what CLECs have done and build to the most profitable areas, or subsidize the plant for both POTS and broadband services. Frank From jayfar at jayfar.com Thu Dec 4 16:09:00 2008 From: jayfar at jayfar.com (Jay Farrell) Date: Thu, 4 Dec 2008 17:09:00 -0500 Subject: Telecom Collapse? In-Reply-To: <6762a99d0812040936q3308e3e4j9d16aeac87698cec@mail.gmail.com> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <20081204172040.GA94137@typo.org> <6762a99d0812040936q3308e3e4j9d16aeac87698cec@mail.gmail.com> Message-ID: <890005330812041409v3a6ad9c5gaaa1735a0d0126fa@mail.gmail.com> The Verizon lay-offs article you linked to ("Verizon just laid off thousands of people ") in the blog post is dated December 29, *2002* Cheers, Jayfar On Thu, Dec 4, 2008 at 12:36 PM, Jim Cowie wrote: > On Thu, Dec 4, 2008 at 12:20 PM, Wayne E. Bouchard wrote: > > > That the old ILECs are having problems due to the fact that few if any > > of them know how to run a decent business is not exactly news. IMO, it > > might be best if some of them were finaly placed in the position of > > figuring out how to come into the 21st century and actually compete > > for business. > > > I wasn't going to say anything, but as long as you brought it up ... > > http://www.renesys.com/blog/2008/12/fiber-to-the-home-ideal-econom.shtml > > Outlandish and bizarre, yes, but perhaps no more so than the other things > you read in the > papers these days? --jim > From jbates at brightok.net Thu Dec 4 16:16:40 2008 From: jbates at brightok.net (Jack Bates) Date: Thu, 04 Dec 2008 16:16:40 -0600 Subject: Telecom Collapse? In-Reply-To: <02f401c9565b$49a6f160$dcf4d420$@org> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <20081204144827.GA827386@hiwaay.net> <02f401c9565b$49a6f160$dcf4d420$@org> Message-ID: <493856C8.5090604@brightok.net> Lorell Hathcock wrote: > The classic problem of the ILECs is that they have a government backed > monopoly on the local loops everywhere and they leverage that monopoly to > compete with companies that don't have government backing. Monopoly? Really? I could have sworn someone devised the idea of CLEC. > 1. Eliminate the FCC Universal Service/Coverage funds and let that farmer > pay the full rates for connecting his hog barn. (If we had pursued this > option years ago, wireless would be much more mature and ubiquitous by now.) I might accept this if wireless carriers are required to maintain the same levels of service an ILEC is supposed to carry. Oh, the reports to fill out if you take a substantial outage, and the excuses as to why it was unavoidable. > 2. Have the government meddle with the ILECs... er, ILEC (singular) and > divide the local loops into a different company that provides a platform for > selling standardized products and services at wholesale rates to all CLECs. > This resulting company would not be allowed to sell to end users just > registered CLECs. What's wrong with the current method? CLEC moves in, borrows plant from ILEC to start service. Over time, CLEC puts their own plant into the ground. Both companies take a hit as they now have fewer customers in the profit zone to cover the cost of plant, and ILEC loses out more due to the hog barns which the CLEC won't dare extend plant to. > I hate government created monopolies. It is obvious to the rest of the > world that the US does not follow our own principles of "democracy". (More > correctly it should be termed a "republic"). > > With corporate commercial welfare rampant, the free market does not exist. > It's not a monopoly when competition is allowed, yet no one wants to compete in a business that won't generate them a profit. Most CLECs stick to highly populated areas and won't even bother with the mid sized towns. If you own a CLEC, please, feel free to lease some lines from AT&T in Ardmore, OK while you put some plant in. I'm sure people there would like more choices than wireless, cable, and ILEC. Jack From surfer at mauigateway.com Thu Dec 4 16:23:27 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 4 Dec 2008 14:23:27 -0800 Subject: Telecom Collapse? Message-ID: <20081204142327.FA6343DD@resin17.mta.everyone.net> --- Valdis.Kletnieks at vt.edu wrote: --------------------- On Wed, 03 Dec 2008 22:59:00 PST, Paul Ferguson said: > I deliberated for a while on whether to send this, or not, but I figure it > might be of interest to this community: > > http://techliberation.com/2008/12/04/telecom-collapse/ The article goes on to quote some other source regarding Hawaiian Telecom's collapse. The *very first sentence* of the quote: "Customers initially had complained about poor service." I quit reading after that, as I could already see where this was heading. --------------------------------------------------------- As with many articles, there is a lot more here than meets the eye. The article is partially about my employer: Hawaiian Telcom. At least for the small telcos, like Hawaiian Telcom, this is important: "...we could free the phone companies to configure and price their basic phone service more efficiently, let them build broadband networks which can compete with the cable companies or anyone else and free taxpayers to rescue someone else." I never realized how hard core the regulatory hurdles are to ILEC competition until I came to work for one. The cable companies have no such barriers. scott From bfeeny at mac.com Thu Dec 4 16:23:36 2008 From: bfeeny at mac.com (Brian Feeny) Date: Thu, 04 Dec 2008 17:23:36 -0500 Subject: Stress Testing LAN/WAN Message-ID: <5D4CC796-6160-4275-A1EC-F524F8EF9AC4@mac.com> I have the need to stress test a LAN and WAN. The primary concern is the WAN which is at most OC-3. The LAN would be an additional bonus if I could do that as well. I am familiar with tools such as those from Spirent and IXIA which are very expensive. I was wondering if someone has had to do this and can recommend some open source tools that would work well. I need to test a few different types of traffic, specifically trying to push traffic into various switch/ router policies to make sure everything is performing as expected. If anyone knows of some software that works well for this I would appreciate letting me know. Thanks, Brian From nanog at daork.net Thu Dec 4 16:26:50 2008 From: nanog at daork.net (Nathan Ward) Date: Fri, 5 Dec 2008 11:26:50 +1300 Subject: Stress Testing LAN/WAN In-Reply-To: <5D4CC796-6160-4275-A1EC-F524F8EF9AC4@mac.com> References: <5D4CC796-6160-4275-A1EC-F524F8EF9AC4@mac.com> Message-ID: <85A81FA7-C323-4BB9-ABD7-325FCEBAE2B9@daork.net> On 5/12/2008, at 11:23 AM, Brian Feeny wrote: > > I have the need to stress test a LAN and WAN. The primary concern > is the WAN which is at most OC-3. The LAN would be an additional > bonus if I could do that as well. > I am familiar with tools such as those from Spirent and IXIA which > are very expensive. I was wondering if someone has had to do this > and can recommend some open source > tools that would work well. I need to test a few different types of > traffic, specifically trying to push traffic into various switch/ > router policies to make sure everything is performing as > expected. If anyone knows of some software that works well for this > I would appreciate letting me know. iPerf. -- Nathan Ward From billf at mu.org Thu Dec 4 16:37:09 2008 From: billf at mu.org (bill fumerola) Date: Thu, 4 Dec 2008 14:37:09 -0800 Subject: Telecom Collapse? In-Reply-To: <1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> Message-ID: <20081204223709.GC97614@elvis.mu.org> On Wed, Dec 03, 2008 at 11:10:57PM -0800, Mike Lyon wrote: > Anyways, for residential VOIP, where are we these days with E911? Are > providers like Vonage and such providing reliable E911 when people > call 911? That is one of the major problems I see with the residential > realm going with VOIP offerings... workgroup: http://www.ietf.org/html.charters/ecrit-charter.html mailing list archives: http://www.ietf.org/mail-archive/web/ecrit/current/maillist.html internet drafts, past and present: http://tools.ietf.org/wg/ecrit/ someone else will have to speak to implementations.. -- bill From Josh.Stephens at solarwinds.com Thu Dec 4 16:52:49 2008 From: Josh.Stephens at solarwinds.com (Stephens, Josh) Date: Thu, 4 Dec 2008 16:52:49 -0600 Subject: Stress Testing LAN/WAN In-Reply-To: <85A81FA7-C323-4BB9-ABD7-325FCEBAE2B9@daork.net> References: <5D4CC796-6160-4275-A1EC-F524F8EF9AC4@mac.com> <85A81FA7-C323-4BB9-ABD7-325FCEBAE2B9@daork.net> Message-ID: <832C54C8546AD0409AEA7E9FEBBEA1EC7454B1@AUS-EXC-01.tul.solarwinds.net> You can download a copy of the SolarWinds toolset from our website (the eval is free). There's a traffic generator in there called "WAN Killer". Give it a try. Josh -----Original Message----- From: Nathan Ward [mailto:nanog at daork.net] Sent: Thursday, December 04, 2008 4:27 PM To: nanog list Subject: Re: Stress Testing LAN/WAN On 5/12/2008, at 11:23 AM, Brian Feeny wrote: > > I have the need to stress test a LAN and WAN. The primary concern > is the WAN which is at most OC-3. The LAN would be an additional > bonus if I could do that as well. > I am familiar with tools such as those from Spirent and IXIA which > are very expensive. I was wondering if someone has had to do this > and can recommend some open source > tools that would work well. I need to test a few different types of > traffic, specifically trying to push traffic into various switch/ > router policies to make sure everything is performing as > expected. If anyone knows of some software that works well for this > I would appreciate letting me know. iPerf. -- Nathan Ward From dholmes at mwdh2o.com Thu Dec 4 17:08:51 2008 From: dholmes at mwdh2o.com (Holmes,David A) Date: Thu, 4 Dec 2008 15:08:51 -0800 Subject: Stress Testing LAN/WAN In-Reply-To: <832C54C8546AD0409AEA7E9FEBBEA1EC7454B1@AUS-EXC-01.tul.solarwinds.net> References: <5D4CC796-6160-4275-A1EC-F524F8EF9AC4@mac.com><85A81FA7-C323-4BB9-ABD7-325FCEBAE2B9@daork.net> <832C54C8546AD0409AEA7E9FEBBEA1EC7454B1@AUS-EXC-01.tul.solarwinds.net> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E0802874D@usmsxt104.mwd.h2o> I have used Solarwinds Wan Killer, but have yet to discover a method of initiating round-trip traffic from a single generator, but Solarwinds can stress a GiGE MAN link using a desktop PC with a GiGE card as the generator. -----Original Message----- From: Stephens, Josh [mailto:Josh.Stephens at solarwinds.com] Sent: Thursday, December 04, 2008 2:53 PM To: Nathan Ward; nanog list Subject: RE: Stress Testing LAN/WAN You can download a copy of the SolarWinds toolset from our website (the eval is free). There's a traffic generator in there called "WAN Killer". Give it a try. Josh -----Original Message----- From: Nathan Ward [mailto:nanog at daork.net] Sent: Thursday, December 04, 2008 4:27 PM To: nanog list Subject: Re: Stress Testing LAN/WAN On 5/12/2008, at 11:23 AM, Brian Feeny wrote: > > I have the need to stress test a LAN and WAN. The primary concern > is the WAN which is at most OC-3. The LAN would be an additional > bonus if I could do that as well. > I am familiar with tools such as those from Spirent and IXIA which > are very expensive. I was wondering if someone has had to do this > and can recommend some open source > tools that would work well. I need to test a few different types of > traffic, specifically trying to push traffic into various switch/ > router policies to make sure everything is performing as > expected. If anyone knows of some software that works well for this > I would appreciate letting me know. iPerf. -- Nathan Ward From Josh.Stephens at solarwinds.com Thu Dec 4 17:11:02 2008 From: Josh.Stephens at solarwinds.com (Stephens, Josh) Date: Thu, 4 Dec 2008 17:11:02 -0600 Subject: Stress Testing LAN/WAN In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E0802874D@usmsxt104.mwd.h2o> References: <5D4CC796-6160-4275-A1EC-F524F8EF9AC4@mac.com><85A81FA7-C323-4BB9-ABD7-325FCEBAE2B9@daork.net> <832C54C8546AD0409AEA7E9FEBBEA1EC7454B1@AUS-EXC-01.tul.solarwinds.net> <485ED9BA02629E4BBBA53AC892EDA50E0802874D@usmsxt104.mwd.h2o> Message-ID: <832C54C8546AD0409AEA7E9FEBBEA1EC7454C8@AUS-EXC-01.tul.solarwinds.net> To generate round-trip traffic you have to enable echo services on the target host and then send to that port. On a Windows box I think it's called "Simple TCP Services" and then you send the traffic to TCP Echo. HTH, Josh -----Original Message----- From: Holmes,David A [mailto:dholmes at mwdh2o.com] Sent: Thursday, December 04, 2008 5:09 PM To: Stephens, Josh; Nathan Ward; nanog list Subject: RE: Stress Testing LAN/WAN I have used Solarwinds Wan Killer, but have yet to discover a method of initiating round-trip traffic from a single generator, but Solarwinds can stress a GiGE MAN link using a desktop PC with a GiGE card as the generator. -----Original Message----- From: Stephens, Josh [mailto:Josh.Stephens at solarwinds.com] Sent: Thursday, December 04, 2008 2:53 PM To: Nathan Ward; nanog list Subject: RE: Stress Testing LAN/WAN You can download a copy of the SolarWinds toolset from our website (the eval is free). There's a traffic generator in there called "WAN Killer". Give it a try. Josh -----Original Message----- From: Nathan Ward [mailto:nanog at daork.net] Sent: Thursday, December 04, 2008 4:27 PM To: nanog list Subject: Re: Stress Testing LAN/WAN On 5/12/2008, at 11:23 AM, Brian Feeny wrote: > > I have the need to stress test a LAN and WAN. The primary concern > is the WAN which is at most OC-3. The LAN would be an additional > bonus if I could do that as well. > I am familiar with tools such as those from Spirent and IXIA which > are very expensive. I was wondering if someone has had to do this > and can recommend some open source > tools that would work well. I need to test a few different types of > traffic, specifically trying to push traffic into various switch/ > router policies to make sure everything is performing as > expected. If anyone knows of some software that works well for this > I would appreciate letting me know. iPerf. -- Nathan Ward From yahoo at jimpop.com Thu Dec 4 17:36:16 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Thu, 4 Dec 2008 18:36:16 -0500 Subject: network testbed (was: Stress Testing LAN/WAN) Message-ID: <7ff145960812041536o96df82fk8db8d96330af1fbb@mail.gmail.com> Coincidentally, this week I was asked to specify current and next-gen equipment for a new network testbed at $DAYJOB. This lab would be used to test software used to monitor large networks. Specifically I need to setup an environment similar to that of large SPs, with emphasis on MPLS, STP, OSPF and BGP. What present and next-gen hardware would you recommend to include in such a testbed? I have vendor C pretty well covered, and I am really trying to look outside the box on this, but whatever you want to recommend is welcome. Private replies are also welcome, I can post a recap once I've received some feedback. Thanks, -Jim P. On Thu, Dec 4, 2008 at 17:23, Brian Feeny wrote: > > I have the need to stress test a LAN and WAN. The primary concern is the > WAN which is at most OC-3. The LAN would be an additional bonus if I could > do that as well. > I am familiar with tools such as those from Spirent and IXIA which are very > expensive. I was wondering if someone has had to do this and can recommend > some open source > tools that would work well. I need to test a few different types of > traffic, specifically trying to push traffic into various switch/router > policies to make sure everything is performing as > expected. If anyone knows of some software that works well for this I would > appreciate letting me know. > > Thanks, > > Brian > > > From bdfleming at kanren.net Thu Dec 4 17:37:38 2008 From: bdfleming at kanren.net (Brad Fleming) Date: Thu, 4 Dec 2008 17:37:38 -0600 Subject: Stress Testing LAN/WAN In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E0802874D@usmsxt104.mwd.h2o> References: <5D4CC796-6160-4275-A1EC-F524F8EF9AC4@mac.com><85A81FA7-C323-4BB9-ABD7-325FCEBAE2B9@daork.net> <832C54C8546AD0409AEA7E9FEBBEA1EC7454B1@AUS-EXC-01.tul.solarwinds.net> <485ED9BA02629E4BBBA53AC892EDA50E0802874D@usmsxt104.mwd.h2o> Message-ID: With iperf, you can use the -d option to initiate a "real-time parallel" test (my term). You can also use the -r option to run a "trade-off parallel" test (again, my term). To see the other options iperf offers: http://pirlwww.lpl.arizona.edu/resources/guide/software/iperf/ Sounds like you might also be interested in the -B option. When coupled with multiple interfaces, you can pretty easily test QoS configs by sourcing from different interfaces / IPs (if that's your identifying characteristic). KanREN uses iperf on Mac Minis running OSX 10.5 with great results. The newer Minis can pretty easily push 950+Mbps if you run 4 or more streams (-n option). Or at least that has been our experience. I would also suggest doing some TCP buffer tuning if you anticipate round-trip latency to be >20ms. Here are some general guidelines for various platforms: http://fasterdata.es.net/TCP-tuning// On Dec 4, 2008, at 5:08 PM, Holmes,David A wrote: > I have used Solarwinds Wan Killer, but have yet to discover a method > of > initiating round-trip traffic from a single generator, but Solarwinds > can stress a GiGE MAN link using a desktop PC with a GiGE card as the > generator. -- Brad Fleming Network Engineer Kansas Research and Education Network Office: 785-856-9800 x.222 Moblie: 785-865-7231 NOC: 866-984-3662 From a.harrowell at gmail.com Thu Dec 4 18:16:38 2008 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Fri, 5 Dec 2008 00:16:38 +0000 Subject: Telecom Collapse? In-Reply-To: <49382D12.3000400@mtcc.com> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> <4a64e2f70812040647l426ddcafie295a02d6fa2a61f@mail.gmail.com> <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> <49380009.8050407@rxsec.com> <0DD2FBFA-E270-40B2-8454-913DD93672CB@hopcount.ca> <49382D12.3000400@mtcc.com> Message-ID: On Thu, Dec 4, 2008 at 7:18 PM, Michael Thomas wrote: > We haven't really had a major catastrophe where we've been totally > dependent on IP yet, AFIAK. Maybe all of the qos, call gapping and > the rest of the stuff the TDM networks do to deal with disasters > will be left in the dustbin of Moore's Law, but maybe they won't. One > thing is certain: we'll definitely find out one day, and it's not > likely to be from a position of having taken the precautions, > congratulating ourselves IMO. The only disaster I experienced which affected telecoms was the July, 2005 terrorist attack on London. Although the infrastructure wasn't affected, there were significant load challenges for the GSM nets especially. It was widely assumed by the unclued that either one or two GSM operators failed under peak load; by the clued that the Access Overload Control process, analogous to the PSTN's Government Telephone Preference Scheme, had been initiated to deal with the peak load. In fact, it turned out much later that AOC had indeed been declared, but unnecessarily, and against the decision of the lead agency dealing with the emergency. The Metropolitan Police didn't request it, but the (smaller) City of London force did, although the network in question was coping - the entire outage was caused by mismanaging the TDM call-gapping and QoS features. Both the Internet, and our corporate VoIP system including its peering with the wider PSTN, worked throughout. From meekjt at gmail.com Thu Dec 4 18:29:05 2008 From: meekjt at gmail.com (Jon Meek) Date: Thu, 4 Dec 2008 19:29:05 -0500 Subject: Stress Testing LAN/WAN In-Reply-To: References: <5D4CC796-6160-4275-A1EC-F524F8EF9AC4@mac.com> <85A81FA7-C323-4BB9-ABD7-325FCEBAE2B9@daork.net> <832C54C8546AD0409AEA7E9FEBBEA1EC7454B1@AUS-EXC-01.tul.solarwinds.net> <485ED9BA02629E4BBBA53AC892EDA50E0802874D@usmsxt104.mwd.h2o> Message-ID: We use iperf running off of a bootable Linux CD with a 2.4 Kernel and can push 960 to 980 Mbps with no drops or errors on any pair of PCs with Gig interfaces we have tried so far. We usually 10 TCP streams, or tune the TCP stack and use a single stream. We also capture the traffic on both sides, run a standard analysis, and plot the send and receive per-second utilization and the re-transmit rate from the send side. Jon From tom at dyndns.com Thu Dec 4 20:16:19 2008 From: tom at dyndns.com (Tom Daly) Date: Thu, 4 Dec 2008 21:16:19 -0500 (EST) Subject: NANOG 45: Register Now, Hotel Link Available In-Reply-To: <1326848.19931228325785070.JavaMail.root@mail.corp.dyndns.com> Message-ID: <1946454.32771228443379887.JavaMail.root@mail.corp.dyndns.com> Folks, NANOG 45 in the Dominican Republic is fast approaching, so now is the time to go get registered for the conference. You can register for NANOG 45 at: https://nanog.merit.edu/registration/ I'm also pleased to report that our hotel has provided us with with a direct link for online reservations. You can make your reservations online at: http://cwp.marriott.com/sdqgw/nanog/ Be aware: the hotel is offering very nice rooms at a great rate (part of what should make your travel justification easier), so be sure to register soon. Also, consider booking travel soon. A number of airlines have substantially discounted flights at the moment, but one never knows when they might expire. Looking forward to seeing you all in SDQ, Tom Daly, for the NANOG Program Committee -- Tom Daly tom at dyndns.com Dynamic Network Services, Inc. http://dynamicnetworkservices.com/ From Skywing at valhallalegends.com Thu Dec 4 21:11:50 2008 From: Skywing at valhallalegends.com (Skywing) Date: Thu, 4 Dec 2008 21:11:50 -0600 Subject: Telecom Collapse? In-Reply-To: References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com><1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BEF93691B3@caralain.haven.nynaeve.net> Yes, that's correct as far as I know -- though you might not be able to receive a return call from the dispatcher. - S -----Original Message----- From: Church, Charles [mailto:cchurc05 at harris.com] Sent: Thursday, December 04, 2008 9:44 AM To: Russell J. Lahti Cc: nanog at nanog.org Subject: RE: Telecom Collapse? In the past, an inactive cell phone could still dial 911. I'm not sure if that's still the case, but it used to be, at least with some carriers. Chuck -----Original Message----- From: Russell J. Lahti [mailto:rlahti at glcom.net] Sent: Thursday, December 04, 2008 7:47 AM To: 'Mike Lyon'; 'Alex Rubenstein' Cc: nanog at nanog.org Subject: RE: Telecom Collapse? That is the one and only thing keeping a land line at my home. I have two young children, and I need to be sure that if something were to ever happen that: 1.) The phone would work even if the power was out, or the Internet connectivity was flaking out. 2.) 911 would function exactly the way it is supposed to, and not be routed to some 3rd party call center which could potentially delay a response. I haven't found the power to be reliable, and the cable Internet tends to go down when the power goes out. There's always cellular, but then you have to depend on there being someone with a cell phone around to make the call, and my kids aren't to the age yet that I would want them toting around their own cell phones. As long as my POTS line is more reliable than VoIP, I'll probably keep it. -Russell > -----Original Message----- > From: Mike Lyon [mailto:mike.lyon at gmail.com] > Sent: Thursday, December 04, 2008 2:11 AM > To: Alex Rubenstein > Cc: nanog at nanog.org > Subject: Re: Telecom Collapse? > > That makes two of us... > > Anyways, for residential VOIP, where are we these days with > E911? Are providers like Vonage and such providing reliable > E911 when people call 911? That is one of the major problems > I see with the residential realm going with VOIP offerings... > > -Mike > > > On Wed, Dec 3, 2008 at 11:06 PM, Alex Rubenstein > wrote: > > > >> I deliberated for a while on whether to send this, or not, but I > >> figure it might be of interest to this community: > >> > >> http://techliberation.com/2008/12/04/telecom-collapse/ > > > > Good god. If there is even the mention of a LEC bailout, I > am going to go insane and probably shoot someone (those who > know me know this is a actual possibility). > > > > If the phone companies had actually focused on providing > good, competitive service, this would have never happened. > Instead, they spent money and time on figuring out ways to > screw with their competition, and have legislation passed > that protects them. > > > > People (at least the ones I know) are fed up with dealing > with these companies, and many people I know don't have land > lines and never intend on having them again. > > > > Let them collapse. It's good for them, us, and the > capitalist in you and me. Go buy a cell phone, and have a coke. > > > > > > > > > > From Skywing at valhallalegends.com Thu Dec 4 21:25:15 2008 From: Skywing at valhallalegends.com (Skywing) Date: Thu, 4 Dec 2008 21:25:15 -0600 Subject: Telecom Collapse? In-Reply-To: <49380009.8050407@rxsec.com> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com><1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com><4a64e2f70812040647l426ddcafie295a02d6fa2a61f@mail.gmail.com> <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> <49380009.8050407@rxsec.com> Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BEF93691B4@caralain.haven.nynaeve.net> No POTS line here. New office is all VoIP, too. For my own use, though, I'm sticking with cell. Don't recall the last time that there was an outage to the point where I couldn't make a voice call in the past few years (though I've seen EVDO data go down for my region and have had to fall back to 1xRTT for an hour or once in the past couple years). Naturally, that doesn't really disprove a negative, but the chances of there being, all at the same time: - a sufficiently localized disaster where I'd have to call 911, and - a sufficiently broad disaster where the cell infrastructure had completely failed for all the CDMA carriers in my area, and - nobody near by who could help or had a landline, and - despite said broad disaster taking out *ALL* CDMA cell networks within range, a condition that still permitted landlines to operate ...seem to be quite vanishing to me. Not impossible, but there's a whole lot more likely concerns to deal with than that, nowadays. The only likely types of situations that might result in that, in general, would probably be things like wide-area hurricane-style events. Those typically provide enough advance warning to get out of harm's way. (Not that I would have to worry about hurricanes in the middle of the continental US, anyway.) - S -----Original Message----- From: Chris Marlatt [mailto:cmarlatt at rxsec.com] Sent: Thursday, December 04, 2008 11:07 AM To: Paul Stewart; nanog at nanog.org Subject: Re: Telecom Collapse? Paul Stewart wrote: > > There's at least two cell phones in our house whenever the family is > home and I have neighbors within quick walking distance. > That's assuming they're not doing the same thing you are, are home, or are willing to let you borrow their phone. You're assuming a lot. I find it surprising that many people replying haven't kept a 911 only POTS line. Regards, Chris From stephen at sprunk.org Thu Dec 4 21:53:09 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 04 Dec 2008 21:53:09 -0600 Subject: Telecom Collapse? In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D6BEF93691B4@caralain.haven.nynaeve.net> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com><1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com><4a64e2f70812040647l426ddcafie295a02d6fa2a61f@mail.gmail.com> <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> <49380009.8050407@rxsec.com> <982D8D05B6407A49AD506E6C3AC8E7D6BEF93691B4@caralain.haven.nynaeve.net> Message-ID: <4938A5A5.2040402@sprunk.org> Skywing wrote: > No POTS line here. New office is all VoIP, too. For my own use, though, I'm sticking with cell. Don't recall the last time that there was an outage to the point where I couldn't make a voice call in the past few years (though I've seen EVDO data go down for my region and have had to fall back to 1xRTT for an hour or once in the past couple years). > Ditto for my GSM/EDGE/3G service; coverage has simply gotten too good (and too cheap) to bother with a land line at home anymore. And that, more than VoIP, is what is killing the ILECs. > Naturally, that doesn't really disprove a negative, but the chances of there being, all at the same time: > > - a sufficiently localized disaster where I'd have to call 911, and > - a sufficiently broad disaster where the cell infrastructure had completely failed for all the CDMA carriers in my area, and > - nobody near by who could help or had a landline, and > - despite said broad disaster taking out *ALL* CDMA cell networks within range, a condition that still permitted landlines to operate > > ...seem to be quite vanishing to me. Not impossible, but there's a whole lot more likely concerns to deal with than that, nowadays. The only likely types of situations that might result in that, in general, would probably be things like wide-area hurricane-style events. Those typically provide enough advance warning to get out of harm's way. (Not that I would have to worry about hurricanes in the middle of the continental US, anyway.) > And, of course, if such an event _did_ occur, the authorities would certainly already know about it without your call -- if you could even get through to them. Even in everyday conditions, calls to 911 here have hold times of several minutes to get an operator. I wouldn't even bother trying, land line or otherwise, if I had an actual emergency; it'd be faster to drive to the nearest hospital/fire station/police station for help. (Unfortunately, the police and fire depts. have stopped publishing their direct numbers, and if you can still find them somewhere, all you get is a recording telling you to call 911 -- even for non-emergency calls.) S -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From nickellman at gmail.com Thu Dec 4 22:12:23 2008 From: nickellman at gmail.com (b nickell) Date: Thu, 4 Dec 2008 21:12:23 -0700 Subject: Telecom Collapse? In-Reply-To: References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> Message-ID: I believe its still the case, but you can order from the local LEC a soft-dial tone. You hear dial tone, however the only calls that can be made are to the LEC's Billing & to the PSAP(911). This might be a good option for people w/ kids, etc. without paying the full price of a land line. I used to work for Hawaiian Tel and we had an earthquake. It knock out the power for several days. Most of our CO's stayed up & supported PSTN due to generators & DC. People who had telephony w/ the cable company lost communications along with their TV. Just a thought. BN On Thu, Dec 4, 2008 at 5:47 AM, Russell J. Lahti wrote: > That is the one and only thing keeping a land line at my home. I > have two young children, and I need to be sure that if something > were to ever happen that: 1.) The phone would work even if the > power was out, or the Internet connectivity was flaking out. > 2.) 911 would function exactly the way it is supposed to, and > not be routed to some 3rd party call center which could potentially > delay a response. > > I haven't found the power to be reliable, and the cable Internet > tends to go down when the power goes out. There's always cellular, > but then you have to depend on there being someone with a cell phone > around to make the call, and my kids aren't to the age yet that I > would want them toting around their own cell phones. As long as > my POTS line is more reliable than VoIP, I'll probably keep it. > > -Russell > > > > > -----Original Message----- > > From: Mike Lyon [mailto:mike.lyon at gmail.com] > > Sent: Thursday, December 04, 2008 2:11 AM > > To: Alex Rubenstein > > Cc: nanog at nanog.org > > Subject: Re: Telecom Collapse? > > > > That makes two of us... > > > > Anyways, for residential VOIP, where are we these days with > > E911? Are providers like Vonage and such providing reliable > > E911 when people call 911? That is one of the major problems > > I see with the residential realm going with VOIP offerings... > > > > -Mike > > > > > > On Wed, Dec 3, 2008 at 11:06 PM, Alex Rubenstein > > wrote: > > > > > >> I deliberated for a while on whether to send this, or not, but I > > >> figure it might be of interest to this community: > > >> > > >> http://techliberation.com/2008/12/04/telecom-collapse/ > > > > > > Good god. If there is even the mention of a LEC bailout, I > > am going to go insane and probably shoot someone (those who > > know me know this is a actual possibility). > > > > > > If the phone companies had actually focused on providing > > good, competitive service, this would have never happened. > > Instead, they spent money and time on figuring out ways to > > screw with their competition, and have legislation passed > > that protects them. > > > > > > People (at least the ones I know) are fed up with dealing > > with these companies, and many people I know don't have land > > lines and never intend on having them again. > > > > > > Let them collapse. It's good for them, us, and the > > capitalist in you and me. Go buy a cell phone, and have a coke. > > > > > > > > > > > > > > > > > > > -- -B From frnkblk at iname.com Thu Dec 4 23:23:32 2008 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 4 Dec 2008 23:23:32 -0600 Subject: Telecom Collapse? In-Reply-To: References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> Message-ID: Even "disconnected" customers due to non-pay have access to E-911.... Frank -----Original Message----- From: b nickell [mailto:nickellman at gmail.com] Sent: Thursday, December 04, 2008 10:12 PM To: Russell J. Lahti Cc: nanog at nanog.org; Alex Rubenstein Subject: Re: Telecom Collapse? I believe its still the case, but you can order from the local LEC a soft-dial tone. You hear dial tone, however the only calls that can be made are to the LEC's Billing & to the PSAP(911). This might be a good option for people w/ kids, etc. without paying the full price of a land line. From fergdawgster at gmail.com Fri Dec 5 01:25:02 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 4 Dec 2008 23:25:02 -0800 Subject: Telecom Collapse? In-Reply-To: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> Message-ID: <6cd462c00812042325w5614efdfxe80b98d7a30aee65@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Dec 3, 2008 at 10:59 PM, Paul Ferguson wrote: > > I deliberated for a while on whether to send this, or not, but I figure > it might be of interest to this community: > > http://techliberation.com/2008/12/04/telecom-collapse/ > On the heals of the rabble-rousing post above :-) come this from BusinessWeek: "AT&T Layoffs: The Tip of a Telecom Downturn" http://www.businessweek.com/technology/content/dec2008/tc2008124_185061.htm I'll stop now. :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJONdHq1pz9mNUZTMRAgtEAKCa2Pf8B68JZAD+KPhNGaXYtU/xrACg3Dgi 77xojrrjCLLAs/9+9b4hqDs= =3Umj -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From rchauvet at haicom.com Fri Dec 5 05:49:54 2008 From: rchauvet at haicom.com (Reginald CHAUVET ( H )) Date: Fri, 5 Dec 2008 06:49:54 -0500 Subject: ARCOS Outage In-Reply-To: <6cd462c00812042325w5614efdfxe80b98d7a30aee65@mail.gmail.com> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <6cd462c00812042325w5614efdfxe80b98d7a30aee65@mail.gmail.com> Message-ID: <4F189BDBD73A43FDA015C58585114F83@ReggieD520> This is my first post on this list. Does anyone on the list knows what happened with the ARCOS submarine cable last night? Last night at 07H14PM Two out of the Three ISP from HAITI connected to the internet backbone on the ARCOS submarine cable through the Dominican Republic at Puerto Plata, experienced a complete outage of internet connectivity. The connectivity was re-established at 10H46PM when the traffic was re-routed through the Antillas submarine cable through Puerto Rico. As we have no direct contact with ARCOS and are buying internet connectivity through operators in the Dominican Republic, it is difficult to obtain clear information as to what exactly happened and or what is the problem. Any info is appreciated. Thanks Reggie Reginald CHAUVET, Ing. President HAICOM Haiti Communications, S.A. 10, Delmas 29; Port-au-Prince, HAITI, HT-6120 011-509-246-2068 Office 011-509-246-2309 Fax 011-509-410-0044 Mobile GSM 011-509-510-0044 Mobile CDMA 305-888-7336 VoIP rchauvet at haicom.com From pfunix at gmail.com Fri Dec 5 07:30:42 2008 From: pfunix at gmail.com (Beavis) Date: Fri, 5 Dec 2008 07:30:42 -0600 Subject: ARCOS Outage In-Reply-To: <4F189BDBD73A43FDA015C58585114F83@ReggieD520> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <6cd462c00812042325w5614efdfxe80b98d7a30aee65@mail.gmail.com> <4F189BDBD73A43FDA015C58585114F83@ReggieD520> Message-ID: I ran through ARCOS(CN) and I didn't get any connectivity disruption yesterday. On Fri, Dec 5, 2008 at 5:49 AM, Reginald CHAUVET ( H ) wrote: > > This is my first post on this list. > > Does anyone on the list knows what happened with the ARCOS submarine cable > last night? > > Last night at 07H14PM Two out of the Three ISP from HAITI connected to the > internet backbone on the ARCOS submarine cable through the Dominican > Republic at Puerto Plata, experienced a complete outage of internet > connectivity. > The connectivity was re-established at 10H46PM when the traffic was > re-routed through the Antillas submarine cable through Puerto Rico. > > As we have no direct contact with ARCOS and are buying internet connectivity > through operators in the Dominican Republic, it is difficult to obtain clear > information as to what exactly happened and or what is the problem. > > Any info is appreciated. > > Thanks > Reggie > > Reginald CHAUVET, Ing. > President > HAICOM > Haiti Communications, S.A. > 10, Delmas 29; > Port-au-Prince, HAITI, HT-6120 > 011-509-246-2068 Office > 011-509-246-2309 Fax > 011-509-410-0044 Mobile GSM > 011-509-510-0044 Mobile CDMA > 305-888-7336 VoIP > rchauvet at haicom.com > > > > From david at cantrell.org.uk Fri Dec 5 08:01:08 2008 From: david at cantrell.org.uk (David Cantrell) Date: Fri, 5 Dec 2008 14:01:08 +0000 Subject: Telecom Collapse? In-Reply-To: <49380EA1.5010600@brightok.net> References: <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> <49380009.8050407@rxsec.com> <0DD2FBFA-E270-40B2-8454-913DD93672CB@hopcount.ca> <49380EA1.5010600@brightok.net> Message-ID: <20081205140108.GD3639@bytemark.barnyard.co.uk> On Thu, Dec 04, 2008 at 11:08:49AM -0600, Jack Bates wrote: > 911 services are heavily used when a geographical area has an emergency, > and that emergency usually includes not having power. Yes, and it usually involves several thousand people all phoning to report the same damned thing, clogging up the emergency service's lines so that *other* emergencies (like, say, someone having a heart attack) don't get dealt with. > Unless you live in a natural disaster prone location. So don't do that. It's really rather silly. I've always thought that people who choose to live on flood plains or on the side of active volcanos etc are at least a little bit crazy. Of course, if they're so poor that they don't have any choice (Bangladesh, perhaps) then they can't afford the non-existent POTS infrastructure anyway - but someone in the village might have a mobile. > Or if your > grandmother's alert bracelet requires a phone line for notification. That's no reason for almost anyone to have a POTS line, because almost everyone doesn't live with their grandmother, and almost all grandmothers don't have alert bracelets. -- David Cantrell | http://www.cantrell.org.uk/david comparative and superlative explained: worse, worser, worsest, worsted, wasted From Rod.Beck at hiberniaatlantic.com Fri Dec 5 08:09:01 2008 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Fri, 5 Dec 2008 14:09:01 -0000 Subject: [SPAM-HEADER] - Re: Telecom Collapse? References: <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net><49380009.8050407@rxsec.com><0DD2FBFA-E270-40B2-8454-913DD93672CB@hopcount.ca><49380EA1.5010600@brightok.net> <20081205140108.GD3639@bytemark.barnyard.co.uk> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB9F67DB@bert.HiberniaAtlantic.local> Folks, I doubt the incumbents are the most vulnerable in this situation. It is debt-laden competitive providers that face the greatest difficulty. Look at balance sheets and who is struggling to generate a profit or who has never generated a profit. Roderick S. Beck Director of European Sales Hibernia Atlantic 13-15, rue Sedaine, 75011 Paris http://www.hiberniaatlantic.com Wireless: 1-212-444-8829. French Landline: 33+1+4355+8224 French Wireless: 33-6-14-33-48-97. AOL Messenger: GlobalBandwidth rod.beck at hiberniaatlantic.com rodbeck at erols.com ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. From me at sharloncarty.net Fri Dec 5 08:16:14 2008 From: me at sharloncarty.net (Sharlon R. Carty) Date: Fri, 5 Dec 2008 10:16:14 -0400 Subject: ARCOS Outage In-Reply-To: References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <6cd462c00812042325w5614efdfxe80b98d7a30aee65@mail.gmail.com> <4F189BDBD73A43FDA015C58585114F83@ReggieD520> Message-ID: Yup, there is a defective card in the Bahamas. They should be flying in this morning to have it replaced. It's been out since yesterday evening. On Fri, Dec 5, 2008 at 9:30 AM, Beavis wrote: > I ran through ARCOS(CN) and I didn't get any connectivity disruption > yesterday. > > > On Fri, Dec 5, 2008 at 5:49 AM, Reginald CHAUVET ( H ) > wrote: > > > > This is my first post on this list. > > > > Does anyone on the list knows what happened with the ARCOS submarine > cable > > last night? > > > > Last night at 07H14PM Two out of the Three ISP from HAITI connected to > the > > internet backbone on the ARCOS submarine cable through the Dominican > > Republic at Puerto Plata, experienced a complete outage of internet > > connectivity. > > The connectivity was re-established at 10H46PM when the traffic was > > re-routed through the Antillas submarine cable through Puerto Rico. > > > > As we have no direct contact with ARCOS and are buying internet > connectivity > > through operators in the Dominican Republic, it is difficult to obtain > clear > > information as to what exactly happened and or what is the problem. > > > > Any info is appreciated. > > > > Thanks > > Reggie > > > > Reginald CHAUVET, Ing. > > President > > HAICOM > > Haiti Communications, S.A. > > 10, Delmas 29; > > Port-au-Prince, HAITI, HT-6120 > > 011-509-246-2068 Office > > 011-509-246-2309 Fax > > 011-509-410-0044 Mobile GSM > > 011-509-510-0044 Mobile CDMA > > 305-888-7336 VoIP > > rchauvet at haicom.com > > > > > > > > > > From tme at multicasttech.com Fri Dec 5 08:21:53 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 5 Dec 2008 09:21:53 -0500 Subject: Telecom Collapse? In-Reply-To: <20081205140108.GD3639@bytemark.barnyard.co.uk> References: <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> <49380009.8050407@rxsec.com> <0DD2FBFA-E270-40B2-8454-913DD93672CB@hopcount.ca> <49380EA1.5010600@brightok.net> <20081205140108.GD3639@bytemark.barnyard.co.uk> Message-ID: On Dec 5, 2008, at 9:01 AM, David Cantrell wrote: > On Thu, Dec 04, 2008 at 11:08:49AM -0600, Jack Bates wrote: > >> 911 services are heavily used when a geographical area has an >> emergency, >> and that emergency usually includes not having power. > > Yes, and it usually involves several thousand people all phoning to > report the same damned thing, clogging up the emergency service's > lines > so that *other* emergencies (like, say, someone having a heart attack) > don't get dealt with. > >> Unless you live in a natural disaster prone location. > > So don't do that. It's really rather silly. > > I've always thought that people who choose to live on flood plains > or on > the side of active volcanos etc are at least a little bit crazy. Of > course, if they're so poor that they don't have any choice > (Bangladesh, > perhaps) then they can't afford the non-existent POTS infrastructure > anyway - but someone in the village might have a mobile. There is literarily no place on the planet that is safe from natural disaster. It's just that the recurrence times differ, and can be rather long in places, giving an illusion of safety. For example, for the recent tsunami in Indonesia, India and Sri Lanka, the recurrence time is estimated to be ~1000 years. Most people would think that they do not have to worry about a once per 1000 year danger, until the water starts entering the second story. Regards Marshall > > >> Or if your >> grandmother's alert bracelet requires a phone line for notification. > > That's no reason for almost anyone to have a POTS line, because almost > everyone doesn't live with their grandmother, and almost all > grandmothers don't have alert bracelets. > > -- > David Cantrell | http://www.cantrell.org.uk/david > > comparative and superlative explained: > > worse, worser, worsest, worsted, wasted > From rchauvet at haicom.com Fri Dec 5 08:24:46 2008 From: rchauvet at haicom.com (Reginald CHAUVET ( H )) Date: Fri, 5 Dec 2008 09:24:46 -0500 Subject: ARCOS Outage In-Reply-To: References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <6cd462c00812042325w5614efdfxe80b98d7a30aee65@mail.gmail.com> <4F189BDBD73A43FDA015C58585114F83@ReggieD520> Message-ID: <24A51B685F3040FB805D3802C46555CC@ReggieD520> Thanks for the confirmation. Regards Reggie _____ From: Sharlon R. Carty [mailto:me at sharloncarty.net] Sent: Friday, December 05, 2008 9:16 AM To: Beavis Cc: rchauvet at haicom.com; nanog at nanog.org Subject: Re: ARCOS Outage Yup, there is a defective card in the Bahamas. They should be flying in this morning to have it replaced. It's been out since yesterday evening. On Fri, Dec 5, 2008 at 9:30 AM, Beavis wrote: I ran through ARCOS(CN) and I didn't get any connectivity disruption yesterday. On Fri, Dec 5, 2008 at 5:49 AM, Reginald CHAUVET ( H ) wrote: > > This is my first post on this list. > > Does anyone on the list knows what happened with the ARCOS submarine cable > last night? > > Last night at 07H14PM Two out of the Three ISP from HAITI connected to the > internet backbone on the ARCOS submarine cable through the Dominican > Republic at Puerto Plata, experienced a complete outage of internet > connectivity. > The connectivity was re-established at 10H46PM when the traffic was > re-routed through the Antillas submarine cable through Puerto Rico. > > As we have no direct contact with ARCOS and are buying internet connectivity > through operators in the Dominican Republic, it is difficult to obtain clear > information as to what exactly happened and or what is the problem. > > Any info is appreciated. > > Thanks > Reggie > > Reginald CHAUVET, Ing. > President > HAICOM > Haiti Communications, S.A. > 10, Delmas 29; > Port-au-Prince, HAITI, HT-6120 > 011-509-246-2068 Office > 011-509-246-2309 Fax > 011-509-410-0044 Mobile GSM > 011-509-510-0044 Mobile CDMA > 305-888-7336 VoIP > rchauvet at haicom.com > > > > From cidr-report at potaroo.net Fri Dec 5 05:00:03 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 5 Dec 2008 22:00:03 +1100 (EST) Subject: BGP Update Report Message-ID: <200812051100.mB5B03o2096476@wattle.apnic.net> BGP Update Report Interval: 03-Nov-08 -to- 04-Dec-08 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 220468 1.9% 174.8 -- SIFY-AS-IN Sify Limited 2 - AS4538 206468 1.8% 40.7 -- ERX-CERNET-BKB China Education and Research Network Center 3 - AS6389 124316 1.1% 28.2 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 4 - AS29282 89169 0.8% 29723.0 -- EMENTOR-AS Enfo Oyj 5 - AS6629 85767 0.8% 1319.5 -- NOAA-AS - NOAA 6 - AS24863 82881 0.7% 121.3 -- LINKdotNET-AS 7 - AS1803 82320 0.7% 58.0 -- ICMNET-5 - Sprint 8 - AS10396 72006 0.6% 1241.5 -- COQUI-NET - DATACOM CARIBE, INC. 9 - AS209 71474 0.6% 23.1 -- ASN-QWEST - Qwest Communications Corporation 10 - AS8151 65993 0.6% 30.0 -- Uninet S.A. de C.V. 11 - AS20115 61091 0.5% 29.5 -- CHARTER-NET-HKY-NC - Charter Communications 12 - AS6478 59692 0.5% 34.0 -- ATT-INTERNET3 - AT&T WorldNet Services 13 - AS6458 52991 0.5% 120.2 -- Telgua 14 - AS6298 52316 0.5% 24.0 -- ASN-CXA-PH-6298-CBS - Cox Communications Inc. 15 - AS7643 50161 0.4% 31.1 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 16 - AS3462 49339 0.4% 238.4 -- HINET Data Communication Business Group 17 - AS2386 47910 0.4% 29.4 -- INS-AS - AT&T Data Communications Services 18 - AS1785 45772 0.4% 26.7 -- AS-PAETEC-NET - PaeTec Communications, Inc. 19 - AS17488 45056 0.4% 30.9 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 20 - AS4323 40246 0.3% 24.9 -- TWTC - tw telecom holdings, inc. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS29282 89169 0.8% 29723.0 -- EMENTOR-AS Enfo Oyj 2 - AS14106 37485 0.3% 18742.5 -- LEPMED01 - Leprechaun, LLC 3 - AS30287 4792 0.0% 4792.0 -- ALON-USA - ALON USA, LP 4 - AS41007 18173 0.2% 3634.6 -- CTCASTANA CTC ASTANA, KZ 5 - AS4130 16727 0.1% 3345.4 -- UPITT-AS - University of Pittsburgh 6 - AS32398 24113 0.2% 3014.1 -- REALNET-ASN-1 7 - AS15561 2972 0.0% 2972.0 -- CDS-ITALY C.D.S. Informatica S.r.l. 8 - AS46115 29419 0.3% 2941.9 -- LUTHER - Luther College 9 - AS47731 2873 0.0% 2873.0 -- ISDC-AS SC ISDC ROMANIA SRL 10 - AS23917 2680 0.0% 2680.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 11 - AS30306 12883 0.1% 2576.6 -- AfOL-Sz-AS 12 - AS30969 19941 0.2% 2492.6 -- TAN-NET TransAfrica Networks 13 - AS40194 2473 0.0% 2473.0 -- INHOUSE-ASSOCIATES-LC - Inhouse Associates, L.C. 14 - AS5033 21917 0.2% 2435.2 -- ISW - Internet Specialties West Inc. 15 - AS28519 7156 0.1% 2385.3 -- Universidad Autonoma de Guadalajara 16 - AS25799 2188 0.0% 2188.0 -- HOLMAN - Holman Enterprises 17 - AS14220 10896 0.1% 2179.2 -- I2A - I 20 Access 18 - AS43925 4211 0.0% 2105.5 -- MOLDCELL_AS Moldcell SA Autonomous System 19 - AS48131 2088 0.0% 2088.0 -- VANGUARD-BG-AS Vanguard SA 20 - AS31901 2079 0.0% 2079.0 -- THECHIMES - The Chimes, Inc. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 77.95.144.0/22 71550 0.6% AS29282 -- EMENTOR-AS Enfo Oyj 2 - 221.134.222.0/24 60545 0.5% AS9583 -- SIFY-AS-IN Sify Limited 3 - 210.214.151.0/24 58419 0.5% AS9583 -- SIFY-AS-IN Sify Limited 4 - 221.135.80.0/24 39086 0.3% AS9583 -- SIFY-AS-IN Sify Limited 5 - 124.7.201.0/24 30734 0.3% AS9583 -- SIFY-AS-IN Sify Limited 6 - 192.102.88.0/24 27336 0.2% AS6629 -- NOAA-AS - NOAA 7 - 192.35.129.0/24 27027 0.2% AS6629 -- NOAA-AS - NOAA 8 - 198.77.177.0/24 27007 0.2% AS6629 -- NOAA-AS - NOAA 9 - 41.204.2.0/24 23566 0.2% AS32398 -- REALNET-ASN-1 10 - 64.162.116.0/24 21754 0.2% AS5033 -- ISW - Internet Specialties West Inc. 11 - 8.192.154.0/24 20398 0.2% AS14106 -- LEPMED01 - Leprechaun, LLC 12 - 217.69.48.0/20 17600 0.1% AS29282 -- EMENTOR-AS Enfo Oyj 13 - 65.44.76.0/24 17087 0.1% AS14106 -- LEPMED01 - Leprechaun, LLC 14 - 150.212.224.0/19 16637 0.1% AS4130 -- UPITT-AS - University of Pittsburgh 15 - 192.12.120.0/24 16241 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 16 - 89.4.131.0/24 11785 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 17 - 203.63.26.0/24 11202 0.1% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 18 - 196.27.104.0/21 9627 0.1% AS30969 -- TAN-NET TransAfrica Networks 19 - 196.27.108.0/22 9585 0.1% AS30969 -- TAN-NET TransAfrica Networks 20 - 195.189.68.0/24 9066 0.1% AS41007 -- CTCASTANA CTC ASTANA, KZ Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Dec 5 05:00:00 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 5 Dec 2008 22:00:00 +1100 (EST) Subject: The Cidr Report Message-ID: <200812051100.mB5B00m9096471@wattle.apnic.net> This report has been generated at Fri Dec 5 21:22:08 2008 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 28-11-08 288778 176595 29-11-08 289005 177125 30-11-08 290303 177473 01-12-08 290335 176312 02-12-08 290415 176118 03-12-08 290216 177472 04-12-08 290560 177808 05-12-08 290432 177896 AS Summary 30175 Number of ASes in routing system 12790 Number of ASes announcing only one prefix 5072 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 89886720 Largest address span announced by an AS (/32s) AS27064: DDN-ASNBLK1 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 05Dec08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 292660 177961 114699 39.2% All ASes AS4538 5072 879 4193 82.7% ERX-CERNET-BKB China Education and Research Network Center AS6389 4380 356 4024 91.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4196 1764 2432 58.0% TWTC - tw telecom holdings, inc. AS209 2984 1311 1673 56.1% ASN-QWEST - Qwest Communications Corporation AS1785 1703 165 1538 90.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS17488 1443 291 1152 79.8% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1177 200 977 83.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 998 64 934 93.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1396 504 892 63.9% Uninet S.A. de C.V. AS6478 1641 809 832 50.7% ATT-INTERNET3 - AT&T WorldNet Services AS18566 1059 240 819 77.3% COVAD - Covad Communications Co. AS11492 1222 451 771 63.1% CABLEONE - CABLE ONE, INC. AS18101 785 73 712 90.7% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS2386 1617 933 684 42.3% INS-AS - AT&T Data Communications Services AS19262 935 262 673 72.0% VZGNI-TRANSIT - Verizon Internet Services Inc. AS3356 1108 509 599 54.1% LEVEL3 Level 3 Communications AS9498 696 120 576 82.8% BBIL-AP BHARTI Airtel Ltd. AS7545 668 167 501 75.0% TPG-INTERNET-AP TPG Internet Pty Ltd AS2706 543 75 468 86.2% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS17676 522 62 460 88.1% GIGAINFRA BB TECHNOLOGY Corp. AS20115 1847 1387 460 24.9% CHARTER-NET-HKY-NC - Charter Communications AS24560 626 171 455 72.7% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4766 1420 967 453 31.9% KIXS-AS-KR Korea Telecom AS4808 624 174 450 72.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS855 561 117 444 79.1% CANET-ASN-4 - Bell Aliant AS7018 1452 1008 444 30.6% ATT-INTERNET4 - AT&T WorldNet Services AS9443 523 84 439 83.9% INTERNETPRIMUS-AS-AP Primus Telecommunications AS4134 908 472 436 48.0% CHINANET-BACKBONE No.31,Jin-rong Street AS22047 553 122 431 77.9% VTR BANDA ANCHA S.A. AS4804 515 89 426 82.7% MPX-AS Microplex PTY LTD Total 43174 13826 29348 68.0% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 62.61.220.0/23 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 87.244.128.0/18 AS8733 CHELLO-BELGIUM UPC Belgium - Chello Belgium 91.209.178.0/24 AS29550 EUROCONNEX-AS Blueconnex Networks Ltd 94.140.128.0/19 AS25086 URALTC-AS UTC AUTONOMUS SYSTEM EKATERINBURG, RUSSIA 94.141.0.0/19 AS5602 KPNQwest Italia S.p.a 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 100.10.10.0/24 AS14000 AXTEL, S.A. de C.V. 119.31.232.0/21 AS38870 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 124.109.16.0/21 AS38137 137.0.0.0/13 AS27064 DDN-ASNBLK1 - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 169.254.0.0/16 AS13184 HANSENET HanseNet Telekommunikation GmbH 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.40.105.0/24 AS41701 CAP-FIN-AS Capgemini Finland Oy 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 195.190.146.0/24 AS9167 WEBPARTNER WEBPARTNER A/S is a Danish Internet Service Provider 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.80.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.0.187.0/24 AS19132 200.5.32.0/21 AS19132 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.42.0/24 AS38205 202.72.46.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.122.120.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.56.0/24 AS38722 202.150.57.0/24 AS38722 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications Ltd 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.48.32.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.229.51.0/24 AS15211 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From alex at corp.nac.net Fri Dec 5 08:31:11 2008 From: alex at corp.nac.net (Alex Rubenstein) Date: Fri, 5 Dec 2008 09:31:11 -0500 Subject: ARCOS Outage In-Reply-To: <24A51B685F3040FB805D3802C46555CC@ReggieD520> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <6cd462c00812042325w5614efdfxe80b98d7a30aee65@mail.gmail.com> <4F189BDBD73A43FDA015C58585114F83@ReggieD520> <24A51B685F3040FB805D3802C46555CC@ReggieD520> Message-ID: I wonder if having a spare card there would have been cheaper than this outage and resulting flights and labour? > > Yup, there is a defective card in the Bahamas. They should be flying in > this > morning to have it replaced. > It's been out since yesterday evening. > From pfunix at gmail.com Fri Dec 5 08:33:14 2008 From: pfunix at gmail.com (Beavis) Date: Fri, 5 Dec 2008 08:33:14 -0600 Subject: ARCOS Outage In-Reply-To: References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <6cd462c00812042325w5614efdfxe80b98d7a30aee65@mail.gmail.com> <4F189BDBD73A43FDA015C58585114F83@ReggieD520> <24A51B685F3040FB805D3802C46555CC@ReggieD520> Message-ID: for the guy that will replace the card .... RoadTrip!!! lol On Fri, Dec 5, 2008 at 8:31 AM, Alex Rubenstein wrote: > I wonder if having a spare card there would have been cheaper than this outage and resulting flights and labour? > >> >> Yup, there is a defective card in the Bahamas. They should be flying in >> this >> morning to have it replaced. >> It's been out since yesterday evening. >> > > From me at sharloncarty.net Fri Dec 5 08:45:40 2008 From: me at sharloncarty.net (Sharlon R. Carty) Date: Fri, 5 Dec 2008 10:45:40 -0400 Subject: ARCOS Outage In-Reply-To: References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <6cd462c00812042325w5614efdfxe80b98d7a30aee65@mail.gmail.com> <4F189BDBD73A43FDA015C58585114F83@ReggieD520> <24A51B685F3040FB805D3802C46555CC@ReggieD520> Message-ID: I definately agree would be cheaper if was available on site. BTW, they should be back up now. On Fri, Dec 5, 2008 at 10:31 AM, Alex Rubenstein wrote: > I wonder if having a spare card there would have been cheaper than this > outage and resulting flights and labour? > > > > > Yup, there is a defective card in the Bahamas. They should be flying in > > this > > morning to have it replaced. > > It's been out since yesterday evening. > > > From david at cantrell.org.uk Fri Dec 5 09:07:33 2008 From: david at cantrell.org.uk (David Cantrell) Date: Fri, 5 Dec 2008 15:07:33 +0000 Subject: Telecom Collapse? In-Reply-To: References: <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> <49380009.8050407@rxsec.com> <0DD2FBFA-E270-40B2-8454-913DD93672CB@hopcount.ca> <49380EA1.5010600@brightok.net> <20081205140108.GD3639@bytemark.barnyard.co.uk> Message-ID: <20081205150733.GJ3639@bytemark.barnyard.co.uk> On Fri, Dec 05, 2008 at 09:21:53AM -0500, Marshall Eubanks wrote: > On Dec 5, 2008, at 9:01 AM, David Cantrell wrote: > >On Thu, Dec 04, 2008 at 11:08:49AM -0600, Jack Bates wrote: > >>Unless you live in a natural disaster prone location. > >So don't do that. > There is literarily no place on the planet that is safe from natural > disaster. A "natural disaster prone location" would, by a normal person, be taken to be one where there is a high probability of being visited by nature's Fuckup Fairies. Such as flood plains (eg much of the Thames estuary) and the sides of active volcanoes (Naples). Most places have a very *low* probability of being visited by the fuckup fairy. -- David Cantrell | Godless Liberal Elitist Safety tip: never strap firearms to a hamster From Skywing at valhallalegends.com Fri Dec 5 09:31:27 2008 From: Skywing at valhallalegends.com (Skywing) Date: Fri, 5 Dec 2008 09:31:27 -0600 Subject: Telecom Collapse? In-Reply-To: <20081205140108.GD3639@bytemark.barnyard.co.uk> References: <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> <49380009.8050407@rxsec.com> <0DD2FBFA-E270-40B2-8454-913DD93672CB@hopcount.ca> <49380EA1.5010600@brightok.net> <20081205140108.GD3639@bytemark.barnyard.co.uk> Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BEF93691B9@caralain.haven.nynaeve.net> Mobiles are usually (much) cheaper than a landline in such places. Inbound calls are usually free too, so they are becoming quite common (relatively), even in underdeveloped areas, at least according to my understanding. - S -----Original Message----- From: David Cantrell [mailto:david at cantrell.org.uk] Sent: Friday, December 05, 2008 9:01 AM To: Jack Bates Cc: nanog at nanog.org Subject: Re: Telecom Collapse? On Thu, Dec 04, 2008 at 11:08:49AM -0600, Jack Bates wrote: > 911 services are heavily used when a geographical area has an emergency, > and that emergency usually includes not having power. Yes, and it usually involves several thousand people all phoning to report the same damned thing, clogging up the emergency service's lines so that *other* emergencies (like, say, someone having a heart attack) don't get dealt with. > Unless you live in a natural disaster prone location. So don't do that. It's really rather silly. I've always thought that people who choose to live on flood plains or on the side of active volcanos etc are at least a little bit crazy. Of course, if they're so poor that they don't have any choice (Bangladesh, perhaps) then they can't afford the non-existent POTS infrastructure anyway - but someone in the village might have a mobile. > Or if your > grandmother's alert bracelet requires a phone line for notification. That's no reason for almost anyone to have a POTS line, because almost everyone doesn't live with their grandmother, and almost all grandmothers don't have alert bracelets. -- David Cantrell | http://www.cantrell.org.uk/david comparative and superlative explained: worse, worser, worsest, worsted, wasted From jbates at brightok.net Fri Dec 5 09:34:01 2008 From: jbates at brightok.net (Jack Bates) Date: Fri, 05 Dec 2008 09:34:01 -0600 Subject: Telecom Collapse? In-Reply-To: <20081205150733.GJ3639@bytemark.barnyard.co.uk> References: <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> <49380009.8050407@rxsec.com> <0DD2FBFA-E270-40B2-8454-913DD93672CB@hopcount.ca> <49380EA1.5010600@brightok.net> <20081205140108.GD3639@bytemark.barnyard.co.uk> <20081205150733.GJ3639@bytemark.barnyard.co.uk> Message-ID: <493949E9.7040504@brightok.net> David Cantrell wrote: > A "natural disaster prone location" would, by a normal person, be > taken to be one where there is a high probability of being visited by > nature's Fuckup Fairies. Such as flood plains (eg much of the Thames > estuary) and the sides of active volcanoes (Naples). Most places have > a very *low* probability of being visited by the fuckup fairy. Yeah, I've been telling them for years that everyone should just vacate Oklahoma, and Kansas. Between tornados and severe storms, these states should be off limits. Of course, we all know people on the west coast are nuts. Must be the earthquakes shaking their brains around. Jack From tme at multicasttech.com Fri Dec 5 09:34:15 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 5 Dec 2008 10:34:15 -0500 Subject: Telecom Collapse? In-Reply-To: <20081205150733.GJ3639@bytemark.barnyard.co.uk> References: <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> <49380009.8050407@rxsec.com> <0DD2FBFA-E270-40B2-8454-913DD93672CB@hopcount.ca> <49380EA1.5010600@brightok.net> <20081205140108.GD3639@bytemark.barnyard.co.uk> <20081205150733.GJ3639@bytemark.barnyard.co.uk> Message-ID: <681FD806-8D64-4928-8418-00482D5D7488@multicasttech.com> On Dec 5, 2008, at 10:07 AM, David Cantrell wrote: > On Fri, Dec 05, 2008 at 09:21:53AM -0500, Marshall Eubanks wrote: >> On Dec 5, 2008, at 9:01 AM, David Cantrell wrote: >>> On Thu, Dec 04, 2008 at 11:08:49AM -0600, Jack Bates wrote: >>>> Unless you live in a natural disaster prone location. >>> So don't do that. >> There is literarily no place on the planet that is safe from natural >> disaster. > > A "natural disaster prone location" would, by a normal person, be > taken to be one where there is a high probability of being visited by > nature's Fuckup Fairies. Such as flood plains (eg much of the Thames > estuary) and the sides of active volcanoes (Naples). Most places have > a very *low* probability of being visited by the fuckup fairy. The recurrence time for Mount Vesuvius is roughly 2000 years and counting. By contrast, the serious Earthquake repeat time on the East Coast of the US is more like 400 years, and overdue, so I guess I should move to Naples. (That doesn't count New Madrid, for which there is serious argument as to the order of magnitude of the recurrence time.) One thing I remember from days trying to measure Earthquake induced deformations of the crust geodetically is that most Earthquakes that kill people occur on previously unknown faults. By the way, the British Geological Survey says that the recurrence time for a serious Earthquake in Britain is about 500 years. (Britain, not the UK; Ireland apparently has a very low occurrence rate for both snakes and Earthquakes.) This is again off-off-topic, so let's take this off-list. Regards Marshall > > > -- > David Cantrell | Godless Liberal Elitist > > Safety tip: never strap firearms to a hamster From mailvortex at gmail.com Fri Dec 5 11:21:03 2008 From: mailvortex at gmail.com (Ben Scott) Date: Fri, 5 Dec 2008 12:21:03 -0500 Subject: Telecom Collapse? In-Reply-To: <493949E9.7040504@brightok.net> References: <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> <49380009.8050407@rxsec.com> <0DD2FBFA-E270-40B2-8454-913DD93672CB@hopcount.ca> <49380EA1.5010600@brightok.net> <20081205140108.GD3639@bytemark.barnyard.co.uk> <20081205150733.GJ3639@bytemark.barnyard.co.uk> <493949E9.7040504@brightok.net> Message-ID: <59f980d60812050921x1c0c8bd6md3b11750c0a7c353@mail.gmail.com> On Fri, Dec 5, 2008 at 10:34 AM, Jack Bates wrote: > Yeah, I've been telling them for years that everyone should just vacate > Oklahoma, and Kansas. And anywhere in Florida within 50 miles of the coast. -- Ben From aaron at wholesaleinternet.net Fri Dec 5 11:52:13 2008 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Fri, 5 Dec 2008 11:52:13 -0600 Subject: Telecom Collapse? In-Reply-To: <493949E9.7040504@brightok.net> References: <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> <49380009.8050407@rxsec.com> <0DD2FBFA-E270-40B2-8454-913DD93672CB@hopcount.ca> <49380EA1.5010600@brightok.net> <20081205140108.GD3639@bytemark.barnyard.co.uk> <20081205150733.GJ3639@bytemark.barnyard.co.uk> <493949E9.7040504@brightok.net> Message-ID: <016e01c95702$3566a400$a033ec00$@net> Hmm... Florida and the entire Gulf Coast and probably Eastern US... Hurricanes, and the West Coast, Earthquakes... and the northern US, severe winter storms. Where does that leave? Utah? Everyone move to Utah! Aaron -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Friday, December 05, 2008 9:34 AM To: David Cantrell Cc: nanog at nanog.org Subject: Re: Telecom Collapse? David Cantrell wrote: > A "natural disaster prone location" would, by a normal person, be > taken to be one where there is a high probability of being visited by > nature's Fuckup Fairies. Such as flood plains (eg much of the Thames > estuary) and the sides of active volcanoes (Naples). Most places have > a very *low* probability of being visited by the fuckup fairy. Yeah, I've been telling them for years that everyone should just vacate Oklahoma, and Kansas. Between tornados and severe storms, these states should be off limits. Of course, we all know people on the west coast are nuts. Must be the earthquakes shaking their brains around. Jack From jeffshultz at wvi.com Fri Dec 5 11:59:01 2008 From: jeffshultz at wvi.com (Jeff Shultz) Date: Fri, 05 Dec 2008 09:59:01 -0800 Subject: Telecom Collapse? In-Reply-To: <016e01c95702$3566a400$a033ec00$@net> References: <89D27DE3375BB6428DDCC2927489826A01D239EB@nexus.nexicomgroup.net> <49380009.8050407@rxsec.com> <0DD2FBFA-E270-40B2-8454-913DD93672CB@hopcount.ca> <49380EA1.5010600@brightok.net> <20081205140108.GD3639@bytemark.barnyard.co.uk> <20081205150733.GJ3639@bytemark.barnyard.co.uk> <493949E9.7040504@brightok.net> <016e01c95702$3566a400$a033ec00$@net> Message-ID: <49396BE5.3090809@wvi.com> Aaron Wendel wrote: > Hmm... Florida and the entire Gulf Coast and probably Eastern US... > Hurricanes, and the West Coast, Earthquakes... and the northern US, severe > winter storms. Where does that leave? Utah? Everyone move to Utah! > > Aaron Inland Pacific NW. Minor (but really minor) earthquake issues. The occasional windstorm and flood is the most we really worry about. -- Jeff Shultz From cscora at apnic.net Fri Dec 5 12:12:27 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 6 Dec 2008 04:12:27 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200812051812.mB5ICRPA005620@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 06 Dec, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 274617 Prefixes after maximum aggregation: 131863 Deaggregation factor: 2.08 Unique aggregates announced to Internet: 134033 Total ASes present in the Internet Routing Table: 30011 Prefixes per ASN: 9.15 Origin-only ASes present in the Internet Routing Table: 26135 Origin ASes announcing only one prefix: 12734 Transit ASes present in the Internet Routing Table: 3876 Transit-only ASes present in the Internet Routing Table: 90 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 19 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 534 Unregistered ASNs in the Routing Table: 195 Number of 32-bit ASNs allocated by the RIRs: 68 Prefixes from 32-bit ASNs in the Routing Table: 9 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 200 Number of addresses announced to Internet: 1966812160 Equivalent to 117 /8s, 59 /16s and 44 /24s Percentage of available address space announced: 53.1 Percentage of allocated address space announced: 63.4 Percentage of available address space allocated: 83.7 Percentage of address space in use by end-sites: 74.5 Total number of prefixes smaller than registry allocations: 134848 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 63620 Total APNIC prefixes after maximum aggregation: 23490 APNIC Deaggregation factor: 2.71 Prefixes being announced from the APNIC address blocks: 60552 Unique aggregates announced from the APNIC address blocks: 27265 APNIC Region origin ASes present in the Internet Routing Table: 3480 APNIC Prefixes per ASN: 17.40 APNIC Region origin ASes announcing only one prefix: 936 APNIC Region transit ASes present in the Internet Routing Table: 532 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 389140384 Equivalent to 23 /8s, 49 /16s and 207 /24s Percentage of available APNIC address space announced: 77.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 122610 Total ARIN prefixes after maximum aggregation: 64581 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 91825 Unique aggregates announced from the ARIN address blocks: 34855 ARIN Region origin ASes present in the Internet Routing Table: 12643 ARIN Prefixes per ASN: 7.26 ARIN Region origin ASes announcing only one prefix: 4889 ARIN Region transit ASes present in the Internet Routing Table: 1208 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 402463648 Equivalent to 23 /8s, 253 /16s and 27 /24s Percentage of available ARIN address space announced: 82.7 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 60947 Total RIPE prefixes after maximum aggregation: 36408 RIPE Deaggregation factor: 1.67 Prefixes being announced from the RIPE address blocks: 56539 Unique aggregates announced from the RIPE address blocks: 37707 RIPE Region origin ASes present in the Internet Routing Table: 12303 RIPE Prefixes per ASN: 4.60 RIPE Region origin ASes announcing only one prefix: 6487 RIPE Region transit ASes present in the Internet Routing Table: 1870 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 17 Number of RIPE addresses announced to Internet: 381049312 Equivalent to 22 /8s, 182 /16s and 89 /24s Percentage of available RIPE address space announced: 87.4 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-49151 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 22671 Total LACNIC prefixes after maximum aggregation: 5602 LACNIC Deaggregation factor: 4.05 Prefixes being announced from the LACNIC address blocks: 20708 Unique aggregates announced from the LACNIC address blocks: 11532 LACNIC Region origin ASes present in the Internet Routing Table: 1039 LACNIC Prefixes per ASN: 19.93 LACNIC Region origin ASes announcing only one prefix: 337 LACNIC Region transit ASes present in the Internet Routing Table: 166 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 58495360 Equivalent to 3 /8s, 124 /16s and 145 /24s Percentage of available LACNIC address space announced: 58.1 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4257 Total AfriNIC prefixes after maximum aggregation: 1360 AfriNIC Deaggregation factor: 3.13 Prefixes being announced from the AfriNIC address blocks: 4568 Unique aggregates announced from the AfriNIC address blocks: 2187 AfriNIC Region origin ASes present in the Internet Routing Table: 274 AfriNIC Prefixes per ASN: 16.67 AfriNIC Region origin ASes announcing only one prefix: 85 AfriNIC Region transit ASes present in the Internet Routing Table: 54 Average AfriNIC Region AS path length visible: 4.0 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 13034240 Equivalent to 0 /8s, 198 /16s and 227 /24s Percentage of available AfriNIC address space announced: 25.9 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 17488 1443 101 105 Hathway IP Over Cable Interne 4766 1340 6409 364 Korea Telecom (KIX) 4755 1169 474 153 TATA Communications formerly 9583 1140 88 486 Sify Limited 4134 907 15509 355 CHINANET-BACKBONE 23577 813 34 692 Korea Telecom (ATM-MPLS) 18101 785 168 33 Reliance Infocom Ltd Internet 4780 727 357 63 Digital United Inc. 9498 694 295 50 BHARTI BT INTERNET LTD. 4808 630 1172 143 CNCGROUP IP network: China169 Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4374 3434 344 bellsouth.net, inc. 209 2982 4031 619 Qwest 20115 1848 1466 745 Charter Communications 1785 1703 717 155 PaeTec Communications, Inc. 6478 1601 367 285 AT&T Worldnet Services 4323 1600 1068 383 Time Warner Telecom 2386 1589 699 897 AT&T Data Communications Serv 7018 1429 5872 989 AT&T WorldNet Services 11492 1222 192 12 Cable One 3356 1099 10991 428 Level 3 Communications, LLC Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 433 1765 383 TDC Tele Danmark 30890 377 79 194 SC Kappa Invexim SRL 12479 373 578 6 Uni2 Autonomous System 3301 335 1413 304 TeliaNet Sweden 8866 331 109 22 Bulgarian Telecommunication C 29049 331 26 3 AzerSat LLC. 3320 329 7064 278 Deutsche Telekom AG 8452 322 188 11 TEDATA 3215 314 2776 97 France Telecom Transpac 8551 303 286 36 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1396 2832 220 UniNet S.A. de C.V. 11830 664 299 9 Instituto Costarricense de El 10620 602 132 43 TVCABLE BOGOTA 22047 553 270 14 VTR PUNTO NET S.A. 7303 502 248 74 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 425 88 50 ENTEL CHILE S.A. 11172 402 118 72 Servicios Alestra S.A de C.V 28573 358 487 25 NET Servicos de Comunicao S.A 14117 333 23 9 Telefonica del Sur S.A. Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 575 73 43 LINKdotNET AS number 3741 270 857 227 The Internet Solution 20858 265 34 3 EgyNet 2018 239 215 140 Tertiary Education Network 6713 144 135 11 Itissalat Al-MAGHRIB 33783 143 10 17 EEPAD TISP TELECOM & INTERNET 5536 120 8 17 Internet Egypt Network 5713 119 555 68 Telkom SA Ltd 33776 116 6 3 Starcomms Nigeria Limited 29571 113 15 8 Ci Telecom Autonomous system Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4374 3434 344 bellsouth.net, inc. 209 2982 4031 619 Qwest 20115 1848 1466 745 Charter Communications 1785 1703 717 155 PaeTec Communications, Inc. 6478 1601 367 285 AT&T Worldnet Services 4323 1600 1068 383 Time Warner Telecom 2386 1589 699 897 AT&T Data Communications Serv 17488 1443 101 105 Hathway IP Over Cable Interne 7018 1429 5872 989 AT&T WorldNet Services 8151 1396 2832 220 UniNet S.A. de C.V. Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2982 2363 Qwest 1785 1703 1548 PaeTec Communications, Inc. 17488 1443 1338 Hathway IP Over Cable Interne 6478 1601 1316 AT&T Worldnet Services 4323 1600 1217 Time Warner Telecom 11492 1222 1210 Cable One 8151 1396 1176 UniNet S.A. de C.V. 20115 1848 1103 Charter Communications 18566 1059 1049 Covad Communications 4755 1169 1016 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 3549 Global Crossing 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.251.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:9 /10:19 /11:55 /12:157 /13:307 /14:553 /15:1076 /16:10193 /17:4476 /18:7742 /19:16581 /20:19512 /21:18966 /22:24124 /23:24670 /24:143313 /25:883 /26:1039 /27:809 /28:98 /29:8 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2858 4374 bellsouth.net, inc. 209 1705 2982 Qwest 2386 1270 1589 AT&T Data Communications Serv 17488 1232 1443 Hathway IP Over Cable Interne 11492 1197 1222 Cable One 1785 1163 1703 PaeTec Communications, Inc. 6478 1126 1601 AT&T Worldnet Services 4766 1083 1340 Korea Telecom (KIX) 18566 1040 1059 Covad Communications 9583 1004 1140 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:12 8:161 12:2218 13:2 15:21 16:3 17:5 20:36 24:1105 32:54 38:519 40:92 41:811 43:1 44:2 47:7 52:3 55:3 56:3 57:26 58:502 59:577 60:447 61:1053 62:1121 63:2012 64:3303 65:2446 66:3530 67:1421 68:652 69:2360 70:523 71:171 72:1596 73:7 74:1319 75:183 76:297 77:903 78:516 79:295 80:938 81:867 82:580 83:410 84:587 85:1046 86:505 87:652 88:354 89:1417 90:43 91:1757 92:325 93:1049 94:775 95:50 96:91 97:140 98:165 99:9 100:1 110:1 111:1 113:41 114:134 115:166 116:1045 117:412 118:267 119:555 120:105 121:691 122:895 123:451 124:857 125:1269 128:359 129:219 130:136 131:409 132:72 133:9 134:190 135:31 136:225 137:123 138:144 139:86 140:415 141:112 142:375 143:338 144:318 145:52 146:373 147:142 148:605 149:212 150:142 151:210 152:140 153:131 154:10 155:251 156:165 157:304 158:166 159:299 160:273 161:131 162:252 163:136 164:509 165:503 166:360 167:350 168:659 169:160 170:462 171:40 172:10 173:123 174:10 187:14 188:1 189:328 190:2469 192:5823 193:4144 194:3292 195:2643 196:1043 198:3720 199:3329 200:5536 201:1496 202:7833 203:8018 204:3943 205:2195 206:2301 207:2763 208:3761 209:3449 210:2716 211:1138 212:1552 213:1671 214:75 215:25 216:4387 217:1244 218:358 219:408 220:1172 221:470 222:286 End of report From revolver.onslaught at gmail.com Fri Dec 5 13:14:08 2008 From: revolver.onslaught at gmail.com (Revolver Onslaught) Date: Fri, 05 Dec 2008 20:14:08 +0100 Subject: McColo and SPAM Message-ID: <49397D80.701@gmail.com> Hello, Since McColo closed, we noticed the spam was far more intensive than before. However, it seems the amount of spam is similar than than before. Do you feel the same ? Many thanks, RO From jeffshultz at wvi.com Fri Dec 5 13:19:37 2008 From: jeffshultz at wvi.com (Jeff Shultz) Date: Fri, 05 Dec 2008 11:19:37 -0800 Subject: McColo and SPAM In-Reply-To: <49397D80.701@gmail.com> References: <49397D80.701@gmail.com> Message-ID: <49397EC9.4060309@wvi.com> Revolver Onslaught wrote: > Hello, > > Since McColo closed, we noticed the spam was far more intensive than before. > > However, it seems the amount of spam is similar than than before. > > Do you feel the same ? > > Many thanks, > RO > I've been getting an fair number of e-mails (up from zero) from customers asking about spam they are getting with their e-mail address being in the From: address. I know that this has always been happening, I'm just wondering if it's been buried under the McColo stuff so they are just noticing it. -- Jeff Shultz From dave at stayonline.com Fri Dec 5 13:24:01 2008 From: dave at stayonline.com (Dave Larter) Date: Fri, 5 Dec 2008 14:24:01 -0500 Subject: McColo and SPAM In-Reply-To: <49397D80.701@gmail.com> References: <49397D80.701@gmail.com> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB397730@MERCURY.socrdu.com> It is still way down for me, see attached. Dave -----Original Message----- From: Revolver Onslaught [mailto:revolver.onslaught at gmail.com] Sent: Friday, December 05, 2008 2:14 PM To: nanog Subject: McColo and SPAM Hello, Since McColo closed, we noticed the spam was far more intensive than before. However, it seems the amount of spam is similar than than before. Do you feel the same ? Many thanks, RO -------------- next part -------------- A non-text attachment was scrubbed... Name: javachart_servlet.png Type: image/png Size: 9482 bytes Desc: javachart_servlet.png URL: From revolver.onslaught at gmail.com Fri Dec 5 13:24:41 2008 From: revolver.onslaught at gmail.com (Revolver Onslaught) Date: Fri, 05 Dec 2008 20:24:41 +0100 Subject: McColo and SPAM In-Reply-To: <8B79B73777E7D544A24BEB8FC50D35DB397730@MERCURY.socrdu.com> References: <49397D80.701@gmail.com> <8B79B73777E7D544A24BEB8FC50D35DB397730@MERCURY.socrdu.com> Message-ID: <49397FF9.7060105@gmail.com> Very stange. I could notice our Spamhaus rejects were the same as before.... Dave Larter a ?crit : > It is still way down for me, see attached. > > Dave > > -----Original Message----- > From: Revolver Onslaught [mailto:revolver.onslaught at gmail.com] > Sent: Friday, December 05, 2008 2:14 PM > To: nanog > Subject: McColo and SPAM > > Hello, > > Since McColo closed, we noticed the spam was far more intensive than > before. > > However, it seems the amount of spam is similar than than before. > > Do you feel the same ? > > Many thanks, > RO > > > > ------------------------------------------------------------------------ > From charles at thewybles.com Fri Dec 5 13:26:42 2008 From: charles at thewybles.com (Charles Wyble) Date: Fri, 05 Dec 2008 11:26:42 -0800 Subject: McColo and SPAM In-Reply-To: <49397EC9.4060309@wvi.com> References: <49397D80.701@gmail.com> <49397EC9.4060309@wvi.com> Message-ID: <49398072.505@thewybles.com> Jeff Shultz wrote >> > I've been getting an fair number of e-mails (up from zero) from > customers asking about spam they are getting with their e-mail address > being in the From: address. I know that this has always been > happening, I'm just wondering if it's been buried under the McColo > stuff so they are just noticing it. Yes I have been getting a lot of that as well. Subject order status. From charles at thewybles.com Fri Dec 5 13:28:27 2008 From: charles at thewybles.com (Charles Wyble) Date: Fri, 05 Dec 2008 11:28:27 -0800 Subject: McColo and SPAM In-Reply-To: <8B79B73777E7D544A24BEB8FC50D35DB397730@MERCURY.socrdu.com> References: <49397D80.701@gmail.com> <8B79B73777E7D544A24BEB8FC50D35DB397730@MERCURY.socrdu.com> Message-ID: <493980DB.6000006@thewybles.com> Is that an off the shelf tool or custom built? From erik_list at caneris.com Fri Dec 5 13:28:38 2008 From: erik_list at caneris.com (Erik (Caneris)) Date: Fri, 5 Dec 2008 14:28:38 -0500 Subject: McColo and SPAM In-Reply-To: <49398072.505@thewybles.com> References: <49397D80.701@gmail.com> <49397EC9.4060309@wvi.com>,<49398072.505@thewybles.com> Message-ID: Same here, with the same subject. Picked up only recently. -- Erik Caneris Tel: 647-723-6365 Fax: 647-723-5365 Toll-free: 1-866-827-0021 www.caneris.com ________________________________________ From: Charles Wyble [charles at thewybles.com] Sent: Friday, December 05, 2008 2:26 PM To: Jeff Shultz Cc: NANOG list Subject: Re: McColo and SPAM Jeff Shultz wrote >> > I've been getting an fair number of e-mails (up from zero) from > customers asking about spam they are getting with their e-mail address > being in the From: address. I know that this has always been > happening, I'm just wondering if it's been buried under the McColo > stuff so they are just noticing it. Yes I have been getting a lot of that as well. Subject order status. From dave at stayonline.com Fri Dec 5 13:36:12 2008 From: dave at stayonline.com (Dave Larter) Date: Fri, 5 Dec 2008 14:36:12 -0500 Subject: McColo and SPAM In-Reply-To: <49397FF9.7060105@gmail.com> References: <49397D80.701@gmail.com> <8B79B73777E7D544A24BEB8FC50D35DB397730@MERCURY.socrdu.com> <49397FF9.7060105@gmail.com> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB397740@MERCURY.socrdu.com> And delivered spam is about the same too. This is just spam I receive, May was when I brought our new smtp gateways online. -----Original Message----- From: Revolver Onslaught [mailto:revolver.onslaught at gmail.com] Sent: Friday, December 05, 2008 2:25 PM To: Dave Larter Cc: nanog Subject: Re: McColo and SPAM Very stange. I could notice our Spamhaus rejects were the same as before.... Dave Larter a ?crit : > It is still way down for me, see attached. > > Dave > > -----Original Message----- > From: Revolver Onslaught [mailto:revolver.onslaught at gmail.com] > Sent: Friday, December 05, 2008 2:14 PM > To: nanog > Subject: McColo and SPAM > > Hello, > > Since McColo closed, we noticed the spam was far more intensive than > before. > > However, it seems the amount of spam is similar than than before. > > Do you feel the same ? > > Many thanks, > RO > > > > ------------------------------------------------------------------------ > -------------- next part -------------- A non-text attachment was scrubbed... Name: spam.xls Type: application/vnd.ms-excel Size: 36352 bytes Desc: spam.xls URL: From dave at stayonline.com Fri Dec 5 13:40:10 2008 From: dave at stayonline.com (Dave Larter) Date: Fri, 5 Dec 2008 14:40:10 -0500 Subject: McColo and SPAM In-Reply-To: <493980DB.6000006@thewybles.com> References: <49397D80.701@gmail.com> <8B79B73777E7D544A24BEB8FC50D35DB397730@MERCURY.socrdu.com> <493980DB.6000006@thewybles.com> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB397743@MERCURY.socrdu.com> It Symantec SMTP gateway v smssmtp501-2007-11-07_02 I have setup another new version Symantec Brightmail Gateway 7.7 product which is in the config stage and only handling a few test domains right now. -----Original Message----- From: Charles Wyble [mailto:charles at thewybles.com] Sent: Friday, December 05, 2008 2:28 PM To: Dave Larter Cc: Revolver Onslaught; nanog Subject: Re: McColo and SPAM Is that an off the shelf tool or custom built? From dave at stayonline.com Fri Dec 5 13:42:32 2008 From: dave at stayonline.com (Dave Larter) Date: Fri, 5 Dec 2008 14:42:32 -0500 Subject: McColo and SPAM In-Reply-To: <493980DB.6000006@thewybles.com> References: <49397D80.701@gmail.com> <8B79B73777E7D544A24BEB8FC50D35DB397730@MERCURY.socrdu.com> <493980DB.6000006@thewybles.com> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB397747@MERCURY.socrdu.com> Sorry, and we have the premium spam add-on too. -----Original Message----- From: Charles Wyble [mailto:charles at thewybles.com] Sent: Friday, December 05, 2008 2:28 PM To: Dave Larter Cc: Revolver Onslaught; nanog Subject: Re: McColo and SPAM Is that an off the shelf tool or custom built? From grinch at panix.com Fri Dec 5 13:47:29 2008 From: grinch at panix.com (Craig Holland) Date: Fri, 05 Dec 2008 11:47:29 -0800 Subject: Recommendation of Tools In-Reply-To: Message-ID: Hi... > According to the 0.75 sorcecode ICMP is still the default prot used, > and the definition of MTR from bitwizards homepage disagress with you: > > "mtr combines the functionality of the 'traceroute' and 'ping' > programs in a single network diagnostic tool. > As mtr starts, it investigates the network connection between the > host mtr runs on and a user-specified destination host. After it > determines the address of each network hop between the machines, it > sends a sequence ICMP ECHO requests to each one to determine the > quality of the link to each machine. As it does this, it prints > running statistics about each machine. For a preview take a look at > the screenshots." > > Even if you use UDP/TCP or whatever, the return packet will be ICMP > and that will be ratelimited by any carrier worth there salt... ...recent attempts to get mtr working through a cisco fwsm got me sniffing, and yes indeed, icmp is the protocol in play with mtr (both outbound and inbound). Rgs, craig From peter.serwe at gmail.com Fri Dec 5 14:48:38 2008 From: peter.serwe at gmail.com (Peter Serwe) Date: Fri, 5 Dec 2008 12:48:38 -0800 Subject: McColo and SPAM Message-ID: On Fri, Dec 5, 2008 at 11:34 AM, wrote: > Message: 1 > Date: Fri, 05 Dec 2008 20:14:08 +0100 > From: Revolver Onslaught > Subject: McColo and SPAM > To: nanog > Message-ID: <49397D80.701 at gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hello, > > Since McColo closed, we noticed the spam was far more intensive than before. > > However, it seems the amount of spam is similar than than before. > > Do you feel the same ? > > Many thanks, > RO It would seem that the sources of SPAM have merely moved since McColo was shut down and it's going to take some time for everyone's blackhole routes and RBL's to catch up. I have personally noticed a higher delivered spam content in my own email accounts. Peter -- ???? From Skywing at valhallalegends.com Fri Dec 5 14:51:16 2008 From: Skywing at valhallalegends.com (Skywing) Date: Fri, 5 Dec 2008 14:51:16 -0600 Subject: McColo and SPAM In-Reply-To: References: Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BEF93691C2@caralain.haven.nynaeve.net> McColo hosted the command and control servers for spam botnets and didn't originate spam directly, at least primarily, according to my understanding. - S -----Original Message----- From: Peter Serwe [mailto:peter.serwe at gmail.com] Sent: Friday, December 05, 2008 3:49 PM To: nanog at nanog.org Subject: Re: McColo and SPAM On Fri, Dec 5, 2008 at 11:34 AM, wrote: > Message: 1 > Date: Fri, 05 Dec 2008 20:14:08 +0100 > From: Revolver Onslaught > Subject: McColo and SPAM > To: nanog > Message-ID: <49397D80.701 at gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hello, > > Since McColo closed, we noticed the spam was far more intensive than before. > > However, it seems the amount of spam is similar than than before. > > Do you feel the same ? > > Many thanks, > RO It would seem that the sources of SPAM have merely moved since McColo was shut down and it's going to take some time for everyone's blackhole routes and RBL's to catch up. I have personally noticed a higher delivered spam content in my own email accounts. Peter -- ???? From chort at smtps.net Fri Dec 5 14:55:55 2008 From: chort at smtps.net (Brian Keefer) Date: Fri, 5 Dec 2008 12:55:55 -0800 Subject: McColo and SPAM In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D6BEF93691C2@caralain.haven.nynaeve.net> References: <982D8D05B6407A49AD506E6C3AC8E7D6BEF93691C2@caralain.haven.nynaeve.net> Message-ID: <1D3DF571-901A-4123-B872-33CFF7784496@smtps.net> On Dec 5, 2008, at 12:51 PM, Skywing wrote: > McColo hosted the command and control servers for spam botnets and > didn't originate spam directly, at least primarily, according to my > understanding. > > - S That is correct. Srizbi and Rustok, primarily. -- bk From peter.serwe at gmail.com Fri Dec 5 14:57:12 2008 From: peter.serwe at gmail.com (Peter Serwe) Date: Fri, 5 Dec 2008 12:57:12 -0800 Subject: McColo and SPAM In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D6BEF93691C2@caralain.haven.nynaeve.net> References: <982D8D05B6407A49AD506E6C3AC8E7D6BEF93691C2@caralain.haven.nynaeve.net> Message-ID: Certainly, I have seen a perceptual, yet completely subjective increase. I know major operators who have claimed to see a gigantic decrease. Peter On Fri, Dec 5, 2008 at 12:51 PM, Skywing wrote: > McColo hosted the command and control servers for spam botnets and didn't originate spam directly, at least primarily, according to my understanding. > > - S > > -----Original Message----- > From: Peter Serwe [mailto:peter.serwe at gmail.com] > Sent: Friday, December 05, 2008 3:49 PM > To: nanog at nanog.org > Subject: Re: McColo and SPAM > > On Fri, Dec 5, 2008 at 11:34 AM, wrote: > >> Message: 1 >> Date: Fri, 05 Dec 2008 20:14:08 +0100 >> From: Revolver Onslaught >> Subject: McColo and SPAM >> To: nanog >> Message-ID: <49397D80.701 at gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hello, >> >> Since McColo closed, we noticed the spam was far more intensive than before. >> >> However, it seems the amount of spam is similar than than before. >> >> Do you feel the same ? >> >> Many thanks, >> RO > > It would seem that the sources of SPAM have merely moved since McColo > was shut down and it's going to > take some time for everyone's blackhole routes and RBL's to catch up. > I have personally noticed a higher > delivered spam content in my own email accounts. > > Peter > > > -- > ???? > > -- ???? From mwalter at 3z.net Fri Dec 5 15:03:19 2008 From: mwalter at 3z.net (Mike Walter) Date: Fri, 5 Dec 2008 16:03:19 -0500 Subject: McColo and SPAM In-Reply-To: <49397D80.701@gmail.com> References: <49397D80.701@gmail.com> Message-ID: We have not seen any decrease. In the last 24 hours we have seen 3.5 million messages blocked. -Mike -----Original Message----- From: Revolver Onslaught [mailto:revolver.onslaught at gmail.com] Sent: Friday, December 05, 2008 2:14 PM To: nanog Subject: McColo and SPAM Hello, Since McColo closed, we noticed the spam was far more intensive than before. However, it seems the amount of spam is similar than than before. Do you feel the same ? Many thanks, RO From marc at let.de Fri Dec 5 15:16:50 2008 From: marc at let.de (Marc Manthey) Date: Fri, 5 Dec 2008 22:16:50 +0100 Subject: Telecom Collapse? In-Reply-To: <5556F486-E3E6-4A38-90D9-819839C8AA16@multicasttech.com> References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <1b5c1c150812032310x37be7f84xd8305c506db9107c@mail.gmail.com> <5556F486-E3E6-4A38-90D9-819839C8AA16@multicasttech.com> Message-ID: <4F9B6341-FA65-4B50-84EB-F07556C212D0@let.de> >> > Also, where I live, if the power goes out hard (for example, during > the last Hurricane), > the cell phone will not have service either. hello What about GPS ? simply sending such data would help more then a "unreliable mobile phone call " right ? (we have enough places where i live and its not a small city , there is no connection like the whitespots on the german DSL map. ) regards Marc >>>> >>>> Let -- web: http://www.let.de Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. From bergmanm at imsg.com Fri Dec 5 13:42:33 2008 From: bergmanm at imsg.com (Mick Bergman) Date: Fri, 5 Dec 2008 14:42:33 -0500 Subject: McColo and SPAM In-Reply-To: <8B79B73777E7D544A24BEB8FC50D35DB397730@MERCURY.socrdu.com> References: <49397D80.701@gmail.com> <8B79B73777E7D544A24BEB8FC50D35DB397730@MERCURY.socrdu.com> Message-ID: <83D04485CE9BEF4883EBF055E1EC159258FB4F@EX02.IMSG.ADS> We are still significantly below the volume we had before McColo got shut down as well. See attached. On a side note, each horizontal line is 50,000 messages received, each color is a class of email received (i.e. blocked due to bad recipient, blocked due to the sender, blocked due to the content of the email, etc.). Before being shut down we accepted about 1000 emails out of 200,000+ emails a day. Yesterday we only received 50,000 emails delivered total but accepted a similar amount (as expected). Mick -----Original Message----- From: Dave Larter [mailto:dave at stayonline.com] Sent: Friday, December 05, 2008 2:24 PM To: Revolver Onslaught; nanog Subject: RE: McColo and SPAM It is still way down for me, see attached. Dave -----Original Message----- From: Revolver Onslaught [mailto:revolver.onslaught at gmail.com] Sent: Friday, December 05, 2008 2:14 PM To: nanog Subject: McColo and SPAM Hello, Since McColo closed, we noticed the spam was far more intensive than before. However, it seems the amount of spam is similar than than before. Do you feel the same ? Many thanks, RO -------------- next part -------------- A non-text attachment was scrubbed... Name: spam_chart.bmp Type: image/bmp Size: 600054 bytes Desc: spam_chart.bmp URL: From rcorbin at TRAFFIQ.com Fri Dec 5 15:30:38 2008 From: rcorbin at TRAFFIQ.com (Raymond Corbin) Date: Fri, 5 Dec 2008 16:30:38 -0500 Subject: McColo and SPAM In-Reply-To: Message-ID: I thought it was mostly control servers....I doubt any 'botnet master' would hardcode an IP address of a server without some sort of backup using some domains that they can always change the DNS on. They update that and the bots will then start connecting to the new 'control servers' and thus spam would come from them. Also did the spam really 'stop' or were they just not able to now get updates from their control servers...those infected I imagine are still sending the spam.... -r -----Original Message----- From: Mike Walter [mailto:mwalter at 3z.net] Sent: Friday, December 05, 2008 4:03 PM To: Revolver Onslaught; nanog Subject: RE: McColo and SPAM We have not seen any decrease. In the last 24 hours we have seen 3.5 million messages blocked. -Mike -----Original Message----- From: Revolver Onslaught [mailto:revolver.onslaught at gmail.com] Sent: Friday, December 05, 2008 2:14 PM To: nanog Subject: McColo and SPAM Hello, Since McColo closed, we noticed the spam was far more intensive than before. However, it seems the amount of spam is similar than than before. Do you feel the same ? Many thanks, RO From peter at peter-dambier.de Fri Dec 5 19:55:01 2008 From: peter at peter-dambier.de (Peter Dambier) Date: Sat, 06 Dec 2008 02:55:01 +0100 Subject: McColo and SPAM In-Reply-To: <49397D80.701@gmail.com> References: <49397D80.701@gmail.com> Message-ID: <4939DB75.2050900@peter-dambier.de> Seen behind my ISP (gmx.de), I get almost no spam. Looking into the spam folder I see some 10% of what I used to see. On the other other hand when they closed I got an alarm for my homepage. I got so many wordbooks on my ssh that they exceeded my traffic limit. I had to move my sshd to IPv6 only to get rid of them. Admin friends told me the wordbook attacks are down again but at the same time spam went up although not as much as it used to be. I have been watching some 10 mailboxes seeing the same results. Kind regards Peter Revolver Onslaught wrote: > Hello, > > Since McColo closed, we noticed the spam was far more intensive than before. > > However, it seems the amount of spam is similar than than before. > > Do you feel the same ? > > Many thanks, > RO -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter at peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ULA= fd80:4ce1:c66a::/48 From frnkblk at iname.com Fri Dec 5 21:33:03 2008 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 5 Dec 2008 21:33:03 -0600 Subject: McColo and SPAM In-Reply-To: References: <982D8D05B6407A49AD506E6C3AC8E7D6BEF93691C2@caralain.haven.nynaeve.net> Message-ID: We experienced exactly no decrease with the McColo shut down a few weeks back, even though we receive 2M+ messages per day. It's interesting that each service provider's spam populations are as different as they are. Some experienced gigantic decreases, others didn't. And it's not like we have just one domain. I know MessageLabs examines spam rates per industry type. Frank -----Original Message----- From: Peter Serwe [mailto:peter.serwe at gmail.com] Sent: Friday, December 05, 2008 2:57 PM To: Skywing Cc: nanog at nanog.org Subject: Re: McColo and SPAM Certainly, I have seen a perceptual, yet completely subjective increase. I know major operators who have claimed to see a gigantic decrease. Peter On Fri, Dec 5, 2008 at 12:51 PM, Skywing wrote: > McColo hosted the command and control servers for spam botnets and didn't originate spam directly, at least primarily, according to my understanding. > > - S > > -----Original Message----- > From: Peter Serwe [mailto:peter.serwe at gmail.com] > Sent: Friday, December 05, 2008 3:49 PM > To: nanog at nanog.org > Subject: Re: McColo and SPAM > > On Fri, Dec 5, 2008 at 11:34 AM, wrote: > >> Message: 1 >> Date: Fri, 05 Dec 2008 20:14:08 +0100 >> From: Revolver Onslaught >> Subject: McColo and SPAM >> To: nanog >> Message-ID: <49397D80.701 at gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hello, >> >> Since McColo closed, we noticed the spam was far more intensive than before. >> >> However, it seems the amount of spam is similar than than before. >> >> Do you feel the same ? >> >> Many thanks, >> RO > > It would seem that the sources of SPAM have merely moved since McColo > was shut down and it's going to > take some time for everyone's blackhole routes and RBL's to catch up. > I have personally noticed a higher > delivered spam content in my own email accounts. > > Peter > > > -- > ???? > > -- ???? From paul at blacknight.com Sat Dec 6 01:10:12 2008 From: paul at blacknight.com (Paul Kelly :: Blacknight) Date: Sat, 6 Dec 2008 07:10:12 +0000 Subject: McColo and SPAM In-Reply-To: References: <982D8D05B6407A49AD506E6C3AC8E7D6BEF93691C2@caralain.haven.nynaeve.net> , Message-ID: We saw a dramatic decrease. Attached is our dnsbl mirror in .ie, it mirrors spamhaus amoungst other things. The numbers are in 1000s of 1000s per 5 minute window. (so 2500k = 2.5m) You can see a dramatic decrease that corresponds with them going offline and then the spam level gradually coming back, but it's certainly not back full tilt yet. Paul Paul Kelly Technical Director Blacknight Internet Solutions ltd Hosting, Colocation, Dedicated servers IP Transit Services Tel: +353 (0) 59 9183072 Lo-call: 1850 929 929 DDI: +353 (0) 59 9183091 e-mail: paul at blacknight.ie web: http://www.blacknight.ie Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park, Sleaty Road, Graiguecullen, Carlow, Ireland Company No.: 370845 ________________________________________ From: Frank Bulk [frnkblk at iname.com] Sent: 06 December 2008 03:33 To: 'Peter Serwe'; Skywing Cc: nanog at nanog.org Subject: RE: McColo and SPAM We experienced exactly no decrease with the McColo shut down a few weeks back, even though we receive 2M+ messages per day. It's interesting that each service provider's spam populations are as different as they are. Some experienced gigantic decreases, others didn't. And it's not like we have just one domain. I know MessageLabs examines spam rates per industry type. Frank -----Original Message----- From: Peter Serwe [mailto:peter.serwe at gmail.com] Sent: Friday, December 05, 2008 2:57 PM To: Skywing Cc: nanog at nanog.org Subject: Re: McColo and SPAM Certainly, I have seen a perceptual, yet completely subjective increase. I know major operators who have claimed to see a gigantic decrease. Peter On Fri, Dec 5, 2008 at 12:51 PM, Skywing wrote: > McColo hosted the command and control servers for spam botnets and didn't originate spam directly, at least primarily, according to my understanding. > > - S > > -----Original Message----- > From: Peter Serwe [mailto:peter.serwe at gmail.com] > Sent: Friday, December 05, 2008 3:49 PM > To: nanog at nanog.org > Subject: Re: McColo and SPAM > > On Fri, Dec 5, 2008 at 11:34 AM, wrote: > >> Message: 1 >> Date: Fri, 05 Dec 2008 20:14:08 +0100 >> From: Revolver Onslaught >> Subject: McColo and SPAM >> To: nanog >> Message-ID: <49397D80.701 at gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hello, >> >> Since McColo closed, we noticed the spam was far more intensive than before. >> >> However, it seems the amount of spam is similar than than before. >> >> Do you feel the same ? >> >> Many thanks, >> RO > > It would seem that the sources of SPAM have merely moved since McColo > was shut down and it's going to > take some time for everyone's blackhole routes and RBL's to catch up. > I have personally noticed a higher > delivered spam content in my own email accounts. > > Peter > > > -- > ???? > > -- ???? -------------- next part -------------- A non-text attachment was scrubbed... Name: aggregate-month.png Type: image/png Size: 4644 bytes Desc: aggregate-month.png URL: From fergdawgster at gmail.com Sat Dec 6 01:36:38 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Fri, 5 Dec 2008 23:36:38 -0800 Subject: McColo and SPAM In-Reply-To: References: <982D8D05B6407A49AD506E6C3AC8E7D6BEF93691C2@caralain.haven.nynaeve.net> Message-ID: <6cd462c00812052336p2368450ep191d1042a86be275@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Dec 5, 2008 at 11:10 PM, Paul Kelly :: Blacknight wrote: > We saw a dramatic decrease. Attached is our dnsbl mirror in .ie, it > mirrors spamhaus amoungst other things. > McColo was just an exercise in "managing" cyber crime operations in the U.S. Please do not be distracted by the whole "spam" issue, it's just a byproduct of much larger criminal operation. What this community should really be discussing is how to deal with these issue in a collaborative manner, because that is exactly what is need to combat it. $.02, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJOit+q1pz9mNUZTMRApsmAKDiMWX7DFUCNxcGku6kOPex5NlW9wCdEMAb TPtpX7pW20Tl6TgPeudjgP0= =n4cP -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From brunner at nic-naa.net Sat Dec 6 07:26:24 2008 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sat, 06 Dec 2008 08:26:24 -0500 Subject: McColo and SPAM In-Reply-To: <6cd462c00812052336p2368450ep191d1042a86be275@mail.gmail.com> References: <982D8D05B6407A49AD506E6C3AC8E7D6BEF93691C2@caralain.haven.nynaeve.net> <6cd462c00812052336p2368450ep191d1042a86be275@mail.gmail.com> Message-ID: <493A7D80.7070607@nic-naa.net> Paul, I read Gregg Keizer's piece in CW where FireEye's Fengmin Gong is quoted as "We have registered a couple hundred domains," Gong said, "but we made the decision that we cannot afford to spend so much money to keep registering so many [domain] names." Now interposing on the Srizbi system's attempt to communicate shouldn't be signing up to do an unlimited number of $6 buys from VGRS plus the overhead to ICANN and a registrar, after all, it is likely that Srizbi isn't using real money to do its domain buys ... so I wrote to the dead mailbox at Gong's company to ask for numbers, and if anyone in the registrar/registry business units knew why Gong's company was doing a couple hundred buys, and what T&C they were offered to keep Srizbi disconnected ... No response. How many domains did FE register, through which registrar(s), and at any point did FE represent to the registrar(s) or to the registry (or registries) the purpose of the buys was to keep Srizbi disconnected? If the registrar(s) or registry(ies) were informed of the purpose of the buys, what response, if any, did they make to FE's representation? I want to know what FE's burn rate was in prophylactic domain buys, and who told FE to let Srizbi resynch its C&C nodes with its bots. I will discuss what I learn to the ICANN GNSO Council. If Keizer's even remotely correct on this point, then this is a "should never happen again" scenario where the GNSO can mandate registry, and registrar responses. So yeah, collaboration would be good, but FE ain't taking my mail, so if this is ever going to go to registrar/registry policy land, it will have to find its own way there. We just lost the unlimited 5 day "Add Grace Period" due to domainers and (some) registrars using it for tasting, and carving out a "prophylactic grace period" for things like this is possible, so that it becomes a no-charge to the interposing buy engine. my two beads worth, Eric Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Fri, Dec 5, 2008 at 11:10 PM, Paul Kelly :: Blacknight > wrote: > > >> We saw a dramatic decrease. Attached is our dnsbl mirror in .ie, it >> mirrors spamhaus amoungst other things. >> >> > > McColo was just an exercise in "managing" cyber crime operations in the > U.S. > > Please do not be distracted by the whole "spam" issue, it's just a > byproduct of much larger criminal operation. > > What this community should really be discussing is how to deal with these > issue in a collaborative manner, because that is exactly what is need to > combat it. > > $.02, > > - - ferg > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.6.3 (Build 3017) > > wj8DBQFJOit+q1pz9mNUZTMRApsmAKDiMWX7DFUCNxcGku6kOPex5NlW9wCdEMAb > TPtpX7pW20Tl6TgPeudjgP0= > =n4cP > -----END PGP SIGNATURE----- > > > From kngspook at gmail.com Sat Dec 6 07:33:07 2008 From: kngspook at gmail.com (Neil) Date: Sat, 6 Dec 2008 08:33:07 -0500 Subject: McColo and SPAM In-Reply-To: References: <982D8D05B6407A49AD506E6C3AC8E7D6BEF93691C2@caralain.haven.nynaeve.net> , Message-ID: <5D3C3DD8-C2DA-46C1-ADA6-FD2B50A060F8@gmail.com> What's very interesting to me is the very rhythmic peaks-and-valleys you show... Seems to go up every day, down during the night; gradually rising mon-wed, slight drops thurs-fri, and then big drop sat, lower drop sun, and then jumps back on monday. On 6 Dec 2008, at 02:10, Paul Kelly :: Blacknight wrote: > We saw a dramatic decrease. Attached is our dnsbl mirror in .ie, it > mirrors spamhaus amoungst other things. > > The numbers are in 1000s of 1000s per 5 minute window. (so 2500k = > 2.5m) > > You can see a dramatic decrease that corresponds with them going > offline and then the spam level gradually coming back, but it's > certainly not back full tilt yet. > > Paul > > Paul Kelly > Technical Director > Blacknight Internet Solutions ltd > Hosting, Colocation, Dedicated servers > IP Transit Services > Tel: +353 (0) 59 9183072 > Lo-call: 1850 929 929 > DDI: +353 (0) 59 9183091 > > e-mail: paul at blacknight.ie > web: http://www.blacknight.ie > > Blacknight Internet Solutions Ltd, > Unit 12A,Barrowside Business Park, > Sleaty Road, > Graiguecullen, > Carlow, > Ireland > > Company No.: 370845 > ________________________________________ > From: Frank Bulk [frnkblk at iname.com] > Sent: 06 December 2008 03:33 > To: 'Peter Serwe'; Skywing > Cc: nanog at nanog.org > Subject: RE: McColo and SPAM > > We experienced exactly no decrease with the McColo shut down a few > weeks > back, even though we receive 2M+ messages per day. It's interesting > that > each service provider's spam populations are as different as they > are. Some > experienced gigantic decreases, others didn't. And it's not like we > have > just one domain. > > I know MessageLabs examines spam rates per industry type. > > Frank > > -----Original Message----- > From: Peter Serwe [mailto:peter.serwe at gmail.com] > Sent: Friday, December 05, 2008 2:57 PM > To: Skywing > Cc: nanog at nanog.org > Subject: Re: McColo and SPAM > > Certainly, I have seen a perceptual, yet completely subjective > increase. > > I know major operators who have claimed to see a gigantic decrease. > > Peter > > On Fri, Dec 5, 2008 at 12:51 PM, Skywing > wrote: >> McColo hosted the command and control servers for spam botnets and >> didn't > originate spam directly, at least primarily, according to my > understanding. >> >> - S >> >> -----Original Message----- >> From: Peter Serwe [mailto:peter.serwe at gmail.com] >> Sent: Friday, December 05, 2008 3:49 PM >> To: nanog at nanog.org >> Subject: Re: McColo and SPAM >> >> On Fri, Dec 5, 2008 at 11:34 AM, wrote: >> >>> Message: 1 >>> Date: Fri, 05 Dec 2008 20:14:08 +0100 >>> From: Revolver Onslaught >>> Subject: McColo and SPAM >>> To: nanog >>> Message-ID: <49397D80.701 at gmail.com> >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> Hello, >>> >>> Since McColo closed, we noticed the spam was far more intensive than > before. >>> >>> However, it seems the amount of spam is similar than than before. >>> >>> Do you feel the same ? >>> >>> Many thanks, >>> RO >> >> It would seem that the sources of SPAM have merely moved since McColo >> was shut down and it's going to >> take some time for everyone's blackhole routes and RBL's to catch up. >> I have personally noticed a higher >> delivered spam content in my own email accounts. >> >> Peter >> >> >> -- >> ???? >> >> > > > > -- > ???? > > > From rbf+nanog at panix.com Sat Dec 6 11:05:24 2008 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Sat, 6 Dec 2008 11:05:24 -0600 Subject: ARCOS Outage In-Reply-To: References: <6cd462c00812032259x64e31ecdw8b31d3d9c9af0c90@mail.gmail.com> <6cd462c00812042325w5614efdfxe80b98d7a30aee65@mail.gmail.com> <4F189BDBD73A43FDA015C58585114F83@ReggieD520> <24A51B685F3040FB805D3802C46555CC@ReggieD520> Message-ID: <20081206170524.GA11350@panix.com> On Fri, Dec 05, 2008 at 09:31:11AM -0500, Alex Rubenstein wrote: > > I wonder if having a spare card there would have been cheaper than > this outage and resulting flights and labour? It unquestionably would have cheaper to have a spare for that card at that location. What might not have been cheaper, though, is having a spare for *every* type of card that could fail, *everywhere* those cards are deployed. > > Yup, there is a defective card in the Bahamas. They should be flying in > > this -- Brett From paul at blacknight.com Sat Dec 6 12:24:25 2008 From: paul at blacknight.com (Paul Kelly :: Blacknight) Date: Sat, 6 Dec 2008 18:24:25 +0000 Subject: McColo and SPAM In-Reply-To: <5D3C3DD8-C2DA-46C1-ADA6-FD2B50A060F8@gmail.com> References: <982D8D05B6407A49AD506E6C3AC8E7D6BEF93691C2@caralain.haven.nynaeve.net> , <5D3C3DD8-C2DA-46C1-ADA6-FD2B50A060F8@gmail.com> Message-ID: The reason for that is our legit e-mail traffic pattern I guess. We probably see the same level of spam 24/7 but from 8am to 8pm GMT we'd get a lot of legit traffic from the few 100k pop3/imap/smtp users we have and as such you'd see the peaks and troughs caused by their usage. Primarily they'd be Irish, but we'd have 10% or so in the UK/Rest of Europe aswell, so they'd fit in with the 8-8 peaks. Paul Paul Kelly Technical Director Blacknight Internet Solutions ltd Hosting, Colocation, Dedicated servers IP Transit Services Tel: +353 (0) 59 9183072 Lo-call: 1850 929 929 DDI: +353 (0) 59 9183091 e-mail: paul at blacknight.ie web: http://www.blacknight.ie Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park, Sleaty Road, Graiguecullen, Carlow, Ireland Company No.: 370845 > -----Original Message----- > From: Neil [mailto:kngspook at gmail.com] > Sent: Saturday, December 06, 2008 1:33 PM > To: Paul Kelly :: Blacknight > Cc: Frank Bulk; 'Peter Serwe'; Skywing; nanog at nanog.org > Subject: Re: McColo and SPAM > > What's very interesting to me is the very rhythmic peaks-and-valleys > you show... Seems to go up every day, down during the night; > gradually rising mon-wed, slight drops thurs-fri, and then big drop > sat, lower drop sun, and then jumps back on monday. > > On 6 Dec 2008, at 02:10, Paul Kelly :: Blacknight wrote: > > > We saw a dramatic decrease. Attached is our dnsbl mirror in > .ie, it > > mirrors spamhaus amoungst other things. > > > > The numbers are in 1000s of 1000s per 5 minute window. (so 2500k = > > 2.5m) > > > > You can see a dramatic decrease that corresponds with them going > > offline and then the spam level gradually coming back, but it's > > certainly not back full tilt yet. > > > > Paul > > > > Paul Kelly > > Technical Director > > Blacknight Internet Solutions ltd > > Hosting, Colocation, Dedicated servers > > IP Transit Services > > Tel: +353 (0) 59 9183072 > > Lo-call: 1850 929 929 > > DDI: +353 (0) 59 9183091 > > > > e-mail: paul at blacknight.ie > > web: http://www.blacknight.ie > > > > Blacknight Internet Solutions Ltd, > > Unit 12A,Barrowside Business Park, > > Sleaty Road, > > Graiguecullen, > > Carlow, > > Ireland > > > > Company No.: 370845 > > ________________________________________ > > From: Frank Bulk [frnkblk at iname.com] > > Sent: 06 December 2008 03:33 > > To: 'Peter Serwe'; Skywing > > Cc: nanog at nanog.org > > Subject: RE: McColo and SPAM > > > > We experienced exactly no decrease with the McColo shut down a few > > weeks > > back, even though we receive 2M+ messages per day. It's > interesting > > that > > each service provider's spam populations are as different as they > > are. Some > > experienced gigantic decreases, others didn't. And it's > not like we > > have > > just one domain. > > > > I know MessageLabs examines spam rates per industry type. > > > > Frank > > > > -----Original Message----- > > From: Peter Serwe [mailto:peter.serwe at gmail.com] > > Sent: Friday, December 05, 2008 2:57 PM > > To: Skywing > > Cc: nanog at nanog.org > > Subject: Re: McColo and SPAM > > > > Certainly, I have seen a perceptual, yet completely subjective > > increase. > > > > I know major operators who have claimed to see a gigantic decrease. > > > > Peter > > > > On Fri, Dec 5, 2008 at 12:51 PM, Skywing > > > wrote: > >> McColo hosted the command and control servers for spam > botnets and > >> didn't > > originate spam directly, at least primarily, according to my > > understanding. > >> > >> - S > >> > >> -----Original Message----- > >> From: Peter Serwe [mailto:peter.serwe at gmail.com] > >> Sent: Friday, December 05, 2008 3:49 PM > >> To: nanog at nanog.org > >> Subject: Re: McColo and SPAM > >> > >> On Fri, Dec 5, 2008 at 11:34 AM, wrote: > >> > >>> Message: 1 > >>> Date: Fri, 05 Dec 2008 20:14:08 +0100 > >>> From: Revolver Onslaught > >>> Subject: McColo and SPAM > >>> To: nanog > >>> Message-ID: <49397D80.701 at gmail.com> > >>> Content-Type: text/plain; charset=ISO-8859-1 > >>> > >>> Hello, > >>> > >>> Since McColo closed, we noticed the spam was far more > intensive than > > before. > >>> > >>> However, it seems the amount of spam is similar than than before. > >>> > >>> Do you feel the same ? > >>> > >>> Many thanks, > >>> RO > >> > >> It would seem that the sources of SPAM have merely moved > since McColo > >> was shut down and it's going to > >> take some time for everyone's blackhole routes and RBL's > to catch up. > >> I have personally noticed a higher > >> delivered spam content in my own email accounts. > >> > >> Peter > >> > >> > >> -- > >> ???? > >> > >> > > > > > > > > -- > > ???? > > > > > > > From drew.linsalata at gmail.com Sun Dec 7 08:10:02 2008 From: drew.linsalata at gmail.com (Drew Linsalata) Date: Sun, 7 Dec 2008 09:10:02 -0500 Subject: Anyone on a Virgin Media UK broadband connection? Message-ID: <70A92421-5710-413A-80DB-101E63A7FCBB@gmail.com> Drop me a note off-list if possible. Thanks! From simonw at zynet.net Mon Dec 8 04:09:14 2008 From: simonw at zynet.net (Simon Waters) Date: Mon, 8 Dec 2008 10:09:14 +0000 Subject: Anyone on a Virgin Media UK broadband connection? In-Reply-To: <70A92421-5710-413A-80DB-101E63A7FCBB@gmail.com> References: <70A92421-5710-413A-80DB-101E63A7FCBB@gmail.com> Message-ID: <200812081009.15439.simonw@zynet.net> On Sunday 07 December 2008 14:10:02 Drew Linsalata wrote: > > Drop me a note off-list if possible. We have a business line from them Urm no Wikipedia this morning - hmm - I think the IWF is self destructing. From james.enck at gmail.com Mon Dec 8 04:37:34 2008 From: james.enck at gmail.com (James Enck) Date: Mon, 8 Dec 2008 10:37:34 +0000 Subject: Anyone on a Virgin Media UK broadband connection? In-Reply-To: <200812081009.15439.simonw@zynet.net> References: <70A92421-5710-413A-80DB-101E63A7FCBB@gmail.com> <200812081009.15439.simonw@zynet.net> Message-ID: <5cf51d6c0812080237v6769bbavf57895161b0cfbdd@mail.gmail.com> FWIW, I'm on a Virgin Media connection in South London (former CWC network), and I'm not experiencing any problems with Wikipedia or the gamer site Drew was having trouble with. Friends in North London are complaining of very slow connections. On Mon, Dec 8, 2008 at 10:09 AM, Simon Waters wrote: > On Sunday 07 December 2008 14:10:02 Drew Linsalata wrote: > > > > Drop me a note off-list if possible. > > We have a business line from them > > Urm no Wikipedia this morning - hmm - I think the IWF is self destructing. > > -- James Enck Senior Associate Telco 2.0 Initiative http://telco2.net +44 7971 263 796 http://eurotelcoblog.blogspot.com Skype: jimiinc Google Talk: james.enck From Hans at is.nl Mon Dec 8 04:40:51 2008 From: Hans at is.nl (Hans Goes) Date: Mon, 8 Dec 2008 11:40:51 +0100 Subject: Anyone on a Virgin Media UK broadband connection? In-Reply-To: <5cf51d6c0812080237v6769bbavf57895161b0cfbdd@mail.gmail.com> References: <70A92421-5710-413A-80DB-101E63A7FCBB@gmail.com> <200812081009.15439.simonw@zynet.net> <5cf51d6c0812080237v6769bbavf57895161b0cfbdd@mail.gmail.com> Message-ID: <2982D4EC0F226648BA4B87FD35318C0CD43739912F@is-exch-001.office.is.nl> Hi, FYI : http://community.zdnet.co.uk/blog/0,1000000567,10009938o-2000331777b,00.htm Hans Goes >-----Oorspronkelijk bericht----- >Van: James Enck [mailto:james.enck at gmail.com] >Verzonden: maandag 8 december 2008 11:38 >Aan: Simon Waters >CC: nanog at nanog.org >Onderwerp: Re: Anyone on a Virgin Media UK broadband connection? > >FWIW, I'm on a Virgin Media connection in South London (former CWC >network), >and I'm not experiencing any problems with Wikipedia or the gamer site >Drew >was having trouble with. Friends in North London are complaining of very >slow connections. > >On Mon, Dec 8, 2008 at 10:09 AM, Simon Waters wrote: > >> On Sunday 07 December 2008 14:10:02 Drew Linsalata wrote: >> > >> > Drop me a note off-list if possible. >> >> We have a business line from them >> >> Urm no Wikipedia this morning - hmm - I think the IWF is self >destructing. >> >> > > >-- >James Enck > >Senior Associate >Telco 2.0 Initiative >http://telco2.net > >+44 7971 263 796 >http://eurotelcoblog.blogspot.com >Skype: jimiinc >Google Talk: james.enck -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5077 bytes Desc: not available URL: From drew.linsalata at gmail.com Mon Dec 8 08:04:59 2008 From: drew.linsalata at gmail.com (Drew Linsalata) Date: Mon, 8 Dec 2008 09:04:59 -0500 Subject: Anyone on a Virgin Media UK broadband connection? In-Reply-To: <2982D4EC0F226648BA4B87FD35318C0CD43739912F@is-exch-001.office.is.nl> References: <70A92421-5710-413A-80DB-101E63A7FCBB@gmail.com> <200812081009.15439.simonw@zynet.net> <5cf51d6c0812080237v6769bbavf57895161b0cfbdd@mail.gmail.com> <2982D4EC0F226648BA4B87FD35318C0CD43739912F@is-exch-001.office.is.nl> Message-ID: <8CFC2F7C-7C85-406B-B22A-DBB1AEE4F243@gmail.com> We were troubleshooting an issue unrelated to Wikipedia. Thanks to all that responded. - Drew On Dec 8, 2008, at 5:40 AM, Hans Goes wrote: > Hi, > > FYI : > > http://community.zdnet.co.uk/blog/0,1000000567,10009938o-2000331777b,00.htm > From pashdown at xmission.com Mon Dec 8 11:50:03 2008 From: pashdown at xmission.com (Pete Ashdown) Date: Mon, 08 Dec 2008 10:50:03 -0700 Subject: NNTP newsfeed peers wanted (non-binary groups) Message-ID: <493D5E4B.3020802@xmission.com> I am looking at freshening my news peer list. Please email me if you are interested. From nanog at mattelmore.com Mon Dec 8 13:00:46 2008 From: nanog at mattelmore.com (Matthew Elmore) Date: Mon, 8 Dec 2008 13:00:46 -0600 Subject: Comcast DNS In-Reply-To: <26CDF379-BCE7-4775-995E-E85AE826F5F0@kooks.net> References: <26CDF379-BCE7-4775-995E-E85AE826F5F0@kooks.net> Message-ID: <5144250B-BB70-4D92-B845-C5B5B3323366@mattelmore.com> No response at all for recursive queries The servers I was using (can't find the IPs at the moment..) I believe were the NJ servers On Dec 3, 2008, at 10:30 PM, Chris Yarnell wrote: > What problems are/were you having out of curiosity? > > On Dec 3, 2008, at 1:40 PM, Matthew Elmore wrote: > >> Anyone else having problems doing recursive lookups on Comcast's >> DNS servers? > From eslerj at gmail.com Mon Dec 8 13:19:22 2008 From: eslerj at gmail.com (Joel Esler) Date: Mon, 8 Dec 2008 14:19:22 -0500 Subject: Comcast DNS In-Reply-To: <5144250B-BB70-4D92-B845-C5B5B3323366@mattelmore.com> References: <26CDF379-BCE7-4775-995E-E85AE826F5F0@kooks.net> <5144250B-BB70-4D92-B845-C5B5B3323366@mattelmore.com> Message-ID: <986A9DFE-0563-4197-A00A-5EB37B16E4A4@gmail.com> I have received reports of some strangeness going on with Google on Comcast's networks today as well. Joel On Dec 8, 2008, at 2:00 PM, Matthew Elmore allegedly wrote: > No response at all for recursive queries > > The servers I was using (can't find the IPs at the moment..) I > believe were the NJ servers > > On Dec 3, 2008, at 10:30 PM, Chris Yarnell wrote: > >> What problems are/were you having out of curiosity? >> >> On Dec 3, 2008, at 1:40 PM, Matthew Elmore wrote: >> >>> Anyone else having problems doing recursive lookups on Comcast's >>> DNS servers? >> > > From niels=nanog at bakker.net Mon Dec 8 14:00:08 2008 From: niels=nanog at bakker.net (Niels Bakker) Date: Mon, 8 Dec 2008 21:00:08 +0100 Subject: Comcast DNS In-Reply-To: <986A9DFE-0563-4197-A00A-5EB37B16E4A4@gmail.com> References: <26CDF379-BCE7-4775-995E-E85AE826F5F0@kooks.net> <5144250B-BB70-4D92-B845-C5B5B3323366@mattelmore.com> <986A9DFE-0563-4197-A00A-5EB37B16E4A4@gmail.com> Message-ID: <20081208200008.GN78345@burnout.tpb.net> Hi Joel, I find your report too specific. Can you make it a bit more generic, perhaps by not including the name of the company that provides a myriad of web-based services? Thanks, -- Niels. * eslerj at gmail.com (Joel Esler) [Mon 08 Dec 2008, 20:19 CET]: >I have received reports of some strangeness going on with Google on >Comcast's networks today as well. > >Joel > >On Dec 8, 2008, at 2:00 PM, Matthew Elmore allegedly wrote: > >> No response at all for recursive queries >> >> The servers I was using (can't find the IPs at the moment..) I >> believe were the NJ servers >> >> On Dec 3, 2008, at 10:30 PM, Chris Yarnell wrote: >> >>> What problems are/were you having out of curiosity? >>> >>> On Dec 3, 2008, at 1:40 PM, Matthew Elmore wrote: >>> >>>> Anyone else having problems doing recursive lookups on Comcast's >>>> DNS servers? -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From tv at duh.org Mon Dec 8 14:17:51 2008 From: tv at duh.org (Todd Vierling) Date: Mon, 8 Dec 2008 15:17:51 -0500 Subject: Comcast DNS In-Reply-To: <20081208200008.GN78345@burnout.tpb.net> References: <26CDF379-BCE7-4775-995E-E85AE826F5F0@kooks.net> <5144250B-BB70-4D92-B845-C5B5B3323366@mattelmore.com> <986A9DFE-0563-4197-A00A-5EB37B16E4A4@gmail.com> <20081208200008.GN78345@burnout.tpb.net> Message-ID: <7883eeaf0812081217x5fa6df23p31bf98f02a5c893e@mail.gmail.com> ObSnark: Hi Niels, I find your response too self-contradictory. ;) On Mon, Dec 8, 2008 at 3:00 PM, Niels Bakker wrote: > Hi Joel, > > I find your report too specific. Can you make it a bit more generic, perhaps by not including the name of the company that provides a myriad of web-based services? > > Thanks, > > > -- Niels. > > * eslerj at gmail.com (Joel Esler) [Mon 08 Dec 2008, 20:19 CET]: >> >> I have received reports of some strangeness going on with Google on Comcast's networks today as well. > [snip] > > -- > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? -- -- Todd Vierling From bgreene at senki.org Mon Dec 8 14:26:16 2008 From: bgreene at senki.org (Barry Raveendran Greene) Date: Mon, 8 Dec 2008 12:26:16 -0800 Subject: "Tech commission suggests new cybersecurity post" (C|NetNews) Message-ID: <7406F7A31FEE41C9A19E5B08FA380DDB@jnpr.net> Hi Team, For those who are looking for more regulation on the Internet and Telecom, here is your new team "NOC." http://news.cnet.com/8301-13578_3-10117856-38.html http://www.csis.org/media/csis/pubs/081208_securingcyberspace_44.pdf For those who do not want more regulation, send this to your company's "Government Affairs Team." To me this seems like a bunch of people wanting jobs in the new administration. What they put in the plan has no linkage to reality. :-( Barry From mike.lyon at gmail.com Mon Dec 8 18:07:41 2008 From: mike.lyon at gmail.com (Mike Lyon) Date: Mon, 8 Dec 2008 16:07:41 -0800 Subject: Slightly OT: Anyone using a PHP based Change Contol App? Message-ID: <1b5c1c150812081607t5ce395eeq32d1cf9d6cd0c12a@mail.gmail.com> Sorry for the slightly OT. Curious though, is anyone using a PHP based change control app for their change control? Please reply off-list Thanks, Mike From nonobvious at gmail.com Mon Dec 8 19:20:03 2008 From: nonobvious at gmail.com (Bill Stewart) Date: Mon, 8 Dec 2008 17:20:03 -0800 Subject: an over-the-top data center In-Reply-To: <200812041219.mB4CJxUP054722@aurora.sol.net> References: <012ECC45-CCF1-4213-B9C1-E301B79CD8E5@internode.com.au> <200812041219.mB4CJxUP054722@aurora.sol.net> Message-ID: <18a5e7cb0812081720of923227h4dfcf0bf82cb1aff@mail.gmail.com> Data centers in used nuclear bunkers aren't new - www.thebunker.net has done that for a decade in the UK. They found that having a cool-looking site made it easy to sell to bankers who wanted reassurance about physical security, and at least with the computer technology of the time it was easy to do HVAC, since the place was naturally cold, and they had good redundant power grid connectivity to work with. As far as the risks of publishing the location of your data centers go, I've generally been on the pro-publishing side; real attackers would *never* think of looking for the large building downtown with no windows, or looking for a data center business named "One Wilshire" near Wilshire Blvd (:-) More seriously, though, many customers need physical diversity for their circuits, and while it's more reliable to get that from a single fiber carrier than try to get predictable diversity from multiple carriers, there's still a need to do some auditing. Of course, if you've got a bunker already, it's pretty cheap to get your CEO a monocle and a white cat, whereas if you're starting with the monocle and the cat, getting a bunker can be fairly expensive. From grinch at panix.com Mon Dec 8 19:42:09 2008 From: grinch at panix.com (Craig Holland) Date: Mon, 08 Dec 2008 17:42:09 -0800 Subject: Comcast DNS In-Reply-To: <20081208200008.GN78345@burnout.tpb.net> Message-ID: Hi... > I find your report too specific. Can you make it a bit more generic, > perhaps by not including the name of the company that provides a myriad > of web-based services? Isn't 'specific' good for operations related stuff? I mean if you are just complaining about something for the sake of complaining or are giving examples I can see where names wouldn't be necessary. Rgs, Craig From grinch at panix.com Mon Dec 8 20:03:56 2008 From: grinch at panix.com (Craig Holland) Date: Tue, 9 Dec 2008 02:03:56 +0000 Subject: Comcast DNS Message-ID: <8559165-1228788248-cardhu_decombobulator_blackberry.rim.net-1308143894-@bxe312.bisx.prod.on.blackberry> *blush* at missing the original sarcasm. ------Original Message------ From: Craig Holland To: NANOG Sent: Dec 8, 2008 5:42 PM Subject: Re: Comcast DNS Hi... > I find your report too specific. Can you make it a bit more generic, > perhaps by not including the name of the company that provides a myriad > of web-based services? Isn't 'specific' good for operations related stuff? I mean if you are just complaining about something for the sake of complaining or are giving examples I can see where names wouldn't be necessary. Rgs, Craig From mike at rockynet.com Mon Dec 8 22:48:29 2008 From: mike at rockynet.com (Mike Lewinski) Date: Mon, 08 Dec 2008 21:48:29 -0700 Subject: Comcast DNS In-Reply-To: <8559165-1228788248-cardhu_decombobulator_blackberry.rim.net-1308143894-@bxe312.bisx.prod.on.blackberry> References: <8559165-1228788248-cardhu_decombobulator_blackberry.rim.net-1308143894-@bxe312.bisx.prod.on.blackberry> Message-ID: <493DF89D.2000704@rockynet.com> There are issues between Google and Comcast in the Denver area for at least the last 12 hours. Pages are sporadically stalling before load (indefinitely as far as I can tell). I found a gmail message I'd sent more than 30 minutes prior still processing. This is affecting all google services that I've tried so far. However, I don't see any evidence this problem is DNS-related, and have not otherwise been experiencing name resolution problems or had any other recent Comcast connectivity issues. So, if there's a clue-wielder from either company around, I'm happy to provide traces and dumps if you want to ping me offlist. From ddunkin at netos.net Mon Dec 8 22:52:34 2008 From: ddunkin at netos.net (Darryl Dunkin) Date: Mon, 8 Dec 2008 20:52:34 -0800 Subject: Comcast DNS References: <8559165-1228788248-cardhu_decombobulator_blackberry.rim.net-1308143894-@bxe312.bisx.prod.on.blackberry> <493DF89D.2000704@rockynet.com> Message-ID: <56F5BC5F404CF84896C447397A1AAF20B0F2B0@MAIL.nosi.netos.com> Add Seattle/Washington to the list. It's been a rough week with Comcast, with a state-wide outage last Thursday morning as well. -----Original Message----- From: Mike Lewinski [mailto:mike at rockynet.com] Sent: Monday, December 08, 2008 20:48 To: nanog at nanog.org Subject: Re: Comcast DNS There are issues between Google and Comcast in the Denver area for at least the last 12 hours. Pages are sporadically stalling before load (indefinitely as far as I can tell). I found a gmail message I'd sent more than 30 minutes prior still processing. This is affecting all google services that I've tried so far. However, I don't see any evidence this problem is DNS-related, and have not otherwise been experiencing name resolution problems or had any other recent Comcast connectivity issues. So, if there's a clue-wielder from either company around, I'm happy to provide traces and dumps if you want to ping me offlist. From nanog at data102.com Mon Dec 8 23:11:04 2008 From: nanog at data102.com (randal k) Date: Mon, 8 Dec 2008 22:11:04 -0700 Subject: Comcast DNS In-Reply-To: <493DF89D.2000704@rockynet.com> References: <8559165-1228788248-cardhu_decombobulator_blackberry.rim.net-1308143894-@bxe312.bisx.prod.on.blackberry> <493DF89D.2000704@rockynet.com> Message-ID: I'll second that. My Google-everything has been totally rocked all evening from my home comcast connection. Randal/Colorado Springs, CO On Mon, Dec 8, 2008 at 9:48 PM, Mike Lewinski wrote: > There are issues between Google and Comcast in the Denver area for at least > the last 12 hours. Pages are sporadically stalling before load (indefinitely > as far as I can tell). I found a gmail message I'd sent more than 30 minutes > prior still processing. This is affecting all google services that I've > tried so far. > > However, I don't see any evidence this problem is DNS-related, and have not > otherwise been experiencing name resolution problems or had any other recent > Comcast connectivity issues. > > So, if there's a clue-wielder from either company around, I'm happy to > provide traces and dumps if you want to ping me offlist. > > From auser at mind.net Mon Dec 8 23:27:14 2008 From: auser at mind.net (S. Ryan) Date: Mon, 08 Dec 2008 21:27:14 -0800 Subject: Comcast DNS In-Reply-To: References: <8559165-1228788248-cardhu_decombobulator_blackberry.rim.net-1308143894-@bxe312.bisx.prod.on.blackberry> <493DF89D.2000704@rockynet.com> Message-ID: <493E01B2.6000001@mind.net> I'm in Fresno, California and having these exact same issues with ATT/Level 3 connectivity to Google. randal k wroteth on 12/8/2008 9:11 PM: > I'll second that. My Google-everything has been totally rocked all > evening from my home comcast connection. > > Randal/Colorado Springs, CO > > On Mon, Dec 8, 2008 at 9:48 PM, Mike Lewinski wrote: >> There are issues between Google and Comcast in the Denver area for at least >> the last 12 hours. Pages are sporadically stalling before load (indefinitely >> as far as I can tell). I found a gmail message I'd sent more than 30 minutes >> prior still processing. This is affecting all google services that I've >> tried so far. >> >> However, I don't see any evidence this problem is DNS-related, and have not >> otherwise been experiencing name resolution problems or had any other recent >> Comcast connectivity issues. >> >> So, if there's a clue-wielder from either company around, I'm happy to >> provide traces and dumps if you want to ping me offlist. >> >> > > From nickellman at gmail.com Mon Dec 8 23:56:42 2008 From: nickellman at gmail.com (b nickell) Date: Mon, 8 Dec 2008 22:56:42 -0700 Subject: Comcast DNS In-Reply-To: <493E01B2.6000001@mind.net> References: <8559165-1228788248-cardhu_decombobulator_blackberry.rim.net-1308143894-@bxe312.bisx.prod.on.blackberry> <493DF89D.2000704@rockynet.com> <493E01B2.6000001@mind.net> Message-ID: Live in littleton CO. Having the same issue. On Mon, Dec 8, 2008 at 10:27 PM, S. Ryan wrote: > I'm in Fresno, California and having these exact same issues with ATT/Level > 3 connectivity to Google. > > > > randal k wroteth on 12/8/2008 9:11 PM: > > I'll second that. My Google-everything has been totally rocked all >> evening from my home comcast connection. >> >> Randal/Colorado Springs, CO >> >> On Mon, Dec 8, 2008 at 9:48 PM, Mike Lewinski wrote: >> >>> There are issues between Google and Comcast in the Denver area for at >>> least >>> the last 12 hours. Pages are sporadically stalling before load >>> (indefinitely >>> as far as I can tell). I found a gmail message I'd sent more than 30 >>> minutes >>> prior still processing. This is affecting all google services that I've >>> tried so far. >>> >>> However, I don't see any evidence this problem is DNS-related, and have >>> not >>> otherwise been experiencing name resolution problems or had any other >>> recent >>> Comcast connectivity issues. >>> >>> So, if there's a clue-wielder from either company around, I'm happy to >>> provide traces and dumps if you want to ping me offlist. >>> >>> >>> >> >> > -- -B From bpfankuch at cpgreeley.com Tue Dec 9 00:18:31 2008 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Mon, 8 Dec 2008 23:18:31 -0700 Subject: Comcast DNS In-Reply-To: <493DF89D.2000704@rockynet.com> References: <8559165-1228788248-cardhu_decombobulator_blackberry.rim.net-1308143894-@bxe312.bisx.prod.on.blackberry> <493DF89D.2000704@rockynet.com> Message-ID: <01759D50DC387C45A018FE1817CE27D754037A00D3@CPExchange1.cpgreeley.com> Having paid attention to this thread, im having issues with all pop3 communication to google mail severs for about the past 24 hours for another email account. Noticed it when outlook started throwing send and receive errors before I went to sleep last night. -----Original Message----- From: Mike Lewinski [mailto:mike at rockynet.com] Sent: Monday, December 08, 2008 9:48 PM To: nanog at nanog.org Subject: Re: Comcast DNS There are issues between Google and Comcast in the Denver area for at least the last 12 hours. Pages are sporadically stalling before load (indefinitely as far as I can tell). I found a gmail message I'd sent more than 30 minutes prior still processing. This is affecting all google services that I've tried so far. However, I don't see any evidence this problem is DNS-related, and have not otherwise been experiencing name resolution problems or had any other recent Comcast connectivity issues. So, if there's a clue-wielder from either company around, I'm happy to provide traces and dumps if you want to ping me offlist. From aoxomoxoa at sunlightdata.com Tue Dec 9 00:51:27 2008 From: aoxomoxoa at sunlightdata.com (Fred Heutte) Date: Tue, 9 Dec 2008 07:51:27 +0100 Subject: new paper on energy performance in data centers Message-ID: <200812090822.mB98MsfE077943@broadway.hevanet.com> A little more mundane than B-movie-set data center deco. cheers from foggy Poznan, Poland* fh *see my new (non-ops) web log: climateobservatory.wordpress.com ------ mail forwarded, original message follows ------ To: UCEI at berkeley.edu From: UCEI at berkeley.edu Subject: NEW EDT Working Paper Date: Thu, 04 Dec 2008 10:17:55 -0800 *University of California Energy Institute's **New Energy Development and Technology (EDT) Working Paper Series** *______________________________________________________________ *EDT-014* *"Improving the Energy Performance of Data Centers**"* * * *Arpad Horvath and Arman Shehabi* University of California, Berkeley _Abstract:_ Data centers greatly impact California?s natural environment and economy. These buildings host computer equipment that provide the massive computational power, data storage, and global networking that is integral to modern information technology. The concentration of densely packed computer equipment in data centers leads to power demands that are much higher than those of a typical residence or commercial office building. Data centers typically consume 15 times more energy per square foot than a typical office building and, in some cases, may be 100 times more energy intensive (Greenberg et al. 2003). Nationally, data centers consumed 61 Terawatt hours in 2006; equivalent to the practical power generation of more than 10, 1 Gigawatt nuclear power plants (Brown et al., 2007). This is approximately equal to annual electricity consumption for the entire state of New Jersey (EIA, 2006). California has the largest data center market in the U.S., indicating that a significant portion of this energy is consumed within the State (Mitchell-Jackson, 2001). This research project focused on identifying how data centers are currently designed and exploring potential energy saving associated with alternative building design options. The energy savings were quantified to understand when design changes resulted in significant benefits and when the benefits from alternative designs were minimal. The potential energy savings benefits were juxtaposed against changes to the environmental conditions in data centers and evaluated within the context of computer reliability concerns. The objective of this research is to provide data center designers and other decision makers with a better understanding of the benefits and concerns associated with data center energy efficiency, thereby reducing the unknown consequences that may hinder attempts to shift away from conventional design practices. Download this paper in Adobe Acrobat format: http://www.ucei.berkeley.edu/PDF/EDT_014.pdf *The document can be downloaded or viewed using Adobe's Acrobat Reader (version 4.0 or later). If you do not have Acrobat Reader, you can download it from Adobe. To DOWNLOAD the documents right mouse click on* *the name and then click again on* *"Save link as..." All EDT working papers can be downloaded **free of charge from the UCEI website: http://www.ucei.org **. From markjr at easydns.com Tue Dec 9 09:40:32 2008 From: markjr at easydns.com (Mark Jeftovic) Date: Tue, 09 Dec 2008 10:40:32 -0500 Subject: ATT, SBC, Pacbell, Prodigy postmaster needed Message-ID: <493E9170.7090306@easydns.com> Sorry to reach out on NANOG again, we've asked on mailops and we are in the process of joining Maawg, but until then, we need to talk to a postmaster at ATT, snet, prodigy, Pacbell, et al ASAP Please contact offlist. thx -mark -- Mark Jeftovic Founder / President, easyDNS Technologies Inc. Company Website: http://www.easyDNS.com I ramble pointlessly from my blog: http://www.PrivateWorld.com From ddunkin at netos.net Tue Dec 9 10:03:33 2008 From: ddunkin at netos.net (Darryl Dunkin) Date: Tue, 9 Dec 2008 08:03:33 -0800 Subject: Comcast DNS References: <8559165-1228788248-cardhu_decombobulator_blackberry.rim.net-1308143894-@bxe312.bisx.prod.on.blackberry><493DF89D.2000704@rockynet.com> <01759D50DC387C45A018FE1817CE27D754037A00D3@CPExchange1.cpgreeley.com> Message-ID: <56F5BC5F404CF84896C447397A1AAF20B0F2B7@MAIL.nosi.netos.com> For me, things appear to have cleared up this morning. Anyone else? -----Original Message----- From: Blake Pfankuch [mailto:bpfankuch at cpgreeley.com] Sent: Monday, December 08, 2008 22:19 To: Mike Lewinski; nanog at nanog.org Subject: RE: Comcast DNS Having paid attention to this thread, im having issues with all pop3 communication to google mail severs for about the past 24 hours for another email account. Noticed it when outlook started throwing send and receive errors before I went to sleep last night. -----Original Message----- From: Mike Lewinski [mailto:mike at rockynet.com] Sent: Monday, December 08, 2008 9:48 PM To: nanog at nanog.org Subject: Re: Comcast DNS There are issues between Google and Comcast in the Denver area for at least the last 12 hours. Pages are sporadically stalling before load (indefinitely as far as I can tell). I found a gmail message I'd sent more than 30 minutes prior still processing. This is affecting all google services that I've tried so far. However, I don't see any evidence this problem is DNS-related, and have not otherwise been experiencing name resolution problems or had any other recent Comcast connectivity issues. So, if there's a clue-wielder from either company around, I'm happy to provide traces and dumps if you want to ping me offlist. From vmalitani at gmail.com Tue Dec 9 11:17:40 2008 From: vmalitani at gmail.com (vitto malitani) Date: Tue, 9 Dec 2008 12:17:40 -0500 Subject: Net Mgmt Tools and supporting OS Message-ID: I am fairly new user of nanog mail list so I am not sure if the question below is appropriate for this list. If not, please excuse it. - I am building a new low-budget customer WAN/LAN network and need some ideas for network management tools. I've seen couple of email threads regarding all sort of "net goodies". However, since I haven't used them all, I am not sure which OS would be the most appropriate for these aps? Can anyone share their ideas in regards of apps and supporting platforms? I would be most comfortable with free distribution of linux, but I am not sure which distro supports most of the tools? Is the paid OS required for all these tools, like RedHat Server or SuSe or Windows platforms? Thanks much, Vitto From michael.dillon at bt.com Tue Dec 9 12:41:40 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 9 Dec 2008 18:41:40 -0000 Subject: Net Mgmt Tools and supporting OS In-Reply-To: Message-ID: > - I am building a new low-budget customer WAN/LAN network and > need some ideas for network management tools. Generally this means that you have someone technical who will work long hard hours to make things work properly. > I would be most comfortable with free distribution of linux, > but I am not sure which distro supports most of the tools? > Is the paid OS required for all these tools, like RedHat > Server or SuSe or Windows platforms? No Linux distro organization will "support" these tools, i.e. you have to provide your own technical support. However the tools will run on all recent distros of Linux. In some cases you will have to compile the tool yourself or use a tool like "alien" to convert between .deb and .rpm packages. Because you will be working hard to get the network management tools working properly, I suggest that you go to or if you prefer, and get a distro that is easy to install and manage. To look for tools, the best place to start is at which should have a listing of every network-related tool that exists. --Michael Dillon From Josh.Stephens at solarwinds.com Tue Dec 9 12:41:58 2008 From: Josh.Stephens at solarwinds.com (Stephens, Josh) Date: Tue, 9 Dec 2008 12:41:58 -0600 Subject: Net Mgmt Tools and supporting OS In-Reply-To: References: Message-ID: <832C54C8546AD0409AEA7E9FEBBEA1EC745F2C@AUS-EXC-01.tul.solarwinds.net> Vitto, My opinion is probably a bit jaded, but here it is anyway... First off, regarding OS, I'd say use whatever OS the customer is most familiar with using/maintaining. If they're a Windows shop you don't want to complicate the administration of the NMS by putting on an OS that they're unfamiliar with. With regards to the NMS applications themselves, I'd be glad to help you get up and running with the stuff we offer here at SolarWinds. Easy to install/use and you can download free copies from SolarWinds.com. Josh -----Original Message----- From: vitto malitani [mailto:vmalitani at gmail.com] Sent: Tuesday, December 09, 2008 11:18 AM To: nanog at nanog.org Subject: Net Mgmt Tools and supporting OS I am fairly new user of nanog mail list so I am not sure if the question below is appropriate for this list. If not, please excuse it. - I am building a new low-budget customer WAN/LAN network and need some ideas for network management tools. I've seen couple of email threads regarding all sort of "net goodies". However, since I haven't used them all, I am not sure which OS would be the most appropriate for these aps? Can anyone share their ideas in regards of apps and supporting platforms? I would be most comfortable with free distribution of linux, but I am not sure which distro supports most of the tools? Is the paid OS required for all these tools, like RedHat Server or SuSe or Windows platforms? Thanks much, Vitto From niels=nanog at bakker.net Tue Dec 9 17:33:10 2008 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 10 Dec 2008 00:33:10 +0100 Subject: IPv6 routing /48s In-Reply-To: <200811260218.mAQ2IQBU017165@drugs.dv.isc.org> References: <20081126021519.GT78345@burnout.tpb.net> <200811260218.mAQ2IQBU017165@drugs.dv.isc.org> Message-ID: <20081209233310.GY78345@burnout.tpb.net> * Mark_Andrews at isc.org (Mark Andrews) [Wed 26 Nov 2008, 03:20 CET]: >It's used for both. Yet from /usr/src/lib/libc/getaddrinfo.c --- /* Rule 7: Prefer native transport. */ /* XXX: not implemented yet */ --- But it is not used to distinguish between 2001: and 2002: as ::/0 has a higher precedence in the default FreeBSD IPv6 address selection policy table. Where does FreeBSD and by extension KAME get its strong preference for 2001: from? I just can't find the code. (I'm reviving this old thread because you chose to ignore my mail to you but did not fail to reply to a single mail I sent to the list concerning this.) -- Niels. -- "We humans get marks for consistency. We always opt for civilization after exhausting the alternatives." -- Carl Guderian From scott.berkman at reignmaker.net Tue Dec 9 17:38:28 2008 From: scott.berkman at reignmaker.net (Scott Berkman) Date: Tue, 9 Dec 2008 18:38:28 -0500 (EST) Subject: Net Mgmt Tools and supporting OS In-Reply-To: References: Message-ID: <084601c95a57$a90aed50$fb20c7f0$@berkman@reignmaker.net> I'd recommend ZenOSS (http://www.zenoss.com) based on your low cost requirement and my own experiences. What Linux distro you use and rather you need to pay for support depends on your level of *nix experience and comfort. Most Linux based software packages like ZenOSS or Groundwork will also tell you what some of their "favorite" distros are based on how they distribute the software and what guides they have if they don't just come right out and say it. Good Luck, -Scott -----Original Message----- From: vitto malitani [mailto:vmalitani at gmail.com] Sent: Tuesday, December 09, 2008 12:18 PM To: nanog at nanog.org Subject: Net Mgmt Tools and supporting OS I am fairly new user of nanog mail list so I am not sure if the question below is appropriate for this list. If not, please excuse it. - I am building a new low-budget customer WAN/LAN network and need some ideas for network management tools. I've seen couple of email threads regarding all sort of "net goodies". However, since I haven't used them all, I am not sure which OS would be the most appropriate for these aps? Can anyone share their ideas in regards of apps and supporting platforms? I would be most comfortable with free distribution of linux, but I am not sure which distro supports most of the tools? Is the paid OS required for all these tools, like RedHat Server or SuSe or Windows platforms? Thanks much, Vitto From Mark_Andrews at isc.org Tue Dec 9 19:12:59 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Wed, 10 Dec 2008 12:12:59 +1100 Subject: IPv6 routing /48s In-Reply-To: Your message of "Wed, 10 Dec 2008 00:33:10 BST." <20081209233310.GY78345@burnout.tpb.net> Message-ID: <200812100113.mBA1CxiJ062346@drugs.dv.isc.org> In message <20081209233310.GY78345 at burnout.tpb.net>, Niels Bakker writes: > * Mark_Andrews at isc.org (Mark Andrews) [Wed 26 Nov 2008, 03:20 CET]: > >It's used for both. > > Yet from /usr/src/lib/libc/getaddrinfo.c > --- > /* Rule 7: Prefer native transport. */ > /* XXX: not implemented yet */ > --- > > But it is not used to distinguish between 2001: and 2002: as ::/0 has a > higher precedence in the default FreeBSD IPv6 address selection policy > table. Where does FreeBSD and by extension KAME get its strong > preference for 2001: from? I just can't find the code. > > (I'm reviving this old thread because you chose to ignore my mail to you > but did not fail to reply to a single mail I sent to the list concerning > this.) /* Rule 5: Prefer matching label. */ If you have a 2001 address and the destination has a 2001 and 2002 address the 2001 will sort to the top here. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From andy at nosignal.org Wed Dec 10 09:40:17 2008 From: andy at nosignal.org (Andy Davidson) Date: Wed, 10 Dec 2008 15:40:17 +0000 Subject: _65000_ in as-path - paging 8544, 16229, 37958 Message-ID: <0BD1B862-0693-4D02-9B1C-B451350E5748@nosignal.org> Hi, Seen in DFZ: 194.9.20.0 - 6661 42652 24611 34088 174 8544 16229 65000 196.216.161.0 - 8657 36881 36881 36881 36881 36881 36881 36881 36881 36881 36881 65000 33763 37036 We manage some bgp speakers running OpenBGPd. This software appears to tear down the session when encountering at least one of these paths : Dec 10 15:31:48 l1-c1 bgpd[15300]: neighbor 84.x.x.x (S): state change Established -> Idle, reason: Fatal error 194.9.20.0 looks like it started being originated by 65000 at 12:30 UTC today or so - this was also the time I started seeing openbgp behave this this way. Renesys thinks 12:58UTC. Andy From tme at multicasttech.com Wed Dec 10 09:58:11 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Wed, 10 Dec 2008 10:58:11 -0500 Subject: _65000_ in as-path - paging 8544, 16229, 37958 In-Reply-To: <0BD1B862-0693-4D02-9B1C-B451350E5748@nosignal.org> References: <0BD1B862-0693-4D02-9B1C-B451350E5748@nosignal.org> Message-ID: On Dec 10, 2008, at 10:40 AM, Andy Davidson wrote: > Hi, > > Seen in DFZ: > > 194.9.20.0 - 6661 42652 24611 34088 174 8544 16229 65000 > > 196.216.161.0 - 8657 36881 36881 36881 36881 36881 36881 36881 36881 > 36881 36881 65000 33763 37036 > > > We manage some bgp speakers running OpenBGPd. This software appears > to tear down the session when encountering at least one of these > paths : > > Dec 10 15:31:48 l1-c1 bgpd[15300]: neighbor 84.x.x.x (S): state > change Established -> Idle, reason: Fatal error > > > 194.9.20.0 looks like it started being originated by 65000 at 12:30 > UTC today or so - this was also the time I started seeing openbgp > behave this this way. Renesys thinks 12:58UTC. > In my DFZ BGP today I see AS 64553 IANA-RSVD2 | 1 prefixes | 1 prefixes & 1 ASN supported | 254 Addresses | 6 hops | as path 174 2914 9498 9730 9498 64553 AS 65000 IANA-RSVD2 | 1 prefixes | 1 prefixes & 1 ASN supported | 254 Addresses | 4 hops | as path 174 8544 16229 65000 AS 65009 IANA-RSVD2 | 2 prefixes | 2 prefixes & 1 ASN supported | 2300 Addresses | 3 hops | as path 174 8167 65009 AS 65500 IANA-RSVD2 | 1 prefixes | 1 prefixes & 1 ASN supported | 254 Addresses | 4 hops | as path 174 21385 33891 65500 AS 65530 IANA-RSVD2 | 2 prefixes | 2 prefixes & 1 ASN supported | 764 Addresses | 5 hops | as path 174 3320 5483 41313 65530 This is fairly typical. Is there some reason why 65000 is especially problematic ? Regards Marshall > > Andy > From zezo at spnet.net Wed Dec 10 10:08:52 2008 From: zezo at spnet.net (Cvetan Ivanov) Date: Wed, 10 Dec 2008 18:08:52 +0200 Subject: _65000_ in as-path - paging 8544, 16229, 37958 In-Reply-To: References: <0BD1B862-0693-4D02-9B1C-B451350E5748@nosignal.org> Message-ID: <493FE994.1080601@spnet.net> Hi, Marshall Eubanks wrote: > > Is there some reason why 65000 is especially problematic ? 65000 and above are private as numbers and should not be seen in the global table. Cvetan -- Cvetan Ivanov System Administrator SpectrumNet Jsc. From tme at multicasttech.com Wed Dec 10 10:24:00 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Wed, 10 Dec 2008 11:24:00 -0500 Subject: _65000_ in as-path - paging 8544, 16229, 37958 In-Reply-To: <493FE994.1080601@spnet.net> References: <0BD1B862-0693-4D02-9B1C-B451350E5748@nosignal.org> <493FE994.1080601@spnet.net> Message-ID: <6FEFE742-2253-4CC1-9C2A-63A20E60A4B2@multicasttech.com> On Dec 10, 2008, at 11:08 AM, Cvetan Ivanov wrote: > Hi, > > Marshall Eubanks wrote: > >> Is there some reason why 65000 is especially problematic ? > > 65000 and above are private as numbers and should not be seen in the > global table. > None of the numbers I included should be seen in the global tables, that is why I included them. However, these bogons are basically always there (not the same set, but something), and I as far as I can tell they are fairly benign. The "private" ASN I have tracked down in the past have all been apparently innocent mistakes. If someone wanted to phish from an AS, there are lots of others that would not be so obvious. Right now, for example, I see 19 ASN from Afrnic blocks with no WHOIS info at all, which worries me rather more. Regards Marshall > Cvetan > > -- > Cvetan Ivanov > System Administrator > SpectrumNet Jsc. > From andy at nosignal.org Wed Dec 10 12:24:20 2008 From: andy at nosignal.org (Andy Davidson) Date: Wed, 10 Dec 2008 18:24:20 +0000 Subject: 91.207.218.0/23 prefix in DFZ - AS3.21 / AS196629 - announced with AS_CONFED_SEQUENCE in AS4_PATH - propagated by 35320 Message-ID: <3A842311-ADB9-41D4-A419-65FDFF0D6A43@nosignal.org> Hi, Further to my email two and a half hours ago, it seems that the prefix causing OpenBGPd speakers to die is 91.207.218.0/23, which is originated by a 4-byte ASN speaker. OpenBGPd is checking AS4_PATH to ensure that it contains only AS_SET and AS_SEQUENCE types, as per RFC4893. When processing the UPDATE for 91.207.218.0/23 it sees : 91.207.218.0/23 Path Attributes - Origin: Incomplete Flags: 0x40 (Well-known, Transitive, Complete) Origin: Incomplete (2) AS_PATH: xx xx 35320 23456 (13 bytes) AS4_PATH: (65044 65057) 196629 (7 bytes) RFC4893 is clear on the matter : " To prevent the possible propagation of confederation path segments outside of a confederation, the path segment types AS_CONFED_SEQUENCE and AS_CONFED_SET [RFC3065] are declared invalid for the AS4_PATH attribute. " OpenBGPd is therefore dropping the sessions when this update is received. Unideal if this attribute is learned on multiple upstreams... The impact today is fairly limited as there are relatively few bgp speakers honouring the 4-byte ASN protocol extension rules, but as code that support these features creeps around the internet, the next time this happens the impact could be much greater, so we need to understand which implementation of which BGP software caused this illegal origination. Modifying the OpenBGPd software to permit AS_CONFED_SEQUENCE, AS_CONFED_SET in an as4_path causes the path to be accepted and the session is not torn down. This isn't a great fix. From a software point of view, I agree that a configurable option to reject the route but keep the session, reject the route and drop the session, accept the route but log/send trap, etc. would be nicer, but this is an implementation thing and probably beyond the scope of this list. For now, does anyone have contacts at 196629 or 35320 who can explain the implementation and fix the behaviour ? Andy From patrick at ianai.net Wed Dec 10 15:20:44 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 10 Dec 2008 16:20:44 -0500 Subject: _65000_ in as-path - paging 8544, 16229, 37958 In-Reply-To: <493FE994.1080601@spnet.net> References: <0BD1B862-0693-4D02-9B1C-B451350E5748@nosignal.org> <493FE994.1080601@spnet.net> Message-ID: <55CBCEB0-8FD8-499F-B898-B1935C3F4DFD@ianai.net> On Dec 10, 2008, at 11:08 AM, Cvetan Ivanov wrote: > Marshall Eubanks wrote: > >> Is there some reason why 65000 is especially problematic ? > > 65000 and above are private as numbers and should not be seen in the > global table. 64512 & above. -- TTFN, patrick From bboles at switchnap.com Wed Dec 10 20:03:34 2008 From: bboles at switchnap.com (Brian Boles) Date: Wed, 10 Dec 2008 18:03:34 -0800 Subject: 3356-1239 Issues in Socal ? Message-ID: <10188D798B596E4585DEAEAC62596D233C2CCCAD@WATERFORD.switchnet.nv> Anyone know of problems in SoCal between 3356-1239? -brian From jay at west.net Wed Dec 10 20:48:06 2008 From: jay at west.net (Jay Hennigan) Date: Wed, 10 Dec 2008 18:48:06 -0800 Subject: 3356-1239 Issues in Socal ? In-Reply-To: <10188D798B596E4585DEAEAC62596D233C2CCCAD@WATERFORD.switchnet.nv> References: <10188D798B596E4585DEAEAC62596D233C2CCCAD@WATERFORD.switchnet.nv> Message-ID: <49407F66.1070906@west.net> Brian Boles wrote: > Anyone know of problems in SoCal between 3356-1239? Yes, we're seeing routes advertised from 1239 in Anaheim to endpoints in 3356 that aren't reachable. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From fweimer at bfk.de Thu Dec 11 02:34:27 2008 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 11 Dec 2008 09:34:27 +0100 Subject: 91.207.218.0/23 prefix in DFZ - AS3.21 / AS196629 - announced with AS_CONFED_SEQUENCE in AS4_PATH - propagated by 35320 In-Reply-To: <3A842311-ADB9-41D4-A419-65FDFF0D6A43@nosignal.org> (Andy Davidson's message of "Wed, 10 Dec 2008 18:24:20 +0000") References: <3A842311-ADB9-41D4-A419-65FDFF0D6A43@nosignal.org> Message-ID: <82oczjglf0.fsf@mid.bfk.de> * Andy Davidson: > OpenBGPd is therefore dropping the sessions when this update is > received. Unideal if this attribute is learned on multiple > upstreams... > > The impact today is fairly limited as there are relatively few bgp > speakers honouring the 4-byte ASN protocol extension rules, but as > code that support these features creeps around the internet, the next > time this happens the impact could be much greater, so we need to > understand which implementation of which BGP software caused this > illegal origination. Uhm, shouldn't you just ignore invalid AS4_PATH attributes, instead of dropping the session? It's a transient, optional attribute, so you can't rely on your peers to filter it. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From andy at nosignal.org Thu Dec 11 03:26:27 2008 From: andy at nosignal.org (Andy Davidson) Date: Thu, 11 Dec 2008 09:26:27 +0000 Subject: 91.207.218.0/23 prefix in DFZ - AS3.21 / AS196629 - announced with AS_CONFED_SEQUENCE in AS4_PATH - propagated by 35320 In-Reply-To: <82oczjglf0.fsf@mid.bfk.de> References: <3A842311-ADB9-41D4-A419-65FDFF0D6A43@nosignal.org> <82oczjglf0.fsf@mid.bfk.de> Message-ID: <88B9884A-0E1B-4D40-B972-65530D2AA39A@nosignal.org> On 11 Dec 2008, at 08:34, Florian Weimer wrote: >> OpenBGPd is therefore dropping the sessions when this update is >> received. Unideal if this attribute is learned on multiple >> upstreams... >> The impact today is fairly limited as there are relatively few bgp >> speakers honouring the 4-byte ASN protocol extension rules, but as >> code that support these features creeps around the internet, the >> next time this happens the impact could be much greater, so we need >> to understand which implementation of which BGP software caused >> this illegal origination. > Uhm, shouldn't you just ignore invalid AS4_PATH attributes, instead > of dropping the session? It's a transient, optional attribute, so > you can't rely on your peers to filter it. Well I have never written written a BGP stack, so I have no code to change as per your suggestion ;-) but as I said on the original post, I'd like to see it as a configurable option, so that I can do the right thing when something breaks. 196629 withdrew the prefix some hours ago and their NOC are investigating. I have asked if they will share some info about the problem when they have chance so that we can understand how to stop this happening in future. They don't use confederations internally so the reason for the break is actually non-obvious. Best wishes Andy From bjorn at mork.no Thu Dec 11 06:28:46 2008 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Thu, 11 Dec 2008 13:28:46 +0100 Subject: 91.207.218.0/23 prefix in DFZ - AS3.21 / AS196629 - announced with AS_CONFED_SEQUENCE in AS4_PATH - propagated by 35320 In-Reply-To: <82oczjglf0.fsf@mid.bfk.de> (Florian Weimer's message of "Thu, 11 Dec 2008 09:34:27 +0100") References: <3A842311-ADB9-41D4-A419-65FDFF0D6A43@nosignal.org> <82oczjglf0.fsf@mid.bfk.de> Message-ID: <87ej0ex5dt.fsf@obelix.mork.no> Florian Weimer writes: > * Andy Davidson: > >> OpenBGPd is therefore dropping the sessions when this update is >> received. Unideal if this attribute is learned on multiple >> upstreams... >> >> The impact today is fairly limited as there are relatively few bgp >> speakers honouring the 4-byte ASN protocol extension rules, but as >> code that support these features creeps around the internet, the next >> time this happens the impact could be much greater, so we need to >> understand which implementation of which BGP software caused this >> illegal origination. > > Uhm, shouldn't you just ignore invalid AS4_PATH attributes, instead of > dropping the session? It's a transient, optional attribute, so you > can't rely on your peers to filter it. No you can't rely on that. But still, RFC4271 doesn't seemt to allow ignoring it. Which must be a bug in the RFC, or my reading of it. Hopefully the latter. Great if someone could correct the interpretation below. IMHO, an optional transitive attribute with the partial bit set should not cause session tear-down, since the attribute is forwarded across one or more routers not handling it and therefore not filtering it. However, RFC4271 does not make such an exception for optional + transitive + partial AFAICS: 6. BGP Error Handling. This section describes actions to be taken when errors are detected while processing BGP messages. When any of the conditions described here are detected, a NOTIFICATION message, with the indicated Error Code, Error Subcode, and Data fields, is sent, and the BGP connection is closed (unless it is explicitly stated that no NOTIFICATION message is to be sent and the BGP connection is not to be closed). If no Error Subcode is specified, then a zero MUST be used. [..] 6.3. UPDATE Message Error Handling All errors detected while processing the UPDATE message MUST be indicated by sending the NOTIFICATION message with the Error Code UPDATE Message Error. The error subcode elaborates on the specific nature of the error [..] If an optional attribute is recognized, then the value of this attribute MUST be checked. If an error is detected, the attribute MUST be discarded, and the Error Subcode MUST be set to Optional Attribute Error. The Data field MUST contain the attribute (type, length, and value). Which basically means that you can take down every RFC-compliant 4-byte ASN honouring router today by injecting a bogus AS4_PATH attribute into the mostly 2-byte-ASN-only Internet... Or did I miss something? I certainly hope I did. Bj?rn From jabley at hopcount.ca Thu Dec 11 07:44:28 2008 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 11 Dec 2008 08:44:28 -0500 Subject: _65000_ in as-path - paging 8544, 16229, 37958 In-Reply-To: <55CBCEB0-8FD8-499F-B898-B1935C3F4DFD@ianai.net> References: <0BD1B862-0693-4D02-9B1C-B451350E5748@nosignal.org> <493FE994.1080601@spnet.net> <55CBCEB0-8FD8-499F-B898-B1935C3F4DFD@ianai.net> Message-ID: On 10 Dec 2008, at 16:20, Patrick W. Gilmore wrote: > On Dec 10, 2008, at 11:08 AM, Cvetan Ivanov wrote: >> Marshall Eubanks wrote: >> >>> Is there some reason why 65000 is especially problematic ? >> >> 65000 and above are private as numbers and should not be seen in >> the global table. > > 64512 & above. Indeed, the reference is RFC 1930 section 10, which says: 10. Reserved AS Numbers The Internet Assigned Numbers Authority (IANA) has reserved the following block of AS numbers for private use (not to be advertised on the global Internet): 64512 through 65535 Joe From lists at memetic.org Thu Dec 11 09:30:08 2008 From: lists at memetic.org (Adam Armstrong) Date: Thu, 11 Dec 2008 15:30:08 +0000 Subject: Net Mgmt Tools and supporting OS In-Reply-To: References: Message-ID: <49413200.3060606@memetic.org> Hi Vitto, The tools you use depend massively on the kind of network you're building. Things I'd look at would be RANCID, Cricket + genrtrconfig, Cacti, jffnms, mon from kernel.org, Nagios, ZenOSS, OpenNMS and my own NMS, Observer (http://www.observer.org). You'll find lots of help with all of these tools from the mailling lists and forums related to them. Good Luck! adam. From Jay.Murphy at state.nm.us Thu Dec 11 10:20:31 2008 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Thu, 11 Dec 2008 09:20:31 -0700 Subject: Tools and toys Message-ID: Vitto, If you want access to NMS tools and tutorials, here is a great resource to delve into, to equip yourself with the appropriate tools.... Jay Murphy IP Network Specialist NMD of Health ITSD - IP Network Operations "We move the information that moves your world." http://www.slac.stanford.edu/xorg/nmtf/nmtf-tools.html <<=======Right here. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Hi Vitto, The tools you use depend massively on the kind of network you're building. Things I'd look at would be RANCID, Cricket + genrtrconfig, Cacti, jffnms, mon from kernel.org, Nagios, ZenOSS, OpenNMS and my own NMS, Observer (http://www.observer.org). You'll find lots of help with all of these tools from the mailling lists and forums related to them. Good Luck! adam. Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From lists at memetic.org Thu Dec 11 10:33:16 2008 From: lists at memetic.org (Adam Armstrong) Date: Thu, 11 Dec 2008 16:33:16 +0000 Subject: Net Mgmt Tools and supporting OS In-Reply-To: <49413200.3060606@memetic.org> References: <49413200.3060606@memetic.org> Message-ID: <494140CC.7030703@memetic.org> Adam Armstrong wrote: > > Things I'd look at would be RANCID, Cricket + genrtrconfig, Cacti, > jffnms, mon from kernel.org, Nagios, ZenOSS, OpenNMS and my own NMS, > Observer (http://www.observer.org). > I may have meant http://www.project-observer.org :) adam. From Jay.Murphy at state.nm.us Thu Dec 11 11:34:18 2008 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Thu, 11 Dec 2008 10:34:18 -0700 Subject: Net Mgmt Tools and supporting OS In-Reply-To: <084601c95a57$a90aed50$fb20c7f0$@berkman@reignmaker.net> References: <084601c95a57$a90aed50$fb20c7f0$@berkman@reignmaker.net> Message-ID: Vitto, If you want access to NMS tools and tutorials, here is a great resource to delve into, to equip yourself with the appropriate tools.... Jay Murphy IP Network Specialist NMD of Health ITSD - IP Network Operations "We move the information that moves your world." http://www.slac.stanford.edu/xorg/nmtf/nmtf-tools.html <<=======Right here. -----Original Message----- From: Scott Berkman [mailto:scott.berkman at reignmaker.net] Sent: Tuesday, December 09, 2008 4:38 PM To: 'vitto malitani'; nanog at nanog.org Subject: RE: Net Mgmt Tools and supporting OS I'd recommend ZenOSS (http://www.zenoss.com) based on your low cost requirement and my own experiences. What Linux distro you use and rather you need to pay for support depends on your level of *nix experience and comfort. Most Linux based software packages like ZenOSS or Groundwork will also tell you what some of their "favorite" distros are based on how they distribute the software and what guides they have if they don't just come right out and say it. Good Luck, -Scott -----Original Message----- From: vitto malitani [mailto:vmalitani at gmail.com] Sent: Tuesday, December 09, 2008 12:18 PM To: nanog at nanog.org Subject: Net Mgmt Tools and supporting OS I am fairly new user of nanog mail list so I am not sure if the question below is appropriate for this list. If not, please excuse it. - I am building a new low-budget customer WAN/LAN network and need some ideas for network management tools. I've seen couple of email threads regarding all sort of "net goodies". However, since I haven't used them all, I am not sure which OS would be the most appropriate for these aps? Can anyone share their ideas in regards of apps and supporting platforms? I would be most comfortable with free distribution of linux, but I am not sure which distro supports most of the tools? Is the paid OS required for all these tools, like RedHat Server or SuSe or Windows platforms? Thanks much, Vitto ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From tarrall at ecentral.com Thu Dec 11 15:00:44 2008 From: tarrall at ecentral.com (Robert Tarrall) Date: Thu, 11 Dec 2008 14:00:44 -0700 Subject: Netblock reassigned from Chile to US ISP... Message-ID: <20081211210044.95A9EC3C3D@smtp.ecentral.com> Request for help here. We have a business partner who, like us, provides DSL services to residential and small-business customers in the US Rocky Mountain region. They just got a /20 from ARIN and were intending to renumber into it in the next week or so, but apparently it used to belong to a company in Chile. Symptoms after a morning of testing: 1) www.google.com is in Spanish 2) Web pages are slow - am assuming this is due to folks like Akamai sending them to content caches in Chile though I haven't tested it myself... God knows "web pages are slow" isn't particularly specific but I'm assuming an OC-3 with 3 DSL subscribers on it will be reasonably free of congestion and I know the upstream is competent. 3) End-user unable to complete an online e-commerce transaction due to a fraud-prevention service thinking he was a Chilean user trying to buy something with a US-based credit card. Can't be the first time this has happened. Anyone have suggestions or experience with this? I assume it'll eventually resolve - at least for 98% of sites/issues - but don't know whether "eventually" means "tomorrow" or "in a couple of years" or what they can do to accelerate the process. -Robert Tarrall.- Director of Technology E.Central/Neighborhood Link From martin at airwire.ie Thu Dec 11 15:10:23 2008 From: martin at airwire.ie (Martin List-Petersen) Date: Thu, 11 Dec 2008 21:10:23 +0000 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <20081211210044.95A9EC3C3D@smtp.ecentral.com> References: <20081211210044.95A9EC3C3D@smtp.ecentral.com> Message-ID: <494181BF.2000903@airwire.ie> Robert Tarrall wrote: > 1) www.google.com is in Spanish > Contact Google. > 2) Web pages are slow - am assuming this is due to folks like Akamai > sending them to content caches in Chile though I haven't tested it > myself... God knows "web pages are slow" isn't particularly specific but > I'm assuming an OC-3 with 3 DSL subscribers on it will be reasonably > free of congestion and I know the upstream is competent. > Again. Akamai is helpful. Contact them. > 3) End-user unable to complete an online e-commerce transaction due to > a fraud-prevention service thinking he was a Chilean user trying to buy > something with a US-based credit card. > There's no fast fix for this, but have you talked to MaxMind about chaning the Geo location ? They'll implent it fast and it's in their DB within a week, max 2, but it'll take 2 months at least, before it makes the internet turn-around. I've ranges, that were originally in Denmark, UK and Germany (we're in Ireland) and after half a year and actively submitting data to MaxMind, that actually ok. I've not had the necessity to contact Google or Akamai. However, the ecommerce issue is a bit worse, because there's some of'em out there, like one of the biggest hosters in the states, that have 2 year old data. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From hannigan at gmail.com Thu Dec 11 15:23:19 2008 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 11 Dec 2008 16:23:19 -0500 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <20081211210044.95A9EC3C3D@smtp.ecentral.com> References: <20081211210044.95A9EC3C3D@smtp.ecentral.com> Message-ID: <2d106eb50812111323s6ab8df48xb0ebc515c26d9587@mail.gmail.com> On Thu, Dec 11, 2008 at 4:00 PM, Robert Tarrall wrote: > > Request for help here. We have a business partner who, like us, provides > DSL services to residential and small-business customers in the US Rocky > Mountain region. > > They just got a /20 from ARIN What is the block that ARIN allocated? -M< From billf at mu.org Thu Dec 11 16:31:33 2008 From: billf at mu.org (bill fumerola) Date: Thu, 11 Dec 2008 14:31:33 -0800 Subject: _65000_ in as-path - paging 8544, 16229, 37958 In-Reply-To: References: <0BD1B862-0693-4D02-9B1C-B451350E5748@nosignal.org> <493FE994.1080601@spnet.net> <55CBCEB0-8FD8-499F-B898-B1935C3F4DFD@ianai.net> Message-ID: <20081211223133.GR97614@elvis.mu.org> On Thu, Dec 11, 2008 at 08:44:28AM -0500, Joe Abley wrote: > On 10 Dec 2008, at 16:20, Patrick W. Gilmore wrote: > >On Dec 10, 2008, at 11:08 AM, Cvetan Ivanov wrote: > >>65000 and above are private as numbers and should not be seen in > >>the global table. > > > >64512 & above. > > Indeed, the reference is RFC 1930 section 10, which says: > > 10. Reserved AS Numbers > > The Internet Assigned Numbers Authority (IANA) has reserved the > following block of AS numbers for private use (not to be advertised > on the global Internet): > > 64512 through 65535 the recently published RFC5398 sets aside a few more to add to the permanent ASN bogon list. 64496-64511 Reserved for use in documentation and sample code 65536-65551 is reserved for same, for those playing in the 32-bit space. -- bill From billf at mu.org Thu Dec 11 16:46:44 2008 From: billf at mu.org (bill fumerola) Date: Thu, 11 Dec 2008 14:46:44 -0800 Subject: 91.207.218.0/23 prefix in DFZ - AS3.21 / AS196629 - announced with AS_CONFED_SEQUENCE in AS4_PATH - propagated by 35320 In-Reply-To: <87ej0ex5dt.fsf@obelix.mork.no> References: <3A842311-ADB9-41D4-A419-65FDFF0D6A43@nosignal.org> <82oczjglf0.fsf@mid.bfk.de> <87ej0ex5dt.fsf@obelix.mork.no> Message-ID: <20081211224644.GS97614@elvis.mu.org> On Thu, Dec 11, 2008 at 01:28:46PM +0100, bjorn at mork.no wrote: > No you can't rely on that. But still, RFC4271 doesn't seemt to allow > ignoring it. Which must be a bug in the RFC, or my reading of it. > Hopefully the latter. Great if someone could correct the interpretation > below. > > IMHO, an optional transitive attribute with the partial bit set should > not cause session tear-down, since the attribute is forwarded across one > or more routers not handling it and therefore not filtering it. > > However, RFC4271 does not make such an exception for optional + > transitive + partial AFAICS: [..... copy/paste deleted .....] > Which basically means that you can take down every RFC-compliant 4-byte > ASN honouring router today by injecting a bogus AS4_PATH attribute into > the mostly 2-byte-ASN-only Internet... > > Or did I miss something? I certainly hope I did. this was brought up in the IETF IDR mailing list today. i've attached the response from that thread that addresses your reading of the RFC. -- bill -------------- next part -------------- An embedded message was scrubbed... From: "John G. Scudder" Subject: Re: [Idr] RFC-4893 handling malformed AS4_PATH attributes Date: Thu, 11 Dec 2008 13:36:21 -0500 Size: 6693 URL: From tarrall at ecentral.com Thu Dec 11 21:44:49 2008 From: tarrall at ecentral.com (Robert Tarrall) Date: Thu, 11 Dec 2008 20:44:49 -0700 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: Message from "Martin List-Petersen " sent Thu, 11 Dec 2008 21:10:23 GMT Message-ID: <20081212034449.5558EC3C11@smtp.ecentral.com> Martin List-Petersen wrote: -> Contact Google. Somebody from Google replied off-list. Sounds like Google maybe had this updated even before he looked at it. -> Again. Akamai is helpful. Contact them. Somebody from Akamai replied off-list and they're looking into it. -> 3) End-user unable to complete an online e-commerce transaction -> due to a fraud-prevention service thinking he was a Chilean user -> trying to buy something with a US-based credit card. -> -> There's no fast fix for this, but have you talked to MaxMind about -> chaning the Geo location ? They'll implent it fast and it's in their -> DB within a week, max 2, but it'll take 2 months at least, before it MaxMind was the first place I checked; they already had the correct info when I looked. IP2Location don't have the right info, but they think it's a Speakeasy.net IP in Washington DC which probably won't be a problem. No idea about Digital Element yet. Netblock is 67.214.48.0/20 - was reg'd a couple of weeks ago so folks who pull ARIN assignments regularly will have it. Those who care but don't check ARIN regularly may want to see if they think it's in Chile, and change it to Denver, Colorado if so. -> However, the ecommerce issue is a bit worse, because there's some -> of'em out there, like one of the biggest hosters in the states, that -> have 2 year old data. Yeah, it's those types that I'm hoping to locate as well... Google and Akamai were immediately noticed by the test users, and have also responded very quickly (thanks, guys), but ideally we'd like to be proactive and get as many of these updated *before* the real customers hit the network and start having problems. -Robert.- From randy at psg.com Thu Dec 11 21:53:17 2008 From: randy at psg.com (Randy Bush) Date: Fri, 12 Dec 2008 12:53:17 +0900 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <20081212034449.5558EC3C11@smtp.ecentral.com> References: <20081212034449.5558EC3C11@smtp.ecentral.com> Message-ID: <4941E02D.3080400@psg.com> try being illiterate and living in japan :) my gripe is the significant sites that put up the kanji page, offer no language choice, and you got there from the US url. you're trapped. and i can not tunnel out of it via my westin or ashburn racks, as my address blocks are registered to my home address here in japan. sense of humor required. younger brain desired, so i can learn japanese. randy From jcurran at istaff.org Thu Dec 11 22:12:43 2008 From: jcurran at istaff.org (John Curran) Date: Thu, 11 Dec 2008 23:12:43 -0500 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <20081212034449.5558EC3C11@smtp.ecentral.com> References: <20081212034449.5558EC3C11@smtp.ecentral.com> Message-ID: On Dec 11, 2008, at 10:44 PM, Robert Tarrall wrote: > ... > Yeah, it's those types that I'm hoping to locate as well... Google > and Akamai were immediately noticed by the test users, and have also > responded very quickly (thanks, guys), but ideally we'd like to be > proactive and get as many of these updated *before* the real customers > hit the network and start having problems. Agreed, and I expect that we're be seeing more dynamic and more granular movement of IPv4 blocks over the next few years. Services that purport to provide useful information about IP block utilization geography had best plan accordingly. /John [my personal view only] From ml at t-b-o-h.net Thu Dec 11 22:57:52 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H) Date: Thu, 11 Dec 2008 23:57:52 -0500 (EST) Subject: DDOS - How much is "too much"? Message-ID: <200812120457.mBC4vqwv095875@vjofn.tucs-beachin-obx-house.com> Hi, I have a client who prior to me settled into a non-carrier-neutral facility. They were approached this week for "DoS/DDoS protection" which they could buy in X Mb/s, 2xX Mb/s or 4xX Mb/s scrubbing solutions. Maybe I've been out of the running my larger Managed Server Hosting Company too long, but wasn't the "non-elegant" solutions something ISPs just "did"? Was it only DoS, and when it comes to DDoS they tell you its just too much to handle. And blocking how many netblocks does an ISP consider "too many" before it tells the client there is only so much it can do for them? Do people tell/give clients their own solutions? (Like Zebra boxes that'll inject BGP into their site) They wanted me to come up with 3 reasons FOR the service, 3 against, and what I felt was a fair market value for this. I just need to know if people still did that type of stuff for each other or if everything costs nowadays.... Thanks, Tuc/TBOH From cidr-report at potaroo.net Fri Dec 12 05:00:04 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 12 Dec 2008 22:00:04 +1100 (EST) Subject: BGP Update Report Message-ID: <200812121100.mBCB043m063256@wattle.apnic.net> BGP Update Report Interval: 05-Nov-08 -to- 06-Dec-08 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4538 232133 1.9% 45.7 -- ERX-CERNET-BKB China Education and Research Network Center 2 - AS9583 228435 1.9% 180.9 -- SIFY-AS-IN Sify Limited 3 - AS6389 130689 1.1% 29.6 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 4 - AS29282 101489 0.8% 33829.7 -- EMENTOR-AS Enfo Oyj 5 - AS1803 94573 0.8% 66.6 -- ICMNET-5 - Sprint 6 - AS6629 84972 0.7% 1307.3 -- NOAA-AS - NOAA 7 - AS6298 83856 0.7% 38.4 -- ASN-CXA-PH-6298-CBS - Cox Communications Inc. 8 - AS24863 83220 0.7% 121.8 -- LINKdotNET-AS 9 - AS8151 73001 0.6% 33.2 -- Uninet S.A. de C.V. 10 - AS209 71988 0.6% 23.2 -- ASN-QWEST - Qwest Communications Corporation 11 - AS20115 63026 0.5% 30.4 -- CHARTER-NET-HKY-NC - Charter Communications 12 - AS6478 61690 0.5% 35.2 -- ATT-INTERNET3 - AT&T WorldNet Services 13 - AS4323 54750 0.5% 12.9 -- TWTC - tw telecom holdings, inc. 14 - AS6458 54576 0.5% 121.8 -- Telgua 15 - AS7643 52459 0.4% 32.4 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 16 - AS2386 51415 0.4% 31.0 -- INS-AS - AT&T Data Communications Services 17 - AS3462 49113 0.4% 244.3 -- HINET Data Communication Business Group 18 - AS17488 48606 0.4% 33.4 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 19 - AS1785 45555 0.4% 26.6 -- AS-PAETEC-NET - PaeTec Communications, Inc. 20 - AS35805 42761 0.3% 206.6 -- UTG-AS United Telecom AS TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS29282 101489 0.8% 33829.7 -- EMENTOR-AS Enfo Oyj 2 - AS14106 32024 0.3% 16012.0 -- LEPMED01 - Leprechaun, LLC 3 - AS30287 4928 0.0% 4928.0 -- ALON-USA - ALON USA, LP 4 - AS30306 19541 0.2% 3908.2 -- AfOL-Sz-AS 5 - AS41007 18540 0.1% 3708.0 -- CTCASTANA CTC ASTANA, KZ 6 - AS46115 36509 0.3% 3650.9 -- LUTHER - Luther College 7 - AS4130 16771 0.1% 3354.2 -- UPITT-AS - University of Pittsburgh 8 - AS32398 26554 0.2% 3319.2 -- REALNET-ASN-1 9 - AS15561 2969 0.0% 2969.0 -- CDS-ITALY C.D.S. Informatica S.r.l. 10 - AS23917 2755 0.0% 2755.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 11 - AS47731 2735 0.0% 2735.0 -- ISDC-AS SC ISDC ROMANIA SRL 12 - AS30969 21860 0.2% 2732.5 -- TAN-NET TransAfrica Networks 13 - AS5033 21730 0.2% 2414.4 -- ISW - Internet Specialties West Inc. 14 - AS28519 7180 0.1% 2393.3 -- Universidad Autonoma de Guadalajara 15 - AS43925 4293 0.0% 2146.5 -- MOLDCELL_AS Moldcell SA Autonomous System 16 - AS48131 2096 0.0% 2096.0 -- VANGUARD-BG-AS Vanguard SA 17 - AS31901 2083 0.0% 2083.0 -- THECHIMES - The Chimes, Inc. 18 - AS25799 2000 0.0% 2000.0 -- HOLMAN - Holman Enterprises 19 - AS19017 1988 0.0% 1988.0 -- QUALCOMM-QWBS-LV - Qualcomm Wireless Business Solutions 20 - AS149 1725 0.0% 1725.0 -- DNIC - DoD Network Information Center TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 77.95.144.0/22 71003 0.6% AS29282 -- EMENTOR-AS Enfo Oyj 2 - 221.134.222.0/24 60022 0.5% AS9583 -- SIFY-AS-IN Sify Limited 3 - 210.214.151.0/24 58695 0.5% AS9583 -- SIFY-AS-IN Sify Limited 4 - 221.135.80.0/24 38881 0.3% AS9583 -- SIFY-AS-IN Sify Limited 5 - 124.7.201.0/24 34334 0.3% AS9583 -- SIFY-AS-IN Sify Limited 6 - 217.69.48.0/20 30450 0.2% AS29282 -- EMENTOR-AS Enfo Oyj 7 - 192.102.88.0/24 27094 0.2% AS6629 -- NOAA-AS - NOAA 8 - 192.35.129.0/24 26804 0.2% AS6629 -- NOAA-AS - NOAA 9 - 198.77.177.0/24 26722 0.2% AS6629 -- NOAA-AS - NOAA 10 - 41.204.2.0/24 25863 0.2% AS32398 -- REALNET-ASN-1 11 - 64.162.116.0/24 21556 0.2% AS5033 -- ISW - Internet Specialties West Inc. 12 - 8.192.154.0/24 17463 0.1% AS14106 -- LEPMED01 - Leprechaun, LLC 13 - 150.212.224.0/19 16681 0.1% AS4130 -- UPITT-AS - University of Pittsburgh 14 - 192.12.120.0/24 16423 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 15 - 65.44.76.0/24 14561 0.1% AS14106 -- LEPMED01 - Leprechaun, LLC 16 - 89.4.131.0/24 11665 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 17 - 203.63.26.0/24 11403 0.1% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 18 - 196.27.104.0/21 10553 0.1% AS30969 -- TAN-NET TransAfrica Networks 19 - 196.27.108.0/22 10508 0.1% AS30969 -- TAN-NET TransAfrica Networks 20 - 195.189.68.0/24 9247 0.1% AS41007 -- CTCASTANA CTC ASTANA, KZ Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Dec 12 05:00:02 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 12 Dec 2008 22:00:02 +1100 (EST) Subject: The Cidr Report Message-ID: <200812121100.mBCB02oH063239@wattle.apnic.net> This report has been generated at Fri Dec 12 21:18:53 2008 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 05-12-08 290432 177961 06-12-08 292661 177588 07-12-08 294362 177884 08-12-08 294699 172849 09-12-08 282262 172817 10-12-08 282192 173193 11-12-08 282545 173526 12-12-08 282624 174029 AS Summary 30159 Number of ASes in routing system 12832 Number of ASes announcing only one prefix 4373 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89828608 Largest address span announced by an AS (/32s) AS27064: DDN-ASNBLK1 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 12Dec08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 282952 173938 109014 38.5% All ASes AS6389 4373 356 4017 91.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4197 1719 2478 59.0% TWTC - tw telecom holdings, inc. AS209 2979 635 2344 78.7% ASN-QWEST - Qwest Communications Corporation AS17488 1442 336 1106 76.7% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4766 1501 455 1046 69.7% KIXS-AS-KR Korea Telecom AS1785 1703 719 984 57.8% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1178 200 978 83.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 992 62 930 93.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1405 539 866 61.6% Uninet S.A. de C.V. AS6478 1604 804 800 49.9% ATT-INTERNET3 - AT&T WorldNet Services AS11492 1229 454 775 63.1% CABLEONE - CABLE ONE, INC. AS18566 1060 336 724 68.3% COVAD - Covad Communications Co. AS18101 783 95 688 87.9% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS19262 938 256 682 72.7% VZGNI-TRANSIT - Verizon Internet Services Inc. AS2386 1590 915 675 42.5% INS-AS - AT&T Data Communications Services AS3356 1104 458 646 58.5% LEVEL3 Level 3 Communications AS2706 543 21 522 96.1% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS7545 678 171 507 74.8% TPG-INTERNET-AP TPG Internet Pty Ltd AS4808 632 159 473 74.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4134 905 438 467 51.6% CHINANET-BACKBONE No.31,Jin-rong Street AS855 580 119 461 79.5% CANET-ASN-4 - Bell Aliant AS17676 522 64 458 87.7% GIGAINFRA BB TECHNOLOGY Corp. AS9443 525 84 441 84.0% INTERNETPRIMUS-AS-AP Primus Telecommunications AS20115 1850 1412 438 23.7% CHARTER-NET-HKY-NC - Charter Communications AS7018 1425 990 435 30.5% ATT-INTERNET4 - AT&T WorldNet Services AS24560 630 195 435 69.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS22047 553 121 432 78.1% VTR BANDA ANCHA S.A. AS4804 515 87 428 83.1% MPX-AS Microplex PTY LTD AS4668 691 276 415 60.1% LGNET-AS-KR LG CNS AS4780 730 329 401 54.9% SEEDNET Digital United Inc. Total 38857 12805 26052 67.0% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 62.61.220.0/23 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 87.244.128.0/18 AS8733 CHELLO-BELGIUM UPC Belgium - Chello Belgium 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 100.10.10.0/24 AS14000 AXTEL, S.A. de C.V. 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 124.109.16.0/21 AS38137 137.0.0.0/13 AS27064 DDN-ASNBLK1 - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.40.105.0/24 AS41701 CAP-FIN-AS Capgemini Finland Oy 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 193.9.26.0/24 AS12594 EXTERNET-AS EXTERNET Autonomus System 193.23.136.0/23 AS43711 SZERVERNET-HU-AS Szervernet Ltd. 193.23.142.0/24 AS47885 HOSTOFFICE-AS HostOffice Kft. 194.0.68.0/22 AS41704 OGS-AS ZAO "Orenburgskaya Gorodskaya Set", Orenburg, Russia 195.190.146.0/24 AS9167 WEBPARTNER WEBPARTNER A/S is a Danish Internet Service Provider 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.80.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.0.187.0/24 AS19132 200.5.32.0/21 AS19132 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.58.224.0/19 AS17925 202.58.224.0/20 AS17925 202.58.240.0/20 AS17925 202.58.240.0/24 AS17925 202.58.244.0/24 AS17925 202.58.249.0/24 AS17925 202.58.250.0/24 AS17925 202.58.253.0/24 AS17925 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.42.0/24 AS38205 202.72.46.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.122.120.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.56.0/24 AS38722 202.150.57.0/24 AS38722 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications Ltd 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.48.32.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.229.51.0/24 AS15211 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From toddunder at gmail.com Fri Dec 12 11:48:49 2008 From: toddunder at gmail.com (Todd Underwood) Date: Fri, 12 Dec 2008 12:48:49 -0500 Subject: [NANOG-announce] NANOG 45 Agenda Posted Message-ID: <65b1fd2e0812120948m60743814kb7a48736523d91ed@mail.gmail.com> On behalf of the NANOG Program Committee and Merit I'm pleased to announce that an updated Agenda is available and posted at: http://www.nanog.org/meetings/nanog45/agenda.php We're excited about the quality of the agenda and we hope you are, too. I want to thank all of the members of the Program Committee who worked hard to recruit, review and select the presentations and tutorials that make up this program. I also want to thank everyone who submitted a proposal. The quality and variety seemed very high this time around. Please note that there remain a very small number of slots open for late-breaking or especially topical presentations, so if the Internet melts down completely between now and January, feel free to submit a presentation explaining what happened. Lighting Talk slots will officially open after the first of the year. If you have not already registered for the conference and reserved your hotel room, now is a great time to do that. See http://nanog.org/meetings/nanog45/ and in particular https://nanog.merit.edu/registration/ to get started. Remember that Hotel expenses are fantastically low this time, with rooms as cheap as $104 and cheap flights are still available to the SDQ airport. The overall cost of this NANOG should be the same or lower as previous ones. I mention this because I know that many travel budgets are tight and I hope that this information might be useful to your management. I look forward to seeing all of you in Santo Domingo. Todd Underwood Chair, NANOG Program Committee toddunder at gmail.com _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From cscora at apnic.net Fri Dec 12 12:11:27 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 13 Dec 2008 04:11:27 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200812121811.mBCIBRNZ005279@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 13 Dec, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 274910 Prefixes after maximum aggregation: 131479 Deaggregation factor: 2.09 Unique aggregates announced to Internet: 134428 Total ASes present in the Internet Routing Table: 30074 Prefixes per ASN: 9.14 Origin-only ASes present in the Internet Routing Table: 26178 Origin ASes announcing only one prefix: 12740 Transit ASes present in the Internet Routing Table: 3896 Transit-only ASes present in the Internet Routing Table: 96 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 25 Max AS path prepend of ASN (42115) 21 Prefixes from unregistered ASNs in the Routing Table: 529 Unregistered ASNs in the Routing Table: 194 Number of 32-bit ASNs allocated by the RIRs: 68 Prefixes from 32-bit ASNs in the Routing Table: 10 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 210 Number of addresses announced to Internet: 1970066112 Equivalent to 117 /8s, 108 /16s and 210 /24s Percentage of available address space announced: 53.2 Percentage of allocated address space announced: 63.5 Percentage of available address space allocated: 83.7 Percentage of address space in use by end-sites: 74.6 Total number of prefixes smaller than registry allocations: 134988 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 63380 Total APNIC prefixes after maximum aggregation: 22998 APNIC Deaggregation factor: 2.76 Prefixes being announced from the APNIC address blocks: 60296 Unique aggregates announced from the APNIC address blocks: 27407 APNIC Region origin ASes present in the Internet Routing Table: 3488 APNIC Prefixes per ASN: 17.29 APNIC Region origin ASes announcing only one prefix: 937 APNIC Region transit ASes present in the Internet Routing Table: 535 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 17 Number of APNIC addresses announced to Internet: 390867936 Equivalent to 23 /8s, 76 /16s and 43 /24s Percentage of available APNIC address space announced: 77.7 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 122980 Total ARIN prefixes after maximum aggregation: 64546 ARIN Deaggregation factor: 1.91 Prefixes being announced from the ARIN address blocks: 92217 Unique aggregates announced from the ARIN address blocks: 35011 ARIN Region origin ASes present in the Internet Routing Table: 12650 ARIN Prefixes per ASN: 7.29 ARIN Region origin ASes announcing only one prefix: 4886 ARIN Region transit ASes present in the Internet Routing Table: 1205 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 20 Number of ARIN addresses announced to Internet: 402263840 Equivalent to 23 /8s, 250 /16s and 15 /24s Percentage of available ARIN address space announced: 82.7 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 61022 Total RIPE prefixes after maximum aggregation: 36518 RIPE Deaggregation factor: 1.67 Prefixes being announced from the RIPE address blocks: 56559 Unique aggregates announced from the RIPE address blocks: 37770 RIPE Region origin ASes present in the Internet Routing Table: 12349 RIPE Prefixes per ASN: 4.58 RIPE Region origin ASes announcing only one prefix: 6498 RIPE Region transit ASes present in the Internet Routing Table: 1883 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 25 Number of RIPE addresses announced to Internet: 382341984 Equivalent to 22 /8s, 202 /16s and 19 /24s Percentage of available RIPE address space announced: 87.7 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-49151 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 22722 Total LACNIC prefixes after maximum aggregation: 5633 LACNIC Deaggregation factor: 4.03 Prefixes being announced from the LACNIC address blocks: 20749 Unique aggregates announced from the LACNIC address blocks: 11546 LACNIC Region origin ASes present in the Internet Routing Table: 1038 LACNIC Prefixes per ASN: 19.99 LACNIC Region origin ASes announcing only one prefix: 335 LACNIC Region transit ASes present in the Internet Routing Table: 172 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 58745856 Equivalent to 3 /8s, 128 /16s and 100 /24s Percentage of available LACNIC address space announced: 58.4 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4298 Total AfriNIC prefixes after maximum aggregation: 1363 AfriNIC Deaggregation factor: 3.15 Prefixes being announced from the AfriNIC address blocks: 4600 Unique aggregates announced from the AfriNIC address blocks: 2195 AfriNIC Region origin ASes present in the Internet Routing Table: 271 AfriNIC Prefixes per ASN: 16.97 AfriNIC Region origin ASes announcing only one prefix: 84 AfriNIC Region transit ASes present in the Internet Routing Table: 56 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 13104128 Equivalent to 0 /8s, 199 /16s and 244 /24s Percentage of available AfriNIC address space announced: 26.0 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 17488 1443 101 99 Hathway IP Over Cable Interne 4766 1424 6409 364 Korea Telecom (KIX) 4755 1171 474 152 TATA Communications formerly 9583 1116 88 484 Sify Limited 4134 905 15509 354 CHINANET-BACKBONE 18101 784 168 32 Reliance Infocom Ltd Internet 4780 729 358 64 Digital United Inc. 9498 700 311 50 BHARTI BT INTERNET LTD. 7545 657 152 81 TPG Internet Pty Ltd 4808 632 1173 144 CNCGROUP IP network: China169 Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4385 3435 346 bellsouth.net, inc. 209 2981 4032 621 Qwest 20115 1819 1418 745 Charter Communications 1785 1702 717 155 PaeTec Communications, Inc. 6478 1613 369 286 AT&T Worldnet Services 4323 1599 1065 382 Time Warner Telecom 2386 1588 708 901 AT&T Data Communications Serv 7018 1428 5872 987 AT&T WorldNet Services 11492 1229 192 12 Cable One 3356 1094 10991 425 Level 3 Communications, LLC Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 435 1766 384 TDC Tele Danmark 30890 378 79 194 SC Kappa Invexim SRL 12479 373 578 6 Uni2 Autonomous System 3301 336 1413 303 TeliaNet Sweden 8866 331 109 22 Bulgarian Telecommunication C 29049 330 26 3 AzerSat LLC. 3320 329 7064 278 Deutsche Telekom AG 8452 322 188 11 TEDATA 3215 315 2792 96 France Telecom Transpac 8551 304 287 35 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1404 2832 222 UniNet S.A. de C.V. 11830 667 299 9 Instituto Costarricense de El 10620 631 134 52 TVCABLE BOGOTA 22047 553 270 14 VTR PUNTO NET S.A. 7303 503 249 74 Telecom Argentina Stet-France 6471 426 54 41 ENTEL CHILE S.A. 16814 426 27 10 NSS, S.A. 11172 400 118 72 Servicios Alestra S.A de C.V 28573 364 489 28 NET Servicos de Comunicao S.A 14117 333 23 9 Telefonica del Sur S.A. Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 585 73 43 LINKdotNET AS number 3741 270 857 227 The Internet Solution 20858 264 34 3 EgyNet 2018 239 215 140 Tertiary Education Network 6713 144 135 11 Itissalat Al-MAGHRIB 33783 143 10 17 EEPAD TISP TELECOM & INTERNET 29571 121 15 8 Ci Telecom Autonomous system 5536 120 8 17 Internet Egypt Network 5713 119 555 68 Telkom SA Ltd 33776 116 6 3 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4385 3435 346 bellsouth.net, inc. 209 2981 4032 621 Qwest 20115 1819 1418 745 Charter Communications 1785 1702 717 155 PaeTec Communications, Inc. 6478 1613 369 286 AT&T Worldnet Services 4323 1599 1065 382 Time Warner Telecom 2386 1588 708 901 AT&T Data Communications Serv 17488 1443 101 99 Hathway IP Over Cable Interne 7018 1428 5872 987 AT&T WorldNet Services 4766 1424 6409 364 Korea Telecom (KIX) Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2981 2360 Qwest 1785 1702 1547 PaeTec Communications, Inc. 17488 1443 1344 Hathway IP Over Cable Interne 6478 1613 1327 AT&T Worldnet Services 4323 1599 1217 Time Warner Telecom 11492 1229 1217 Cable One 8151 1404 1182 UniNet S.A. de C.V. 20115 1819 1074 Charter Communications 4766 1424 1060 Korea Telecom (KIX) 18566 1060 1050 Covad Communications Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.251.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:9 /10:19 /11:54 /12:158 /13:307 /14:554 /15:1085 /16:10232 /17:4468 /18:7707 /19:16569 /20:19491 /21:19057 /22:24149 /23:24750 /24:144035 /25:682 /26:835 /27:615 /28:99 /29:8 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2864 4385 bellsouth.net, inc. 209 1705 2981 Qwest 2386 1267 1588 AT&T Data Communications Serv 17488 1232 1443 Hathway IP Over Cable Interne 11492 1200 1229 Cable One 1785 1162 1702 PaeTec Communications, Inc. 4766 1161 1424 Korea Telecom (KIX) 6478 1129 1613 AT&T Worldnet Services 18566 1041 1060 Covad Communications 9583 980 1116 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:169 12:2221 13:2 15:21 16:3 17:5 20:36 24:1108 32:54 38:525 40:92 41:840 43:1 44:2 47:13 52:3 55:3 56:3 57:26 58:510 59:597 60:456 61:1058 62:1122 63:2012 64:3373 65:2463 66:3601 67:1437 68:658 69:2362 70:526 71:173 72:1592 73:7 74:1331 75:191 76:303 77:892 78:521 79:296 80:940 81:866 82:581 83:385 84:586 85:1041 86:506 87:652 88:355 89:1420 90:44 91:1765 92:305 93:1058 94:791 95:57 96:94 97:142 98:172 99:10 100:1 110:1 111:1 113:60 114:145 115:170 116:1062 117:416 118:261 119:558 120:105 121:696 122:903 123:452 124:858 125:1274 128:358 129:220 130:136 131:399 132:72 133:9 134:190 135:31 136:225 137:128 138:143 139:91 140:414 141:111 142:382 143:325 144:314 145:53 146:370 147:141 148:601 149:215 150:139 151:210 152:181 153:131 154:10 155:250 156:171 157:303 158:165 159:300 160:272 161:131 162:253 163:136 164:517 165:505 166:359 167:351 168:661 169:162 170:461 171:40 172:10 173:130 174:11 186:1 187:16 188:1 189:345 190:2512 192:5818 193:4156 194:3297 195:2658 196:1047 198:3703 199:3316 200:5534 201:1496 202:7845 203:8073 204:3931 205:2176 206:2302 207:2788 208:3766 209:3500 210:2742 211:1119 212:1564 213:1662 214:65 215:22 216:4493 217:1244 218:361 219:407 220:1189 221:455 222:290 End of report From ernst at easystreet.com Fri Dec 12 12:15:16 2008 From: ernst at easystreet.com (Rick Ernst) Date: Fri, 12 Dec 2008 10:15:16 -0800 (PST) Subject: UDP DoS mitigation? Message-ID: <57995.69.30.17.85.1229105716.squirrel@www.woofpaws.com> We've had an increasing rate of DoS attacks that spew tens-of-thousands of small UDP packets to a destination on our network. We are getting roughly 2x our entire normal pps across all providers through one interface, or about 4x normal through the individual interface. The Cisco 7206VXR/NPE-G1 CPU melts (>95% load vs 15% average, 20% normal peak) when this hits. I'm using CEF and ip-route-cache flow on the outside interface. Unicast RPF is also enabled on the interface. Unicast RPF in conjunction with a BGP black-hole generator handles TCP attacks fairly well. Two questions: - Are there any knobs I should be turning in the Cisco config to help with mitigate this? - Are there any platforms that deal with high PPS/small packet more gracefully? We are looking at a network refresh and aren't locked into Cisco as a vendor (although our current IP network consists entirely of Cisco gear). Our current aggregate (all providers, in- plus out-bound) bandwidth is ~500Mbs, but projected growth is 1Gbs within the year. Thanks, Rick From rdobbins at cisco.com Fri Dec 12 12:24:23 2008 From: rdobbins at cisco.com (Roland Dobbins) Date: Sat, 13 Dec 2008 02:24:23 +0800 Subject: UDP DoS mitigation? In-Reply-To: <57995.69.30.17.85.1229105716.squirrel@www.woofpaws.com> References: <57995.69.30.17.85.1229105716.squirrel@www.woofpaws.com> Message-ID: <24FBDD73-BAB3-4910-9FD4-D092F4BA8FCD@cisco.com> On Dec 13, 2008, at 2:15 AM, Rick Ernst wrote: > - Are there any platforms that deal with high PPS/small packet more > gracefully? S/RTBH can deal with any type of packet-flooding DDoS at layer-3, up to the capacity of the platform in question. It sounds as if a) you should investigate getting DDoS mitigation assistance from your upstreams and/or b) moving from your currently software-based platform to a hardware-based platform at your edge to provide increased performance (this holds true irrespective of which vendor you select for your edge platform). If you move to a hardware-based edge platform, be sure to first investigate all the particulars of its uRPF implementation so as to ensure that you can use it for S/RTBH, and if at all possible, test it before buying. ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile History is a great teacher, but it also lies with impunity. -- John Robb From dkotlerewsky at oversee.net Fri Dec 12 12:27:10 2008 From: dkotlerewsky at oversee.net (David Kotlerewsky) Date: Fri, 12 Dec 2008 10:27:10 -0800 Subject: UDP DoS mitigation? In-Reply-To: <57995.69.30.17.85.1229105716.squirrel@www.woofpaws.com> References: <57995.69.30.17.85.1229105716.squirrel@www.woofpaws.com> Message-ID: <83167A7C7B83A84B90E8C1AFD6800FBD02D14912@FIJIEXCHANGE.corp.oversee.net> Couple of things come to mind: 1. Take a packet capture to see some UDP traffic characteristics, based on which traffic rate-limiting may be configured by your upstream providers, so that this traffic doesn't saturate your pipes, and maybe the ISP can even drop it. That is if they're willing to help you. 2. As far as hardware is concerned, we're in the same boat as far as various UDP/ICMP floods, and our Juniper M10i's handle it with no issues (running multiple BGP sessions, OSPF, firewall sets/access lists). Sincerely, David Kotlerewsky, Sr. Network Engineer ------------------------------------------------- OVERSEE.NET 515 S. Flower Street, Suite 4400 Los Angeles, CA 90071 ph 213.408.0080 x1458 cell 310.350.0399 www.oversee.net dkotlerewsky at oversee.net Confidentiality Warning: this email contains information intended for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in it, or transmitted with this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you. -----Original Message----- From: Rick Ernst [mailto:ernst at easystreet.com] Sent: Friday, December 12, 2008 10:15 AM To: nanog at nanog.org Subject: UDP DoS mitigation? We've had an increasing rate of DoS attacks that spew tens-of-thousands of small UDP packets to a destination on our network. We are getting roughly 2x our entire normal pps across all providers through one interface, or about 4x normal through the individual interface. The Cisco 7206VXR/NPE-G1 CPU melts (>95% load vs 15% average, 20% normal peak) when this hits. I'm using CEF and ip-route-cache flow on the outside interface. Unicast RPF is also enabled on the interface. Unicast RPF in conjunction with a BGP black-hole generator handles TCP attacks fairly well. Two questions: - Are there any knobs I should be turning in the Cisco config to help with mitigate this? - Are there any platforms that deal with high PPS/small packet more gracefully? We are looking at a network refresh and aren't locked into Cisco as a vendor (although our current IP network consists entirely of Cisco gear). Our current aggregate (all providers, in- plus out-bound) bandwidth is ~500Mbs, but projected growth is 1Gbs within the year. Thanks, Rick From rdobbins at cisco.com Fri Dec 12 12:33:59 2008 From: rdobbins at cisco.com (Roland Dobbins) Date: Sat, 13 Dec 2008 02:33:59 +0800 Subject: UDP DoS mitigation? In-Reply-To: <83167A7C7B83A84B90E8C1AFD6800FBD02D14912@FIJIEXCHANGE.corp.oversee.net> References: <57995.69.30.17.85.1229105716.squirrel@www.woofpaws.com> <83167A7C7B83A84B90E8C1AFD6800FBD02D14912@FIJIEXCHANGE.corp.oversee.net> Message-ID: On Dec 13, 2008, at 2:27 AM, David Kotlerewsky wrote: > 2. As far as hardware is concerned, we're in the same boat as far as > various UDP/ICMP floods, and our Juniper M10i's handle it with no > issues > (running multiple BGP sessions, OSPF, firewall sets/access lists). Right - a hardware-based platform is required to deal with high pps rates (the Cisco equivalent is the ASR1000; I'm not familiar with boxes from other vendors, but I'm pretty sure there are others in this same class). ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile History is a great teacher, but it also lies with impunity. -- John Robb From frnkblk at iname.com Fri Dec 12 13:13:59 2008 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 12 Dec 2008 13:13:59 -0600 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <20081212034449.5558EC3C11@smtp.ecentral.com> References: Message from "Martin List-Petersen " sent Thu, 11 Dec 2008 21:10:23 GMT <20081212034449.5558EC3C11@smtp.ecentral.com> Message-ID: Is there an easy way to get past history on an IP block? Most sites will show you aspects of that *now*.... Frank -----Original Message----- From: Robert Tarrall [mailto:tarrall at ecentral.com] Sent: Thursday, December 11, 2008 9:45 PM To: nanog at nanog.org Subject: Re: Netblock reassigned from Chile to US ISP... Martin List-Petersen wrote: -> Contact Google. Somebody from Google replied off-list. Sounds like Google maybe had this updated even before he looked at it. -> Again. Akamai is helpful. Contact them. Somebody from Akamai replied off-list and they're looking into it. -> 3) End-user unable to complete an online e-commerce transaction -> due to a fraud-prevention service thinking he was a Chilean user -> trying to buy something with a US-based credit card. -> -> There's no fast fix for this, but have you talked to MaxMind about -> chaning the Geo location ? They'll implent it fast and it's in their -> DB within a week, max 2, but it'll take 2 months at least, before it MaxMind was the first place I checked; they already had the correct info when I looked. IP2Location don't have the right info, but they think it's a Speakeasy.net IP in Washington DC which probably won't be a problem. No idea about Digital Element yet. Netblock is 67.214.48.0/20 - was reg'd a couple of weeks ago so folks who pull ARIN assignments regularly will have it. Those who care but don't check ARIN regularly may want to see if they think it's in Chile, and change it to Denver, Colorado if so. -> However, the ecommerce issue is a bit worse, because there's some -> of'em out there, like one of the biggest hosters in the states, that -> have 2 year old data. Yeah, it's those types that I'm hoping to locate as well... Google and Akamai were immediately noticed by the test users, and have also responded very quickly (thanks, guys), but ideally we'd like to be proactive and get as many of these updated *before* the real customers hit the network and start having problems. -Robert.- From nantoniello at antel.net.uy Fri Dec 12 13:38:25 2008 From: nantoniello at antel.net.uy (Nicolas Antoniello) Date: Fri, 12 Dec 2008 17:38:25 -0200 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: References: Message from "Martin List-Petersen " sent Thu, 11 Dec 2008 21:10:23 GMT <20081212034449.5558EC3C11@smtp.ecentral.com> Message-ID: <4942BDB1.80608@antel.net.uy> Sorry for my ignorance... but may some one explain how this fraud-prevention service works? How about US tourists in Chile trying to buy something with it's US based credit card? :) Thx, Nic. Frank Bulk wrote: > Is there an easy way to get past history on an IP block? Most sites will > show you aspects of that *now*.... > > Frank > > -----Original Message----- > From: Robert Tarrall [mailto:tarrall at ecentral.com] > Sent: Thursday, December 11, 2008 9:45 PM > To: nanog at nanog.org > Subject: Re: Netblock reassigned from Chile to US ISP... > > Martin List-Petersen wrote: > -> Contact Google. > > Somebody from Google replied off-list. Sounds like Google maybe > had this updated even before he looked at it. > > -> Again. Akamai is helpful. Contact them. > > Somebody from Akamai replied off-list and they're looking into it. > > -> 3) End-user unable to complete an online e-commerce transaction > -> due to a fraud-prevention service thinking he was a Chilean user > -> trying to buy something with a US-based credit card. > -> > -> There's no fast fix for this, but have you talked to MaxMind about > -> chaning the Geo location ? They'll implent it fast and it's in their > -> DB within a week, max 2, but it'll take 2 months at least, before it > > MaxMind was the first place I checked; they already had the correct > info when I looked. IP2Location don't have the right info, but they > think it's a Speakeasy.net IP in Washington DC which probably won't be a > problem. No idea about Digital Element yet. > > Netblock is 67.214.48.0/20 - was reg'd a couple of weeks ago so folks > who pull ARIN assignments regularly will have it. Those who care but > don't check ARIN regularly may want to see if they think it's in Chile, > and change it to Denver, Colorado if so. > > -> However, the ecommerce issue is a bit worse, because there's some > -> of'em out there, like one of the biggest hosters in the states, that > -> have 2 year old data. > > Yeah, it's those types that I'm hoping to locate as well... Google > and Akamai were immediately noticed by the test users, and have also > responded very quickly (thanks, guys), but ideally we'd like to be > proactive and get as many of these updated *before* the real customers > hit the network and start having problems. > > -Robert.- > > > From yahoo at jimpop.com Fri Dec 12 13:55:14 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Fri, 12 Dec 2008 14:55:14 -0500 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <4942BDB1.80608@antel.net.uy> References: <20081212034449.5558EC3C11@smtp.ecentral.com> <4942BDB1.80608@antel.net.uy> Message-ID: <7ff145960812121155u49a2b56ajb1aca82cca2dc2df@mail.gmail.com> On Fri, Dec 12, 2008 at 14:38, Nicolas Antoniello wrote: > How about US tourists in Chile trying to buy something with it's US > based credit card? :) It just doesn't work. -Jim P. From martin at airwire.ie Fri Dec 12 14:02:07 2008 From: martin at airwire.ie (Martin List-Petersen) Date: Fri, 12 Dec 2008 20:02:07 +0000 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <4942BDB1.80608@antel.net.uy> References: Message from "Martin List-Petersen " sent Thu, 11 Dec 2008 21:10:23 GMT <20081212034449.5558EC3C11@smtp.ecentral.com> <4942BDB1.80608@antel.net.uy> Message-ID: <4942C33F.8010201@airwire.ie> Nicolas Antoniello wrote: > Sorry for my ignorance... but may some one explain how this > fraud-prevention service works? > > How about US tourists in Chile trying to buy something with it's US > based credit card? :) > It's a misconception of some muppets, especially in IT related products, that forget, that a lot or IT professionals do travel all over the world and usually have a credit card in their home country. Pure and utter nonsense. /M > Thx, > Nic. > > > Frank Bulk wrote: > >> Is there an easy way to get past history on an IP block? Most sites will >> show you aspects of that *now*.... >> >> Frank >> >> -----Original Message----- >> From: Robert Tarrall [mailto:tarrall at ecentral.com] >> Sent: Thursday, December 11, 2008 9:45 PM >> To: nanog at nanog.org >> Subject: Re: Netblock reassigned from Chile to US ISP... >> >> Martin List-Petersen wrote: >> -> Contact Google. >> >> Somebody from Google replied off-list. Sounds like Google maybe >> had this updated even before he looked at it. >> >> -> Again. Akamai is helpful. Contact them. >> >> Somebody from Akamai replied off-list and they're looking into it. >> >> -> 3) End-user unable to complete an online e-commerce transaction >> -> due to a fraud-prevention service thinking he was a Chilean user >> -> trying to buy something with a US-based credit card. >> -> >> -> There's no fast fix for this, but have you talked to MaxMind about >> -> chaning the Geo location ? They'll implent it fast and it's in their >> -> DB within a week, max 2, but it'll take 2 months at least, before it >> >> MaxMind was the first place I checked; they already had the correct >> info when I looked. IP2Location don't have the right info, but they >> think it's a Speakeasy.net IP in Washington DC which probably won't be a >> problem. No idea about Digital Element yet. >> >> Netblock is 67.214.48.0/20 - was reg'd a couple of weeks ago so folks >> who pull ARIN assignments regularly will have it. Those who care but >> don't check ARIN regularly may want to see if they think it's in Chile, >> and change it to Denver, Colorado if so. >> >> -> However, the ecommerce issue is a bit worse, because there's some >> -> of'em out there, like one of the biggest hosters in the states, that >> -> have 2 year old data. >> >> Yeah, it's those types that I'm hoping to locate as well... Google >> and Akamai were immediately noticed by the test users, and have also >> responded very quickly (thanks, guys), but ideally we'd like to be >> proactive and get as many of these updated *before* the real customers >> hit the network and start having problems. >> >> -Robert.- >> >> >> >> > > -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From mhuff at ox.com Fri Dec 12 14:04:07 2008 From: mhuff at ox.com (Matthew Huff) Date: Fri, 12 Dec 2008 15:04:07 -0500 Subject: UDP DoS mitigation? In-Reply-To: <57995.69.30.17.85.1229105716.squirrel@www.woofpaws.com> References: <57995.69.30.17.85.1229105716.squirrel@www.woofpaws.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F91433CB473C@PUR-EXCH07.ox.com> Although the problem we had wasn't DoS, but rather high packet rates for market data, we saw a huge improvement by moving from a 7204VRX to a 7600 platform. Going from a software switched environment to a hardware one help deal with large number of packet drops during peaks of burst activity. We looked at the ASR1000, but found the price too high. Although cisco doesn't promote it, the 7604 with the Sup32 engine (WS-SUP32-GE-3B) with 8 x GE interfaces is a very cost effective hardware router. -----Original Message----- From: Rick Ernst [mailto:ernst at easystreet.com] Sent: Friday, December 12, 2008 1:15 PM To: nanog at nanog.org Subject: UDP DoS mitigation? We've had an increasing rate of DoS attacks that spew tens-of-thousands of small UDP packets to a destination on our network. We are getting roughly 2x our entire normal pps across all providers through one interface, or about 4x normal through the individual interface. The Cisco 7206VXR/NPE-G1 CPU melts (>95% load vs 15% average, 20% normal peak) when this hits. I'm using CEF and ip-route-cache flow on the outside interface. Unicast RPF is also enabled on the interface. Unicast RPF in conjunction with a BGP black-hole generator handles TCP attacks fairly well. Two questions: - Are there any knobs I should be turning in the Cisco config to help with mitigate this? - Are there any platforms that deal with high PPS/small packet more gracefully? We are looking at a network refresh and aren't locked into Cisco as a vendor (although our current IP network consists entirely of Cisco gear). Our current aggregate (all providers, in- plus out-bound) bandwidth is ~500Mbs, but projected growth is 1Gbs within the year. Thanks, Rick From ernst at easystreet.com Fri Dec 12 14:47:36 2008 From: ernst at easystreet.com (Rick Ernst) Date: Fri, 12 Dec 2008 12:47:36 -0800 (PST) Subject: UDP DoS mitigation? In-Reply-To: <57995.69.30.17.85.1229105716.squirrel@www.woofpaws.com> References: <57995.69.30.17.85.1229105716.squirrel@www.woofpaws.com> Message-ID: <49833.69.30.17.85.1229114856.squirrel@www.woofpaws.com> Replying to my own since there are currently about a dozen responses. - Hardware/ASIC routers are a consistent response. We are currently evaluating Juniper for other reasons, but I'll add DoS mitigation to mix. - Upstream involvement: We get transit from 701, 1239, etc. I've had mixed results getting timely responses from our upstreams. It's useful for long-term issues, but I need as much local and timely control as I can get. - I'm not having a problem with pipe bandwidth, but high pps. - uRPF and RTBH helped internally, but anything passing through that upstream connection was impacted. - This instance was a DoS, not DDoS. Single source and destination, but the source (assuming no spoofing) was in Italy. Turning off netflow seemed to help, but the attack itself stopped at about the same time. Also, thanks for the offers of individual help in mitigation, although I'd be concerned that "Hey, can somebody block traffic {from} or {to}?" would be an interesting experiment in a socially-engineered DoS. Finally, there were some suggestions "S/RTBH". RTBH I get, but my Google-fu is weak on S/RTBH. Details? Thanks, Rick On Fri, December 12, 2008 10:15, Rick Ernst wrote: > > We've had an increasing rate of DoS attacks that spew tens-of-thousands of > small UDP packets to a destination on our network. We are getting roughly > 2x our entire normal pps across all providers through one interface, or > about 4x normal through the individual interface. The Cisco > 7206VXR/NPE-G1 CPU melts (>95% load vs 15% average, 20% normal peak) when > this hits. > > I'm using CEF and ip-route-cache flow on the outside interface. Unicast > RPF is also enabled on the interface. Unicast RPF in conjunction with a > BGP black-hole generator handles TCP attacks fairly well. > > Two questions: > - Are there any knobs I should be turning in the Cisco config to help with > mitigate this? > - Are there any platforms that deal with high PPS/small packet more > gracefully? > > We are looking at a network refresh and aren't locked into Cisco as a > vendor (although our current IP network consists entirely of Cisco gear). > Our current aggregate (all providers, in- plus out-bound) bandwidth is > ~500Mbs, but projected growth is 1Gbs within the year. > > Thanks, > Rick > > > From leslie at craigslist.org Fri Dec 12 15:37:38 2008 From: leslie at craigslist.org (Leslie) Date: Fri, 12 Dec 2008 13:37:38 -0800 Subject: e300 vs mx240 for border router ? Message-ID: <4942D9A2.7090002@craigslist.org> Hey nanog-izens So for routers that are touching our transit and (hopefully soon) future peering, we're looking at both the force10 e300's and juniper mx240's. The e300's are cheap but I have heard some rumors/talk of falling over when it has to deal with large numbers of prefixes and routes? The mx240's are nice but the cost difference is enormous. Does anyone have experience with e300's running into issues with large routing tables? Are there any tricks/tips that work around any issues (if they exist?) Thanks in advance Leslie From dkotlerewsky at oversee.net Fri Dec 12 15:46:18 2008 From: dkotlerewsky at oversee.net (David Kotlerewsky) Date: Fri, 12 Dec 2008 13:46:18 -0800 Subject: e300 vs mx240 for border router ? In-Reply-To: <4942D9A2.7090002@craigslist.org> References: <4942D9A2.7090002@craigslist.org> Message-ID: <83167A7C7B83A84B90E8C1AFD6800FBD02D14923@FIJIEXCHANGE.corp.oversee.net> How many BGP sessions will you run on these routers? Sincerely, David Kotlerewsky, Sr. Network Engineer ------------------------------------------------- OVERSEE.NET 515 S. Flower Street, Suite 4400 Los Angeles, CA 90071 ph 213.408.0080 x1458 cell 310.350.0399 www.oversee.net dkotlerewsky at oversee.net Confidentiality Warning: this email contains information intended for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in it, or transmitted with this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you. -----Original Message----- From: Leslie [mailto:leslie at craigslist.org] Sent: Friday, December 12, 2008 1:38 PM To: nanog at nanog.org Subject: e300 vs mx240 for border router ? Hey nanog-izens So for routers that are touching our transit and (hopefully soon) future peering, we're looking at both the force10 e300's and juniper mx240's. The e300's are cheap but I have heard some rumors/talk of falling over when it has to deal with large numbers of prefixes and routes? The mx240's are nice but the cost difference is enormous. Does anyone have experience with e300's running into issues with large routing tables? Are there any tricks/tips that work around any issues (if they exist?) Thanks in advance Leslie From leslie at craigslist.org Fri Dec 12 16:27:57 2008 From: leslie at craigslist.org (Leslie) Date: Fri, 12 Dec 2008 14:27:57 -0800 Subject: e300 vs mx240 for border router ? In-Reply-To: <4942D9A2.7090002@craigslist.org> References: <4942D9A2.7090002@craigslist.org> Message-ID: <4942E56D.5060105@craigslist.org> Thanks to everyone who wrote back privately -- I also didn't know that force10 now has dual-cam linecards which raises the amount of routes it can handle Leslie wrote: > Hey nanog-izens > > So for routers that are touching our transit and (hopefully soon) future > peering, we're looking at both the force10 e300's and juniper mx240's. > The e300's are cheap but I have heard some rumors/talk of falling over > when it has to deal with large numbers of prefixes and routes? The > mx240's are nice but the cost difference is enormous. Does anyone have > experience with e300's running into issues with large routing tables? > Are there any tricks/tips that work around any issues (if they exist?) > > Thanks in advance > > Leslie From mike at m5computersecurity.com Fri Dec 12 16:37:05 2008 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Fri, 12 Dec 2008 14:37:05 -0800 Subject: e300 vs mx240 for border router ? In-Reply-To: <4942E56D.5060105@craigslist.org> References: <4942D9A2.7090002@craigslist.org> <4942E56D.5060105@craigslist.org> Message-ID: <1229121425.6160.1938.camel@mike-desktop> Leslie, Can you summarize any other info you may have learned in the private responses for the benefit of those that are interested ? I am not at all familiar with the Force10s, am buying new border routers now. Thanks, Mike On Fri, 2008-12-12 at 14:27 -0800, Leslie wrote: > Thanks to everyone who wrote back privately -- > > I also didn't know that force10 now has dual-cam linecards which raises > the amount of routes it can handle > > Leslie wrote: > > Hey nanog-izens > > > > So for routers that are touching our transit and (hopefully soon) future > > peering, we're looking at both the force10 e300's and juniper mx240's. > > The e300's are cheap but I have heard some rumors/talk of falling over > > when it has to deal with large numbers of prefixes and routes? The > > mx240's are nice but the cost difference is enormous. Does anyone have > > experience with e300's running into issues with large routing tables? > > Are there any tricks/tips that work around any issues (if they exist?) > > > > Thanks in advance > > > > Leslie > -- ************************************************************ Michael J. McCafferty Principal, Security Engineer M5 Hosting http://www.m5hosting.com You can have your own custom Dedicated Server up and running today ! RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more ************************************************************ From jabley at hopcount.ca Fri Dec 12 17:06:42 2008 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 12 Dec 2008 18:06:42 -0500 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <4942C33F.8010201@airwire.ie> References: Message from "Martin List-Petersen " sent Thu, 11 Dec 2008 21:10:23 GMT <20081212034449.5558EC3C11@smtp.ecentral.com> <4942BDB1.80608@antel.net.uy> <4942C33F.8010201@airwire.ie> Message-ID: <2831F941-EAB4-4BC2-BC04-D213994B0356@hopcount.ca> On 2008-12-12, at 15:02, Martin List-Petersen wrote: > It's a misconception of some muppets, especially in IT related > products, that forget, that a lot or IT professionals do travel all > over the world and usually have a credit card in their home country. > > Pure and utter nonsense. Or perhaps the hassle of dealing with stolen US credit card numbers from clients outside the US costs far more money than you could hope to make back with the purchases of US nationals travelling overseas? Could well be muppets, but surely there are other possibilities. Joe From nathan at robotics.net Fri Dec 12 17:14:38 2008 From: nathan at robotics.net (Nathan Stratton) Date: Fri, 12 Dec 2008 17:14:38 -0600 (CST) Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <2831F941-EAB4-4BC2-BC04-D213994B0356@hopcount.ca> References: Message from "Martin List-Petersen " sent Thu, 11 Dec 2008 21:10:23 GMT <20081212034449.5558EC3C11@smtp.ecentral.com> <4942BDB1.80608@antel.net.uy> <4942C33F.8010201@airwire.ie> <2831F941-EAB4-4BC2-BC04-D213994B0356@hopcount.ca> Message-ID: On Fri, 12 Dec 2008, Joe Abley wrote: > On 2008-12-12, at 15:02, Martin List-Petersen wrote: > >> It's a misconception of some muppets, especially in IT related products, >> that forget, that a lot or IT professionals do travel all over the world >> and usually have a credit card in their home country. >> >> Pure and utter nonsense. > > Or perhaps the hassle of dealing with stolen US credit card numbers from > clients outside the US costs far more money than you could hope to make back > with the purchases of US nationals travelling overseas? > > Could well be muppets, but surely there are other possibilities. Sad but true, we have had to turn off signups outside the US because of that very problem. Yes, I am sure we lose some sales, but in general it is not worth the fraud costs. ><> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com From owen at delong.com Fri Dec 12 17:49:11 2008 From: owen at delong.com (Owen DeLong) Date: Fri, 12 Dec 2008 15:49:11 -0800 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: References: Message from "Martin List-Petersen " sent Thu, 11 Dec 2008 21:10:23 GMT <20081212034449.5558EC3C11@smtp.ecentral.com> <4942BDB1.80608@antel.net.uy> <4942C33F.8010201@airwire.ie> <2831F941-EAB4-4BC2-BC04-D213994B0356@hopcount.ca> Message-ID: <060F3B30-0EE6-439A-8098-66499BE6FD78@delong.com> On Dec 12, 2008, at 3:14 PM, Nathan Stratton wrote: > On Fri, 12 Dec 2008, Joe Abley wrote: > >> On 2008-12-12, at 15:02, Martin List-Petersen wrote: >> >>> It's a misconception of some muppets, especially in IT related >>> products, that forget, that a lot or IT professionals do travel >>> all over the world and usually have a credit card in their home >>> country. >>> Pure and utter nonsense. >> >> Or perhaps the hassle of dealing with stolen US credit card numbers >> from clients outside the US costs far more money than you could >> hope to make back with the purchases of US nationals travelling >> overseas? >> >> Could well be muppets, but surely there are other possibilities. > > Sad but true, we have had to turn off signups outside the US because > of that very problem. Yes, I am sure we lose some sales, but in > general it is not worth the fraud costs. Why don't the fraudsters just use Open US Proxies? Owen From martin at airwire.ie Fri Dec 12 17:54:43 2008 From: martin at airwire.ie (Martin List-Petersen) Date: Fri, 12 Dec 2008 23:54:43 +0000 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <2831F941-EAB4-4BC2-BC04-D213994B0356@hopcount.ca> References: Message from "Martin List-Petersen " sent Thu, 11 Dec 2008 21:10:23 GMT <20081212034449.5558EC3C11@smtp.ecentral.com> <4942BDB1.80608@antel.net.uy> <4942C33F.8010201@airwire.ie> <2831F941-EAB4-4BC2-BC04-D213994B0356@hopcount.ca> Message-ID: <4942F9C3.9080106@airwire.ie> Joe Abley wrote: > > On 2008-12-12, at 15:02, Martin List-Petersen wrote: > >> It's a misconception of some muppets, especially in IT related >> products, that forget, that a lot or IT professionals do travel all >> over the world and usually have a credit card in their home country. >> >> Pure and utter nonsense. > > Or perhaps the hassle of dealing with stolen US credit card numbers from > clients outside the US costs far more money than you could hope to make > back with the purchases of US nationals travelling overseas? > > Could well be muppets, but surely there are other possibilities. > I can understand merchants wanting the extra security, but the issue is, that they then don't want to fork out for a MaxMind subscription or the likes. One of the bigger colo providers in the states is selling SSL certificates, but their geoip data is ancient. I even bothered to raise a ticket with them and the answer was just "we're working with our development team on that". When I revisited 6 months later, nothing had changed. It's not the only case, that I've ran into this issue and the US is not the only place that credit cards are issued or used. Nor is credit card/credit card theft a outside US only thing. It happens anywhere, inside or outside the US. That's exactly, why the banks starting adding the personalized password option etc. Using outdated geoip data for merchant-services is as unprofessional as asking people to fax a copy of their credit card to some fax number. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From martin at airwire.ie Fri Dec 12 17:56:46 2008 From: martin at airwire.ie (Martin List-Petersen) Date: Fri, 12 Dec 2008 23:56:46 +0000 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <060F3B30-0EE6-439A-8098-66499BE6FD78@delong.com> References: Message from "Martin List-Petersen " sent Thu, 11 Dec 2008 21:10:23 GMT <20081212034449.5558EC3C11@smtp.ecentral.com> <4942BDB1.80608@antel.net.uy> <4942C33F.8010201@airwire.ie> <2831F941-EAB4-4BC2-BC04-D213994B0356@hopcount.ca> <060F3B30-0EE6-439A-8098-66499BE6FD78@delong.com> Message-ID: <4942FA3E.2050308@airwire.ie> Owen DeLong wrote: > > On Dec 12, 2008, at 3:14 PM, Nathan Stratton wrote: > >> On Fri, 12 Dec 2008, Joe Abley wrote: >> >>> On 2008-12-12, at 15:02, Martin List-Petersen wrote: >>> >>>> It's a misconception of some muppets, especially in IT related >>>> products, that forget, that a lot or IT professionals do travel all >>>> over the world and usually have a credit card in their home country. >>>> Pure and utter nonsense. >>> >>> Or perhaps the hassle of dealing with stolen US credit card numbers >>> from clients outside the US costs far more money than you could hope >>> to make back with the purchases of US nationals travelling overseas? >>> >>> Could well be muppets, but surely there are other possibilities. >> >> Sad but true, we have had to turn off signups outside the US because >> of that very problem. Yes, I am sure we lose some sales, but in >> general it is not worth the fraud costs. > > Why don't the fraudsters just use Open US Proxies? > You can be sure, that the people wanting to defraud merchants know all these tricks and use them. The verified by visa password option is a far better solution, but I've not seen many US merchants supporting that yet. Instead they're relying on outdated geoip data or ask people to fax a copy of their credit card. /Martin -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From tomb at byrneit.net Fri Dec 12 18:32:57 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Fri, 12 Dec 2008 16:32:57 -0800 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <2831F941-EAB4-4BC2-BC04-D213994B0356@hopcount.ca> References: Message from "Martin List-Petersen " sent Thu, 11 Dec 200821:10:23 GMT <20081212034449.5558EC3C11@smtp.ecentral.com> <4942BDB1.80608@antel.net.uy> <4942C33F.8010201@airwire.ie> <2831F941-EAB4-4BC2-BC04-D213994B0356@hopcount.ca> Message-ID: <70D072392E56884193E3D2DE09C097A9FB2D@pascal.zaphodb.org> We probably should move this to funsec, but I'll bite. The basic problem is the lack of security and non-repudiation in credit cards in general, and the US in particular. Non-clonable, card-present, technologies have existed for a long time, and card readers are cheap. AMEX tried to make this free with Blue, but it wasn't adopted. So, the US banks, and AMEX, seem willing to exchange some amount of fraud, and inconvenience for a minority; in exchange for convenience and higher transaction volume for the majority. They've been enabled by the fact that HNC's software works very well. As long as those who make the profit bear the bulk of the risk, as they do with credit cards, I guess there's no issue. Given the "debit card" lack of limit of liability for the consumer, this may change. >-----Original Message----- >From: Joe Abley [mailto:jabley at hopcount.ca] >Sent: Friday, December 12, 2008 3:07 PM >To: Martin List-Petersen >Cc: nanog at nanog.org >Subject: Re: Netblock reassigned from Chile to US ISP... > > >On 2008-12-12, at 15:02, Martin List-Petersen wrote: > >> It's a misconception of some muppets, especially in IT related >> products, that forget, that a lot or IT professionals do travel all >> over the world and usually have a credit card in their home country. >> >> Pure and utter nonsense. > >Or perhaps the hassle of dealing with stolen US credit card numbers >from clients outside the US costs far more money than you could hope >to make back with the purchases of US nationals travelling overseas? > >Could well be muppets, but surely there are other possibilities. > > >Joe > From tomb at byrneit.net Fri Dec 12 18:33:51 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Fri, 12 Dec 2008 16:33:51 -0800 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <060F3B30-0EE6-439A-8098-66499BE6FD78@delong.com> References: Message from "Martin List-Petersen " sent Thu, 11 Dec 2008 21:10:23 GMT<20081212034449.5558EC3C11@smtp.ecentral.com><4942BDB1.80608@antel.net.uy> <4942C33F.8010201@airwire.ie><2831F941-EAB4-4BC2-BC04-D213994B0356@hopcount.ca> <060F3B30-0EE6-439A-8098-66499BE6FD78@delong.com> Message-ID: <70D072392E56884193E3D2DE09C097A9FB2E@pascal.zaphodb.org> Because anyone with half a brain blocks proxies from their e-commerce site. >-----Original Message----- >From: Owen DeLong [mailto:owen at delong.com] >Sent: Friday, December 12, 2008 3:49 PM >To: Nathan Stratton >Cc: nanog at nanog.org >Subject: Re: Netblock reassigned from Chile to US ISP... > > >On Dec 12, 2008, at 3:14 PM, Nathan Stratton wrote: > >> On Fri, 12 Dec 2008, Joe Abley wrote: >> >>> On 2008-12-12, at 15:02, Martin List-Petersen wrote: >>> >>>> It's a misconception of some muppets, especially in IT related >>>> products, that forget, that a lot or IT professionals do travel >>>> all over the world and usually have a credit card in their home >>>> country. >>>> Pure and utter nonsense. >>> >>> Or perhaps the hassle of dealing with stolen US credit card numbers >>> from clients outside the US costs far more money than you could >>> hope to make back with the purchases of US nationals travelling >>> overseas? >>> >>> Could well be muppets, but surely there are other possibilities. >> >> Sad but true, we have had to turn off signups outside the US because >> of that very problem. Yes, I am sure we lose some sales, but in >> general it is not worth the fraud costs. > >Why don't the fraudsters just use Open US Proxies? > >Owen > From hannigan at gmail.com Sat Dec 13 01:05:01 2008 From: hannigan at gmail.com (Martin Hannigan) Date: Sat, 13 Dec 2008 02:05:01 -0500 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <70D072392E56884193E3D2DE09C097A9FB2E@pascal.zaphodb.org> References: <20081212034449.5558EC3C11@smtp.ecentral.com> <4942BDB1.80608@antel.net.uy> <4942C33F.8010201@airwire.ie> <2831F941-EAB4-4BC2-BC04-D213994B0356@hopcount.ca> <060F3B30-0EE6-439A-8098-66499BE6FD78@delong.com> <70D072392E56884193E3D2DE09C097A9FB2E@pascal.zaphodb.org> Message-ID: <2d106eb50812122305xac0d12am16bed5d8ad804e8@mail.gmail.com> On Fri, Dec 12, 2008 at 7:33 PM, Tomas L. Byrnes wrote: > Because anyone with half a brain blocks proxies from their e-commerce > site. > I doubt it. -M< From randy at psg.com Sat Dec 13 01:12:59 2008 From: randy at psg.com (Randy Bush) Date: Sat, 13 Dec 2008 16:12:59 +0900 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <70D072392E56884193E3D2DE09C097A9FB2E@pascal.zaphodb.org> References: Message from "Martin List-Petersen " sent Thu, 11 Dec 2008 21:10:23 GMT<20081212034449.5558EC3C11@smtp.ecentral.com><4942BDB1.80608@antel.net.uy> <4942C33F.8010201@airwire.ie><2831F941-EAB4-4BC2-BC04-D213994B0356@hopcount.ca> <060F3B30-0EE6-439A-8098-66499BE6FD78@delong.com> <70D072392E56884193E3D2DE09C097A9FB2E@pascal.zaphodb.org> Message-ID: <4943607B.70305@psg.com> On 08.12.13 09:33, Tomas L. Byrnes wrote: > anyone with half a brain blocks proxies from their e-commerce site. can you know at a reasonable confidence level that it's a proxy? randy From fergdawgster at gmail.com Sat Dec 13 01:22:24 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Fri, 12 Dec 2008 23:22:24 -0800 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <4943607B.70305@psg.com> References: <20081212034449.5558EC3C11@smtp.ecentral.com> <4942BDB1.80608@antel.net.uy> <4942C33F.8010201@airwire.ie> <2831F941-EAB4-4BC2-BC04-D213994B0356@hopcount.ca> <060F3B30-0EE6-439A-8098-66499BE6FD78@delong.com> <70D072392E56884193E3D2DE09C097A9FB2E@pascal.zaphodb.org> <4943607B.70305@psg.com> Message-ID: <6cd462c00812122322k195fccdeu34b212fe5cc1f38d@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Dec 12, 2008 at 11:12 PM, Randy Bush wrote: > On 08.12.13 09:33, Tomas L. Byrnes wrote: >> >> anyone with half a brain blocks proxies from their e-commerce site. > > can you know at a reasonable confidence level that it's a proxy? > Give me an IP address (privately, of course). I can tell you if it is, with consult from other colleagues in the security community. That's almost a no-brainer. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJQ2Kqq1pz9mNUZTMRArkZAJ42wBsiviQOeX/Ei6gPCY+Rk8zRjQCdHDfg djeldwF25CYOUsDoGQQzKPs= =jkIf -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From randy at psg.com Sat Dec 13 01:24:14 2008 From: randy at psg.com (Randy Bush) Date: Sat, 13 Dec 2008 16:24:14 +0900 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <6cd462c00812122322k195fccdeu34b212fe5cc1f38d@mail.gmail.com> References: <20081212034449.5558EC3C11@smtp.ecentral.com> <4942BDB1.80608@antel.net.uy> <4942C33F.8010201@airwire.ie> <2831F941-EAB4-4BC2-BC04-D213994B0356@hopcount.ca> <060F3B30-0EE6-439A-8098-66499BE6FD78@delong.com> <70D072392E56884193E3D2DE09C097A9FB2E@pascal.zaphodb.org> <4943607B.70305@psg.com> <6cd462c00812122322k195fccdeu34b212fe5cc1f38d@mail.gmail.com> Message-ID: <4943631E.3010303@psg.com> > Give me an IP address (privately, of course). I can tell you if it is, with > consult from other colleagues in the security community. 147.28.0.36 and "consult with colleagues" is not something very operationally scalable. randy From fergdawgster at gmail.com Sat Dec 13 01:30:09 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Fri, 12 Dec 2008 23:30:09 -0800 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <4943631E.3010303@psg.com> References: <4942BDB1.80608@antel.net.uy> <4942C33F.8010201@airwire.ie> <2831F941-EAB4-4BC2-BC04-D213994B0356@hopcount.ca> <060F3B30-0EE6-439A-8098-66499BE6FD78@delong.com> <70D072392E56884193E3D2DE09C097A9FB2E@pascal.zaphodb.org> <4943607B.70305@psg.com> <6cd462c00812122322k195fccdeu34b212fe5cc1f38d@mail.gmail.com> <4943631E.3010303@psg.com> Message-ID: <6cd462c00812122330n3063708fp3dda331ff5c5327@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Dec 12, 2008 at 11:24 PM, Randy Bush wrote: >> Give me an IP address (privately, of course). I can tell you if it is, >> with >> consult from other colleagues in the security community. > > 147.28.0.36 > > and "consult with colleagues" is not something very operationally > scalable. > Of course, chasing ghosts in RGnet/PSGnet is clever, but not a worthwhile exercise. The point here is that there are many folks monitoring open proxies for illegal activities, etc., and not all of the mind-share reside in one single database. A collaborate effort to share information on abuse activity is required, of course -- and indeed already exists. So having said all that, what exactly was your point? :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJQ2R7q1pz9mNUZTMRArY+AJ0VRvOLF/xEBzAKHysNKRo668ucQwCgmhL9 ZoPn/XhkTcABuVQwFBKa2qk= =sdw8 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From randy at psg.com Sat Dec 13 01:36:55 2008 From: randy at psg.com (Randy Bush) Date: Sat, 13 Dec 2008 16:36:55 +0900 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <6cd462c00812122330n3063708fp3dda331ff5c5327@mail.gmail.com> References: <4942BDB1.80608@antel.net.uy> <4942C33F.8010201@airwire.ie> <2831F941-EAB4-4BC2-BC04-D213994B0356@hopcount.ca> <060F3B30-0EE6-439A-8098-66499BE6FD78@delong.com> <70D072392E56884193E3D2DE09C097A9FB2E@pascal.zaphodb.org> <4943607B.70305@psg.com> <6cd462c00812122322k195fccdeu34b212fe5cc1f38d@mail.gmail.com> <4943631E.3010303@psg.com> <6cd462c00812122330n3063708fp3dda331ff5c5327@mail.gmail.com> Message-ID: <49436617.6060402@psg.com> > So having said all that, what exactly was your point? :-) bluff calling. that you can not tell us if that specific host is a proxy means that this is pretty much bs. that you and your no-girls-allowed club have some list of things you think are proxies (sure would be nice to have a definition thereof), doeth not make a rigorous, testable, and scalable system. though i guess some list of things you don't like has some utility. but it sure ain't automatible ops let alone computer science. randy From fergdawgster at gmail.com Sat Dec 13 01:43:19 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Fri, 12 Dec 2008 23:43:19 -0800 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <49436617.6060402@psg.com> References: <2831F941-EAB4-4BC2-BC04-D213994B0356@hopcount.ca> <060F3B30-0EE6-439A-8098-66499BE6FD78@delong.com> <70D072392E56884193E3D2DE09C097A9FB2E@pascal.zaphodb.org> <4943607B.70305@psg.com> <6cd462c00812122322k195fccdeu34b212fe5cc1f38d@mail.gmail.com> <4943631E.3010303@psg.com> <6cd462c00812122330n3063708fp3dda331ff5c5327@mail.gmail.com> <49436617.6060402@psg.com> Message-ID: <6cd462c00812122343k2d61bdb3le09fef99112e8f7d@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Dec 12, 2008 at 11:36 PM, Randy Bush wrote: >> So having said all that, what exactly was your point? :-) > > bluff calling. > > that you can not tell us if that specific host is a proxy means that this > is pretty much bs. > > that you and your no-girls-allowed club have some list of things you > think are proxies (sure would be nice to have a definition thereof), > doeth not make a rigorous, testable, and scalable system. Gee, I seem to have said that before regarding nsp-sec. D-oh! Look it, whatever you may think, there's certainly no "old boys club" factor at work here, but I'm certainly not going to put up a portal where anyone and their grandmother can check for known open proxies -- there is already enough of that -- and that actually is not the point. That chip on your shoulder must be getting pretty heavy... so forget it. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJQ2eRq1pz9mNUZTMRAsWNAKDU1/u/PH3xTNQAfGJqZIpT6H6jpQCg+cbM nxKsQOt+2vwa92pA3oWqI5w= =vmia -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From mysidia at gmail.com Sat Dec 13 02:22:01 2008 From: mysidia at gmail.com (James Hess) Date: Sat, 13 Dec 2008 02:22:01 -0600 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <6cd462c00812122322k195fccdeu34b212fe5cc1f38d@mail.gmail.com> References: <4942BDB1.80608@antel.net.uy> <4942C33F.8010201@airwire.ie> <2831F941-EAB4-4BC2-BC04-D213994B0356@hopcount.ca> <060F3B30-0EE6-439A-8098-66499BE6FD78@delong.com> <70D072392E56884193E3D2DE09C097A9FB2E@pascal.zaphodb.org> <4943607B.70305@psg.com> <6cd462c00812122322k195fccdeu34b212fe5cc1f38d@mail.gmail.com> Message-ID: <6eb799ab0812130022l16ed94e3r172a178f20812d24@mail.gmail.com> >> On 08.12.13 09:33, Tomas L. Byrnes wrote: >>> anyone with half a brain blocks proxies from their e-commerce site. >> can you know at a reasonable confidence level that it's a proxy? > Give me an IP address (privately, of course). I can tell you if it is, with > consult from other colleagues in the security community. > That's almost a no-brainer. Oh, but can you tell if an IP address is a compromised workstation or host of a VPN application that only allows the proxy access to the intruder? Not all proxies are plainly visible. Geography of an IP address can be a useful heuristic to assist detection, when most transactions attempted from certain regions are bad; esp. when combined with other factors This is a strategy well-known to be probalistic, and thus imperfect (not every fraud attempt will be noticed by a detector, and there will be false positives, but probably very few in relation to the total transaction throughput of say a large online retailer). E-mail spam filters use imperfect methods like this all the time; there is no magic check to prove a message spam or not spam. Instead, _many_ randomized spam checks are strung in sequence for the same message. And if any one or two checks fail, filters drop the message. A successful message (or E-commerce transaction) is one that clears substantially all spam/ fraud checks. An in-depth strategy with hundreds or thousands of factors examined results in a smaller (but still present) possibility of the filter/detector being fooled. IP-based methods can be combined with the other stronger analysis of transaction details and other info that can be gathered about a submitter for detection of attempted abuse. -- -J From mysidia at gmail.com Sat Dec 13 02:22:01 2008 From: mysidia at gmail.com (James Hess) Date: Sat, 13 Dec 2008 02:22:01 -0600 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <6cd462c00812122322k195fccdeu34b212fe5cc1f38d@mail.gmail.com> References: <4942BDB1.80608@antel.net.uy> <4942C33F.8010201@airwire.ie> <2831F941-EAB4-4BC2-BC04-D213994B0356@hopcount.ca> <060F3B30-0EE6-439A-8098-66499BE6FD78@delong.com> <70D072392E56884193E3D2DE09C097A9FB2E@pascal.zaphodb.org> <4943607B.70305@psg.com> <6cd462c00812122322k195fccdeu34b212fe5cc1f38d@mail.gmail.com> Message-ID: <6eb799ab0812130022l16ed94e3r172a178f20812d24@mail.gmail.com> >> On 08.12.13 09:33, Tomas L. Byrnes wrote: >>> anyone with half a brain blocks proxies from their e-commerce site. >> can you know at a reasonable confidence level that it's a proxy? > Give me an IP address (privately, of course). I can tell you if it is, with > consult from other colleagues in the security community. > That's almost a no-brainer. Oh, but can you tell if an IP address is a compromised workstation or host of a VPN application that only allows the proxy access to the intruder? Not all proxies are plainly visible. Geography of an IP address can be a useful heuristic to assist detection, when most transactions attempted from certain regions are bad; esp. when combined with other factors This is a strategy well-known to be probalistic, and thus imperfect (not every fraud attempt will be noticed by a detector, and there will be false positives, but probably very few in relation to the total transaction throughput of say a large online retailer). E-mail spam filters use imperfect methods like this all the time; there is no magic check to prove a message spam or not spam. Instead, _many_ randomized spam checks are strung in sequence for the same message. And if any one or two checks fail, filters drop the message. A successful message (or E-commerce transaction) is one that clears substantially all spam/ fraud checks. An in-depth strategy with hundreds or thousands of factors examined results in a smaller (but still present) possibility of the filter/detector being fooled. IP-based methods can be combined with the other stronger analysis of transaction details and other info that can be gathered about a submitter for detection of attempted abuse. -- -J From fergdawgster at gmail.com Sat Dec 13 02:29:00 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sat, 13 Dec 2008 00:29:00 -0800 Subject: Security Intelligence [Was: Re: Netblock reassigned from Chile to US ISP...] Message-ID: <6cd462c00812130029k7b08b8d5rd92c68dc9550a94e@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Dec 13, 2008 at 12:22 AM, James Hess wrote: > > An in-depth strategy with hundreds or thousands of factors examined > results in a smaller > (but still present) possibility of the filter/detector being fooled. > > IP-based methods can be combined with the other stronger analysis of > transaction details and other info that can be gathered about a > submitter for detection of attempted abuse. > Personally, I don;t NANOG is the proper forum for this discussion. There are other forums, however, which do follow these issues -- some public, some private. If folks think that people are not "doing" massive correlation of criminal activity on the Internet, they would be mistaken. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJQ3JBq1pz9mNUZTMRAjqTAKD30/yrEYWu1ep4v7cOH2q3++aKRQCg2Sad wwap7dwpUiOv6r/w5st04KQ= =AZDw -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From fergdawgster at gmail.com Sat Dec 13 02:44:32 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sat, 13 Dec 2008 00:44:32 -0800 Subject: Security Intelligence [Was: Re: Netblock reassigned from Chile to US ISP...] In-Reply-To: <6cd462c00812130029k7b08b8d5rd92c68dc9550a94e@mail.gmail.com> References: <6cd462c00812130029k7b08b8d5rd92c68dc9550a94e@mail.gmail.com> Message-ID: <6cd462c00812130044k1178ba82kd0df6c3e7b2255d5@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Not in the habit of responding to my e-mail, but... On Sat, Dec 13, 2008 at 12:29 AM, Paul Ferguson wrote: > > On Sat, Dec 13, 2008 at 12:22 AM, James Hess wrote: > >> >> An in-depth strategy with hundreds or thousands of factors examined >> results in a smaller >> (but still present) possibility of the filter/detector being fooled. >> >> IP-based methods can be combined with the other stronger analysis of >> transaction details and other info that can be gathered about a >> submitter for detection of attempted abuse. >> > > Personally, I don;t NANOG is the proper forum for this discussion. > > There are other forums, however, which do follow these issues -- some > public, some private. > > If folks think that people are not "doing" massive correlation of > criminal activity on the Internet, they would be mistaken. > The point I am trying to make here is that ISPs should much more engaged in this entire process. In the not-so-distant past, I have tried to engage the ISP community (via NANOG, at NANOG meetings) to get involved in the fight against cyber crime, with lackluster response -- unfortunately. If this problem is ever going to get reduced to a manageable level, ISPs must play a critical role -- one which they have not been willing participants to this day. ISPs have been (one of) the missing links here. Of course, there are very responsible ISPs out there who handle these issue when they are brought to their attention, and they deserve kudos -- but unfortunately, they are are in the minority. This community should be asking itself why that is... and figuring out way to deal with it responsibly. $.02, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJQ3Xpq1pz9mNUZTMRAuloAKDydG8eb0Le53iKzgLdVYzFi/LQ8ACfY9GA 5wqCM9bn9baQnBARNNRIb0Q= =mzwy -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From randy at psg.com Sat Dec 13 02:46:59 2008 From: randy at psg.com (Randy Bush) Date: Sat, 13 Dec 2008 17:46:59 +0900 Subject: Security Intelligence [Was: Re: Netblock reassigned from Chile to US ISP...] In-Reply-To: <6cd462c00812130029k7b08b8d5rd92c68dc9550a94e@mail.gmail.com> References: <6cd462c00812130029k7b08b8d5rd92c68dc9550a94e@mail.gmail.com> Message-ID: <49437683.9030805@psg.com> > If folks think that people are not "doing" massive correlation of criminal > activity on the Internet, they would be mistaken. engineers judge by the results. and, unfortunately, we can read them in the ny times. though some recent papers sure make interesting reading. just picking on one particular cs researcher http://www-cse.ucsd.edu/~savage/papers/CCS08Conversion.pdf http://www-cse.ucsd.edu/~savage/papers/login08.pdf http://www-cse.ucsd.edu/~savage/papers/LEETHeisenbot08.pdf the last being particularly interesting in the domain of being able to *accurately* isolate evil. randy From randy at psg.com Sat Dec 13 02:51:13 2008 From: randy at psg.com (Randy Bush) Date: Sat, 13 Dec 2008 17:51:13 +0900 Subject: Security Intelligence [Was: Re: Netblock reassigned from Chile to US ISP...] In-Reply-To: <6cd462c00812130044k1178ba82kd0df6c3e7b2255d5@mail.gmail.com> References: <6cd462c00812130029k7b08b8d5rd92c68dc9550a94e@mail.gmail.com> <6cd462c00812130044k1178ba82kd0df6c3e7b2255d5@mail.gmail.com> Message-ID: <49437781.2000005@psg.com> > The point I am trying to make here is that ISPs should much more engaged in > this entire process. most of the larger isps have reasonable security teams with some good folk. but you need to be much more specific about what you want from medium and smaller isps, and what the immediate payoffs (cf. the financial secions of the newpaper) will be to them to justify the costs. just whining that no one will come out to play is not a success strategy, as you say you have well demonstrated. be specific, like "if you run X tools the payoff will be Y." randy From jasper at seektrack.co.nz Sat Dec 13 05:23:57 2008 From: jasper at seektrack.co.nz (Jasper Bryant-Greene) Date: Sun, 14 Dec 2008 00:23:57 +1300 Subject: Dedicated server provider in LA Message-ID: Hi all, Apologies for the operational content, does anyone know (or is anyone) a dedicated server provider who can get a Linux server online for us in the next three hours? We urgently need to move a live site due to system failure. Preferably west coast USA, but beggars can't be choosers. Replies off-list. Thanks in advance, -- Jasper Bryant-Greene Managing Director Seektrack (NZ) Limited +64 21 129 9458 From smb at cs.columbia.edu Sat Dec 13 06:39:47 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Sat, 13 Dec 2008 07:39:47 -0500 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <70D072392E56884193E3D2DE09C097A9FB2E@pascal.zaphodb.org> References: <20081212034449.5558EC3C11@smtp.ecentral.com> <4942BDB1.80608@antel.net.uy> <4942C33F.8010201@airwire.ie> <2831F941-EAB4-4BC2-BC04-D213994B0356@hopcount.ca> <060F3B30-0EE6-439A-8098-66499BE6FD78@delong.com> <70D072392E56884193E3D2DE09C097A9FB2E@pascal.zaphodb.org> Message-ID: <20081213073947.084b6175@cs.columbia.edu> On Fri, 12 Dec 2008 16:33:51 -0800 "Tomas L. Byrnes" wrote: > Because anyone with half a brain blocks proxies from their e-commerce > site. > What is a proxy? A garden-variety squid server, in the DMZ of a corporate firewall? The nasty box in some hotels that "helps" guests surf the net? A socks proxy installed by the RBN on unsuspecting desktops? I *always* use a squid proxy server; if nothing else, it protects me when I'm using a wireless network. I've never had a problem (though now that Google thinks that Randy's machines are in Japan, I'm expecting some trouble...) --Steve Bellovin, http://www.cs.columbia.edu/~smb From andy at nosignal.org Sat Dec 13 07:40:05 2008 From: andy at nosignal.org (Andy Davidson) Date: Sat, 13 Dec 2008 13:40:05 +0000 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: <20081213073947.084b6175@cs.columbia.edu> References: <20081212034449.5558EC3C11@smtp.ecentral.com> <4942BDB1.80608@antel.net.uy> <4942C33F.8010201@airwire.ie> <2831F941-EAB4-4BC2-BC04-D213994B0356@hopcount.ca> <060F3B30-0EE6-439A-8098-66499BE6FD78@delong.com> <70D072392E56884193E3D2DE09C097A9FB2E@pascal.zaphodb.org> <20081213073947.084b6175@cs.columbia.edu> Message-ID: <37090427-EAE5-401F-BA06-C94FAE9579F6@nosignal.org> On 13 Dec 2008, at 12:39, Steven M. Bellovin wrote: > On Fri, 12 Dec 2008 16:33:51 -0800 "Tomas L. Byrnes" > wrote: >> Because anyone with half a brain blocks proxies from their e- >> commerce site. > What is a proxy? A garden-variety squid server, in the DMZ of a > corporate firewall? The nasty box in some hotels that "helps" > guests surf the net? A socks proxy installed by the RBN on > unsuspecting desktops? Hi, We've all jumped on Tomas, but I suspect that the word 'open' was missing from his summary. I've worked in e-commerce environments where we deployed tools that checked whether orders with high risk scores appeared to come through an open proxy, and unusual browsing patterns were detected and investigated for the same. I wont give the game away, since some of the people on this list will be able to work out who I am talking about :-) but open proxies are a source of fraudulent orders, and also competitors spidering e-commerce sites for price and availability information. Making it harder for both was an important job - both groups of troublemakers would look for a softer target elsewhere. Andy From jeffrey.lyon at blacklotus.net Sat Dec 13 08:56:05 2008 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 13 Dec 2008 09:56:05 -0500 Subject: DDOS - How much is "too much"? In-Reply-To: <16720fe00812130655i11df40aco7394a6692f750467@mail.gmail.com> References: <200812120457.mBC4vqwv095875@vjofn.tucs-beachin-obx-house.com> <16720fe00812130655i11df40aco7394a6692f750467@mail.gmail.com> Message-ID: <16720fe00812130656u74edaa8ep523cd1474c7807f7@mail.gmail.com> DDoS protection packages are generally sold with Mbps, PPS, and often TCP-SYN / UDP session limits. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. > > On Thu, Dec 11, 2008 at 11:57 PM, Tuc at T-B-O-H wrote: >> Hi, >> >> I have a client who prior to me settled into a non-carrier-neutral >> facility. They were approached this week for "DoS/DDoS protection" which >> they could buy in X Mb/s, 2xX Mb/s or 4xX Mb/s scrubbing solutions. >> >> Maybe I've been out of the running my larger Managed Server >> Hosting Company too long, but wasn't the "non-elegant" solutions >> something ISPs just "did"? Was it only DoS, and when it comes to >> DDoS they tell you its just too much to handle. And blocking how many >> netblocks does an ISP consider "too many" before it tells the client >> there is only so much it can do for them? Do people tell/give clients >> their own solutions? (Like Zebra boxes that'll inject BGP into their >> site) >> >> They wanted me to come up with 3 reasons FOR the service, >> 3 against, and what I felt was a fair market value for this. I just need >> to know if people still did that type of stuff for each other or if >> everything costs nowadays.... >> >> Thanks, Tuc/TBOH >> >> > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From ianh at chime.net.au Sat Dec 13 21:02:20 2008 From: ianh at chime.net.au (Ian Henderson) Date: Sun, 14 Dec 2008 12:02:20 +0900 Subject: UDP DoS mitigation? In-Reply-To: <49833.69.30.17.85.1229114856.squirrel@www.woofpaws.com> References: <57995.69.30.17.85.1229105716.squirrel@www.woofpaws.com> <49833.69.30.17.85.1229114856.squirrel@www.woofpaws.com> Message-ID: <100362309621454DAA534950B17E55DB0111FC1992EB@isp-per-exc01.win2k.iinet.net.au> Rick Ernst wrote on 2008-12-13: > - This instance was a DoS, not DDoS. Single source and destination, > but > the source (assuming no spoofing) was in Italy. Turning off netflow > seemed to help, but the attack itself stopped at about the same time. Before moving to hardware based platforms, we used a lot of G1s on sticks. One of the advantages of this is the ability to filter DOS traffic on the switch in front of the router - anything 2950 or higher (with L3 snooping capabilities) can do this with an access list. Router1 Gi0/1 ----- Gi0/1 Switch1 Gi0/2 ----- Upstream On Switch1 configure something like: access-list 100 deny ip host x.x.x.x access-list 100 permit ip any any interface GigabitEthernet0/2 ip access-group 100 in So if your topology allows for it, this is a great short term fix. Note that this means you lose high speed convergence due to immediate link state notifications, and should use aggressive timers to compensate. -- Ian Henderson, CCIE #14721 Senior Network Engineer, iiNet Limited From fw at deneb.enyo.de Sun Dec 14 06:52:17 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 14 Dec 2008 13:52:17 +0100 Subject: UDP DoS mitigation? In-Reply-To: <57995.69.30.17.85.1229105716.squirrel@www.woofpaws.com> (Rick Ernst's message of "Fri, 12 Dec 2008 10:15:16 -0800 (PST)") References: <57995.69.30.17.85.1229105716.squirrel@www.woofpaws.com> Message-ID: <878wqirkam.fsf@mid.deneb.enyo.de> * Rick Ernst: > We've had an increasing rate of DoS attacks that spew tens-of-thousands of > small UDP packets to a destination on our network. We are getting roughly > 2x our entire normal pps across all providers through one interface, or > about 4x normal through the individual interface. The Cisco > 7206VXR/NPE-G1 CPU melts (>95% load vs 15% average, 20% normal peak) when > this hits. > > I'm using CEF and ip-route-cache flow on the outside interface. Is the UDP stream a single flow, or does it consist of lots of different flows? From rsk at gsp.org Sun Dec 14 14:08:52 2008 From: rsk at gsp.org (Rich Kulawiec) Date: Sun, 14 Dec 2008 15:08:52 -0500 Subject: Security Intelligence [Was: Re: Netblock reassigned from Chile to US ISP...] In-Reply-To: <49437781.2000005@psg.com> References: <6cd462c00812130029k7b08b8d5rd92c68dc9550a94e@mail.gmail.com> <6cd462c00812130044k1178ba82kd0df6c3e7b2255d5@mail.gmail.com> <49437781.2000005@psg.com> Message-ID: <20081214200852.GB9303@gsp.org> On Sat, Dec 13, 2008 at 05:51:13PM +0900, Randy Bush wrote: > but you need to be much more specific about what you want from > medium and smaller isps, and what the immediate payoffs (cf. the > financial secions of the newpaper) will be to them to justify the costs. Inferior people look solely for financial payoff. Superior people recognize their fundamental obligation to prevent their operation from being a menace to others, and do it based on ethics. ---Rsk From leothelion.murtaza at gmail.com Sun Dec 14 14:13:28 2008 From: leothelion.murtaza at gmail.com (Murtaza) Date: Mon, 15 Dec 2008 01:13:28 +0500 Subject: Security Intelligence [Was: Re: Netblock reassigned from Chile to US ISP...] In-Reply-To: <20081214200852.GB9303@gsp.org> References: <6cd462c00812130029k7b08b8d5rd92c68dc9550a94e@mail.gmail.com> <6cd462c00812130044k1178ba82kd0df6c3e7b2255d5@mail.gmail.com> <49437781.2000005@psg.com> <20081214200852.GB9303@gsp.org> Message-ID: <949b74980812141213i860966j2d0182ea696e4a5d@mail.gmail.com> Wow!! thats an eye opener.. On Mon, Dec 15, 2008 at 1:08 AM, Rich Kulawiec wrote: > On Sat, Dec 13, 2008 at 05:51:13PM +0900, Randy Bush wrote: > > but you need to be much more specific about what you want from > > medium and smaller isps, and what the immediate payoffs (cf. the > > financial secions of the newpaper) will be to them to justify the costs. > > Inferior people look solely for financial payoff. Superior people > recognize their fundamental obligation to prevent their operation from > being a menace to others, and do it based on ethics. > > ---Rsk > > -- Ghulam Murtaza Lahore University of Management Sciences From randy at psg.com Sun Dec 14 14:33:31 2008 From: randy at psg.com (Randy Bush) Date: Mon, 15 Dec 2008 05:33:31 +0900 Subject: Security Intelligence [Was: Re: Netblock reassigned from Chile to US ISP...] In-Reply-To: <20081214200852.GB9303@gsp.org> References: <6cd462c00812130029k7b08b8d5rd92c68dc9550a94e@mail.gmail.com> <6cd462c00812130044k1178ba82kd0df6c3e7b2255d5@mail.gmail.com> <49437781.2000005@psg.com> <20081214200852.GB9303@gsp.org> Message-ID: <49456D9B.80700@psg.com> On 08.12.15 05:08, Rich Kulawiec wrote: > On Sat, Dec 13, 2008 at 05:51:13PM +0900, Randy Bush wrote: >> but you need to be much more specific about what you want from >> medium and smaller isps, and what the immediate payoffs (cf. the >> financial secions of the newpaper) will be to them to justify the costs. > Inferior people look solely for financial payoff. Superior people > recognize their fundamental obligation to prevent their operation from > being a menace to others, and do it based on ethics. nice and glib. but we have limited resources, and they're gonna get more limited and less resources. so we allocate them based on how we perceive need and relevance to running the actual network. and we just can't do everything. so when ferg says "i exhort and folk don't jump," perhaps there could be a problem with the exhortation not the lack of ethics on the part of the operators. randy From jfmezei at vaxination.ca Sun Dec 14 14:48:02 2008 From: jfmezei at vaxination.ca (JF Mezei) Date: Sun, 14 Dec 2008 15:48:02 -0500 Subject: Security Intelligence [Was: Re: Netblock reassigned from Chile to US ISP...] In-Reply-To: <20081214200852.GB9303@gsp.org> References: <6cd462c00812130029k7b08b8d5rd92c68dc9550a94e@mail.gmail.com> <6cd462c00812130044k1178ba82kd0df6c3e7b2255d5@mail.gmail.com> <49437781.2000005@psg.com> <20081214200852.GB9303@gsp.org> Message-ID: <49457102.2010602@vaxination.ca> Quick comment on e-commerce. Consider that in many/most cases, the merchant will want to capture the customer's address which is sent along with credit card information for authorization. Once the merchant has received an authorization, he is pretty much garanteed to get pad by the credit card company. So the whole "geolocation" bit is not really necessary because they will want a real address anyways. Where geolocation is used is for media companies. If CBS has negotiated the rights to air a program in the USA, then its web site will be programmed to only allow USA based IPs to view the on-line version of that program. In the UK, BBC gets tax revenus from UK citizens, so only UK IPs are allowed to view the on-line versions of those programs. From chaim.rieger at gmail.com Sun Dec 14 15:19:31 2008 From: chaim.rieger at gmail.com (chaim.rieger at gmail.com) Date: Sun, 14 Dec 2008 21:19:31 +0000 Subject: Sbc contact Message-ID: <683253036-1229289579-cardhu_decombobulator_blackberry.rim.net-1394742045-@bxe325.bisx.prod.on.blackberry> Please contact me offlist. Regarding socal connectivity. Thanx Sent via BlackBerry from T-Mobile From ge at linuxbox.org Sun Dec 14 19:44:30 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sun, 14 Dec 2008 19:44:30 -0600 (CST) Subject: Security Intelligence [Was: Re: Netblock reassigned from Chile to US ISP...] In-Reply-To: <20081214200852.GB9303@gsp.org> References: <6cd462c00812130029k7b08b8d5rd92c68dc9550a94e@mail.gmail.com> <6cd462c00812130044k1178ba82kd0df6c3e7b2255d5@mail.gmail.com> <49437781.2000005@psg.com> <20081214200852.GB9303@gsp.org> Message-ID: On Sun, 14 Dec 2008, Rich Kulawiec wrote: > On Sat, Dec 13, 2008 at 05:51:13PM +0900, Randy Bush wrote: >> but you need to be much more specific about what you want from >> medium and smaller isps, and what the immediate payoffs (cf. the >> financial secions of the newpaper) will be to them to justify the costs. > > Inferior people look solely for financial payoff. Superior people > recognize their fundamental obligation to prevent their operation from > being a menace to others, and do it based on ethics. They don't need t be moral, they need to understand 4 years down the line it will cost them significantly to the point of losing a lot of business. A good example is registrars. They lose quite a bit now. Foresight on security is not something that really works. > ---Rsk > From morrowc.lists at gmail.com Sun Dec 14 20:28:32 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 14 Dec 2008 21:28:32 -0500 Subject: Security Intelligence [Was: Re: Netblock reassigned from Chile to US ISP...] In-Reply-To: References: <6cd462c00812130029k7b08b8d5rd92c68dc9550a94e@mail.gmail.com> <6cd462c00812130044k1178ba82kd0df6c3e7b2255d5@mail.gmail.com> <49437781.2000005@psg.com> <20081214200852.GB9303@gsp.org> Message-ID: <75cb24520812141828od18abf8se0a512345b1ffac9@mail.gmail.com> On Sun, Dec 14, 2008 at 8:44 PM, Gadi Evron wrote: > On Sun, 14 Dec 2008, Rich Kulawiec wrote: >> >> On Sat, Dec 13, 2008 at 05:51:13PM +0900, Randy Bush wrote: >>> >>> but you need to be much more specific about what you want from >>> medium and smaller isps, and what the immediate payoffs (cf. the >>> financial secions of the newpaper) will be to them to justify the costs. >> >> Inferior people look solely for financial payoff. Superior people >> recognize their fundamental obligation to prevent their operation from >> being a menace to others, and do it based on ethics. > > They don't need t be moral, they need to understand 4 years down the line it > will cost them significantly to the point of losing a lot of business. A > good example is registrars. They lose quite a bit now. do they lose 'quite a bit' now? how much is 'quite a bit'? and is that more or less than they take home at the end of the day? I'm curious because near as I can tell there doesn't seem to be really any change in how registrars handle transactions... even domains knowingly bought with stolen credit cards seem to hang around (and change) long after the CC company frauded out the transaction(s)... If there really was a large loss, wouldn't they make changes to process/procedures/activities to limit their exposure? -chris From Ubaidali_Abdul_Razack at 3com.com Sun Dec 14 20:35:06 2008 From: Ubaidali_Abdul_Razack at 3com.com (Ubaidali_Abdul_Razack at 3com.com) Date: Mon, 15 Dec 2008 10:35:06 +0800 Subject: e300 vs mx240 for border router ? In-Reply-To: <1229121425.6160.1938.camel@mike-desktop> Message-ID: Have you tried 3Com's 6040 / MSR-50 routers? Regards Ubaidali Abdul Razack +65.65436404 (Office) +65.65436278 (Fax) Michael J McCafferty 12/13/2008 06:37 AM To nanog cc Subject Re: e300 vs mx240 for border router ? Leslie, Can you summarize any other info you may have learned in the private responses for the benefit of those that are interested ? I am not at all familiar with the Force10s, am buying new border routers now. Thanks, Mike On Fri, 2008-12-12 at 14:27 -0800, Leslie wrote: > Thanks to everyone who wrote back privately -- > > I also didn't know that force10 now has dual-cam linecards which raises > the amount of routes it can handle > > Leslie wrote: > > Hey nanog-izens > > > > So for routers that are touching our transit and (hopefully soon) future > > peering, we're looking at both the force10 e300's and juniper mx240's. > > The e300's are cheap but I have heard some rumors/talk of falling over > > when it has to deal with large numbers of prefixes and routes? The > > mx240's are nice but the cost difference is enormous. Does anyone have > > experience with e300's running into issues with large routing tables? > > Are there any tricks/tips that work around any issues (if they exist?) > > > > Thanks in advance > > > > Leslie > -- ************************************************************ Michael J. McCafferty Principal, Security Engineer M5 Hosting http://www.m5hosting.com You can have your own custom Dedicated Server up and running today ! RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more ************************************************************ CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is being sent by 3Com for the sole use of the intended recipient(s) and may contain confidential, proprietary and/or privileged information. Any unauthorized review, use, disclosure and/or distribution by any recipient is prohibited. If you are not the intended recipient, please delete and/or destroy all copies of this message regardless of form and any included attachments and notify 3Com immediately by contacting the sender via reply e-mail or forwarding to 3Com at postmaster at 3com.com. From bortzmeyer at nic.fr Mon Dec 15 03:38:38 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 15 Dec 2008 10:38:38 +0100 Subject: Netblock reassigned from Chile to US ISP... In-Reply-To: References: <20081212034449.5558EC3C11@smtp.ecentral.com> Message-ID: <20081215093838.GB20278@nic.fr> On Fri, Dec 12, 2008 at 01:13:59PM -0600, Frank Bulk wrote a message of 52 lines which said: > Is there an easy way to get past history on an IP block? Most sites > will show you aspects of that *now*.... http://www.renesys.com/blog/2008/11/for-sale-clean-lightly-used-ip.shtml (That's just an idea, not a real service.) From ge at linuxbox.org Mon Dec 15 07:24:29 2008 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 15 Dec 2008 07:24:29 -0600 (CST) Subject: Security Intelligence [Was: Re: Netblock reassigned from Chile to US ISP...] In-Reply-To: <75cb24520812141828od18abf8se0a512345b1ffac9@mail.gmail.com> References: <6cd462c00812130029k7b08b8d5rd92c68dc9550a94e@mail.gmail.com> <6cd462c00812130044k1178ba82kd0df6c3e7b2255d5@mail.gmail.com> <49437781.2000005@psg.com> <20081214200852.GB9303@gsp.org> <75cb24520812141828od18abf8se0a512345b1ffac9@mail.gmail.com> Message-ID: On Sun, 14 Dec 2008, Christopher Morrow wrote: > On Sun, Dec 14, 2008 at 8:44 PM, Gadi Evron wrote: >> On Sun, 14 Dec 2008, Rich Kulawiec wrote: >>> >>> On Sat, Dec 13, 2008 at 05:51:13PM +0900, Randy Bush wrote: >>>> >>>> but you need to be much more specific about what you want from >>>> medium and smaller isps, and what the immediate payoffs (cf. the >>>> financial secions of the newpaper) will be to them to justify the costs. >>> >>> Inferior people look solely for financial payoff. Superior people >>> recognize their fundamental obligation to prevent their operation from >>> being a menace to others, and do it based on ethics. >> >> They don't need t be moral, they need to understand 4 years down the line it >> will cost them significantly to the point of losing a lot of business. A >> good example is registrars. They lose quite a bit now. > > do they lose 'quite a bit' now? how much is 'quite a bit'? and is that > more or less than they take home at the end of the day? > > I'm curious because near as I can tell there doesn't seem to be really > any change in how registrars handle transactions... even domains > knowingly bought with stolen credit cards seem to hang around (and > change) long after the CC company frauded out the transaction(s)... > > If there really was a large loss, wouldn't they make changes to > process/procedures/activities to limit their exposure? The ones that don't take the "legal risk" now handle fraud quite differently. They are required to handle such purchases with the credit companies, and that costs them (the ones which do as they are required depending on law) on a scale which is .. very disturbing. > -chris > From eugen at imacandi.net Mon Dec 15 10:43:35 2008 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Mon, 15 Dec 2008 18:43:35 +0200 Subject: e300 vs mx240 for border router ? In-Reply-To: References: Message-ID: <49468937.5090709@imacandi.net> Ubaidali_Abdul_Razack at 3com.com wrote: > Have you tried 3Com's 6040 / MSR-50 routers? No offense / no flame, but really, do you actually compare 3Com with Juniper ? From ops.lists at gmail.com Mon Dec 15 10:53:24 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 15 Dec 2008 22:23:24 +0530 Subject: e300 vs mx240 for border router ? In-Reply-To: <49468937.5090709@imacandi.net> References: <49468937.5090709@imacandi.net> Message-ID: On Mon, Dec 15, 2008 at 10:13 PM, Eugeniu Patrascu wrote: > Ubaidali_Abdul_Razack at 3com.com wrote: >> >> Have you tried 3Com's 6040 / MSR-50 routers? > > No offense / no flame, but really, do you actually compare 3Com with Juniper > ? Patriotism :) -- Suresh Ramasubramanian (ops.lists at gmail.com) From vmalitani at gmail.com Mon Dec 15 11:05:52 2008 From: vmalitani at gmail.com (vitto malitani) Date: Mon, 15 Dec 2008 12:05:52 -0500 Subject: Net Mgmt Tools and supporting OS In-Reply-To: <761304.82257.qm@web52512.mail.re2.yahoo.com> References: <761304.82257.qm@web52512.mail.re2.yahoo.com> Message-ID: Thanks to all who replied. Due to ease of deployment I will probably go with the Cent)S based server and tools and modify things as I need it afterwards. Best of luck, Vitto, On Tue, Dec 9, 2008 at 4:00 PM, Claudia de Luna wrote: > Vito, > > I"m currently consulting to the state of California corrections department > on their wan and this question continually comes up. > > My recommendation is to get started with CactiEZ as you SNMP management > tool. CactiEZ is a CentOS based Cacti server that essentially loads > everything you need to get up and running. If you already have an > authoratative and complete list of all your network infrastructure equipment > it is then a simple matter of adding the devices to the server. > Out of the box you get your syslog server (essential) with some basic > search capabilities, your monitoring for bandwidth utilization, errors, > latency (ping based) and router CPU. > > You can grow from there with notification (it's pretty basic but better > than nothing), availability reports, and even a weather map. > > As someone else already said, use the OS you are most comfortable with. > Running monitoring on a network is a full time job in and of itself so don't > complicate things! > > Tools like OpenNMS and Nagios are a little more complex. The CactiEZ CD is > pretty much turnkey and gives you most, if not all, the tools to get you up > and running. From there you can see what needs it does not meet and grow > from there. > > Claudia > > > This link lists the "plug ins" available out of the box but there are > others as Cacti has a very good plug in architecture. > http://cactiusers.org/wiki/Homepage > > Example WeatherMap > > > > ------------------------------ > *From:* vitto malitani > *To:* nanog at nanog.org > *Sent:* Tuesday, December 9, 2008 9:17:40 AM > *Subject:* Net Mgmt Tools and supporting OS > > I am fairly new user of nanog mail list so I am not sure if the question > below is appropriate for this list. If not, please excuse it. > - I am building a new low-budget customer WAN/LAN network and need some > ideas for network management tools. I've seen couple of email threads > regarding all sort of "net goodies". However, since I haven't used them > all, I am not sure which OS would be the most appropriate for these aps? > Can anyone share their ideas in regards of apps and supporting platforms? > I would be most comfortable with free distribution of linux, but I am not > sure which distro supports most of the tools? Is the paid OS required for > all these tools, like RedHat Server or SuSe or Windows platforms? > > Thanks much, > > Vitto > From me at sharloncarty.net Mon Dec 15 13:05:44 2008 From: me at sharloncarty.net (Sharlon R. Carty) Date: Mon, 15 Dec 2008 15:05:44 -0400 Subject: No route to verizon Message-ID: <4FAF11268A404B368385EB3E4E297A5F@stupidcomp> Hello, This is my first post. Can anyone provide some info or Verizon why there is no connectivity to Verizon CA(Verizon Business UUNETCA8-A)? Can not reach the following net range: 66.48.66.160 - 66.48.66.175 --sharlon From martin at airwire.ie Mon Dec 15 13:15:20 2008 From: martin at airwire.ie (Martin List-Petersen) Date: Mon, 15 Dec 2008 19:15:20 +0000 Subject: No route to verizon In-Reply-To: <4FAF11268A404B368385EB3E4E297A5F@stupidcomp> References: <4FAF11268A404B368385EB3E4E297A5F@stupidcomp> Message-ID: <4946ACC8.7020202@airwire.ie> Sharlon R. Carty wrote: > Hello, > > > > This is my first post. > > Can anyone provide some info or Verizon why there is no connectivity to > Verizon CA(Verizon Business UUNETCA8-A)? > Can not reach the following net range: 66.48.66.160 - 66.48.66.175 > 11. ae-4-99.edge2.NewYork2.Level 0.0% 12. mci-level3-xe.newyork2.Level 0.0% 13. 0.xe-5-0-3.XL4.NYC4.ALTER.NE 0.0% 14. ??? 100.0 It gets into Verizons network and as far as New York. Maybe a fault between Verizon and the customer ? After all, Alter.net is Verizon. /Martin -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From r.engehausen at gmail.com Mon Dec 15 13:16:18 2008 From: r.engehausen at gmail.com (Roy) Date: Mon, 15 Dec 2008 11:16:18 -0800 Subject: No route to verizon In-Reply-To: <4FAF11268A404B368385EB3E4E297A5F@stupidcomp> References: <4FAF11268A404B368385EB3E4E297A5F@stupidcomp> Message-ID: <4946AD02.9050406@gmail.com> Sharlon R. Carty wrote: > Hello, > > > > This is my first post. > > Can anyone provide some info or Verizon why there is no connectivity to > Verizon CA(Verizon Business UUNETCA8-A)? > Can not reach the following net range: 66.48.66.160 - 66.48.66.175 > > > > --sharlon > > > That network is assigned to a customer: Tremor Technology Group Inc TREMORUU2 (NET-66-48-66-160-1) 66.48.66.160 - 66.48.66.175 You would have to contact them. Lots of possibilities: line failure, equipment failure, or they didn't pay their bill. From streiner at cluebyfour.org Mon Dec 15 13:20:42 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 15 Dec 2008 14:20:42 -0500 (EST) Subject: No route to verizon In-Reply-To: <4FAF11268A404B368385EB3E4E297A5F@stupidcomp> References: <4FAF11268A404B368385EB3E4E297A5F@stupidcomp> Message-ID: On Mon, 15 Dec 2008, Sharlon R. Carty wrote: > This is my first post. > > Can anyone provide some info or Verizon why there is no connectivity to > Verizon CA(Verizon Business UUNETCA8-A)? > Can not reach the following net range: 66.48.66.160 - 66.48.66.175 Your best bet might be to call Verizon directly, as a range this small is not likely to be seen in the global routing table as a free-standing route. I see 66.48.0.0/16 from my transit providers, originated from AS701, which is what I'd expect to see. Beyond that, your post doesn't contain enough information to do much more troubleshooting. jms From me at sharloncarty.net Mon Dec 15 13:24:22 2008 From: me at sharloncarty.net (Sharlon R. Carty) Date: Mon, 15 Dec 2008 15:24:22 -0400 Subject: No route to verizon In-Reply-To: References: <4FAF11268A404B368385EB3E4E297A5F@stupidcomp> Message-ID: <3FAEFF57159841B89B73F98DAF9F96D6@stupidcomp> Ok thanks everyone. I'll be contacting Verizon. I do not believe the issue lies with the customer not paying their bills. -----Original Message----- From: Justin M. Streiner [mailto:streiner at cluebyfour.org] Sent: Monday, December 15, 2008 3:21 PM To: nanog at nanog.org Subject: Re: No route to verizon On Mon, 15 Dec 2008, Sharlon R. Carty wrote: > This is my first post. > > Can anyone provide some info or Verizon why there is no connectivity to > Verizon CA(Verizon Business UUNETCA8-A)? > Can not reach the following net range: 66.48.66.160 - 66.48.66.175 Your best bet might be to call Verizon directly, as a range this small is not likely to be seen in the global routing table as a free-standing route. I see 66.48.0.0/16 from my transit providers, originated from AS701, which is what I'd expect to see. Beyond that, your post doesn't contain enough information to do much more troubleshooting. jms From black at csulb.edu Mon Dec 15 13:34:00 2008 From: black at csulb.edu (Matthew Black) Date: Mon, 15 Dec 2008 11:34:00 -0800 Subject: No route to verizon In-Reply-To: <4FAF11268A404B368385EB3E4E297A5F@stupidcomp> References: <4FAF11268A404B368385EB3E4E297A5F@stupidcomp> Message-ID: On Mon, 15 Dec 2008 15:05:44 -0400 "Sharlon R. Carty" wrote: > Hello, > > This is my first post. > > Can anyone provide some info or Verizon why there is no connectivity to > Verizon CA(Verizon Business UUNETCA8-A)? > Can not reach the following net range: 66.48.66.160 - 66.48.66.175 My traceroute also ends with ALTER.NET: traceroute to 66.48.66.160 (66.48.66.160), 30 hops max, 40 byte packets ... 7 los-edge-01.inet.qwest.net (63.147.28.181) 1.701 ms 1.870 ms 1.734 ms 8 los-core-01.inet.qwest.net (205.171.32.33) 1.755 ms 1.670 ms 1.823 ms 9 lap-brdr-01.inet.qwest.net (205.171.32.10) 1.722 ms 2.082 ms 2.676 ms 10 0.so-4-3-0.BR1.LAX7.ALTER.NET (204.255.169.193) 2.094 ms 2.046 ms 1.720 ms matthew black e-mail postmaster california state university, long beach From hescominsoon at emmanuelcomputerconsulting.com Mon Dec 15 13:46:35 2008 From: hescominsoon at emmanuelcomputerconsulting.com (William Warren) Date: Mon, 15 Dec 2008 14:46:35 -0500 Subject: No route to verizon In-Reply-To: References: <4FAF11268A404B368385EB3E4E297A5F@stupidcomp> Message-ID: <4946B41B.3070203@emmanuelcomputerconsulting.com> Matthew Black wrote: > On Mon, 15 Dec 2008 15:05:44 -0400 > "Sharlon R. Carty" wrote: >> Hello, >> >> This is my first post. >> Can anyone provide some info or Verizon why there is no connectivity to >> Verizon CA(Verizon Business UUNETCA8-A)? Can not reach the following >> net range: 66.48.66.160 - 66.48.66.175 > > My traceroute also ends with ALTER.NET: > traceroute to 66.48.66.160 (66.48.66.160), 30 hops max, 40 byte packets > ... > 7 los-edge-01.inet.qwest.net (63.147.28.181) 1.701 ms 1.870 ms > 1.734 ms > 8 los-core-01.inet.qwest.net (205.171.32.33) 1.755 ms 1.670 ms > 1.823 ms > 9 lap-brdr-01.inet.qwest.net (205.171.32.10) 1.722 ms 2.082 ms > 2.676 ms > 10 0.so-4-3-0.BR1.LAX7.ALTER.NET (204.255.169.193) 2.094 ms 2.046 > ms 1.720 ms > > > matthew black > e-mail postmaster > california state university, long beach > > whoops meant that to go to the list. I thought i had their website..but i didn't. From r.hyunseog at ieee.org Mon Dec 15 13:55:31 2008 From: r.hyunseog at ieee.org (Alex H. Ryu) Date: Mon, 15 Dec 2008 13:55:31 -0600 Subject: No route to verizon In-Reply-To: <3FAEFF57159841B89B73F98DAF9F96D6@stupidcomp> References: <4FAF11268A404B368385EB3E4E297A5F@stupidcomp> <3FAEFF57159841B89B73F98DAF9F96D6@stupidcomp> Message-ID: <4946B633.7080203@ieee.org> It may be. If the customer is BGP customer, and they have connectivity problem, your traffic will flow into Verizon since Verizon have supernet. But within Verizon network, Verizon router doesn't have specific route info to route into. So you may see time-out as soon as it hit Verizon network. Alex Sharlon R. Carty wrote: > Ok thanks everyone. > I'll be contacting Verizon. > > I do not believe the issue lies with the customer not paying their bills. > > -----Original Message----- > From: Justin M. Streiner [mailto:streiner at cluebyfour.org] > Sent: Monday, December 15, 2008 3:21 PM > To: nanog at nanog.org > Subject: Re: No route to verizon > > On Mon, 15 Dec 2008, Sharlon R. Carty wrote: > > >> This is my first post. >> >> Can anyone provide some info or Verizon why there is no connectivity to >> Verizon CA(Verizon Business UUNETCA8-A)? >> Can not reach the following net range: 66.48.66.160 - 66.48.66.175 >> > > Your best bet might be to call Verizon directly, as a range this small is > not likely to be seen in the global routing table as a free-standing > route. I see 66.48.0.0/16 from my transit providers, originated from > AS701, which is what I'd expect to see. > > Beyond that, your post doesn't contain enough information to do much more > troubleshooting. > > jms > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: r_hyunseog.vcf Type: text/x-vcard Size: 360 bytes Desc: not available URL: From Ventzislav.Tzvetkov at telefonica.de Tue Dec 16 12:49:59 2008 From: Ventzislav.Tzvetkov at telefonica.de (Ventzislav.Tzvetkov at telefonica.de) Date: Tue, 16 Dec 2008 19:49:59 +0100 Subject: =?ISO-8859-1?Q?Ventzislav_Tzvetkov_ist_au=DFer_Haus=2E?= Message-ID: Ich werde ab 16.12.2008 nicht im B?ro sein. Ich kehre zur?ck am 18.12.2008. Ich werde Ihre Nachricht nach meiner R?ckkehr beantworten. From mike-nanog at tiedyenetworks.com Tue Dec 16 15:45:04 2008 From: mike-nanog at tiedyenetworks.com (mike) Date: Tue, 16 Dec 2008 13:45:04 -0800 Subject: postini contact? Message-ID: <49482160.5070305@tiedyenetworks.com> I have a serious problem with postini applying some rules that look like the work of a rouge engineer in their ranks, and I need an internal contact to discuss the problem with. thanks. From jabley at hopcount.ca Tue Dec 16 15:53:30 2008 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 16 Dec 2008 16:53:30 -0500 Subject: postini contact? In-Reply-To: <49482160.5070305@tiedyenetworks.com> References: <49482160.5070305@tiedyenetworks.com> Message-ID: <23B08A91-565C-4BC4-8613-A544CE907458@hopcount.ca> On 2008-12-16, at 16:45, mike wrote: > I have a serious problem with postini applying some rules that look > like the work of a rouge engineer in their ranks, and I need an > internal contact to discuss the problem with. What is it with those rouge engineers, anyway? People need to pay more attention during the hiring process, and give greater priority to the verts and bleus. Joe From Valdis.Kletnieks at vt.edu Tue Dec 16 15:55:33 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 16 Dec 2008 16:55:33 -0500 Subject: postini contact? In-Reply-To: Your message of "Tue, 16 Dec 2008 13:45:04 PST." <49482160.5070305@tiedyenetworks.com> References: <49482160.5070305@tiedyenetworks.com> Message-ID: <113489.1229464533@turing-police.cc.vt.edu> On Tue, 16 Dec 2008 13:45:04 PST, mike said: > I have a serious problem with postini applying some rules that look like > the work of a rouge engineer in their ranks, and I need an internal > contact to discuss the problem with. It actually qualifies as "rogue" rather than merely "chucklehead"? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From williamsjj at digitar.com Tue Dec 16 15:57:20 2008 From: williamsjj at digitar.com (Jason Williams) Date: Tue, 16 Dec 2008 14:57:20 -0700 Subject: postini contact? In-Reply-To: <49482160.5070305@tiedyenetworks.com> References: <49482160.5070305@tiedyenetworks.com> Message-ID: <16A7AA43-4C9D-4A53-ACDE-4B9BB8E99677@digitar.com> Hi Mike, Our experience with Postini is they don't do NOC-2-NOC. Normally, we work with their customer support folks: 800.566.3180 If you let them know you're a service/network provider trying to facilitate communications with their customers they usually are pretty helpful. -J On Dec 16, 2008, at 2:45 PM, mike wrote: > > I have a serious problem with postini applying some rules that look > like the work of a rouge engineer in their ranks, and I need an > internal contact to discuss the problem with. > > thanks. > > !SIG:494821bf318931653378747! > From karnaugh at karnaugh.za.net Tue Dec 16 16:22:07 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Wed, 17 Dec 2008 00:22:07 +0200 Subject: postini contact? In-Reply-To: <23B08A91-565C-4BC4-8613-A544CE907458@hopcount.ca> References: <49482160.5070305@tiedyenetworks.com> <23B08A91-565C-4BC4-8613-A544CE907458@hopcount.ca> Message-ID: <49482A0F.5030909@karnaugh.za.net> On 2008/12/16 11:53 PM Joe Abley wrote: > > On 2008-12-16, at 16:45, mike wrote: > >> I have a serious problem with postini applying some rules that look >> like the work of a rouge engineer in their ranks, and I need an >> internal contact to discuss the problem with. > > What is it with those rouge engineers, anyway? People need to pay more > attention during the hiring process, and give greater priority to the > verts and bleus. Yes, they should have Warlocks or Paladins. From frnkblk at iname.com Tue Dec 16 23:36:27 2008 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 16 Dec 2008 23:36:27 -0600 Subject: postini contact? In-Reply-To: <16A7AA43-4C9D-4A53-ACDE-4B9BB8E99677@digitar.com> References: <49482160.5070305@tiedyenetworks.com> <16A7AA43-4C9D-4A53-ACDE-4B9BB8E99677@digitar.com> Message-ID: I've only had to call them once (turned out to be our problem) but they were reasonably helpful. If I had to compare it to any other freemail provider, I would have to say Postini was fantastic. Frank -----Original Message----- From: Jason Williams [mailto:williamsjj at digitar.com] Sent: Tuesday, December 16, 2008 3:57 PM To: mike Cc: nanog at nanog.org Subject: Re: postini contact? Hi Mike, Our experience with Postini is they don't do NOC-2-NOC. Normally, we work with their customer support folks: 800.566.3180 If you let them know you're a service/network provider trying to facilitate communications with their customers they usually are pretty helpful. -J On Dec 16, 2008, at 2:45 PM, mike wrote: > > I have a serious problem with postini applying some rules that look > like the work of a rouge engineer in their ranks, and I need an > internal contact to discuss the problem with. > > thanks. > > !SIG:494821bf318931653378747! > From kngspook at gmail.com Wed Dec 17 02:53:51 2008 From: kngspook at gmail.com (King Spook) Date: Wed, 17 Dec 2008 00:53:51 -0800 Subject: postini contact? In-Reply-To: References: <49482160.5070305@tiedyenetworks.com> <16A7AA43-4C9D-4A53-ACDE-4B9BB8E99677@digitar.com> Message-ID: <77e4079b0812170053n2a01317cq18806d021b05a91c@mail.gmail.com> On Tue, Dec 16, 2008 at 9:36 PM, Frank Bulk wrote: > I've only had to call them once (turned out to be our problem) but they were > reasonably helpful. If I had to compare it to any other freemail provider, > I would have to say Postini was fantastic. > > Frank [Sorry for the semi-hijack.] I assume you're a big org of some sort? What are they like for little people? (I was toying with setting them up for some management consultants I know who were having a spam problems; but I heard some hearsay that support was poor unless you're a large player, and that made me a little uncomfortable regarding making the recommendation.) From jerome.benoit at grenouille.com Wed Dec 17 03:57:24 2008 From: jerome.benoit at grenouille.com (Jerome Benoit) Date: Wed, 17 Dec 2008 10:57:24 +0100 Subject: e300 vs mx240 for border router ? In-Reply-To: References: <49468937.5090709@imacandi.net> Message-ID: <20081217105724.3d2895b4.jerome.benoit@grenouille.com> Le Mon, 15 Dec 2008 22:23:24 +0530, "Suresh Ramasubramanian" a ?crit : > On Mon, Dec 15, 2008 at 10:13 PM, Eugeniu Patrascu > wrote: > > Ubaidali_Abdul_Razack at 3com.com wrote: > >> > >> Have you tried 3Com's 6040 / MSR-50 routers? > > > > No offense / no flame, but really, do you actually compare 3Com > > with Juniper ? > > Patriotism :) > OpenBGPd on OpenBSD worth a try then :) Cheers. -- J?r?me Benoit aka fraggle La M?t?o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From nanog at daork.net Wed Dec 17 04:59:27 2008 From: nanog at daork.net (Nathan Ward) Date: Wed, 17 Dec 2008 23:59:27 +1300 Subject: e300 vs mx240 for border router ? In-Reply-To: <20081217105724.3d2895b4.jerome.benoit@grenouille.com> References: <49468937.5090709@imacandi.net> <20081217105724.3d2895b4.jerome.benoit@grenouille.com> Message-ID: <77B3D21D-B0DB-4661-8E40-07640321588A@daork.net> On 17/12/2008, at 10:57 PM, Jerome Benoit wrote: > OpenBGPd on OpenBSD worth a try then :) OpenBGPd has a couple of cool things, notably irr-filter. However, it cannot choose best path based on IGP metric to reach the BGP next hop. When you have multiple border routers with multiple routers between them this is really annoying. As OpenBGPd and OpenOSPFd are different daemons and the OS[1] has no concept of metric, it doesn't work so well. Until it can do this, I'm sticking with Quagga for host based routers. Useful for route servers at an IXP though (if your IXP has route- servers) - irr-filter is very useful here. It also did this weird thing where I'd route 2002::/16 at an stf(6to4) interface and OpenBGPd would do a recursive lookup and install the route with a next-hop of my local interface, or something weird like that. Quagga did what I expected so I stuck with it. -- Nathan Ward [1] I only tried with FreeBSD, I'm told OpenBSD is similar. From chris at ghostbusters.co.uk Wed Dec 17 08:02:46 2008 From: chris at ghostbusters.co.uk (Chris) Date: Wed, 17 Dec 2008 14:02:46 +0000 Subject: Gigabit Linux Routers Message-ID: Hi All, Sorry if this is a repeat topic. I've done a fair bit of trawling but can't find anything concrete to base decisions on. I'm hoping someone can offer some advice on suitable hardware and kernel tweaks for using Linux as a router running bgpd via Quagga. We do this at the moment and our box manages under the 100Mbps level very effectively. Over the next year however we expect to push about 250Mbps outbound traffic with very little inbound (50Mbps simultaneously) and I'm seeing differing suggestions of what to do in order to move up to the 1Gbps level. It seems even a dual core box with expensive NICs and some kernel tweaks will accomplish this but we can't afford to get the hardware purchases wrong. We'd be looking to buy one live and one standby box within the next month or so. They will only run Quagga primarily with 'tc' for shaping. We're in the UK if it makes any difference. Any help massively appreciated, ideally from those doing the same in production environments. Thanks, Chris From lists at quux.de Wed Dec 17 08:19:20 2008 From: lists at quux.de (Jens Link) Date: Wed, 17 Dec 2008 15:19:20 +0100 Subject: Gigabit Linux Routers In-Reply-To: (chris@ghostbusters.co.uk's message of "Wed\, 17 Dec 2008 14\:02\:46 +0000") References: Message-ID: <87ljue7ul3.fsf@laphroiag.quux.de> Chris writes: > I'm hoping someone can offer some advice on suitable hardware and kernel > tweaks for using Linux as a router running bgpd via Quagga. There was a talk "Towards 10Gb/s open-source routing" at this years Linux-Kongress in Hamburg. Here are th slides: http://data.guug.de/slides/lk2008/10G_preso_lk2008.pdf cheers Jens -- Berlin, Germany | http://www.quux.de | jabber: jenslink at guug.de sage at guug Berlin: http://www.guug.de/lokal/berlin/index.html From david at davidcoulson.net Wed Dec 17 08:21:23 2008 From: david at davidcoulson.net (David Coulson) Date: Wed, 17 Dec 2008 09:21:23 -0500 Subject: Gigabit Linux Routers In-Reply-To: References: Message-ID: <49490AE3.5080303@davidcoulson.net> I've been pretty happy running IBM x-series hardware using RHEL4. Usually it's PPS rather than throughput that will kill it, so if you're doing 250Mbit of DNS/I-mix/HTTP, you'll probably have very different results. There are some rx-ring tweaks for the NICs that are needed, but on the most part it's all out of the box (No custom kernel patches, and such - Just some sysctl settings). I have two x3650s (Quad core) doing around 6-700Mbit/sec (40k pps) at around 20% CPU right now. No Quagga BGP, but that's minimal in terms of CPU. I've not been able to get much beyond 1Gb/sec on this environment because my ASAs are not configured to support more than one Gig into that particular network. Chris wrote: > Hi All, > Sorry if this is a repeat topic. I've done a fair bit of trawling but can't > find anything concrete to base decisions on. > > I'm hoping someone can offer some advice on suitable hardware and kernel > tweaks for using Linux as a router running bgpd via Quagga. We do this at > the moment and our box manages under the 100Mbps level very effectively. > Over the next year however we expect to push about 250Mbps outbound traffic > with very little inbound (50Mbps simultaneously) and I'm seeing differing > suggestions of what to do in order to move up to the 1Gbps level. > > It seems even a dual core box with expensive NICs and some kernel tweaks > will accomplish this but we can't afford to get the hardware purchases > wrong. We'd be looking to buy one live and one standby box within the next > month or so. They will only run Quagga primarily with 'tc' for shaping. > We're in the UK if it makes any difference. > > Any help massively appreciated, ideally from those doing the same in > production environments. > > Thanks, > > Chris > From darden at armc.org Wed Dec 17 08:29:18 2008 From: darden at armc.org (Darden, Patrick S.) Date: Wed, 17 Dec 2008 09:29:18 -0500 Subject: Gigabit Linux Routers In-Reply-To: Message-ID: I don't think you will have any troubles with industry standard hardware for the rates you are quoting. When you get in excess of 300Mbps you have to start worrying about PPS. When you are looking at >600Mbps then you should pick out your system more carefully (tcpoe nics, pcie(X), cpu at over Xghz, fast ram if you are doing a lot of BGP, tweaking your linux distribution and kernel, etc.). You should be fine with any recent hardware. A cheap HP dl360 would do a great job. --p -----Original Message----- From: Chris [mailto:chris at ghostbusters.co.uk] Sent: Wednesday, December 17, 2008 9:03 AM To: nanog list Subject: Gigabit Linux Routers Hi All, Sorry if this is a repeat topic. I've done a fair bit of trawling but can't find anything concrete to base decisions on. I'm hoping someone can offer some advice on suitable hardware and kernel tweaks for using Linux as a router running bgpd via Quagga. We do this at the moment and our box manages under the 100Mbps level very effectively. Over the next year however we expect to push about 250Mbps outbound traffic with very little inbound (50Mbps simultaneously) and I'm seeing differing suggestions of what to do in order to move up to the 1Gbps level. It seems even a dual core box with expensive NICs and some kernel tweaks will accomplish this but we can't afford to get the hardware purchases wrong. We'd be looking to buy one live and one standby box within the next month or so. They will only run Quagga primarily with 'tc' for shaping. We're in the UK if it makes any difference. Any help massively appreciated, ideally from those doing the same in production environments. Thanks, Chris From ka at pacific.net Wed Dec 17 08:34:51 2008 From: ka at pacific.net (Ken A) Date: Wed, 17 Dec 2008 08:34:51 -0600 Subject: postini contact? In-Reply-To: <77e4079b0812170053n2a01317cq18806d021b05a91c@mail.gmail.com> References: <49482160.5070305@tiedyenetworks.com> <16A7AA43-4C9D-4A53-ACDE-4B9BB8E99677@digitar.com> <77e4079b0812170053n2a01317cq18806d021b05a91c@mail.gmail.com> Message-ID: <49490E0B.2020607@pacific.net> King Spook wrote: > On Tue, Dec 16, 2008 at 9:36 PM, Frank Bulk wrote: >> I've only had to call them once (turned out to be our problem) but they were >> reasonably helpful. If I had to compare it to any other freemail provider, >> I would have to say Postini was fantastic. >> >> Frank > > [Sorry for the semi-hijack.] > > I assume you're a big org of some sort? > What are they like for little people? > > (I was toying with setting them up for some management consultants I > know who were having a spam problems; but I heard some hearsay that > support was poor unless you're a large player, and that made me a > little uncomfortable regarding making the recommendation.) > We are a small ISP. Postini (now owned by Google) asks service providers to do support for their own customers, and service provider may escalate to Postini support if needed. End users don't get Postini support. We use them for spam filtering. They are pretty good at what they do. Our customers' only legitimate complaint with them is that they have a 4000 character limit on the total number of characters in whitelisted addresses, so some customers are forced to whitelist whole domains. We've asked Postini to increase this limit, and they've 'passed it on to the development team', but that has been over 2 years ago and the limit is still there. I realize whitelist matching can be expensive code. Ken -- Ken Anderson http://www.pacific.net/ From eugen at imacandi.net Wed Dec 17 08:43:40 2008 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Wed, 17 Dec 2008 16:43:40 +0200 Subject: Gigabit Linux Routers In-Reply-To: References: Message-ID: <4949101C.1000108@imacandi.net> Chris wrote: > Hi All, > Sorry if this is a repeat topic. I've done a fair bit of trawling but can't > find anything concrete to base decisions on. > > I'm hoping someone can offer some advice on suitable hardware and kernel > tweaks for using Linux as a router running bgpd via Quagga. We do this at > the moment and our box manages under the 100Mbps level very effectively. > Over the next year however we expect to push about 250Mbps outbound traffic > with very little inbound (50Mbps simultaneously) and I'm seeing differing > suggestions of what to do in order to move up to the 1Gbps level. Any recent hardware can do do 1Gbps of routing from one NIC to another without issues. What you would need is PCI-Express cards, each with it's own slot (try avoiding dual/quad port cards for I/O intensive tasks). Quagga with one full view and two feeds of about 5000 prefixes each consumes around 50MB of RAM. Putting alot of RAM in the box will not help you with increasing performance. You can also use a kernel with LC-Trie as route hashing algorithm to improve FIB lookups. > > It seems even a dual core box with expensive NICs and some kernel tweaks > will accomplish this but we can't afford to get the hardware purchases > wrong. We'd be looking to buy one live and one standby box within the next > month or so. They will only run Quagga primarily with 'tc' for shaping. > We're in the UK if it makes any difference. Regarding tc, make sure you use a scalable algorithm like HTB/HSFQ and tweak your rules so that a packet will spend the least amount of time in matching and classifying routines. > > Any help massively appreciated, ideally from those doing the same in > production environments. At 100Mbps FDX full load (routing traffic from one NIC to another) on 2.53 GHz Celeron box with 512Mbps of traffic, the load is between 0.00 and 0.01-0.02 From frnkblk at iname.com Wed Dec 17 08:47:41 2008 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 17 Dec 2008 08:47:41 -0600 Subject: postini contact? In-Reply-To: <77e4079b0812170053n2a01317cq18806d021b05a91c@mail.gmail.com> References: <49482160.5070305@tiedyenetworks.com> <16A7AA43-4C9D-4A53-ACDE-4B9BB8E99677@digitar.com> <77e4079b0812170053n2a01317cq18806d021b05a91c@mail.gmail.com> Message-ID: No, we're a small service provider with a small bank as a customer. The bank was the one that wasn't receiving e-mail from our customers. Since the primary network admin for the bank was out of pocket, after the bank opened the ticket we continued the troubleshooting process. Perhaps I was lucky and landed on a good and friendly support engineer. Frank -----Original Message----- From: King Spook [mailto:kngspook at gmail.com] Sent: Wednesday, December 17, 2008 2:54 AM To: Frank Bulk Cc: Jason Williams; mike; nanog at nanog.org Subject: Re: postini contact? On Tue, Dec 16, 2008 at 9:36 PM, Frank Bulk wrote: > I've only had to call them once (turned out to be our problem) but they were > reasonably helpful. If I had to compare it to any other freemail provider, > I would have to say Postini was fantastic. > > Frank [Sorry for the semi-hijack.] I assume you're a big org of some sort? What are they like for little people? (I was toying with setting them up for some management consultants I know who were having a spam problems; but I heard some hearsay that support was poor unless you're a large player, and that made me a little uncomfortable regarding making the recommendation.) From chris at ghostbusters.co.uk Wed Dec 17 09:11:25 2008 From: chris at ghostbusters.co.uk (Chris) Date: Wed, 17 Dec 2008 15:11:25 +0000 Subject: Gigabit Linux Routers In-Reply-To: References: Message-ID: You've given me lots to think about ! Thanks for all the input so far. A few queries for the replies if I may. My brain is whirring. Chris: You're right and I'm tempted. I've almost had my arm twisted to go down the proprietory route as I have some Cisco experience but have become pretty familiar with Quagga and tc. David: May I ask which NICs you use in the IBM boxes ? I see the Intels recommended by Mike have dual ports on one board (the docs say "Two complete Gigabit Ethernet connections in a single device ? Lower latency due to one electrical load on the bus"). Patrick: That's what I was hoping to hear :) It's not the world's biggest network. Michael: Thanks very much. We have three upstreams. I guess 2GB of RAM would cover many more sessions. Eugeniu: That's very useful. The Intel dual port NICs mentioned aren't any good then I presume (please see my comment to David). Thanks again, Chris From ren.provo at gmail.com Wed Dec 17 09:13:37 2008 From: ren.provo at gmail.com (Ren Provo) Date: Wed, 17 Dec 2008 10:13:37 -0500 Subject: NANOG 45: Register Now, Hotel Link Available In-Reply-To: <1946454.32771228443379887.JavaMail.root@mail.corp.dyndns.com> References: <1326848.19931228325785070.JavaMail.root@mail.corp.dyndns.com> <1946454.32771228443379887.JavaMail.root@mail.corp.dyndns.com> Message-ID: <787581440812170713k690f6f7v3a0ae455fb78ddd8@mail.gmail.com> Hi folks, As a reminder Peter Cohen is running the new and improved Peering BOF survey during NANOG45. If you wouldn't mind answering questions posted at http://tinyurl.com/bofsurvey after you register we would all appreciate it. Thanks! -Ren Provo On Thu, Dec 4, 2008 at 9:16 PM, Tom Daly wrote: > Folks, > NANOG 45 in the Dominican Republic is fast approaching, so now is the time > to go get registered for the conference. > > You can register for NANOG 45 at: > > https://nanog.merit.edu/registration/ > > I'm also pleased to report that our hotel has provided us with with a > direct link for online reservations. You can make your reservations online > at: > > http://cwp.marriott.com/sdqgw/nanog/ > > Be aware: the hotel is offering very nice rooms at a great rate (part of > what should make your travel justification easier), so be sure to register > soon. > > Also, consider booking travel soon. A number of airlines have > substantially discounted flights at the moment, but one never knows when > they might expire. > > Looking forward to seeing you all in SDQ, > > Tom Daly, > for the NANOG Program Committee > > -- > Tom Daly > tom at dyndns.com > Dynamic Network Services, Inc. > http://dynamicnetworkservices.com/ > > From david at davidcoulson.net Wed Dec 17 09:14:55 2008 From: david at davidcoulson.net (David Coulson) Date: Wed, 17 Dec 2008 10:14:55 -0500 Subject: Gigabit Linux Routers In-Reply-To: References: Message-ID: <4949176F.50204@davidcoulson.net> The boxes (3650s) came with Broadcom BCM5708 on-board, but I push most of my traffic over these: 1c:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter Flags: bus master, fast devsel, latency 0, IRQ 58 Memory at c7ea0000 (32-bit, non-prefetchable) [size=128K] Memory at c7e80000 (32-bit, non-prefetchable) [size=128K] I/O ports at 6020 [size=32] Capabilities: [c8] Power Management version 2 Capabilities: [d0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable+ Capabilities: [e0] Express Endpoint IRQ 0 Capabilities: [100] Advanced Error Reporting There are four Intel ports in the boxes, so traffic may or may not stay on the same PCI-X card depending how things are flowing. Chris wrote: > David: May I ask which NICs you use in the IBM boxes ? I see the Intels > recommended by Mike have dual ports on one board (the docs say "Two complete > Gigabit Ethernet connections in a single device ? Lower latency due to one > electrical load on the bus"). > From fweimer at bfk.de Wed Dec 17 09:23:44 2008 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 17 Dec 2008 16:23:44 +0100 Subject: Gigabit Linux Routers In-Reply-To: <4949101C.1000108@imacandi.net> (Eugeniu Patrascu's message of "Wed, 17 Dec 2008 16:43:40 +0200") References: <4949101C.1000108@imacandi.net> Message-ID: <82oczaq0zj.fsf@mid.bfk.de> * Eugeniu Patrascu: > You can also use a kernel with LC-Trie as route hashing algorithm to > improve FIB lookups. Do you know if it's possible to switch of the route cache? Based on my past experience, it was a major source of routing performance dependency on traffic patterns (it's basically flow-based forwarding). Anyway, with very few flows, we get quite decent performance (several hundred megabits five-minute peak, and we haven't bothered tuning yet), running on mid-range single-socket server boards and Intel NICs (PCI-X, this is all 2006 hardware). We use a router-on-a-stick configuration with VLAN separation between all hosts to get a decent number of ports. My concern with PC routing (in the WAN area) is a lack of WAN NICs with properly maintained kernel drivers. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From nanog at shankland.org Wed Dec 17 10:30:05 2008 From: nanog at shankland.org (Jim Shankland) Date: Wed, 17 Dec 2008 08:30:05 -0800 Subject: Gigabit Linux Routers In-Reply-To: References: Message-ID: <4949290D.4060606@shankland.org> Chris wrote: > Hi All, > Sorry if this is a repeat topic. I've done a fair bit of trawling but can't > find anything concrete to base decisions on. > > I'm hoping someone can offer some advice on suitable hardware and kernel > tweaks for using Linux as a router running bgpd via Quagga. We do this at > the moment and our box manages under the 100Mbps level very effectively. > Over the next year however we expect to push about 250Mbps outbound traffic > with very little inbound (50Mbps simultaneously) and I'm seeing differing > suggestions of what to do in order to move up to the 1Gbps level. As somebody else said, it's more pps than bits you need to worry about. The Intel NICs can do a full gigabit without any difficulty, if packet size is large enough. But they buckle somewhere around 300Kpps. 300K 100-byte packets is only 240 Mb/s. On the other hand, you mentioned your traffic is mostly outbound, which makes me think you might be a content provider. In that case, you'll know what your average packet size is -- and it should be a lot bigger than 100 bytes. For that type of traffic, using a Linux router up to, say, 1.5-2 Gb/s is pretty trivial. You can do more than that, too, but have to start getting a lot more careful about hardware selection, tuning, etc. The other issue is the number of concurrent flows. The actual route table size is unimportant -- it's the size of the route cache that matters. Unfortunately, I have no figures here. But I did once convert a router from limited routes (quagga, 10K routes) to full routes (I think about 200K routes at the time), with absolutely no measurable impact. There were only a few thousand concurrent flows, and that number did not change -- and that's the one that might have made a difference. I hope this is helpful. Jim From alex at blastro.com Wed Dec 17 10:33:15 2008 From: alex at blastro.com (Alex Thurlow) Date: Wed, 17 Dec 2008 10:33:15 -0600 Subject: Gigabit Linux Routers In-Reply-To: References: Message-ID: <494929CB.70802@blastro.com> Just as another source of info here, I'm running: Dual Core Intel Xeon 3060 @ 2.4Ghz 2 Gb Ram (it says "Mem: 2059280k total, 1258500k used, 800780k free, 278004k buffers" right now) 2 of these on the motherboard: Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) (port-channel bonded to my switch) One other card with 2 ports: Ethernet controller: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03) Gentoo Linux with a fairly small kernel with FIB_TRIE enabled. I'm taking in 2 full BGP feeds, a decent amount of iptables rules, and I've hit 1.2 Gbps with no problems. At this point, I just don't have anything behind the router to push more than that. -- Alex Thurlow Blastro Networks http://www.blastro.com http://www.roxwel.com http://www.yallwire.com Chris wrote: > You've given me lots to think about ! Thanks for all the input so far. > > A few queries for the replies if I may. My brain is whirring. > > Chris: You're right and I'm tempted. I've almost had my arm twisted to go > down the proprietory route as I have some Cisco experience but have become > pretty familiar with Quagga and tc. > > David: May I ask which NICs you use in the IBM boxes ? I see the Intels > recommended by Mike have dual ports on one board (the docs say "Two complete > Gigabit Ethernet connections in a single device ? Lower latency due to one > electrical load on the bus"). > > Patrick: That's what I was hoping to hear :) It's not the world's biggest > network. > > Michael: Thanks very much. We have three upstreams. I guess 2GB of RAM would > cover many more sessions. > > Eugeniu: That's very useful. The Intel dual port NICs mentioned aren't any > good then I presume (please see my comment to David). > > Thanks again, > > Chris > > From alex at blastro.com Wed Dec 17 10:33:24 2008 From: alex at blastro.com (Alex Thurlow) Date: Wed, 17 Dec 2008 10:33:24 -0600 Subject: Gigabit Linux Routers In-Reply-To: <82oczaq0zj.fsf@mid.bfk.de> References: <4949101C.1000108@imacandi.net> <82oczaq0zj.fsf@mid.bfk.de> Message-ID: <494929D4.9090909@blastro.com> Florian Weimer wrote: > * Eugeniu Patrascu: > > > My concern with PC routing (in the WAN area) is a lack of WAN NICs > with properly maintained kernel drivers. > Depending on your WAN interface, there's actually a decent amount of stuff out there. The cheaper alternative to me has actually always been to get some old cisco hardware with the proper interfaces and use it for media conversion. I have a 6500 with Sup1As in it. It can't take BGP feeds with the amount of memory it has, but with the right cards, it will give my router Ethernet and push a few million pps with no problem. Sounds like he's getting Ethernet from his provider though, so this probably isn't an issue. -- Alex Thurlow Blastro Networks http://www.blastro.com http://www.roxwel.com http://www.yallwire.com From eugen at imacandi.net Wed Dec 17 10:43:00 2008 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Wed, 17 Dec 2008 18:43:00 +0200 Subject: Gigabit Linux Routers In-Reply-To: <82oczaq0zj.fsf@mid.bfk.de> References: <4949101C.1000108@imacandi.net> <82oczaq0zj.fsf@mid.bfk.de> Message-ID: <49492C14.2010000@imacandi.net> Florian Weimer wrote: > * Eugeniu Patrascu: > >> You can also use a kernel with LC-Trie as route hashing algorithm to >> improve FIB lookups. > > Do you know if it's possible to switch of the route cache? Based on > my past experience, it was a major source of routing performance > dependency on traffic patterns (it's basically flow-based forwarding). I don't understand your question. In kernel, when you compile it, you have two options: - hash based route algorithm - lc-trie based route algorithm From what I've read on the internet about the latter algorithm, it's supposed to be faster regarding route lookups with large routing tables (like a global routing table). > > Anyway, with very few flows, we get quite decent performance (several > hundred megabits five-minute peak, and we haven't bothered tuning > yet), running on mid-range single-socket server boards and Intel NICs > (PCI-X, this is all 2006 hardware). We use a router-on-a-stick > configuration with VLAN separation between all hosts to get a decent > number of ports. In that configuration you'll split available bandwidth on the NIC and also have less throughput because server NICs are not optimized for "same interface switching". > > My concern with PC routing (in the WAN area) is a lack of WAN NICs > with properly maintained kernel drivers. > Usually it's better to get a dedicated router for that kind of stuff than bother with PC WAN cards. From chris at ghostbusters.co.uk Wed Dec 17 11:17:40 2008 From: chris at ghostbusters.co.uk (Chris) Date: Wed, 17 Dec 2008 17:17:40 +0000 Subject: Gigabit Linux Routers In-Reply-To: <4949290D.4060606@shankland.org> References: <4949290D.4060606@shankland.org> Message-ID: All the responses have been really helpful. Thanks to everyone for being friendly and for taking the time to answer in detail. I've asked a hardware provider to quote for a couple of x86 boxes and I'll look for suitable Intel NICs too. Jim: We're a very small ISP and have a full mix of packet sizes on the network but the vast majority is outbound on port 80 so hopefully that'll help. Any more input will of course be considered. I may post the NIC models for approval if I'm scratching my head again :) Thanks, Chris 2008/12/17 Jim Shankland > Chris wrote: > >> Hi All, >> Sorry if this is a repeat topic. I've done a fair bit of trawling but >> can't >> find anything concrete to base decisions on. >> >> I'm hoping someone can offer some advice on suitable hardware and kernel >> tweaks for using Linux as a router running bgpd via Quagga. We do this at >> the moment and our box manages under the 100Mbps level very effectively. >> Over the next year however we expect to push about 250Mbps outbound >> traffic >> with very little inbound (50Mbps simultaneously) and I'm seeing differing >> suggestions of what to do in order to move up to the 1Gbps level. >> > > As somebody else said, it's more pps than bits you need to worry about. > The Intel NICs can do a full gigabit without any difficulty, if packet > size is large enough. But they buckle somewhere around 300Kpps. 300K > 100-byte packets is only 240 Mb/s. On the other hand, you mentioned > your traffic is mostly outbound, which makes me think you might be a > content provider. In that case, you'll know what your average packet > size is -- and it should be a lot bigger than 100 bytes. For that type > of traffic, using a Linux router up to, say, 1.5-2 Gb/s is pretty trivial. > You can do more than that, too, but have to start getting a lot more > careful > about hardware selection, tuning, etc. > > The other issue is the number of concurrent flows. The actual route > table size is unimportant -- it's the size of the route cache that > matters. Unfortunately, I have no figures here. But I did once > convert a router from limited routes (quagga, 10K routes) to full routes > (I think about 200K routes at the time), with absolutely no measurable > impact. There were only a few thousand concurrent flows, and that > number did not change -- and that's the one that might have made a > difference. > > I hope this is helpful. > > Jim > From adrian at creative.net.au Wed Dec 17 11:23:37 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 18 Dec 2008 02:23:37 +0900 Subject: Gigabit Linux Routers In-Reply-To: References: <4949290D.4060606@shankland.org> Message-ID: <20081217172337.GE25453@skywalker.creative.net.au> On Wed, Dec 17, 2008, Chris wrote: > All the responses have been really helpful. Thanks to everyone for being > friendly and for taking the time to answer in detail. > I've asked a hardware provider to quote for a couple of x86 boxes and I'll > look for suitable Intel NICs too. > > Jim: We're a very small ISP and have a full mix of packet sizes on the > network but the vast majority is outbound on port 80 so hopefully that'll > help. > > Any more input will of course be considered. I may post the NIC models for > approval if I'm scratching my head again :) Just FYI, the more recent Intel hardware has multiple hardware TX/RX queues, implemented via seperate (IIRC) PCIe channels, and Linux/FreeBSD is growing support to handle these multiple queues via multiple kernel threads. Ie, multiple CPUs handling packet forwarding. The trick is whether they can pull it off in a way that scales the FIB and RIB lookups and updates across 4 core (and more) boxes. But 40kpps is absolutely doable on one CPU. Some of the FreeBSD guys working on it are looking at supporting 1mil pps + on 10GE cards (in the public source tree), so .. :) Adrian From eugen at imacandi.net Wed Dec 17 11:33:38 2008 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Wed, 17 Dec 2008 19:33:38 +0200 Subject: Gigabit Linux Routers In-Reply-To: References: Message-ID: <494937F2.2010608@imacandi.net> Chris wrote: > > Eugeniu: That's very useful. The Intel dual port NICs mentioned aren't any > good then I presume (please see my comment to David). Actually it depends on the motherboard chipset. Some chipsets allocate an interrupt per slot, and when you have lot's a traffic between two ports on a dual port card the will increase dramatically, but should get you at 1Gbps, at higer speeds... depends. It's adviseable to use a 2.6 kernel as the network stack, compared to 2.4, is way better and you can achieve higher speeds. From MRunkel at untangle.com Wed Dec 17 11:37:11 2008 From: MRunkel at untangle.com (Marc Runkel) Date: Wed, 17 Dec 2008 09:37:11 -0800 Subject: Advice requested for OpenBSD vs. Linux/OpenBGP vs. Quagga router deployment. In-Reply-To: Message-ID: Greetings all, We are a software development firm that currently delivers our install ISOs via Sourceforge. We need to start serving them ourselves for marketing reasons and are therefore increasing our bandwidth and getting a 2nd ISP in our datacenter. Both ISPs will be delivering 100mbit/sec links. We don't expect to increase that for the next year or so and expect average traffic to be about 40-60mbit/sec. We are planning to run two OpenBSD based firewalls (with CARP and pf) running OpenBGP in order to connect to the two ISPs. I saw from previous email that Quagga was recommended as opposed to OpenBGP. Any further comments on that? Also, any comments on the choice of OpenBSD vs. Linux? I don't want to start a religious war :-) Just curious about what most folks are doing and what their experiences have been. Thanks in advance, Marc Runkel Technical Operations Manager Untangle, Inc. From adrian at creative.net.au Wed Dec 17 11:41:26 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 18 Dec 2008 02:41:26 +0900 Subject: Advice requested for OpenBSD vs. Linux/OpenBGP vs. Quagga router deployment. In-Reply-To: References: Message-ID: <20081217174126.GF25453@skywalker.creative.net.au> OpenBSD SMP support is quite limited. NetBSD SMP is quite limited. FreeBSD and Linux seem to be running better. :) Adrian On Wed, Dec 17, 2008, Marc Runkel wrote: > Greetings all, > > We are a software development firm that currently delivers our install ISOs via Sourceforge. We need to start serving them ourselves for marketing reasons and are therefore increasing our bandwidth and getting a 2nd ISP in our datacenter. Both ISPs will be delivering 100mbit/sec links. We don't expect to increase that for the next year or so and expect average traffic to be about 40-60mbit/sec. > > We are planning to run two OpenBSD based firewalls (with CARP and pf) running OpenBGP in order to connect to the two ISPs. > > I saw from previous email that Quagga was recommended as opposed to OpenBGP. Any further comments on that? Also, any comments on the choice of OpenBSD vs. Linux? > > I don't want to start a religious war :-) Just curious about what most folks are doing and what their experiences have been. > > Thanks in advance, > > Marc Runkel > Technical Operations Manager > Untangle, Inc. -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA - From darkuncle at gmail.com Wed Dec 17 11:53:20 2008 From: darkuncle at gmail.com (Scott Francis) Date: Wed, 17 Dec 2008 09:53:20 -0800 Subject: Advice requested for OpenBSD vs. Linux/OpenBGP vs. Quagga router deployment. In-Reply-To: References: Message-ID: <171423de0812170953s7922ee6at2581316d3a67e5ab@mail.gmail.com> On Wed, Dec 17, 2008 at 9:37 AM, Marc Runkel wrote: [snip] > Greetings all, > > We are a software development firm that currently delivers our install ISOs via Sourceforge. > We need to start serving them ourselves for marketing reasons and are therefore increasing > our bandwidth and getting a 2nd ISP in our datacenter. Both ISPs will be delivering > 100mbit/sec links. We don't expect to increase that for the next year or so and expect > average traffic to be about 40-60mbit/sec. > > We are planning to run two OpenBSD based firewalls (with CARP and pf) running OpenBGP > in order to connect to the two ISPs. > > I saw from previous email that Quagga was recommended as opposed to OpenBGP. Any > further comments on that? Also, any comments on the choice of OpenBSD vs. Linux? IMO, the performance and utility of OpenBSD as a routing/networking platform is unmatched by any other open source platform. OpenBGPD (recent 4-byte ASN issues notwithstanding) has been very stable for us in production (running roughly equivalent traffic levels to what you're discussing), and the best part is that you get stateful transparent failover with CARP, filtering/redirection with pf, load balancing all the way up through layer7 with relayd, and a host of other excellent tools for the network engineer's toolkit, all included, and all integrated. Then of course there's the wider issues of OpenBSD's track record on security and networking in comparison with the other OSS platforms, the smaller pool of folks to draw on who are experienced in running and tuning OpenBSD (although any reasonably competent UNIX admin should be able to adapt to it in a few days, given the generally clean layout and high degree of internal consistency). advocacy at openbsd.org is down the hall, so I'll stop there. :) As Adrian said, there are other platforms with better SMP implementations ... but my experience has been that for small and mid-size sites, CPU utilization on a reasonably modern x86-based router is the least of one's worries. -- darkuncle@{gmail.com,darkuncle.net} || 0x5537F527 http://darkuncle.net/pubkey.asc for public key From darkuncle at gmail.com Wed Dec 17 11:58:09 2008 From: darkuncle at gmail.com (Scott Francis) Date: Wed, 17 Dec 2008 09:58:09 -0800 Subject: Gigabit Linux Routers In-Reply-To: <4949290D.4060606@shankland.org> References: <4949290D.4060606@shankland.org> Message-ID: <171423de0812170958i33341f9bs15061b48aab9cbd9@mail.gmail.com> the recent facebook engineering post on scaling memcached to 200-300K UDP requests/sec/node may be germaine here (in particular, patches to make irq handling more intelligent become very useful at the traffic levels being discussed). http://www.facebook.com/note.php?note_id=39391378919&id=9445547199&index=0 /sf On Wed, Dec 17, 2008 at 8:30 AM, Jim Shankland wrote: > Chris wrote: >> >> Hi All, >> Sorry if this is a repeat topic. I've done a fair bit of trawling but >> can't >> find anything concrete to base decisions on. >> >> I'm hoping someone can offer some advice on suitable hardware and kernel >> tweaks for using Linux as a router running bgpd via Quagga. We do this at >> the moment and our box manages under the 100Mbps level very effectively. >> Over the next year however we expect to push about 250Mbps outbound >> traffic >> with very little inbound (50Mbps simultaneously) and I'm seeing differing >> suggestions of what to do in order to move up to the 1Gbps level. > > As somebody else said, it's more pps than bits you need to worry about. > The Intel NICs can do a full gigabit without any difficulty, if packet > size is large enough. But they buckle somewhere around 300Kpps. 300K > 100-byte packets is only 240 Mb/s. On the other hand, you mentioned > your traffic is mostly outbound, which makes me think you might be a > content provider. In that case, you'll know what your average packet > size is -- and it should be a lot bigger than 100 bytes. For that type > of traffic, using a Linux router up to, say, 1.5-2 Gb/s is pretty trivial. > You can do more than that, too, but have to start getting a lot more careful > about hardware selection, tuning, etc. > > The other issue is the number of concurrent flows. The actual route > table size is unimportant -- it's the size of the route cache that > matters. Unfortunately, I have no figures here. But I did once > convert a router from limited routes (quagga, 10K routes) to full routes > (I think about 200K routes at the time), with absolutely no measurable > impact. There were only a few thousand concurrent flows, and that > number did not change -- and that's the one that might have made a > difference. > > I hope this is helpful. > > Jim > > -- darkuncle@{gmail.com,darkuncle.net} || 0x5537F527 http://darkuncle.net/pubkey.asc for public key From Stefan.Fouant at neustar.biz Wed Dec 17 12:32:34 2008 From: Stefan.Fouant at neustar.biz (Fouant, Stefan) Date: Wed, 17 Dec 2008 13:32:34 -0500 Subject: Global Crossing SOC Message-ID: Folks, Any Global Crossing SOC folks here? We've had a simple DoS attack targeting one of our nodes connected to Global Crossing but have literally spent 3 hours on the phone with Global Crossing support attempting to get someone with a clue as to how to implement a simple ACL on their edge router to deal with this. If there's anyone here who can assist, please contact me off list. Regards, Stefan Fouant: NeuStar, Inc. Principal Network Engineer 46000 Center Oak Plaza Sterling, VA 20166 [ T ] +1 571 434 5656 [ M ] +1 202 210 2075 [ E ] stefan.fouant at neustar.biz [ W ] www.neustar.biz From Stefan.Fouant at neustar.biz Wed Dec 17 13:40:34 2008 From: Stefan.Fouant at neustar.biz (Fouant, Stefan) Date: Wed, 17 Dec 2008 14:40:34 -0500 Subject: DDOS - How much is "too much"? In-Reply-To: <200812120457.mBC4vqwv095875@vjofn.tucs-beachin-obx-house.com> References: <200812120457.mBC4vqwv095875@vjofn.tucs-beachin-obx-house.com> Message-ID: > -----Original Message----- > From: Tuc at T-B-O-H [mailto:ml at t-b-o-h.net] > Subject: DDOS - How much is "too much"? > > Maybe I've been out of the running my larger Managed Server > Hosting Company too long, but wasn't the "non-elegant" solutions > something ISPs just "did"? Was it only DoS, and when it comes to > DDoS they tell you its just too much to handle. And blocking how many > netblocks does an ISP consider "too many" before it tells the client > there is only so much it can do for them? Do people tell/give clients In my experience developing DDoS Mitigation and Detection products for Verizon, I believe the typical scenario is that most Service Providers will implement ACLs or rate-limits on their edge and/or implement some form of Real-Time Blackhole routing for small DoS attacks in which the number of sources is fairly small. I'm not sure there is a particular "number" that ISP's would consider "too many" before it suggests moving to a more purpose-built solution, but the general rule of thumb is that if there are a large number of distributed sources and if source-address spoofing is employed, it's much akin to hitting a moving target and the above-mentioned techniques will largely be ineffective. Furthermore, filtering techniques such as this may have the unintended consequence of causing a denial of legitimate service. > 3 against, and what I felt was a fair market value for this. I just > need > to know if people still did that type of stuff for each other or if > everything costs nowadays.... Yep, pretty much everything costs nowadays. With IP being the commodity that it is, Service Providers are continually looking at every angle to monetize the network and the services they offer. Stefan Fouant: NeuStar, Inc. Principal Network Engineer 46000 Center Oak Plaza Sterling, VA 20166 [ T ] +1 571 434 5656 [ M ] +1 202 210 2075 [ E ] stefan.fouant at neustar.biz [ W ] www.neustar.biz From joshpotter at gmail.com Wed Dec 17 13:45:02 2008 From: joshpotter at gmail.com (Josh Potter) Date: Wed, 17 Dec 2008 13:45:02 -0600 Subject: Global Crossing SOC In-Reply-To: References: Message-ID: <4a64e2f70812171145j4c8f6a4dqd7a45ee38a9e56c8@mail.gmail.com> Sounds like you need to talk to the Global Crossing NCC. They're located in Phoenix however I don't have their number. On Wed, Dec 17, 2008 at 12:32 PM, Fouant, Stefan wrote: > Folks, > > > > Any Global Crossing SOC folks here? We've had a simple DoS attack > targeting one of our nodes connected to Global Crossing but have > literally spent 3 hours on the phone with Global Crossing support > attempting to get someone with a clue as to how to implement a simple > ACL on their edge router to deal with this. > > > > If there's anyone here who can assist, please contact me off list. > > > > Regards, > > > > Stefan Fouant: NeuStar, Inc. > Principal Network Engineer > 46000 Center Oak Plaza Sterling, VA 20166 > [ T ] +1 571 434 5656 [ M ] +1 202 210 2075 > > [ E ] stefan.fouant at neustar.biz [ W ] www.neustar.biz > > > > -- Josh Potter From Stefan.Fouant at neustar.biz Wed Dec 17 14:17:03 2008 From: Stefan.Fouant at neustar.biz (Fouant, Stefan) Date: Wed, 17 Dec 2008 15:17:03 -0500 Subject: Global Crossing SOC In-Reply-To: <4a64e2f70812171145j4c8f6a4dqd7a45ee38a9e56c8@mail.gmail.com> References: <4a64e2f70812171145j4c8f6a4dqd7a45ee38a9e56c8@mail.gmail.com> Message-ID: I?m good now, but it would be nice if the people on the front lines at Global Crossing were even aware what a ?Denial of Service? attack was, or that they even have a SOC for incident handling. Once we got redirected into their SOC we were in good hands. Stefan Fouant: NeuStar, Inc. Principal Network Engineer 46000 Center Oak Plaza Sterling, VA 20166 [ T ] +1 571 434 5656 [ M ] +1 202 210 2075 [ E ] stefan.fouant at neustar.biz [ W ] www.neustar.biz From: Josh Potter [mailto:joshpotter at gmail.com] Sent: Wednesday, December 17, 2008 2:45 PM To: Fouant, Stefan Cc: nanog at nanog.org; Brown, Chad Subject: Re: Global Crossing SOC Sounds like you need to talk to the Global Crossing NCC. They're located in Phoenix however I don't have their number. On Wed, Dec 17, 2008 at 12:32 PM, Fouant, Stefan wrote: Folks, Any Global Crossing SOC folks here? We've had a simple DoS attack targeting one of our nodes connected to Global Crossing but have literally spent 3 hours on the phone with Global Crossing support attempting to get someone with a clue as to how to implement a simple ACL on their edge router to deal with this. If there's anyone here who can assist, please contact me off list. Regards, Stefan Fouant: NeuStar, Inc. Principal Network Engineer 46000 Center Oak Plaza Sterling, VA 20166 [ T ] +1 571 434 5656 [ M ] +1 202 210 2075 [ E ] stefan.fouant at neustar.biz [ W ] www.neustar.biz -- Josh Potter From joshpotter at gmail.com Wed Dec 17 14:19:30 2008 From: joshpotter at gmail.com (Josh Potter) Date: Wed, 17 Dec 2008 14:19:30 -0600 Subject: Global Crossing SOC In-Reply-To: References: <4a64e2f70812171145j4c8f6a4dqd7a45ee38a9e56c8@mail.gmail.com> Message-ID: <4a64e2f70812171219t667b711t3bb88ca9d7211aee@mail.gmail.com> Tier 1 is Tier 1. :/ On Wed, Dec 17, 2008 at 2:17 PM, Fouant, Stefan wrote: > I'm good now, but it would be nice if the people on the front lines at > Global Crossing were even aware what a "Denial of Service" attack was, or > that they even have a SOC for incident handling. Once we got redirected > into their SOC we were in good hands. > > > > *Stefan Fouant**:** **NeuStar, Inc.** > *Principal Network Engineer > 46000 Center Oak Plaza Sterling, VA 20166 > *[ T ]** *+1 571 434 5656 *[ M ]** *+1 202 210 2075 > > *[ E ]* stefan.fouant at neustar.biz *[ W ]* www.neustar.biz > > > > *From:* Josh Potter [mailto:joshpotter at gmail.com] > *Sent:* Wednesday, December 17, 2008 2:45 PM > *To:* Fouant, Stefan > *Cc:* nanog at nanog.org; Brown, Chad > *Subject:* Re: Global Crossing SOC > > > > Sounds like you need to talk to the Global Crossing NCC. They're located > in Phoenix however I don't have their number. > > On Wed, Dec 17, 2008 at 12:32 PM, Fouant, Stefan < > Stefan.Fouant at neustar.biz> wrote: > > Folks, > > > > Any Global Crossing SOC folks here? We've had a simple DoS attack > targeting one of our nodes connected to Global Crossing but have > literally spent 3 hours on the phone with Global Crossing support > attempting to get someone with a clue as to how to implement a simple > ACL on their edge router to deal with this. > > > > If there's anyone here who can assist, please contact me off list. > > > > Regards, > > > > Stefan Fouant: NeuStar, Inc. > Principal Network Engineer > 46000 Center Oak Plaza Sterling, VA 20166 > [ T ] +1 571 434 5656 [ M ] +1 202 210 2075 > > [ E ] stefan.fouant at neustar.biz [ W ] www.neustar.biz > > > > > > -- > Josh Potter > -- Josh Potter From sil at infiltrated.net Wed Dec 17 14:29:36 2008 From: sil at infiltrated.net (J. Oquendo) Date: Wed, 17 Dec 2008 14:29:36 -0600 Subject: Global Crossing SOC In-Reply-To: <4a64e2f70812171219t667b711t3bb88ca9d7211aee@mail.gmail.com> References: <4a64e2f70812171145j4c8f6a4dqd7a45ee38a9e56c8@mail.gmail.com> <4a64e2f70812171219t667b711t3bb88ca9d7211aee@mail.gmail.com> Message-ID: <20081217202936.GB95690@infiltrated.net> > I'm good now, but it would be nice if the people on the front lines at > Global Crossing were even aware what a "Denial of Service" attack was, or > that they even have a SOC for incident handling. Once we got redirected > into their SOC we were in good hands. You're "assuming" (anyone remember the Benny Hill assume skit). How many companies - especially large "layered" companies can you name that would even be able to determine what a SOC is on their customer service level. I've seen companies with level2 and level3 layers that couldn't even understand what it was. Perhaps DNS lookups could include such information in the future. It would be nice to nslookup a netblock and get something "relevant" for the security ops as opposed to the standard "abuse" which was largely relevant for mail operations (spam). I'm sure I'm not the only one who has thought about this. Maybe NAP's and NSP's can place contact information somewhere for those with a specific need to contact those with direct knowledge. Then real world sinks in... Ticketing systems, accountability, engineers who would rather be on IRC then cleaning up their nets, etc. Happy holidays all ;) =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "Enough research will tend to support your conclusions." - Arthur Bloch "A conclusion is the place where you got tired of thinking" - Arthur Bloch 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From Stefan.Fouant at neustar.biz Wed Dec 17 14:50:28 2008 From: Stefan.Fouant at neustar.biz (Fouant, Stefan) Date: Wed, 17 Dec 2008 15:50:28 -0500 Subject: Global Crossing SOC In-Reply-To: <20081217202936.GB95690@infiltrated.net> References: <4a64e2f70812171145j4c8f6a4dqd7a45ee38a9e56c8@mail.gmail.com><4a64e2f70812171219t667b711t3bb88ca9d7211aee@mail.gmail.com> <20081217202936.GB95690@infiltrated.net> Message-ID: > -----Original Message----- > From: J. Oquendo [mailto:sil at infiltrated.net] > Subject: Re: Global Crossing SOC > > only one who has thought about this. Maybe NAP's and NSP's can > place contact information somewhere for those with a specific > need to contact those with direct knowledge. I think it's a lovely idea, I just wonder how long such a system would last before people really start taking advantage of it, i.e. I have a really low priority, non-important issue I need resolved, let me get in touch with the MOST clueful person I can to get a really quick resolution... Stefan Fouant: NeuStar, Inc. Principal Network Engineer 46000 Center Oak Plaza Sterling, VA 20166 [ T ] +1 571 434 5656 [ M ] +1 202 210 2075 [ E ] stefan.fouant at neustar.biz [ W ] www.neustar.biz From sil at infiltrated.net Wed Dec 17 15:01:12 2008 From: sil at infiltrated.net (J. Oquendo) Date: Wed, 17 Dec 2008 15:01:12 -0600 Subject: Global Crossing SOC In-Reply-To: References: <20081217202936.GB95690@infiltrated.net> Message-ID: <20081217210111.GA9031@infiltrated.net> On Wed, 17 Dec 2008, Fouant, Stefan wrote: > > -----Original Message----- > > From: J. Oquendo [mailto:sil at infiltrated.net] > > Subject: Re: Global Crossing SOC > > > > only one who has thought about this. Maybe NAP's and NSP's can > > place contact information somewhere for those with a specific > > need to contact those with direct knowledge. > > I think it's a lovely idea, I just wonder how long such a system would > last before people really start taking advantage of it, i.e. I have a > really low priority, non-important issue I need resolved, let me get in > touch with the MOST clueful person I can to get a really quick > resolution... > I thought I had made it clear about the cons. Obviously the con would be someone contacting say Global or Level3 or someone else with: "OMFG like... Some virus!", the cost of doing business. That doesn't stop them NOW from Googling "security" +"Global", they're not doing an nslookup for contact information. I would like to believe that the majority of people doing nslookup's for contact information usually have a higher grasp of what they're looking for. Ask any "Average Joe" to perform an nslookup and compare those results to deer on the highways looking at those high-beams. You can't expect someone with a less than mission critical reason to contact someone in a higher position, there is no guarantee someone wouldn't be clueful enough to just Google "SOC" +"Global Crossing" +SOC (http://www.google.com/search?q=%22global+crossing%22+%2B%22SOC%22+%2Bcontact) What I infer from you is "right... Buddy go ahead and do it... Then the whole world will be screaming about not-so-important shtuff!" If this is the case, what's to stop them from using Google. For the most part, we can infer a large portion of users outside of those with *some* form of networking concepts/experience, can use and know what nslookup is for. Placing relevant information is not going to "cripple SOC" no more than Google would. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "Enough research will tend to support your conclusions." - Arthur Bloch "A conclusion is the place where you got tired of thinking" - Arthur Bloch 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From Stefan.Fouant at neustar.biz Wed Dec 17 15:49:33 2008 From: Stefan.Fouant at neustar.biz (Fouant, Stefan) Date: Wed, 17 Dec 2008 16:49:33 -0500 Subject: Global Crossing SOC In-Reply-To: <20081217210111.GA9031@infiltrated.net> References: <20081217202936.GB95690@infiltrated.net> <20081217210111.GA9031@infiltrated.net> Message-ID: While I understand where you are coming from and I completely agree, I think I should point out that the search pattern you generated actually produced an Press Release about Global Crossing's SOC implementing some ISO 9001:2000 certification. At the bottom of the article it had Press "Contacts" within Global Crossing. It didn't actually contain any useful contact information for any SOC personnel whatsoever... It's a moot point however, because I happen to agree with you that obtaining that information via nslookup is a more effective barrier at weeding out the less clueful. Stefan Fouant: NeuStar, Inc. Principal Network Engineer 46000 Center Oak Plaza Sterling, VA 20166 [ T ] +1 571 434 5656 [ M ] +1 202 210 2075 [ E ] stefan.fouant at neustar.biz [ W ] www.neustar.biz > -----Original Message----- > From: J. Oquendo [mailto:sil at infiltrated.net] > Sent: Wednesday, December 17, 2008 4:01 PM > To: nanog at nanog.org > Subject: Re: Global Crossing SOC > > On Wed, 17 Dec 2008, Fouant, Stefan wrote: > > > > -----Original Message----- > > > From: J. Oquendo [mailto:sil at infiltrated.net] > > > Subject: Re: Global Crossing SOC > > > > > > only one who has thought about this. Maybe NAP's and NSP's can > > > place contact information somewhere for those with a specific > > > need to contact those with direct knowledge. > > > > I think it's a lovely idea, I just wonder how long such a system > would > > last before people really start taking advantage of it, i.e. I have a > > really low priority, non-important issue I need resolved, let me get > in > > touch with the MOST clueful person I can to get a really quick > > resolution... > > > > I thought I had made it clear about the cons. Obviously the con would > be someone contacting say Global or Level3 or someone else with: "OMFG > like... Some virus!", the cost of doing business. That doesn't stop > them NOW from Googling "security" +"Global", they're not doing an > nslookup > for contact information. I would like to believe that the majority of > people doing nslookup's for contact information usually have a higher > grasp of what they're looking for. Ask any "Average Joe" to perform an > nslookup and compare those results to deer on the highways looking at > those high-beams. > > You can't expect someone with a less than mission critical reason to > contact someone in a higher position, there is no guarantee someone > wouldn't be clueful enough to just Google "SOC" +"Global Crossing" > +SOC > > (http://www.google.com/search?q=%22global+crossing%22+%2B%22SOC%22+%2Bc > ontact) > > What I infer from you is "right... Buddy go ahead and do it... Then > the whole world will be screaming about not-so-important shtuff!" > If this is the case, what's to stop them from using Google. For the > most part, we can infer a large portion of users outside of those > with *some* form of networking concepts/experience, can use and know > what nslookup is for. Placing relevant information is not going to > "cripple SOC" no more than Google would. > > > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > J. Oquendo > SGFA, SGFE, C|EH, CNDA, CHFI, OSCP > > "Enough research will tend to support your > conclusions." - Arthur Bloch > > "A conclusion is the place where you got > tired of thinking" - Arthur Bloch > > 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E > From nanog at daork.net Wed Dec 17 16:07:47 2008 From: nanog at daork.net (Nathan Ward) Date: Thu, 18 Dec 2008 11:07:47 +1300 Subject: Gigabit Linux Routers In-Reply-To: References: Message-ID: <14706848-EA79-4A77-93F2-6556CF222A16@daork.net> On 18/12/2008, at 3:02 AM, Chris wrote: > Hi All, > Sorry if this is a repeat topic. I've done a fair bit of trawling > but can't > find anything concrete to base decisions on. > > I'm hoping someone can offer some advice on suitable hardware and > kernel > tweaks for using Linux as a router running bgpd via Quagga. We do > this at > the moment and our box manages under the 100Mbps level very > effectively. > Over the next year however we expect to push about 250Mbps outbound > traffic > with very little inbound (50Mbps simultaneously) and I'm seeing > differing > suggestions of what to do in order to move up to the 1Gbps level. > > It seems even a dual core box with expensive NICs and some kernel > tweaks > will accomplish this but we can't afford to get the hardware purchases > wrong. We'd be looking to buy one live and one standby box within > the next > month or so. They will only run Quagga primarily with 'tc' for > shaping. > We're in the UK if it makes any difference. > > Any help massively appreciated, ideally from those doing the same in > production environments. Give Click a try - it is an alternative forwarding plane for Linux, that ran much faster than regular Linux forwarding a few years ago, and I imagine would still do so. The XORP routing suite supports various different FIBs, including Click. http://read.cs.ucla.edu/click/ -- Nathan Ward From sil at infiltrated.net Wed Dec 17 16:02:59 2008 From: sil at infiltrated.net (J. Oquendo) Date: Wed, 17 Dec 2008 16:02:59 -0600 Subject: Global Crossing SOC In-Reply-To: References: <20081217210111.GA9031@infiltrated.net> Message-ID: <20081217220259.GB34672@infiltrated.net> On Wed, 17 Dec 2008, Fouant, Stefan wrote: > While I understand where you are coming from and I completely agree, I > think I should point out that the search pattern you generated actually > produced an Press Release about Global Crossing's SOC implementing some > ISO 9001:2000 certification. At the bottom of the article it had Press > "Contacts" within Global Crossing. It didn't actually contain any > useful contact information for any SOC personnel whatsoever... > > It's a moot point however, because I happen to agree with you that > obtaining that information via nslookup is a more effective barrier at > weeding out the less clueful. > I didn't want to spend too much time sorting out Google searches ;) Anyhow, how do we get others to understand the need for something like this (information via say whois trickled from an nslookup on a netblock). That would definitely be more productive than someone having to contact abuse - which is highly likely going to ignored/not remedied appropriately. Would definitely be a plus for me if say I had someone directly contact my SOC team for a security related issue. Would save time for me and the caller. I see it as a no brainer... Others will likely see it as "that's what abuse is for" Maybe Jared should start a SOC contact page or something similar. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "Enough research will tend to support your conclusions." - Arthur Bloch "A conclusion is the place where you got tired of thinking" - Arthur Bloch 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From dgilbert at dclg.ca Wed Dec 17 16:13:06 2008 From: dgilbert at dclg.ca (David Gilbert) Date: Wed, 17 Dec 2008 17:13:06 -0500 Subject: Gigabit Linux Routers In-Reply-To: References: <4949290D.4060606@shankland.org> Message-ID: <18761.31090.285994.96139@canoe.dclg.ca> >>>>> "chris" == chris writes: chris> All the responses have been really helpful. Thanks to everyone chris> for being friendly and for taking the time to answer in detail. chris> I've asked a hardware provider to quote for a couple of x86 chris> boxes and I'll look for suitable Intel NICs too. chris> Jim: We're a very small ISP and have a full mix of packet sizes chris> on the network but the vast majority is outbound on port 80 so chris> hopefully that'll help. chris> Any more input will of course be considered. I may post the NIC chris> models for approval if I'm scratching my head again :) It's also worth saying that you should consider using FreeBSD --- which uses an r-tree for routes (constant time lookup) and is not flow-based. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can be | |Mail: dave at daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From sdhillon at decarta.com Wed Dec 17 17:02:09 2008 From: sdhillon at decarta.com (Sargun Dhillon) Date: Wed, 17 Dec 2008 15:02:09 -0800 Subject: Gigabit Linux Routers In-Reply-To: <14706848-EA79-4A77-93F2-6556CF222A16@daork.net> References: <14706848-EA79-4A77-93F2-6556CF222A16@daork.net> Message-ID: <494984F1.8000207@decarta.com> Ah, NO! Stay away from Click. It is NOT stable. Unless you want to hold your network together with paperclips and rubber bands, stay away. We use Linux software routing extensively where I work. We use Quagga primarily. I tried XORP, and it was very interesting, but not particularly ready for production. For our non-Linux boxes (FreeBSD), we use OpenBGPd, whereas on Linux, Quagga is far more stable. From a hardware perspective, you guys really don't need anything special anymore. Nathan Ward wrote: > On 18/12/2008, at 3:02 AM, Chris wrote: > >> Hi All, >> Sorry if this is a repeat topic. I've done a fair bit of trawling but >> can't >> find anything concrete to base decisions on. >> >> I'm hoping someone can offer some advice on suitable hardware and kernel >> tweaks for using Linux as a router running bgpd via Quagga. We do >> this at >> the moment and our box manages under the 100Mbps level very effectively. >> Over the next year however we expect to push about 250Mbps outbound >> traffic >> with very little inbound (50Mbps simultaneously) and I'm seeing >> differing >> suggestions of what to do in order to move up to the 1Gbps level. >> >> It seems even a dual core box with expensive NICs and some kernel tweaks >> will accomplish this but we can't afford to get the hardware purchases >> wrong. We'd be looking to buy one live and one standby box within the >> next >> month or so. They will only run Quagga primarily with 'tc' for shaping. >> We're in the UK if it makes any difference. >> >> Any help massively appreciated, ideally from those doing the same in >> production environments. > > > Give Click a try - it is an alternative forwarding plane for Linux, > that ran much faster than regular Linux forwarding a few years ago, > and I imagine would still do so. > > The XORP routing suite supports various different FIBs, including Click. > > http://read.cs.ucla.edu/click/ > > -- > Nathan Ward > > > > > -- +1.925.202.9485 Sargun Dhillon deCarta sdhillon at decarta.com www.decarta.com From chris at ghostbusters.co.uk Thu Dec 18 02:44:02 2008 From: chris at ghostbusters.co.uk (Chris) Date: Thu, 18 Dec 2008 08:44:02 +0000 Subject: Gigabit Linux Routers In-Reply-To: <494984F1.8000207@decarta.com> References: <14706848-EA79-4A77-93F2-6556CF222A16@daork.net> <494984F1.8000207@decarta.com> Message-ID: Thanks to the list again. There's lots more options than I'd considered. I think it's likely that I'll stick with what I know, which is Linux not FreeBSD and Quagga. The lack of a need to learn new stuff is the my main motivation behind this because I'm unlikely to break things as frequently. One final quick question on the NICs if I can. Following Mike's suggestion about specific Intel chipsets (82575 or 82576) it looks like it's much easier to source the chipsets mentioned by David (82571EB). If these NICs are embedded on the motherboard is it going to be of disadvantage in terms of performance ? I take the point of the interrupts being the key, kindly thrown into the mix by Eugeniu. A nice man called John mailed me off list and mentioned this off-the-shelf build. On that note does anyone have any experience of Lannerinc's appliances mentioned above by Ingo or John's suggested RouterBoard: "the 1000 series seems good, just short on ram on the basic spec. At sub ?500 notes, it's cheaper than buying a basic server and it's designed to do the job you need. http://www.routerboard.com/prices.html". Both appliances seem to perform well in the throughput tests. Now to look at very affordable layer 2, Gigabit 3com switches with good pps. Chris From eugen at imacandi.net Thu Dec 18 03:00:05 2008 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Thu, 18 Dec 2008 11:00:05 +0200 Subject: Gigabit Linux Routers In-Reply-To: References: <14706848-EA79-4A77-93F2-6556CF222A16@daork.net> <494984F1.8000207@decarta.com> Message-ID: <494A1115.8000105@imacandi.net> Chris wrote: > > Now to look at very affordable layer 2, Gigabit 3com switches with good pps. You should take a look at HP. They have very good gigabit switches and also offer lifetime guarantee on them. HP actually has a CLI to configure the switch, not the crap 3Com has. From jeroen at easyhosting.nl Thu Dec 18 03:13:03 2008 From: jeroen at easyhosting.nl (Jeroen Wunnink) Date: Thu, 18 Dec 2008 10:13:03 +0100 Subject: Gigabit Linux Routers In-Reply-To: <4949176F.50204@davidcoulson.net> References: <4949176F.50204@davidcoulson.net> Message-ID: <494A141F.1020707@easyhosting.nl> This might be of some use, it's a document written by one of the AMS-IX engineers, it's a little aged (almost 2 years old) so there should be some improvement in the numbers, but it might give you some insight in the bottlenecks when pushing a Linux server to it's max (10Gigabit in this case) http://noc.easycolocate.nl/10-GE_Routing_on_Linux.pdf David Coulson wrote: > The boxes (3650s) came with Broadcom BCM5708 on-board, but I push most > of my traffic over these: > > 1c:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit > Ethernet Controller (rev 06) > Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter > Flags: bus master, fast devsel, latency 0, IRQ 58 > Memory at c7ea0000 (32-bit, non-prefetchable) [size=128K] > Memory at c7e80000 (32-bit, non-prefetchable) [size=128K] > I/O ports at 6020 [size=32] > Capabilities: [c8] Power Management version 2 > Capabilities: [d0] Message Signalled Interrupts: 64bit+ > Queue=0/0 Enable+ > Capabilities: [e0] Express Endpoint IRQ 0 > Capabilities: [100] Advanced Error Reporting > > There are four Intel ports in the boxes, so traffic may or may not > stay on the same PCI-X card depending how things are flowing. > > Chris wrote: >> David: May I ask which NICs you use in the IBM boxes ? I see the Intels >> recommended by Mike have dual ports on one board (the docs say "Two >> complete >> Gigabit Ethernet connections in a single device ? Lower latency due >> to one >> electrical load on the bus"). >> > > -- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer at easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl From if at xip.at Thu Dec 18 05:41:47 2008 From: if at xip.at (Ingo Flaschberger) Date: Thu, 18 Dec 2008 12:41:47 +0100 (CET) Subject: Gigabit Linux Routers In-Reply-To: References: <14706848-EA79-4A77-93F2-6556CF222A16@daork.net> <494984F1.8000207@decarta.com> Message-ID: Dear Chris, > One final quick question on the NICs if I can. Following Mike's suggestion > about specific Intel chipsets (82575 or 82576) it looks like it's much > easier to source the chipsets mentioned by David (82571EB). If these NICs > are embedded on the motherboard is it going to be of disadvantage in terms > of performance ? I take the point of the interrupts being the key, kindly > thrown into the mix by Eugeniu. For a new system you should go with pci-e cards. > A nice man called John mailed me off list and mentioned this off-the-shelf > build. On that note does anyone have any experience of Lannerinc's > appliances mentioned above by Ingo I have posted thos off-list, for the list: http://www.lannerinc.com/DM/FW-7550_DM.pdf pros: cheap, cf-disk support, low power (~50W) cons: only 1GB Ram (enough for 1million routes), pci-connected intel 82541GI, 32bit, 33MHZ acpi max-temp is set to low in bios and needs an acpi-aml file to be loaded http://www.axiomtek.de/uploads/na-820.pdf pros: 7x pci-e www.endian.com use them. http://www.endian.com/en/products/hardware/macro-x2/ OS: Freebsd: pros: very stable, quagge runs very well, fastforwarding support, simple traffic shaping, interrupt less polling supported cons: only 1 route for each network, vrrp failover is not easy to implement with quagga and ospf, no multipath routing Linux: pros: more than 1 route for each network possible, interrupt less polling should be supported? fastforwarding ? cons: no multipath routing Cpu's: Single-core-cpus performs better at freebsd than multi-core ones At freebsd-net mailinglist there is a very long thread about freebsd-routers. Kind regards, Ingo Flaschberger From eugen at imacandi.net Thu Dec 18 05:48:11 2008 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Thu, 18 Dec 2008 13:48:11 +0200 Subject: Gigabit Linux Routers In-Reply-To: References: <14706848-EA79-4A77-93F2-6556CF222A16@daork.net> <494984F1.8000207@decarta.com> Message-ID: <494A387B.4010503@imacandi.net> Ingo Flaschberger wrote: > OS: > Freebsd: > pros: very stable, quagge runs very well, fastforwarding support, > simple traffic shaping, interrupt less polling supported > cons: only 1 route for each network, vrrp failover is not easy to > implement with quagga and ospf, no multipath routing > Linux: > pros: more than 1 route for each network possible, > interrupt less polling should be supported? > fastforwarding ? > cons: no multipath routing ^^^^^^^^^^^^^^^^^^^^ Are you sure ? Because there is an option in the kernel, under advanced routing setup to enable multipath routing. And also, with iproute2, you can add multiple gateways with different/equal weights for a specific prefix From tme at multicasttech.com Thu Dec 18 05:51:07 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 18 Dec 2008 06:51:07 -0500 Subject: Gigabit Linux Routers In-Reply-To: <494A141F.1020707@easyhosting.nl> References: <4949176F.50204@davidcoulson.net> <494A141F.1020707@easyhosting.nl> Message-ID: <54D52BFC-1628-4F2A-94F1-F1D764110E6E@multicasttech.com> On Dec 18, 2008, at 4:13 AM, Jeroen Wunnink wrote: > This might be of some use, it's a document written by one of the AMS- > IX engineers, it's a little aged (almost 2 years old) so there > should be some improvement in the numbers, but it might give you > some insight in the bottlenecks when pushing a Linux server to it's > max (10Gigabit in this case) > > http://noc.easycolocate.nl/10-GE_Routing_on_Linux.pdf Note that this test did not involve full BGP. Given the problems that used to occur on some name brand routers when BGP took up too much CPU, I would be careful extrapolating these results if you are planning on running full BGP. As the paper itself says, " In a real-world situation the device might be running BGP, with a full routing table. This will surely affect the performance of the device." Regards Marshall > > > > > David Coulson wrote: >> The boxes (3650s) came with Broadcom BCM5708 on-board, but I push >> most of my traffic over these: >> >> 1c:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit >> Ethernet Controller (rev 06) >> Subsystem: Intel Corporation PRO/1000 PT Dual Port Server >> Adapter >> Flags: bus master, fast devsel, latency 0, IRQ 58 >> Memory at c7ea0000 (32-bit, non-prefetchable) [size=128K] >> Memory at c7e80000 (32-bit, non-prefetchable) [size=128K] >> I/O ports at 6020 [size=32] >> Capabilities: [c8] Power Management version 2 >> Capabilities: [d0] Message Signalled Interrupts: 64bit+ >> Queue=0/0 Enable+ >> Capabilities: [e0] Express Endpoint IRQ 0 >> Capabilities: [100] Advanced Error Reporting >> >> There are four Intel ports in the boxes, so traffic may or may not >> stay on the same PCI-X card depending how things are flowing. >> >> Chris wrote: >>> David: May I ask which NICs you use in the IBM boxes ? I see the >>> Intels >>> recommended by Mike have dual ports on one board (the docs say >>> "Two complete >>> Gigabit Ethernet connections in a single device ? Lower latency >>> due to one >>> electrical load on the bus"). >>> >> >> > > -- > > Met vriendelijke groet, > > Jeroen Wunnink, > EasyHosting B.V. Systeembeheerder > systeembeheer at easyhosting.nl > > telefoon:+31 (035) 6285455 Postbus 48 > fax: +31 (035) 6838242 3755 ZG Eemnes > > http://www.easyhosting.nl > http://www.easycolocate.nl > > > From karnaugh at karnaugh.za.net Thu Dec 18 05:56:16 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Thu, 18 Dec 2008 13:56:16 +0200 Subject: Gigabit Linux Routers In-Reply-To: References: <14706848-EA79-4A77-93F2-6556CF222A16@daork.net> <494984F1.8000207@decarta.com> Message-ID: <494A3A60.2070202@karnaugh.za.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ingo Flaschberger wrote: > cons: only 1 route for each network, vrrp failover is not easy to > implement with quagga and ospf, no multipath routing Anyone cares about VRRPD when you have Heartbeat? > Linux: > pros: more than 1 route for each network possible, > interrupt less polling should be supported? > fastforwarding ? > cons: no multipath routing In what way is multipath routing not supported? Iproute2 and contrack has done this for ages. Equal metric round robin is also possible and works very well, only problem is it's not capacity sensitive. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJSjpg0FZZWLfHKjURAi5vAJ9KM3lS2vzG/ssh0UqkSijul1q8DACcDxAZ GijQNdu+5YYdNuO1LBtkCNA= =VmHM -----END PGP SIGNATURE----- From fweimer at bfk.de Thu Dec 18 06:07:03 2008 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 18 Dec 2008 13:07:03 +0100 Subject: Gigabit Linux Routers In-Reply-To: <49492C14.2010000@imacandi.net> (Eugeniu Patrascu's message of "Wed, 17 Dec 2008 18:43:00 +0200") References: <4949101C.1000108@imacandi.net> <82oczaq0zj.fsf@mid.bfk.de> <49492C14.2010000@imacandi.net> Message-ID: <82wsdxlmag.fsf@mid.bfk.de> * Eugeniu Patrascu: >> Do you know if it's possible to switch of the route cache? Based on >> my past experience, it was a major source of routing performance >> dependency on traffic patterns (it's basically flow-based forwarding). > > I don't understand your question. Flow-based routing does not deal well with certain traffic patterns (high HTTP or DNS load, or DoS attacks). > In kernel, when you compile it, you have two options: > - hash based route algorithm > - lc-trie based route algorithm > > From what I've read on the internet about the latter algorithm, it's > supposed to be faster regarding route lookups with large routing > tables (like a global routing table). In the past, Linux used flow routing. First, an ordinary hash table (the dst cache, also called route cache) is looked up using the destination address of the packet (and a few other bits). In case of a hit, the information is used. In case of a miss, a FIB lookup (using the hash algorithm or LC-trie) is performed, and the result is stored in the cache and used. If there are more flows than cache entries, the work to update the cache (and expire old records from it) is wasted. But under more benign conditions, the cache is a win. > In that configuration you'll split available bandwidth on the NIC and > also have less throughput because server NICs are not optimized for > "same interface switching". If this is a problem, I can use multiple trunk ports or multiple routers. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer at bfk.de Thu Dec 18 06:08:09 2008 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 18 Dec 2008 13:08:09 +0100 Subject: Gigabit Linux Routers In-Reply-To: <494929D4.9090909@blastro.com> (Alex Thurlow's message of "Wed, 17 Dec 2008 10:33:24 -0600") References: <4949101C.1000108@imacandi.net> <82oczaq0zj.fsf@mid.bfk.de> <494929D4.9090909@blastro.com> Message-ID: <82vdthlm8m.fsf@mid.bfk.de> * Alex Thurlow: > Depending on your WAN interface, there's actually a decent amount of > stuff out there. The cheaper alternative to me has actually always been > to get some old cisco hardware with the proper interfaces and use it for > media conversion. I have a 6500 with Sup1As in it. It can't take BGP > feeds with the amount of memory it has, but with the right cards, it > will give my router Ethernet and push a few million pps with no problem. But you have to ask your peer to enable eBGP multihop, right? Or are there some TTL tricks you can play? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From if at xip.at Thu Dec 18 06:13:07 2008 From: if at xip.at (Ingo Flaschberger) Date: Thu, 18 Dec 2008 13:13:07 +0100 (CET) Subject: Gigabit Linux Routers In-Reply-To: <494A387B.4010503@imacandi.net> References: <14706848-EA79-4A77-93F2-6556CF222A16@daork.net> <494984F1.8000207@decarta.com> <494A387B.4010503@imacandi.net> Message-ID: Dear Eugeniu, >> OS: >> Freebsd: >> pros: very stable, quagge runs very well, fastforwarding support, >> simple traffic shaping, interrupt less polling supported >> cons: only 1 route for each network, vrrp failover is not easy to >> implement with quagga and ospf, no multipath routing >> Linux: >> pros: more than 1 route for each network possible, >> interrupt less polling should be supported? >> fastforwarding ? >> cons: no multipath routing > ^^^^^^^^^^^^^^^^^^^^ > Are you sure ? Because there is an option in the kernel, under > advanced routing setup to enable multipath routing. > And also, with iproute2, you can add multiple gateways with > different/equal weights for a specific prefix Multipath, yes, but flow-based, not per packet. There exists a patch for 2.4 kernel, but not for 2.6 Or tinker with iptables. Kind regards, Ingo Flaschberger From b.vontobel at meteonews.ch Thu Dec 18 07:55:14 2008 From: b.vontobel at meteonews.ch (Beat Vontobel) Date: Thu, 18 Dec 2008 14:55:14 +0100 Subject: Advice requested for OpenBSD vs. Linux/OpenBGP vs. Quagga router deployment. In-Reply-To: References: Message-ID: Hi Marc, > I saw from previous email that Quagga was recommended as opposed to > OpenBGP. Any further comments on that? Also, any comments on the > choice of OpenBSD vs. Linux? > > I don't want to start a religious war :-) Just curious about what > most folks are doing and what their experiences have been. We run a similar setup since about a year. I also don't want to start a "religious war" (being a happy user of both Linux and OpenBSD, for different purposes), but in this scenario my decision was quick and clear: I went for OpenBSD with OpenBGPD, consistent with my experience throughout the last few years, that for the basic, "hidden" (from end user perspective) network services (routing, firewalling, DHCP, DNS?) OpenBSD never let me down and saved me a _lot_ of time and hassle as an admin (doing this stuff with Linux before). And admin time is often more valuable than that of one or two CPU cycles? (and as long as I get the throughput I demand plus a large enough margin I really don't care about those). My basic rule of thumb now is (and I'm just pragmatic, not religious): If I can get away with the base installation of OpenBSD for a service, I really give it the first try. So for OpenBGPD. It was also the documentation, the clean design and the usability (okay, that's really personal taste, but I really got to love the OpenBSD config file style) that helped with that decision. And from my perspective, it really was the right one: The setup just works, right from the beginning. Flawless. With both Junipers and Ciscos as neighbors. > We are planning to run two OpenBSD based firewalls (with CARP and > pf) running OpenBGP in order to connect to the two ISPs. Just one thing independent of the OpenBSD vs. Linux question: Depending on the complexity of your setup and maybe also for a cleaner design and possibly additional layers of security, I'd recommend to think about separating the "pure" firewalls from the BGP stuff. I do have three OpenBGPD boxes towards the Internet as our BGP peers plus two redundant pairs of OpenBSD carp/pf boxes towards different internal networks and DMZs. Between the OpenBGPD and the carp/pf boxes is our "backbone". I experimented with a setup as you describe it (many different BGP/ router/firewalling roles combined on one pair of OpenBSD boxes) first, but soon realized that (while perfectly okay for a simple setup) as soon as you get more and more specialized requirements, things tend to get unneccessarily complicated and you're probably better of with dedicated boxes (if not for performance reasons, then still for the design). Best regards, Beat Vontobel -- Beat Vontobel, CTO, MeteoNews AG Siewerdtstr. 105, CH-8050 Zurich, Switzerland E-Mail: b.vontobel at meteonews.ch IT Department: +41 (0)43 288 40 54 Main phone: +41 (0)43 288 40 50 From shrdlu at deaddrop.org Thu Dec 18 07:59:30 2008 From: shrdlu at deaddrop.org (Etaoin Shrdlu) Date: Thu, 18 Dec 2008 05:59:30 -0800 Subject: Gigabit Linux Routers In-Reply-To: <494A1115.8000105@imacandi.net> References: <14706848-EA79-4A77-93F2-6556CF222A16@daork.net> <494984F1.8000207@decarta.com> <494A1115.8000105@imacandi.net> Message-ID: <494A5742.1040001@deaddrop.org> Eugeniu Patrascu wrote: > Chris wrote: > >> >> Now to look at very affordable layer 2, Gigabit 3com switches with >> good pps. > > > You should take a look at HP. They have very good gigabit switches and > also offer lifetime guarantee on them. > > HP actually has a CLI to configure the switch, not the crap 3Com has. Let me provide a strong second to HP. They are rock solid, easy to configure, easy to monitor remotely, and worth every penny. -- I like mathematics because it is not human and has nothing particular to do with this planet or with the whole accidental universe - because, like Spinoza's God, it won't love us in return. (Bertrand Russell) From david at davidcoulson.net Thu Dec 18 08:02:16 2008 From: david at davidcoulson.net (David Coulson) Date: Thu, 18 Dec 2008 09:02:16 -0500 Subject: Gigabit Linux Routers In-Reply-To: References: <14706848-EA79-4A77-93F2-6556CF222A16@daork.net> <494984F1.8000207@decarta.com> <494A387B.4010503@imacandi.net> Message-ID: <494A57E8.5050809@davidcoulson.net> Ingo Flaschberger wrote: > Multipath, yes, but flow-based, not per packet. > There exists a patch for 2.4 kernel, but not for 2.6 > Or tinker with iptables. And last I checked, even with multiple 'nexthop' entries, it still wasn't smart enough to drop a route if you lose an interface. From chris at ghostbusters.co.uk Thu Dec 18 08:56:21 2008 From: chris at ghostbusters.co.uk (Chris) Date: Thu, 18 Dec 2008 14:56:21 +0000 Subject: Gigabit Linux Routers In-Reply-To: <494A57E8.5050809@davidcoulson.net> References: <14706848-EA79-4A77-93F2-6556CF222A16@daork.net> <494984F1.8000207@decarta.com> <494A387B.4010503@imacandi.net> <494A57E8.5050809@davidcoulson.net> Message-ID: One final query for this thread if I may. Our hardware provider has come back with this as an 'easy to source build' in case we want two or three identical boxes: Supermicro X7SBI-LN2 motherboard with 2 x Intel 82573V/L gigabit PCI-Express NICs Does anyone have experience of these NICs before I commit ? Or any other comments ? I'll start trawling their specs too. Thanks again to all that responded, Chris From adam+nanog at uptill3.com Thu Dec 18 09:07:04 2008 From: adam+nanog at uptill3.com (Adam Crosby) Date: Thu, 18 Dec 2008 10:07:04 -0500 Subject: Gigabit Linux Routers In-Reply-To: <494A1115.8000105@imacandi.net> References: <14706848-EA79-4A77-93F2-6556CF222A16@daork.net> <494984F1.8000207@decarta.com> <494A1115.8000105@imacandi.net> Message-ID: On Dec 18, 2008, at 4:00 AM, Eugeniu Patrascu wrote: > Chris wrote: > >> Now to look at very affordable layer 2, Gigabit 3com switches with >> good pps. > > You should take a look at HP. They have very good gigabit switches > and also offer lifetime guarantee on them. > > HP actually has a CLI to configure the switch, not the crap 3Com has. > Not to defend 3Com or anything, but all of their enterprise stuff (for quite a few years now) has an extremely similar CLI to IOS. Came out very shortly after they got involved with Huawei. If you're already familiar with 3com enterprise gear, check out the 4200G series for cheap L2 gig switching. -- Adam From michael.dinn at airfire.ca Thu Dec 18 09:11:29 2008 From: michael.dinn at airfire.ca (Michael 'Moose' Dinn) Date: Thu, 18 Dec 2008 11:11:29 -0400 Subject: Gigabit Linux Routers In-Reply-To: References: <14706848-EA79-4A77-93F2-6556CF222A16@daork.net> <494984F1.8000207@decarta.com> <494A1115.8000105@imacandi.net> Message-ID: <20081218151128.GC29294@blend.twistedpair.ca> > Not to defend 3Com or anything, but all of their enterprise stuff (for quite > a few years now) has an extremely similar CLI to IOS. Came out very shortly > after they got involved with Huawei. > If you're already familiar with 3com enterprise gear, check out the 4200G > series for cheap L2 gig switching. 3Com's CLI is just different enough from Cisco's so they won't get sued. show interface = display interface write mem = save no ip address = undo ip address etc. All in all we've been fairly happy with the higher end gear (5500EI, 5500GEI). From anwalam at yahoo.com Thu Dec 18 09:20:58 2008 From: anwalam at yahoo.com (andy lam) Date: Thu, 18 Dec 2008 07:20:58 -0800 (PST) Subject: Arbor vs Narus comparison? Message-ID: <769202.55013.qm@web42108.mail.mud.yahoo.com> Recently I've been searching for something that is comparable to Arbor to see what else is out there.? Someone suggested Narus. ? Anyone out there have an opinion regarding the 2 applications and their differences?? Or another application that is worth noting? ? I am currently using Arbor Peakflow for Netflow analysis against?my peering/transit?traffic and their Security suite?to identify DoS, etc at the edge. ? Feel free to?contact off-list. ? Thanks From tdurack at gmail.com Thu Dec 18 10:51:30 2008 From: tdurack at gmail.com (Tim Durack) Date: Thu, 18 Dec 2008 11:51:30 -0500 Subject: Advice requested for OpenBSD vs. Linux/OpenBGP vs. Quagga router deployment. In-Reply-To: References: Message-ID: <9e246b4d0812180851g2cb26813k5aed38b9436261b1@mail.gmail.com> On Thu, Dec 18, 2008 at 8:55 AM, Beat Vontobel wrote: > Hi Marc, > >> I saw from previous email that Quagga was recommended as opposed to >> OpenBGP. Any further comments on that? Also, any comments on the choice >> of OpenBSD vs. Linux? >> >> I don't want to start a religious war :-) Just curious about what most >> folks are doing and what their experiences have been. For the past couple of years we've had good success running Quagga border router/firewall boxes on Debian booting from Sony Microvault 1GB USB. Standard Debian install with some minor mods to make it USB friendly (noatime, a few /dev/shm links.) Once you've got used to apt, it's hard to accept anything else. I know lots of people prefer a stripped down system, but if you're running the same basic services (BGP, SSH) I don't see the difference. Disclaimer: we only take default from our upstreams, so can't comment on Quagga and full routes. Tim:> From jschauma at netmeister.org Thu Dec 18 10:53:43 2008 From: jschauma at netmeister.org (Jan Schaumann) Date: Thu, 18 Dec 2008 11:53:43 -0500 Subject: RCN dns contact Message-ID: <20081218165343.GA19640@netmeister.org> Hi, If there's somebody from RCN on this list who I can talk to about their DNS (specifically about records that are too large for UDP and fall back to TCP), please contact me. Thanks, -Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jgreco at ns.sol.net Thu Dec 18 10:55:18 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 18 Dec 2008 10:55:18 -0600 (CST) Subject: Gigabit Linux Routers In-Reply-To: from "Ingo Flaschberger" at Dec 18, 2008 12:41:47 PM Message-ID: <200812181655.mBIGtIHR042995@aurora.sol.net> > I have posted thos off-list, for the list: > http://www.lannerinc.com/DM/FW-7550_DM.pdf > pros: cheap, cf-disk support, low power (~50W) cf-disk support is pretty easy to add to lots of things. With the advent of 4GB compact flash modules and CF-to-IDE adapters, it is not too hard to avoid rotating media... > OS: > Freebsd: > pros: very stable, quagge runs very well, fastforwarding support, quagga OSPF needs a patch on FreeBSD 7, else it will decimate your OSPF environment. > simple traffic shaping, interrupt less polling supported Several different traffic shaping strategies are available, and I think all of them go far beyond "simple". > cons: only 1 route for each network, vrrp failover is not easy to > implement with quagga and ospf, no multipath routing carp seems easy to implement, even with quagga and ospf. At least, it's set up on a lab setup here and everything appears to work as expected. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From if at xip.at Thu Dec 18 12:13:07 2008 From: if at xip.at (Ingo Flaschberger) Date: Thu, 18 Dec 2008 19:13:07 +0100 (CET) Subject: Gigabit Linux Routers In-Reply-To: <200812181655.mBIGtIHR042995@aurora.sol.net> References: <200812181655.mBIGtIHR042995@aurora.sol.net> Message-ID: Dear Joe, > Several different traffic shaping strategies are available, and I think > all of them go far beyond "simple". ipfw 100 add pipe 1 all from 192.168.0.0/24 to any xmit vlan1 ipfw pipe 1 config bw 95Mbit/s queue 200Kbytes thats simple. >> cons: only 1 route for each network, vrrp failover is not easy to >> implement with quagga and ospf, no multipath routing > > carp seems easy to implement, even with quagga and ospf. At least, it's > set up on a lab setup here and everything appears to work as expected. example setup: A----(ospf)---B \ / \ / \ / \ / \ / lan1 A and B share 1 virtual ip for lan1 (192.168.0.1/24). problems: *) only 1 ip-net supported (no aliases) *) carp is i bound, carp-dev line openbsd is in development (not shure if already stable) *) if carp switch over: t=0: A is master, has route 192.168.0.1/24 B has route 192.168.0.1/24 via ospf t=1: A goes down, route disappear (need linkstate in ospf) t=2: B carp takes over 192.168.0.1/24 B can not add 192.168.0.1/24 route as it is still known via ospf t=3: B gets update to remove route 192.168.0.1/24 via ospf t=4: 192.168.0.1/24 route has disappeared, failover broken. with ucarp, some special scripts and source code changed I was able to handle this situation, but not with carp and ospf (at least at freebsd 6.3) Kind regards, Ingo Flaschberger From rays at maine.edu Thu Dec 18 13:45:28 2008 From: rays at maine.edu (Soucy, Ray) Date: Thu, 18 Dec 2008 14:45:28 -0500 Subject: Gigabit Linux Routers In-Reply-To: References: Message-ID: <36243D984F88BA4ABD1E0EFC1E61B9894DBA08@fudd.ad.maine.edu> We spent a good amount of time looking into deploying a home-grown Linux-based CPE device over the summer. Generally, Linux is not the issue with performance. You want to focus on your hardware. We've seen the best performance with Intel MT series PCI-X server NICs. When we were testing the PCI-e cards were still underperforming, but they may have improved recently. The Intel cards have significantly better driver support in Linux so you will prob. want to stay away from anything without an Intel chipset. We also went with a low-end server-grade box from Dell (PowerEdge 840 w/ Dual core Xeon 3040 1.86 GHz, 1066 MHz FSB) which proved to be more than adequate. We used a tower for the text box to cut costs, but you would probably want something rack-mountable. With our setup we were able to sustain about 970 Mbps. Ultimately, we stopped because Quagga lacked any multicast support (we need PIM-SM). We recently looked at XORP as a possibility, and it works... but lacks the level of logging and control you would expect for a production environment. Vyatta recently announced a shift from XORP to Quagga so Quagga may see some new functionality. We also found IP Infusion which is being advertised as a complete solution, but when we tried to talk to them about getting a demo they seemed hesitant to work with us on anything beyond what Quagga already does (I'm guessing that they don't really have anything and it's all advertising). If all you're looking for is basic routing though, it might be worthwhile just getting a Vyatta appliance. Ray -----Original Message----- From: Chris [mailto:chris at ghostbusters.co.uk] Sent: Wednesday, December 17, 2008 9:03 AM To: nanog list Subject: Gigabit Linux Routers Hi All, Sorry if this is a repeat topic. I've done a fair bit of trawling but can't find anything concrete to base decisions on. I'm hoping someone can offer some advice on suitable hardware and kernel tweaks for using Linux as a router running bgpd via Quagga. We do this at the moment and our box manages under the 100Mbps level very effectively. Over the next year however we expect to push about 250Mbps outbound traffic with very little inbound (50Mbps simultaneously) and I'm seeing differing suggestions of what to do in order to move up to the 1Gbps level. It seems even a dual core box with expensive NICs and some kernel tweaks will accomplish this but we can't afford to get the hardware purchases wrong. We'd be looking to buy one live and one standby box within the next month or so. They will only run Quagga primarily with 'tc' for shaping. We're in the UK if it makes any difference. Any help massively appreciated, ideally from those doing the same in production environments. Thanks, Chris From chris.jackman+nanog at rcn.com Thu Dec 18 14:20:54 2008 From: chris.jackman+nanog at rcn.com (Chris Jackman) Date: Thu, 18 Dec 2008 15:20:54 -0500 Subject: RCN dns contact In-Reply-To: <20081218165343.GA19640@netmeister.org> References: <20081218165343.GA19640@netmeister.org> Message-ID: <20081218202054.GF22393@collab.or8.net> On Thu, Dec 18, 2008 at 11:53:43AM -0500, Jan Schaumann wrote: > Hi, > > If there's somebody from RCN on this list who I can talk to about their > DNS (specifically about records that are too large for UDP and fall back > to TCP), please contact me. Taken off list. To make this post useful, noc at rcn.com is always available. -cj -- Chris Jackman RCN Internet Systems From bruce at greatbasin.net Thu Dec 18 18:02:14 2008 From: bruce at greatbasin.net (Bruce Robertson) Date: Thu, 18 Dec 2008 16:02:14 -0800 Subject: Gigabit Linux Routers In-Reply-To: <36243D984F88BA4ABD1E0EFC1E61B9894DBA08@fudd.ad.maine.edu> References: <36243D984F88BA4ABD1E0EFC1E61B9894DBA08@fudd.ad.maine.edu> Message-ID: <494AE486.9080009@greatbasin.net> Imagestream does nice work as well. Soucy, Ray wrote: > If all you're looking for is basic routing though, it might be > worthwhile just getting a Vyatta appliance. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: bruce.vcf Type: text/x-vcard Size: 335 bytes Desc: not available URL: From lionair at samsung.com Thu Dec 18 20:40:47 2008 From: lionair at samsung.com (=?euc-kr?B?waTEob+1?=) Date: Fri, 19 Dec 2008 02:40:47 +0000 (GMT) Subject: What is the most standard subnet length on internet Message-ID: <11527796.20751229654447763.JavaMail.weblogic@epml12> Hi everyone, I'm going to rebuild IP allocation policy of my company and I am looking for some standard reference for my policy. I have already studied some standard like RFC1518, RIPE181, RFC2050 and I got it is very important to maintain hierachy structure. However, what I am really wondering is what is the most standard subnet length that always can be guaranteed through Internet. less than /24 bit ? I could not find any documents about that, which subnet length is most proper value and pursue internet standard policy ? Could anyone give me some information guides ? Best wishes, Chiyoung ============================================= Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lionair at samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 ============================================= From randy at psg.com Thu Dec 18 20:45:51 2008 From: randy at psg.com (Randy Bush) Date: Fri, 19 Dec 2008 11:45:51 +0900 Subject: What is the most standard subnet length on internet In-Reply-To: <11527796.20751229654447763.JavaMail.weblogic@epml12> References: <11527796.20751229654447763.JavaMail.weblogic@epml12> Message-ID: <494B0ADF.209@psg.com> On 08.12.19 11:40, ??? wrote: > what is the most standard subnet length that always can be > guaranteed through Internet. less than /24 bit ? nothing can always be guaranteed in life or the internet. but /24s do seem to be fairly widely used. so they probably work for the folk announcing them. randy From mike.lyon at gmail.com Thu Dec 18 20:49:51 2008 From: mike.lyon at gmail.com (Mike Lyon) Date: Thu, 18 Dec 2008 18:49:51 -0800 Subject: What is the most standard subnet length on internet In-Reply-To: <11527796.20751229654447763.JavaMail.weblogic@epml12> References: <11527796.20751229654447763.JavaMail.weblogic@epml12> Message-ID: <1b5c1c150812181849m1f5e06d6j19b7461cea3dc6d2@mail.gmail.com> Chiyong, Check out: http://bgp.potaroo.net/bgprpts/rva-index.html Since you are on nanog, you probably get the CIDR-REPORT every Friday but if not, go surf around at http://www.cidr-report.org Cheers, Mike On Thu, Dec 18, 2008 at 6:40 PM, ??? wrote: > Hi everyone, > > I'm going to rebuild IP allocation policy of my company and I am looking > for some standard reference for my policy. > I have already studied some standard like RFC1518, RIPE181, RFC2050 and I > got it is very important to maintain hierachy structure. > However, what I am really wondering is what is the most standard subnet > length that always can be guaranteed through Internet. less than /24 bit ? > I could not find any documents about that, which subnet length is most > proper value and pursue internet standard policy ? > > Could anyone give me some information guides ? > > Best wishes, > Chiyoung > ============================================= > Chi-Young Joung > SAMSUNG NETWORKS Inc. > Email: lionair at samsung.com > Tel +82 70 7015 0623, Mobile +82 17 520 9193 > Fax +82 70 7016 0031 > ============================================= From tme at multicasttech.com Thu Dec 18 20:56:12 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 18 Dec 2008 21:56:12 -0500 Subject: What is the most standard subnet length on internet In-Reply-To: <11527796.20751229654447763.JavaMail.weblogic@epml12> References: <11527796.20751229654447763.JavaMail.weblogic@epml12> Message-ID: <98FCB2E9-1EDD-474C-8EC7-C6AFD55A4377@multicasttech.com> On Dec 18, 2008, at 9:40 PM, ??? wrote: > Hi everyone, > > I'm going to rebuild IP allocation policy of my company and I am > looking for some standard reference for my policy. > I have already studied some standard like RFC1518, RIPE181, RFC2050 > and I got it is very important to maintain hierachy structure. > However, what I am really wondering is what is the most standard > subnet length that always can be guaranteed through Internet. less > than /24 bit ? Depends on how you count it - /24 is definitely the most numerous from where I sit. You might find this interesting : http://www.multicasttech.com/status/cidr.html Regards Marshall > > I could not find any documents about that, which subnet length is > most proper value and pursue internet standard policy ? > > Could anyone give me some information guides ? > > Best wishes, > Chiyoung > ============================================= > Chi-Young Joung > SAMSUNG NETWORKS Inc. > Email: lionair at samsung.com > Tel +82 70 7015 0623, Mobile +82 17 520 9193 > Fax +82 70 7016 0031 > ============================================= From ops.lists at gmail.com Thu Dec 18 21:37:56 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 19 Dec 2008 09:07:56 +0530 Subject: What is the most standard subnet length on internet In-Reply-To: <11527796.20751229654447763.JavaMail.weblogic@epml12> References: <11527796.20751229654447763.JavaMail.weblogic@epml12> Message-ID: Chi Young, let me clarify one thing here .. Do you mean IP allocation as in subnet allocation, swipping in apnic or through a rwhois server etc? Or do you mean "what is the minimum subnet size I can announce on the internet and have other providers not drop it on the floor"? srs On Fri, Dec 19, 2008 at 8:10 AM, ??? wrote: > Hi everyone, > > I'm going to rebuild IP allocation policy of my company and I am looking for some standard reference for my policy. > I have already studied some standard like RFC1518, RIPE181, RFC2050 and I got it is very important to maintain hierachy structure. > However, what I am really wondering is what is the most standard subnet length that always can be guaranteed through Internet. less than /24 bit ? > I could not find any documents about that, which subnet length is most proper value and pursue internet standard policy ? > From lionair at samsung.com Thu Dec 18 22:43:57 2008 From: lionair at samsung.com (=?euc-kr?B?waTEob+1?=) Date: Fri, 19 Dec 2008 04:43:57 +0000 (GMT) Subject: What is the most standard subnet length on internet Message-ID: <15850784.26571229661837046.JavaMail.weblogic@epml12> Suresh, Yes, I guess my concern is close to the second meaning. It seems so simple. Currently annoucement of /24 seems to be okey, most upstream providers accept this. However I wonder if there is any ground rule based on any standard or official recommandation. If there is some standardized rule about prefix length to be annouced, I will make my bgp & IP allocation policy of each data center of my company, and I will be able to more fairly and squarely speak to my customer like this "You have to change your server's IP address if you want move your server to other place" chiyoung ============================================= Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lionair at samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 ============================================= ------- Original Message ------- Sender : Suresh Ramasubramanian Date : 2008-12-19 12:37 (GMT+09:00) Title : Re: What is the most standard subnet length on internet Chi Young, let me clarify one thing here .. Do you mean IP allocation as in subnet allocation, swipping in apnic or through a rwhois server etc? Or do you mean "what is the minimum subnet size I can announce on the internet and have other providers not drop it on the floor"? srs On Fri, Dec 19, 2008 at 8:10 AM, ??? wrote: > Hi everyone, > > I'm going to rebuild IP allocation policy of my company and I am looking for some standard reference for my policy. > I have already studied some standard like RFC1518, RIPE181, RFC2050 and I got it is very important to maintain hierachy structure. > However, what I am really wondering is what is the most standard subnet length that always can be guaranteed through Internet. less than /24 bit ? > I could not find any documents about that, which subnet length is most proper value and pursue internet standard policy ? > From lionair at samsung.com Thu Dec 18 23:01:34 2008 From: lionair at samsung.com (=?euc-kr?B?waTEob+1?=) Date: Fri, 19 Dec 2008 05:01:34 +0000 (GMT) Subject: Fwd: Re: Re: What is the most standard subnet length on internet Message-ID: <7042375.27731229662894079.JavaMail.weblogic@epml12> "You have to change your server's IP address if you want move your server to other place" -> It is very natural case, but some customer could think of it will be okey to move if they have C class. but I have different idea. because the border router of that center is annoucing more greater IP block, and if customer move to other center with C class, then I have to newly announce that C class at the border router of other center. and then it is the time my hierachy structure is broken. To prevent this situation, I'm trying to find some standard material every person would understand and accept. ============================================= Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lionair at samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 ============================================= ------- Original Message ------- Sender : ??? ??/??1?/?????? Date : 2008-12-19 13:43 (GMT+09:00) Title : Re: Re: What is the most standard subnet length on internet Suresh, Yes, I guess my concern is close to the second meaning. It seems so simple. Currently annoucement of /24 seems to be okey, most upstream providers accept this. However I wonder if there is any ground rule based on any standard or official recommandation. If there is some standardized rule about prefix length to be annouced, I will make my bgp & IP allocation policy of each data center of my company, and I will be able to more fairly and squarely speak to my customer like this "You have to change your server's IP address if you want move your server to other place" chiyoung ============================================= Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lionair at samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 ============================================= ------- Original Message ------- Sender : Suresh Ramasubramanian Date : 2008-12-19 12:37 (GMT+09:00) Title : Re: What is the most standard subnet length on internet Chi Young, let me clarify one thing here .. Do you mean IP allocation as in subnet allocation, swipping in apnic or through a rwhois server etc? Or do you mean "what is the minimum subnet size I can announce on the internet and have other providers not drop it on the floor"? srs On Fri, Dec 19, 2008 at 8:10 AM, ??? wrote: > Hi everyone, > > I'm going to rebuild IP allocation policy of my company and I am looking for some standard reference for my policy. > I have already studied some standard like RFC1518, RIPE181, RFC2050 and I got it is very important to maintain hierachy structure. > However, what I am really wondering is what is the most standard subnet length that always can be guaranteed through Internet. less than /24 bit ? > I could not find any documents about that, which subnet length is most proper value and pursue internet standard policy ? > From ddunkin at netos.net Thu Dec 18 23:05:40 2008 From: ddunkin at netos.net (Darryl Dunkin) Date: Thu, 18 Dec 2008 21:05:40 -0800 Subject: What is the most standard subnet length on internet References: <15850784.26571229661837046.JavaMail.weblogic@epml12> Message-ID: <56F5BC5F404CF84896C447397A1AAF20B0F7D4@MAIL.nosi.netos.com> In general, announce what you are allocated from the RIR. The minimum allocation from you will see is a /24. A couple examples: http://www.arin.net/reference/ip_blocks.html#ipv4 https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html If you are allocated a /22, announce the /22. Do not announce anything longer unless you have a requirement to (such as a different origin AS). If you are further allocating a subset of that to a downstream, then a /24 out of that is acceptable as the origin will be different. -----Original Message----- From: ??? [mailto:lionair at samsung.com] Sent: Thursday, December 18, 2008 20:44 To: Suresh Ramasubramanian Cc: nanog at nanog.org Subject: Re: Re: What is the most standard subnet length on internet Suresh, Yes, I guess my concern is close to the second meaning. It seems so simple. Currently annoucement of /24 seems to be okey, most upstream providers accept this. However I wonder if there is any ground rule based on any standard or official recommandation. If there is some standardized rule about prefix length to be annouced, I will make my bgp & IP allocation policy of each data center of my company, and I will be able to more fairly and squarely speak to my customer like this "You have to change your server's IP address if you want move your server to other place" chiyoung ============================================= Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lionair at samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 ============================================= ------- Original Message ------- Sender : Suresh Ramasubramanian Date : 2008-12-19 12:37 (GMT+09:00) Title : Re: What is the most standard subnet length on internet Chi Young, let me clarify one thing here .. Do you mean IP allocation as in subnet allocation, swipping in apnic or through a rwhois server etc? Or do you mean "what is the minimum subnet size I can announce on the internet and have other providers not drop it on the floor"? srs On Fri, Dec 19, 2008 at 8:10 AM, ??? wrote: > Hi everyone, > > I'm going to rebuild IP allocation policy of my company and I am looking for some standard reference for my policy. > I have already studied some standard like RFC1518, RIPE181, RFC2050 and I got it is very important to maintain hierachy structure. > However, what I am really wondering is what is the most standard subnet length that always can be guaranteed through Internet. less than /24 bit ? > I could not find any documents about that, which subnet length is most proper value and pursue internet standard policy ? > From ops.lists at gmail.com Thu Dec 18 23:27:56 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 19 Dec 2008 10:57:56 +0530 Subject: What is the most standard subnet length on internet In-Reply-To: <56F5BC5F404CF84896C447397A1AAF20B0F7D4@MAIL.nosi.netos.com> References: <15850784.26571229661837046.JavaMail.weblogic@epml12> <56F5BC5F404CF84896C447397A1AAF20B0F7D4@MAIL.nosi.netos.com> Message-ID: Even if a longer prefix like a /24 is announced, chances of people accepting it is slim. Especially, as you say, if the RIR allocation is something larger than /24 And I have a feeling acceptance /24 route announcements of anything other than legacy classful space, infrastructure space like the root servers is going to be patchy at best. 2008/12/19 Darryl Dunkin : > > If you are allocated a /22, announce the /22. Do not announce anything longer unless you have a requirement to (such as a different origin AS). If you are further allocating a subset of that to a downstream, then a /24 out of that is acceptable as the origin will be different. > From rubensk at gmail.com Thu Dec 18 23:56:28 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Thu, 18 Dec 2008 21:56:28 -0800 Subject: Arbor vs Narus comparison? In-Reply-To: <769202.55013.qm@web42108.mail.mud.yahoo.com> References: <769202.55013.qm@web42108.mail.mud.yahoo.com> Message-ID: <6bb5f5b10812182156u78ef79f6g8ac17d5c6db7fd75@mail.gmail.com> As Arbor bought Ellacoya and entered the service control business, Allot striked back buying Esphion, and it's now called Allot ServiceProtector. I haven't tested any of those. Rubens On Thu, Dec 18, 2008 at 7:20 AM, andy lam wrote: > Recently I've been searching for something that is comparable to Arbor to see what else is out there. Someone suggested Narus. > > Anyone out there have an opinion regarding the 2 applications and their differences? Or another application that is worth noting? > > I am currently using Arbor Peakflow for Netflow analysis against my peering/transit traffic and their Security suite to identify DoS, etc at the edge. > > Feel free to contact off-list. > > Thanks > > > > From bmanning at vacation.karoshi.com Fri Dec 19 00:08:44 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 19 Dec 2008 06:08:44 +0000 Subject: What is the most standard subnet length on internet In-Reply-To: <11527796.20751229654447763.JavaMail.weblogic@epml12> References: <11527796.20751229654447763.JavaMail.weblogic@epml12> Message-ID: <20081219060844.GA3686@vacation.karoshi.com.> On Fri, Dec 19, 2008 at 02:40:47AM +0000, l l9l wrote: > However, what I am really wondering is what is the most standard subnet length that always can be guaranteed through Internet. less than /24 bit ? > while one can get away w/ /24s (if that is all one has) for many places, I suspect that there will be increasing pressure to drop more specific /24s as folks routing tables grow. your question, "...length that can be guaranteed through the Internet." argues for fairly short netmasks, e.g. a /16 is likley to be accepted by most folks while very short masks, e.g. /8 or smaller are likly to be seen with some level of consideration since so very few prefixes of that size are likely to be origin-sourced (often proxy aggregates from transit parties)... as others have pointed out - this "acceptable" value is fluid, changing over time and variable between ISPs. Creating a static policy is likely to be flawed. --bill (crawling out from under his rock, blinking in the bright lights) From andy at nosignal.org Fri Dec 19 02:45:36 2008 From: andy at nosignal.org (Andy Davidson) Date: Fri, 19 Dec 2008 08:45:36 +0000 Subject: What is the most standard subnet length on internet In-Reply-To: <15850784.26571229661837046.JavaMail.weblogic@epml12> References: <15850784.26571229661837046.JavaMail.weblogic@epml12> Message-ID: <00F3404A-4787-44E1-99CF-79275ABD053D@nosignal.org> On 19 Dec 2008, at 04:43, ??? wrote: > It seems so simple. Currently annoucement of /24 seems to be okey, > most upstream providers accept this. > However I wonder if there is any ground rule based on any standard > or official recommandation. The only rule is "my network, my rules" ;-) But if general rules did exist, they might say 1) not to announce smaller than a /24 to external parties without agreement, and 2) not to carve up registry assigned address blocks into individual announcements. 1 - You might announce your registry assigned block, AND deaggregated blocks to upstreams or peers for traffic engineering purposes, but you need to work closely with them to make sure that they don't filter the deaggs from your session, and also to make sure they don't onwardly announce the deaggs). 2 - The default free routing table is 270,000 entries large, and this is too big for lots of kit, so networks ARE FILTERING TODAY on registry boundaries. If you don't understand the implications of this do not deaggregate the addresses that the registry assign you. Good luck with your project. Drop me a note offlist if you need specific advice. Andy From cidr-report at potaroo.net Fri Dec 19 05:00:04 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 19 Dec 2008 22:00:04 +1100 (EST) Subject: BGP Update Report Message-ID: <200812191100.mBJB04xJ071372@wattle.apnic.net> BGP Update Report Interval: 05-Nov-08 -to- 06-Dec-08 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4538 232133 1.9% 45.7 -- ERX-CERNET-BKB China Education and Research Network Center 2 - AS9583 228435 1.9% 180.9 -- SIFY-AS-IN Sify Limited 3 - AS6389 130689 1.1% 29.6 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 4 - AS29282 101489 0.8% 33829.7 -- EMENTOR-AS Enfo Oyj 5 - AS1803 94573 0.8% 66.6 -- ICMNET-5 - Sprint 6 - AS6629 84972 0.7% 1307.3 -- NOAA-AS - NOAA 7 - AS6298 83856 0.7% 38.4 -- ASN-CXA-PH-6298-CBS - Cox Communications Inc. 8 - AS24863 83220 0.7% 121.8 -- LINKdotNET-AS 9 - AS8151 73001 0.6% 33.2 -- Uninet S.A. de C.V. 10 - AS209 71988 0.6% 23.2 -- ASN-QWEST - Qwest Communications Corporation 11 - AS20115 63026 0.5% 30.4 -- CHARTER-NET-HKY-NC - Charter Communications 12 - AS6478 61690 0.5% 35.2 -- ATT-INTERNET3 - AT&T WorldNet Services 13 - AS4323 54750 0.5% 12.9 -- TWTC - tw telecom holdings, inc. 14 - AS6458 54576 0.5% 121.8 -- Telgua 15 - AS7643 52459 0.4% 32.4 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 16 - AS2386 51415 0.4% 31.0 -- INS-AS - AT&T Data Communications Services 17 - AS3462 49113 0.4% 244.3 -- HINET Data Communication Business Group 18 - AS17488 48606 0.4% 33.4 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 19 - AS1785 45555 0.4% 26.6 -- AS-PAETEC-NET - PaeTec Communications, Inc. 20 - AS35805 42761 0.3% 206.6 -- UTG-AS United Telecom AS TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS29282 101489 0.8% 33829.7 -- EMENTOR-AS Enfo Oyj 2 - AS14106 32024 0.3% 16012.0 -- LEPMED01 - Leprechaun, LLC 3 - AS30287 4928 0.0% 4928.0 -- ALON-USA - ALON USA, LP 4 - AS30306 19541 0.2% 3908.2 -- AfOL-Sz-AS 5 - AS41007 18540 0.1% 3708.0 -- CTCASTANA CTC ASTANA, KZ 6 - AS46115 36509 0.3% 3650.9 -- LUTHER - Luther College 7 - AS4130 16771 0.1% 3354.2 -- UPITT-AS - University of Pittsburgh 8 - AS32398 26554 0.2% 3319.2 -- REALNET-ASN-1 9 - AS15561 2969 0.0% 2969.0 -- CDS-ITALY C.D.S. Informatica S.r.l. 10 - AS23917 2755 0.0% 2755.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 11 - AS47731 2735 0.0% 2735.0 -- ISDC-AS SC ISDC ROMANIA SRL 12 - AS30969 21860 0.2% 2732.5 -- TAN-NET TransAfrica Networks 13 - AS5033 21730 0.2% 2414.4 -- ISW - Internet Specialties West Inc. 14 - AS28519 7180 0.1% 2393.3 -- Universidad Autonoma de Guadalajara 15 - AS43925 4293 0.0% 2146.5 -- MOLDCELL_AS Moldcell SA Autonomous System 16 - AS48131 2096 0.0% 2096.0 -- VANGUARD-BG-AS Vanguard SA 17 - AS31901 2083 0.0% 2083.0 -- THECHIMES - The Chimes, Inc. 18 - AS25799 2000 0.0% 2000.0 -- HOLMAN - Holman Enterprises 19 - AS19017 1988 0.0% 1988.0 -- QUALCOMM-QWBS-LV - Qualcomm Wireless Business Solutions 20 - AS149 1725 0.0% 1725.0 -- DNIC - DoD Network Information Center TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 77.95.144.0/22 71003 0.6% AS29282 -- EMENTOR-AS Enfo Oyj 2 - 221.134.222.0/24 60022 0.5% AS9583 -- SIFY-AS-IN Sify Limited 3 - 210.214.151.0/24 58695 0.5% AS9583 -- SIFY-AS-IN Sify Limited 4 - 221.135.80.0/24 38881 0.3% AS9583 -- SIFY-AS-IN Sify Limited 5 - 124.7.201.0/24 34334 0.3% AS9583 -- SIFY-AS-IN Sify Limited 6 - 217.69.48.0/20 30450 0.2% AS29282 -- EMENTOR-AS Enfo Oyj 7 - 192.102.88.0/24 27094 0.2% AS6629 -- NOAA-AS - NOAA 8 - 192.35.129.0/24 26804 0.2% AS6629 -- NOAA-AS - NOAA 9 - 198.77.177.0/24 26722 0.2% AS6629 -- NOAA-AS - NOAA 10 - 41.204.2.0/24 25863 0.2% AS32398 -- REALNET-ASN-1 11 - 64.162.116.0/24 21556 0.2% AS5033 -- ISW - Internet Specialties West Inc. 12 - 8.192.154.0/24 17463 0.1% AS14106 -- LEPMED01 - Leprechaun, LLC 13 - 150.212.224.0/19 16681 0.1% AS4130 -- UPITT-AS - University of Pittsburgh 14 - 192.12.120.0/24 16423 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 15 - 65.44.76.0/24 14561 0.1% AS14106 -- LEPMED01 - Leprechaun, LLC 16 - 89.4.131.0/24 11665 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 17 - 203.63.26.0/24 11403 0.1% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 18 - 196.27.104.0/21 10553 0.1% AS30969 -- TAN-NET TransAfrica Networks 19 - 196.27.108.0/22 10508 0.1% AS30969 -- TAN-NET TransAfrica Networks 20 - 195.189.68.0/24 9247 0.1% AS41007 -- CTCASTANA CTC ASTANA, KZ Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Dec 19 05:00:02 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 19 Dec 2008 22:00:02 +1100 (EST) Subject: The Cidr Report Message-ID: <200812191100.mBJB02FZ071362@wattle.apnic.net> This report has been generated at Fri Dec 19 21:19:34 2008 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 12-12-08 282624 173848 13-12-08 282898 173838 14-12-08 282975 173850 15-12-08 282781 174282 16-12-08 283153 174958 17-12-08 283693 175193 18-12-08 284094 175932 19-12-08 284488 176119 AS Summary 30262 Number of ASes in routing system 12884 Number of ASes announcing only one prefix 4398 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89820672 Largest address span announced by an AS (/32s) AS27064: DDN-ASNBLK1 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 19Dec08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 284867 176167 108700 38.2% All ASes AS6389 4398 370 4028 91.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4206 1720 2486 59.1% TWTC - tw telecom holdings, inc. AS209 2983 1320 1663 55.7% ASN-QWEST - Qwest Communications Corporation AS4766 1659 480 1179 71.1% KIXS-AS-KR Korea Telecom AS17488 1442 323 1119 77.6% HATHWAY-NET-AP Hathway IP Over Cable Internet AS1785 1706 708 998 58.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1184 205 979 82.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 995 62 933 93.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1406 532 874 62.2% Uninet S.A. de C.V. AS6478 1633 825 808 49.5% ATT-INTERNET3 - AT&T WorldNet Services AS11492 1230 454 776 63.1% CABLEONE - CABLE ONE, INC. AS18101 786 100 686 87.3% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS19262 941 257 684 72.7% VZGNI-TRANSIT - Verizon Internet Services Inc. AS2386 1587 905 682 43.0% INS-AS - AT&T Data Communications Services AS3356 1096 452 644 58.8% LEVEL3 Level 3 Communications AS18566 1060 478 582 54.9% COVAD - Covad Communications Co. AS2706 543 21 522 96.1% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS7545 676 170 506 74.9% TPG-INTERNET-AP TPG Internet Pty Ltd AS855 598 131 467 78.1% CANET-ASN-4 - Bell Aliant AS4808 624 157 467 74.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS17676 522 64 458 87.7% GIGAINFRA BB TECHNOLOGY Corp. AS24560 634 178 456 71.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4134 901 452 449 49.8% CHINANET-BACKBONE No.31,Jin-rong Street AS9443 525 84 441 84.0% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7018 1438 998 440 30.6% ATT-INTERNET4 - AT&T WorldNet Services AS22047 565 127 438 77.5% VTR BANDA ANCHA S.A. AS20115 1854 1432 422 22.8% CHARTER-NET-HKY-NC - Charter Communications AS4668 691 278 413 59.8% LGNET-AS-KR LG CNS AS4780 729 327 402 55.1% SEEDNET Digital United Inc. AS7011 927 536 391 42.2% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. Total 39539 14146 25393 64.2% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 62.61.220.0/23 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 87.244.128.0/18 AS8733 CHELLO-BELGIUM UPC Belgium - Chello Belgium 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 100.10.10.0/24 AS14000 AXTEL, S.A. de C.V. 119.31.232.0/21 AS38870 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 124.0.0.0/8 AS17550 SMC-AS-AP San Miguel Corporation 124.109.16.0/21 AS38137 137.0.0.0/13 AS27064 DDN-ASNBLK1 - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 193.9.26.0/24 AS12594 EXTERNET-AS EXTERNET Autonomus System 193.23.136.0/23 AS43711 SZERVERNET-HU-AS Szervernet Ltd. 193.23.142.0/24 AS47885 HOSTOFFICE-AS HostOffice Kft. 194.0.68.0/22 AS41704 OGS-AS ZAO "Orenburgskaya Gorodskaya Set", Orenburg, Russia 195.190.146.0/24 AS9167 WEBPARTNER WEBPARTNER A/S is a Danish Internet Service Provider 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.80.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.0.187.0/24 AS19132 200.5.32.0/21 AS19132 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.58.224.0/19 AS17925 202.58.224.0/20 AS17925 202.58.240.0/20 AS17925 202.58.240.0/24 AS17925 202.58.244.0/24 AS17925 202.58.249.0/24 AS17925 202.58.250.0/24 AS17925 202.58.253.0/24 AS17925 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.42.0/24 AS38205 202.72.46.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.122.120.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.56.0/24 AS38722 202.150.57.0/24 AS38722 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications Ltd 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.48.32.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.229.51.0/24 AS15211 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From patrick at ianai.net Fri Dec 19 06:07:08 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 19 Dec 2008 07:07:08 -0500 Subject: What is the most standard subnet length on internet In-Reply-To: References: <15850784.26571229661837046.JavaMail.weblogic@epml12> <56F5BC5F404CF84896C447397A1AAF20B0F7D4@MAIL.nosi.netos.com> Message-ID: On Dec 19, 2008, at 12:27 AM, Suresh Ramasubramanian wrote: > Even if a longer prefix like a /24 is announced, chances of people > accepting it is slim. Especially, as you say, if the RIR allocation > is something larger than /24 > > And I have a feeling acceptance /24 route announcements of anything > other than legacy classful space, infrastructure space like the root > servers is going to be patchy at best. If you are worried about /24s (and I really don't think you need to worry that much), just announce the covering CIDR somewhere and the few places that don't hear the /24 will send packets "at" the shorter prefix. Since routing is hop-based, as soon as the packet reaches an AS that hears the /24, the packet will be forwarded to the correct destination. I know from personal experience this works perfectly well today. But in all seriousness, /24s are close to universally heard. Networks used to filter them, but by and large, they went away or changed their policy. Of course, there are hold-outs, but most corporations which own networks realize that the Internet is a tool to make money, not prove or disprove some random technical argument on NANOG. Listening to /24s make most networks money (either directly by giving them more traffic for which they charge their downstreams, or indirectly by having networks - like mine - stop using them if they don't), ... well, the rest is left as an exercise for the reader. As for routing table size, no router which can handle 10s of Gbps is at all bothered by the size of the global table, so only edge devices or stub networks are in danger of needing to filter /24s. And both of those can (should?) have something called a "default route", making it completely irrelevant whether they hear the /24s anyway. -- TTFN, patrick > 2008/12/19 Darryl Dunkin : >> >> If you are allocated a /22, announce the /22. Do not announce >> anything longer unless you have a requirement to (such as a >> different origin AS). If you are further allocating a subset of >> that to a downstream, then a /24 out of that is acceptable as the >> origin will be different. >> > From patrick at ianai.net Fri Dec 19 06:07:26 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 19 Dec 2008 07:07:26 -0500 Subject: What is the most standard subnet length on internet In-Reply-To: <56F5BC5F404CF84896C447397A1AAF20B0F7D4@MAIL.nosi.netos.com> References: <15850784.26571229661837046.JavaMail.weblogic@epml12> <56F5BC5F404CF84896C447397A1AAF20B0F7D4@MAIL.nosi.netos.com> Message-ID: Even if a longer prefix like a /24 is announced, chances of people accepting it is slim. Especially, as you say, if the RIR allocation is something larger than /24 And I have a feeling acceptance /24 route announcements of anything other than legacy classful space, infrastructure space like the root servers is going to be patchy at best. 2008/12/19 Darryl Dunkin : > > If you are allocated a /22, announce the /22. Do not announce > anything longer unless you have a requirement to (such as a > different origin AS). If you are further allocating a subset of that > to a downstream, then a /24 out of that is acceptable as the origin > will be different. > From hcb at netcases.net Fri Dec 19 09:36:27 2008 From: hcb at netcases.net (Howard C. Berkowitz) Date: Fri, 19 Dec 2008 10:36:27 -0500 (EST) Subject: Fwd: Re: Re: What is the most standard subnet length on internet In-Reply-To: <7042375.27731229662894079.JavaMail.weblogic@epml12> References: <7042375.27731229662894079.JavaMail.weblogic@epml12> Message-ID: <1464.76.118.12.107.1229700987.squirrel@webmail4.pair.com> I may not completely understand your concerns, especially about customers moving. I would, however, strongly encouraging not using the terms A,B or C in NANOG discussions; I've found they lead to assumptions based on obsolete ideas. Let's assume an enterprise has had one transit provider, who is in the default-free zone. Working together, the customer and provider agreed the customer needed a /23, and the provider assigns 1.0.0.0/23 as a PA subpart of its own space. 1.0.0.0/8. Using RFC 1998 techniques, for load sharing at four POPs of that same provider, that customer then announces, at each POP, a /25 reflecting the /25 used for machines in the local area of that POP, but also announces the /23. With a single provider, the RFC1998 method applies, and the routes announced are tagged with NO-EXPORT. As long as the enterprise is not multihomed, its more-specifics will be handled properly by provider A's announcement of 1.0.0.0/8? Now, assume that customer gets a single link to a different provider B, whose PI space is 2.0.0.0/8. For multihoming to work, at least two things start to happen. Both providers A and B need to announce 1.0.0.0/23 to the rest of the Internet. If only provider B advertised (2.0.0.0/8, 1.0.0.0/23) to the rest of the internet, all traffic to the enterprise would come through provider B, because it announces a more-specific. For the traffic to work, BOTH A and B have to announce 1.0.0.0/23, so other providers, with full routes, spread load to the two providers. The enterprise can still announce both /23 and /25 to Provider A, with NO-EXPORT on the /25's, because Provider A can make use of the /25 to better manage traffic to its POPs. Administratively, Providers A and B have to agree to Provider B advertising a piece of Provider A's space. Am I answering the question you are asking? ?????? wrote: > "You have to change your server's IP address if you want move your server > to other place" > > -> It is very natural case, but some customer could think of it will be > okey to move if they have C class. > but I have different idea. because the border router of that center is > annoucing more greater IP block, > and if customer move to other center with C class, then I have to newly > announce that C class at the border router of other center. > and then it is the time my hierachy structure is broken. > To prevent this situation, I'm trying to find some standard material every > person would understand and accept. > > ============================================= > Chi-Young Joung > SAMSUNG NETWORKS Inc. > Email: lionair at samsung.com > Tel +82 70 7015 0623, Mobile +82 17 520 9193 > Fax +82 70 7016 0031 > ============================================= > > ------- Original Message ------- > Sender : ?????? ????/????1??/???????????? > Date : 2008-12-19 13:43 (GMT+09:00) > Title : Re: Re: What is the most standard subnet length on internet > > Suresh, > > Yes, I guess my concern is close to the second meaning. > > It seems so simple. Currently annoucement of /24 seems to be okey, most > upstream providers accept this. > However I wonder if there is any ground rule based on any standard or > official recommandation. > If there is some standardized rule about prefix length to be annouced, I > will make my bgp & IP allocation policy of > each data center of my company, and I will be able to more fairly and > squarely speak to my customer like this > "You have to change your server's IP address if you want move your server > to other place" > > chiyoung > ============================================= > Chi-Young Joung > SAMSUNG NETWORKS Inc. > Email: lionair at samsung.com > Tel +82 70 7015 0623, Mobile +82 17 520 9193 > Fax +82 70 7016 0031 > ============================================= > > ------- Original Message ------- > Sender : Suresh Ramasubramanian > Date : 2008-12-19 12:37 (GMT+09:00) > Title : Re: What is the most standard subnet length on internet > > Chi Young, let me clarify one thing here .. > > Do you mean IP allocation as in subnet allocation, swipping in apnic > or through a rwhois server etc? > > Or do you mean "what is the minimum subnet size I can announce on the > internet and have other providers not drop it on the floor"? > > srs > > On Fri, Dec 19, 2008 at 8:10 AM, ?????? wrote: >> Hi everyone, >> >> I'm going to rebuild IP allocation policy of my company and I am looking >> for some standard reference for my policy. >> I have already studied some standard like RFC1518, RIPE181, RFC2050 and >> I got it is very important to maintain hierachy structure. >> However, what I am really wondering is what is the most standard subnet >> length that always can be guaranteed through Internet. less than /24 bit >> ? >> I could not find any documents about that, which subnet length is most >> proper value and pursue internet standard policy ? >> > > > > > From jgreco at ns.sol.net Fri Dec 19 09:48:50 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 19 Dec 2008 09:48:50 -0600 (CST) Subject: What is the most standard subnet length on internet In-Reply-To: from "Patrick W. Gilmore" at Dec 19, 2008 07:07:08 AM Message-ID: <200812191548.mBJFmoFP029058@aurora.sol.net> > As for routing table size, no router which can handle 10s of Gbps is > at all bothered by the size of the global table, ... as long as it isn't something like a Cisco Catalyst 6509 with SUP720 and doesn't have a PFC3BXL helping out ... ... or if we conveniently don't classify a Catalyst 65xx as a router because it was primarily intended as a switch, despite how ISP's commonly use them ... > so only edge devices > or stub networks are in danger of needing to filter /24s. And both of > those can (should?) have something called a "default route", making it > completely irrelevant whether they hear the /24s anyway. A more accurate statement is probably that "any router that can handle 10s of Gbps is likely to be available in a configuration that is not at all bothered by the current size of the global table, most likely at some substantial additional cost." ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jabley at hopcount.ca Fri Dec 19 09:53:48 2008 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 19 Dec 2008 10:53:48 -0500 Subject: What is the most standard subnet length on internet In-Reply-To: References: <15850784.26571229661837046.JavaMail.weblogic@epml12> <56F5BC5F404CF84896C447397A1AAF20B0F7D4@MAIL.nosi.netos.com> Message-ID: On 2008-12-19, at 00:27, Suresh Ramasubramanian wrote: > Even if a longer prefix like a /24 is announced, chances of people > accepting it is slim. Especially, as you say, if the RIR allocation > is something larger than /24 I think in practice that's over-stating the problem. If an RIR assigns you a /22, the chances are good it has been assigned from some larger block which is also used to assign longer prefixes, down to whatever the RIR's minimum is (e.g. /24 under common critical infrastructure policies). While it's possible to imagine someone re-parsing a full set of all RIR data every day and rolling out martian filters to all border routers based on precisely what assignments have been made, that someone would incur that operational cost in the face of what is a fairly slim benefit seems unlikely. More likely that someone would filter based on the longest assignment made in a particular /8 (e.g. in 202/7, 199/8 we might expect to see / 24s, in 76/8 not so much, etc). Even more likely than that is that people might filter out obvious RFC3330-style martians and permit everything else up to a /24. > And I have a feeling acceptance /24 route announcements of anything > other than legacy classful space, infrastructure space like the root > servers is going to be patchy at best. We're both speculating, of course. It'd be nice if some grad student somewhere with friends in the operations community was to experiment with /24s carved out of larger blocks from all over the planet and present some empirical data. Joe From nanog-post at rsuc.gweep.net Fri Dec 19 10:56:28 2008 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Fri, 19 Dec 2008 11:56:28 -0500 Subject: What is the most standard subnet length on internet In-Reply-To: References: <15850784.26571229661837046.JavaMail.weblogic@epml12> <56F5BC5F404CF84896C447397A1AAF20B0F7D4@MAIL.nosi.netos.com> Message-ID: <20081219165628.GA87519@gweep.net> [cf http://www.merit.edu/mail.archives/nanog/msg12684.html and related past threads] On Fri, Dec 19, 2008 at 10:53:48AM -0500, Joe Abley wrote: [snip] > More likely that someone would filter based on the longest assignment > made in a particular /8 (e.g. in 202/7, 199/8 we might expect to see / > 24s, in 76/8 not so much, etc). This matches my past experience, and it is often the case that an entity is slow to revist specific /8s when RIR policies change... [snip] > It'd be nice if some grad student somewhere with friends in the > operations community was to experiment with /24s carved out of larger > blocks from all over the planet and present some empirical data. We do know that filters come and filters go, and the policies most likely reflect who can afford what level of RIB storage across how large a DFZ folks maintain within their own ASN. I wonder if like hemlines, RIB storage capacity is an indirect economic indicator... In lieu of detailed data reporting, being as conservative as you can about contributing to the mess while being liberal as you can [fit into your budget cycles] in receiving the mess is a long-honoured, functional ops stance. :-) Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From ops.lists at gmail.com Fri Dec 19 11:17:57 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 19 Dec 2008 22:47:57 +0530 Subject: Cap'n Bubba the marine backhoe driver - SEA-ME-WE 3 and 4, FLAG cut Message-ID: On Dave Farber's IP list. > > From: France Telecom / Press > To: France Telecom / Press > Subject: Three undersea cables cut: traffic greatly disturbed between > Europe and Asia/Near East zone > Date: Fri, 19 Dec 2008 17:09:03 +0100 (CET) > X-Concentric-MX-Info: s=0AKNHR84D300:1 ts=0 td=53 dt=0 tro=1 tra=2 > trb=1 sro=1 sra=2 ic=0 > X-Concentric-DKIM: SigStatus="No signature", PolSusp="No", > PolTest="No", Policy="none", Handling="none" > X-Virus-Status: No > > If you can't read this email, please go to : http://www.orange.com/en_EN/press/press_releases/cp081219en.html > Paris, December 19, 2008 > Three undersea cables cut: traffic greatly disturbed between Europe and > Asia/Near East zone > > 3 cables cut this morning (Sea Me We3 partly + Sea Me We4 + FLAG) > France Telecom Marine cable ship about to depart > > France Telecom observed today that 3 major underwater cables were cut: > ?Sea Me We 4? at 7:28am, ?Sea Me We3? at 7:33am and FLAG at 8:06am. > The causes of the cut, which is located in the Mediterranean between > Sicily and Tunisia, on sections linking Sicily to Egypt, remain > unclear. > > Most of the B to B traffic between Europe and Asia is rerouted through > the USA. > Traffic from Europe to Algeria and Tunisia is not affected, but traffic > from Europe to the Near East and Asia is interrupted to a greater or > lesser extent (see country list below). > Part of the internet traffic towards R?union is affected as well as 50% > towards Jordan. > A first appraisal at 7:44 am UTC gave an estimate of the following > impact on the voice traffic (in percentage of out of service capacity): > - Saudi Arabia: 55% out of service > - Djibouti: 71% out of service > - Egypt: 52% out of service > - United Arab Emirates: 68% out of service > - India: 82% out of service > - Lebanon: 16% out of service > - Malaysia: 42% out of service > - Maldives: 100% out of service > - Pakistan: 51% out of service > - Qatar: 73% out of service > - Syria: 36% out of service > - Taiwan: 39% out of service > - Yemen: 38% out of service > - Zambia: 62% out of service > > France Telecom immediately alerted one of the two maintenance boats > based in the Mediterranean area, the ?Raymond Croze?. This France > Telecom Marine cable ship based at Seyne-sur-Mer has received its > mobilization order early this afternoon and will cast off tonight at > 3:00 am with 20 kilometers spare cable on board. It should be on > location on Monday morning for a relief mission. > Priority will be given to the recovery of the Sea Me We4 cable, then on > the Sea Me We3. > By December 25th, Sea Me We4 could be operating. By December 31st, the > situation should be back to normal. > > > download all the press release > press contactsLouis-Michel Aymard ? +33 1 44 44 93 93 > latest releasespress information and communication professionals From hannigan at gmail.com Fri Dec 19 11:21:48 2008 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 19 Dec 2008 12:21:48 -0500 Subject: Cap'n Bubba the marine backhoe driver - SEA-ME-WE 3 and 4, FLAG cut In-Reply-To: References: Message-ID: <2d106eb50812190921q4b65045dp54ae48fb9be3afe1@mail.gmail.com> Yep. I wonder if anyone learned from the last event: http://www.fiercetelecom.com/story/middle-east-undersea-cable-cuts-strike-again/2008-12-19 On Fri, Dec 19, 2008 at 12:17 PM, Suresh Ramasubramanian wrote: > On Dave Farber's IP list. > >> >> From: France Telecom / Press >> To: France Telecom / Press >> Subject: Three undersea cables cut: traffic greatly disturbed between >> Europe and Asia/Near East zone >> Date: Fri, 19 Dec 2008 17:09:03 +0100 (CET) >> X-Concentric-MX-Info: s=0AKNHR84D300:1 ts=0 td=53 dt=0 tro=1 tra=2 >> trb=1 sro=1 sra=2 ic=0 >> X-Concentric-DKIM: SigStatus="No signature", PolSusp="No", >> PolTest="No", Policy="none", Handling="none" >> X-Virus-Status: No >> >> If you can't read this email, please go to : http://www.orange.com/en_EN/press/press_releases/cp081219en.html >> Paris, December 19, 2008 >> Three undersea cables cut: traffic greatly disturbed between Europe and >> Asia/Near East zone >> >> 3 cables cut this morning (Sea Me We3 partly + Sea Me We4 + FLAG) >> France Telecom Marine cable ship about to depart >> >> France Telecom observed today that 3 major underwater cables were cut: >> ?Sea Me We 4? at 7:28am, ?Sea Me We3? at 7:33am and FLAG at 8:06am. >> The causes of the cut, which is located in the Mediterranean between >> Sicily and Tunisia, on sections linking Sicily to Egypt, remain >> unclear. >> >> Most of the B to B traffic between Europe and Asia is rerouted through >> the USA. >> Traffic from Europe to Algeria and Tunisia is not affected, but traffic >> from Europe to the Near East and Asia is interrupted to a greater or >> lesser extent (see country list below). >> Part of the internet traffic towards R?union is affected as well as 50% >> towards Jordan. >> A first appraisal at 7:44 am UTC gave an estimate of the following >> impact on the voice traffic (in percentage of out of service capacity): >> - Saudi Arabia: 55% out of service >> - Djibouti: 71% out of service >> - Egypt: 52% out of service >> - United Arab Emirates: 68% out of service >> - India: 82% out of service >> - Lebanon: 16% out of service >> - Malaysia: 42% out of service >> - Maldives: 100% out of service >> - Pakistan: 51% out of service >> - Qatar: 73% out of service >> - Syria: 36% out of service >> - Taiwan: 39% out of service >> - Yemen: 38% out of service >> - Zambia: 62% out of service >> >> France Telecom immediately alerted one of the two maintenance boats >> based in the Mediterranean area, the ?Raymond Croze?. This France >> Telecom Marine cable ship based at Seyne-sur-Mer has received its >> mobilization order early this afternoon and will cast off tonight at >> 3:00 am with 20 kilometers spare cable on board. It should be on >> location on Monday morning for a relief mission. >> Priority will be given to the recovery of the Sea Me We4 cable, then on >> the Sea Me We3. >> By December 25th, Sea Me We4 could be operating. By December 31st, the >> situation should be back to normal. >> >> >> download all the press release >> press contactsLouis-Michel Aymard ? +33 1 44 44 93 93 >> latest releasespress information and communication professionals > > From joshpotter at gmail.com Fri Dec 19 11:25:25 2008 From: joshpotter at gmail.com (Josh Potter) Date: Fri, 19 Dec 2008 11:25:25 -0600 Subject: Cap'n Bubba the marine backhoe driver - SEA-ME-WE 3 and 4, FLAG cut In-Reply-To: References: Message-ID: <4a64e2f70812190925l718993a5mbee7cca7bb72a182@mail.gmail.com> I would consider myself a very skilled precision underwater backhoe operator. On Fri, Dec 19, 2008 at 11:17 AM, Suresh Ramasubramanian < ops.lists at gmail.com> wrote: > On Dave Farber's IP list. > > > > > From: France Telecom / Press > > To: France Telecom / Press > > Subject: Three undersea cables cut: traffic greatly disturbed between > > Europe and Asia/Near East zone > > Date: Fri, 19 Dec 2008 17:09:03 +0100 (CET) > > X-Concentric-MX-Info: s=0AKNHR84D300:1 ts=0 td=53 dt=0 tro=1 tra=2 > > trb=1 sro=1 sra=2 ic=0 > > X-Concentric-DKIM: SigStatus="No signature", PolSusp="No", > > PolTest="No", Policy="none", Handling="none" > > X-Virus-Status: No > > > > If you can't read this email, please go to : > http://www.orange.com/en_EN/press/press_releases/cp081219en.html > > Paris, December 19, 2008 > > Three undersea cables cut: traffic greatly disturbed between Europe and > > Asia/Near East zone > > > > 3 cables cut this morning (Sea Me We3 partly + Sea Me We4 + FLAG) > > France Telecom Marine cable ship about to depart > > > > France Telecom observed today that 3 major underwater cables were cut: > > ?Sea Me We 4? at 7:28am, ?Sea Me We3? at 7:33am and FLAG at 8:06am. > > The causes of the cut, which is located in the Mediterranean between > > Sicily and Tunisia, on sections linking Sicily to Egypt, remain > > unclear. > > > > Most of the B to B traffic between Europe and Asia is rerouted through > > the USA. > > Traffic from Europe to Algeria and Tunisia is not affected, but traffic > > from Europe to the Near East and Asia is interrupted to a greater or > > lesser extent (see country list below). > > Part of the internet traffic towards R?union is affected as well as 50% > > towards Jordan. > > A first appraisal at 7:44 am UTC gave an estimate of the following > > impact on the voice traffic (in percentage of out of service capacity): > > - Saudi Arabia: 55% out of service > > - Djibouti: 71% out of service > > - Egypt: 52% out of service > > - United Arab Emirates: 68% out of service > > - India: 82% out of service > > - Lebanon: 16% out of service > > - Malaysia: 42% out of service > > - Maldives: 100% out of service > > - Pakistan: 51% out of service > > - Qatar: 73% out of service > > - Syria: 36% out of service > > - Taiwan: 39% out of service > > - Yemen: 38% out of service > > - Zambia: 62% out of service > > > > France Telecom immediately alerted one of the two maintenance boats > > based in the Mediterranean area, the ?Raymond Croze?. This France > > Telecom Marine cable ship based at Seyne-sur-Mer has received its > > mobilization order early this afternoon and will cast off tonight at > > 3:00 am with 20 kilometers spare cable on board. It should be on > > location on Monday morning for a relief mission. > > Priority will be given to the recovery of the Sea Me We4 cable, then on > > the Sea Me We3. > > By December 25th, Sea Me We4 could be operating. By December 31st, the > > situation should be back to normal. > > > > > > download all the press release > > press contactsLouis-Michel Aymard ? +33 1 44 44 93 93 > > latest releasespress information and communication professionals > > -- Josh Potter From eslerj at gmail.com Fri Dec 19 11:32:13 2008 From: eslerj at gmail.com (Joel Esler) Date: Fri, 19 Dec 2008 12:32:13 -0500 Subject: Cap'n Bubba the marine backhoe driver - SEA-ME-WE 3 and 4, FLAG cut In-Reply-To: References: Message-ID: I just posted an article about this on the Internet Storm Center, I have reports pouring in there as well. Joel (http://isc.sans.org) On Dec 19, 2008, at 12:17 PM, Suresh Ramasubramanian allegedly wrote: >> If you can't read this email, please go to :http://www.orange.com/en_EN/press/press_releases/cp081219en.html >> Paris, December 19, 2008 >> Three undersea cables cut: traffic greatly disturbed between Europe >> and >> Asia/Near East zone >> >> 3 cables cut this morning (Sea Me We3 partly + Sea Me We4 + FLAG) >> France Telecom Marine cable ship about to depart >> >> France Telecom observed today that 3 major underwater cables were >> cut: >> ?Sea Me We 4? at 7:28am, ?Sea Me We3? at 7:33am and FLAG at 8:06am. >> The causes of the cut, which is located in the Mediterranean between >> Sicily and Tunisia, on sections linking Sicily to Egypt, remain >> unclear. >> >> Most of the B to B traffic between Europe and Asia is rerouted >> through >> the USA. >> Traffic from Europe to Algeria and Tunisia is not affected, but >> traffic >> from Europe to the Near East and Asia is interrupted to a greater or >> lesser extent (see country list below). >> Part of the internet traffic towards R?union is affected as well as >> 50% >> towards Jordan. >> A first appraisal at 7:44 am UTC gave an estimate of the following >> impact on the voice traffic (in percentage of out of service >> capacity): >> - Saudi Arabia: 55% out of service >> - Djibouti: 71% out of service >> - Egypt: 52% out of service >> - United Arab Emirates: 68% out of service >> - India: 82% out of service >> - Lebanon: 16% out of service >> - Malaysia: 42% out of service >> - Maldives: 100% out of service >> - Pakistan: 51% out of service >> - Qatar: 73% out of service >> - Syria: 36% out of service >> - Taiwan: 39% out of service >> - Yemen: 38% out of service >> - Zambia: 62% out of service >> >> France Telecom immediately alerted one of the two maintenance boats >> based in the Mediterranean area, the ?Raymond Croze?. This France >> Telecom Marine cable ship based at Seyne-sur-Mer has received its >> mobilization order early this afternoon and will cast off tonight at >> 3:00 am with 20 kilometers spare cable on board. It should be on >> location on Monday morning for a relief mission. >> Priority will be given to the recovery of the Sea Me We4 cable, >> then on >> the Sea Me We3. >> By December 25th, Sea Me We4 could be operating. By December 31st, >> the >> situation should be back to normal. -- Joel Esler ? http://www.joelesler.net [m] From cscora at apnic.net Fri Dec 19 12:12:11 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 20 Dec 2008 04:12:11 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200812191812.mBJICBR4006914@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 20 Dec, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 275380 Prefixes after maximum aggregation: 131356 Deaggregation factor: 2.10 Unique aggregates announced to Internet: 132855 Total ASes present in the Internet Routing Table: 30108 Prefixes per ASN: 9.15 Origin-only ASes present in the Internet Routing Table: 26219 Origin ASes announcing only one prefix: 12782 Transit ASes present in the Internet Routing Table: 3889 Transit-only ASes present in the Internet Routing Table: 94 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 20 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 522 Unregistered ASNs in the Routing Table: 187 Number of 32-bit ASNs allocated by the RIRs: 68 Prefixes from 32-bit ASNs in the Routing Table: 12 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 259 Number of addresses announced to Internet: 1976219264 Equivalent to 117 /8s, 202 /16s and 182 /24s Percentage of available address space announced: 53.3 Percentage of allocated address space announced: 63.7 Percentage of available address space allocated: 83.7 Percentage of address space in use by end-sites: 75.0 Total number of prefixes smaller than registry allocations: 135179 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 63202 Total APNIC prefixes after maximum aggregation: 22693 APNIC Deaggregation factor: 2.79 Prefixes being announced from the APNIC address blocks: 60116 Unique aggregates announced from the APNIC address blocks: 25952 APNIC Region origin ASes present in the Internet Routing Table: 3494 APNIC Prefixes per ASN: 17.21 APNIC Region origin ASes announcing only one prefix: 952 APNIC Region transit ASes present in the Internet Routing Table: 535 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 17 Number of APNIC addresses announced to Internet: 393369248 Equivalent to 23 /8s, 114 /16s and 86 /24s Percentage of available APNIC address space announced: 78.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 122949 Total ARIN prefixes after maximum aggregation: 64542 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 92199 Unique aggregates announced from the ARIN address blocks: 35045 ARIN Region origin ASes present in the Internet Routing Table: 12660 ARIN Prefixes per ASN: 7.28 ARIN Region origin ASes announcing only one prefix: 4896 ARIN Region transit ASes present in the Internet Routing Table: 1212 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 20 Number of ARIN addresses announced to Internet: 405197088 Equivalent to 24 /8s, 38 /16s and 209 /24s Percentage of available ARIN address space announced: 83.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 62209 Total RIPE prefixes after maximum aggregation: 36644 RIPE Deaggregation factor: 1.70 Prefixes being announced from the RIPE address blocks: 56377 Unique aggregates announced from the RIPE address blocks: 37798 RIPE Region origin ASes present in the Internet Routing Table: 12375 RIPE Prefixes per ASN: 4.56 RIPE Region origin ASes announcing only one prefix: 6516 RIPE Region transit ASes present in the Internet Routing Table: 1866 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 17 Number of RIPE addresses announced to Internet: 382814560 Equivalent to 22 /8s, 209 /16s and 73 /24s Percentage of available RIPE address space announced: 87.8 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-49151 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 22976 Total LACNIC prefixes after maximum aggregation: 5628 LACNIC Deaggregation factor: 4.08 Prefixes being announced from the LACNIC address blocks: 21001 Unique aggregates announced from the LACNIC address blocks: 11591 LACNIC Region origin ASes present in the Internet Routing Table: 1042 LACNIC Prefixes per ASN: 20.15 LACNIC Region origin ASes announcing only one prefix: 337 LACNIC Region transit ASes present in the Internet Routing Table: 169 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 59214848 Equivalent to 3 /8s, 135 /16s and 140 /24s Percentage of available LACNIC address space announced: 58.8 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 3541 Total AfriNIC prefixes after maximum aggregation: 1429 AfriNIC Deaggregation factor: 2.48 Prefixes being announced from the AfriNIC address blocks: 5159 Unique aggregates announced from the AfriNIC address blocks: 1961 AfriNIC Region origin ASes present in the Internet Routing Table: 262 AfriNIC Prefixes per ASN: 19.69 AfriNIC Region origin ASes announcing only one prefix: 81 AfriNIC Region transit ASes present in the Internet Routing Table: 54 Average AfriNIC Region AS path length visible: 4.2 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 12454656 Equivalent to 0 /8s, 190 /16s and 11 /24s Percentage of available AfriNIC address space announced: 24.7 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1557 6409 364 Korea Telecom (KIX) 17488 1442 101 99 Hathway IP Over Cable Interne 4755 1174 475 153 TATA Communications formerly 4134 898 15543 356 CHINANET-BACKBONE 9583 871 133 81 Sify Limited 18101 786 168 33 Reliance Infocom Ltd Internet 4780 727 358 64 Digital United Inc. 9498 688 310 48 BHARTI BT INTERNET LTD. 7545 656 152 81 TPG Internet Pty Ltd 24560 635 210 164 Bharti Airtel Ltd. Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4383 3435 344 bellsouth.net, inc. 209 2847 4033 626 Qwest 20115 1849 1472 742 Charter Communications 1785 1706 717 155 PaeTec Communications, Inc. 4323 1611 1067 382 Time Warner Telecom 6478 1601 368 289 AT&T Worldnet Services 2386 1578 705 891 AT&T Data Communications Serv 7018 1436 5873 994 AT&T WorldNet Services 11492 1230 192 12 Cable One 3356 1104 10994 430 Level 3 Communications, LLC Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8452 1632 188 11 TEDATA 3292 434 1764 383 TDC Tele Danmark 30890 391 80 203 SC Kappa Invexim SRL 12479 377 578 6 Uni2 Autonomous System 3301 336 1413 303 TeliaNet Sweden 3320 333 7065 282 Deutsche Telekom AG 8866 331 109 22 Bulgarian Telecommunication C 29049 330 26 3 AzerSat LLC. 3215 321 2856 95 France Telecom Transpac 8551 303 287 35 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1406 2833 222 UniNet S.A. de C.V. 11830 667 299 9 Instituto Costarricense de El 10620 631 135 55 TVCABLE BOGOTA 22047 565 302 14 VTR PUNTO NET S.A. 7303 503 249 74 Telecom Argentina Stet-France 6471 429 86 43 ENTEL CHILE S.A. 16814 426 27 10 NSS, S.A. 11172 400 118 72 Servicios Alestra S.A de C.V 28573 365 491 24 NET Servicos de Comunicao S.A 7738 343 730 27 Telecomunicacoes da Bahia S.A Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 280 48 128 LINKdotNET AS number 3741 270 857 227 The Internet Solution 2018 239 215 140 Tertiary Education Network 6713 144 135 11 Itissalat Al-MAGHRIB 33783 143 10 17 EEPAD TISP TELECOM & INTERNET 29571 121 15 8 Ci Telecom Autonomous system 5536 120 8 17 Internet Egypt Network 5713 119 555 68 Telkom SA Ltd 33776 116 6 3 Starcomms Nigeria Limited 2905 80 177 76 Verizon South Africa Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4383 3435 344 bellsouth.net, inc. 209 2847 4033 626 Qwest 20115 1849 1472 742 Charter Communications 1785 1706 717 155 PaeTec Communications, Inc. 8452 1632 188 11 TEDATA 4323 1611 1067 382 Time Warner Telecom 6478 1601 368 289 AT&T Worldnet Services 2386 1578 705 891 AT&T Data Communications Serv 4766 1557 6409 364 Korea Telecom (KIX) 17488 1442 101 99 Hathway IP Over Cable Interne Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2847 2221 Qwest 8452 1632 1621 TEDATA 1785 1706 1551 PaeTec Communications, Inc. 17488 1442 1343 Hathway IP Over Cable Interne 6478 1601 1312 AT&T Worldnet Services 4323 1611 1229 Time Warner Telecom 11492 1230 1218 Cable One 4766 1557 1193 Korea Telecom (KIX) 8151 1406 1184 UniNet S.A. de C.V. 20115 1849 1107 Charter Communications Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.251.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:9 /10:20 /11:54 /12:159 /13:308 /14:559 /15:1096 /16:10268 /17:4512 /18:7750 /19:16644 /20:19464 /21:19076 /22:24169 /23:24653 /24:144536 /25:644 /26:807 /27:519 /28:97 /29:8 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2866 4383 bellsouth.net, inc. 209 1594 2847 Qwest 8452 1317 1632 TEDATA 4766 1292 1557 Korea Telecom (KIX) 2386 1260 1578 AT&T Data Communications Serv 17488 1232 1442 Hathway IP Over Cable Interne 11492 1200 1230 Cable One 1785 1166 1706 PaeTec Communications, Inc. 6478 1129 1601 AT&T Worldnet Services 18566 1041 1060 Covad Communications Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:12 8:170 12:2225 13:2 15:21 16:3 17:5 20:36 24:1107 32:54 38:525 40:96 41:1772 43:1 44:2 47:9 52:3 55:3 56:3 57:26 58:518 59:595 60:456 61:1094 62:1016 63:2002 64:3406 65:2445 66:3607 67:1439 68:655 69:2374 70:530 71:173 72:1597 73:7 74:1335 75:191 76:306 77:853 78:511 79:299 80:920 81:907 82:537 83:392 84:410 85:1036 86:494 87:655 88:350 89:1363 90:45 91:1796 92:298 93:1052 94:837 95:106 96:95 97:150 98:172 99:10 100:1 110:1 111:1 113:52 114:144 115:166 116:1069 117:416 118:234 119:578 120:116 121:699 122:895 123:435 124:790 125:1273 128:359 129:219 130:135 131:408 132:72 133:9 134:193 135:33 136:225 137:131 138:144 139:91 140:412 141:110 142:389 143:296 144:309 145:53 146:371 147:143 148:610 149:219 150:140 151:209 152:149 153:131 154:10 155:249 156:167 157:304 158:164 159:300 160:274 161:131 162:254 163:146 164:515 165:500 166:364 167:348 168:669 169:159 170:459 171:38 172:10 173:128 174:11 187:16 188:1 189:356 190:2542 192:5822 193:4145 194:3298 195:2631 196:1205 198:3710 199:3315 200:5584 201:1504 202:7780 203:8068 204:3930 205:2128 206:2319 207:2761 208:3794 209:3494 210:2688 211:1132 212:1501 213:1583 214:62 215:26 216:4498 217:1201 218:379 219:405 220:1220 221:400 222:299 End of report From aaronh at bind.com Fri Dec 19 12:40:02 2008 From: aaronh at bind.com (Aaron Hughes) Date: Fri, 19 Dec 2008 10:40:02 -0800 Subject: Peering Personals BoF NANOG45, Attention Peering Coordinators Message-ID: <20081219184002.GD1192@trace.bind.com> Peering Coordinators, Reminder: The deadline is approaching quickly and thus far, I have 4 companies that would like to introduce themselves. Please be sure to send me your info if you are interested in introducing yourself or your network to the greater peering community. For those of you who may be thinking . o O ("I've got until the end of the month"), please keep in mind that for many of you, today is that day with vacation time / the holidays. So please spend 30 seconds sending the form to me today. :) Thank you fellow peers! Cheers, Aaron > Attention Peering Coordinators, > > NANOG45 is approaching quickly and it's time to get our Peering Personals participants lined up for the Peering BoF. > > Peering Personals is part of the Peering BoF (Birds Of a Feather) session and provides a forum for Peering Coordinators to meet each other with the goal of establishing peering relationships. > > Participating Peering Coordinators will complete and email the form below to the Peering BOF moderator in advance of the BOF. > > Peering Coordinators will have ~two minutes at the BOF to introduce themselves, their networks, where they currently peer and where they intend to be peering in the next several months, a little bit about what they require of potential peers and what they are looking for in a peering candidate. Peering Coordinators who would like to participate in Peering Introductions should e-mail the following information to aaronh at bind.com with the subject of "NANOG 45 Peering BOF" no later than Dec 31, 2008.: > > Name: _____________________ > Company:__________________ > AS#: _____________________ > Email Address: ________________ > Peering Locations Today: __________________ > Peering Locations in the next 3-6 months: ________________ > Is your network more Content-Heavy or Access-Heavy ? > Do you source/sink more than 5Gbps of traffic? > Do you require Contracts for Peering? > Do you have an "Open Peering Policy (meaning you will peer with anyone in any single location), "Selective Peering Policy (meaning you will peer but have some prerequisites that must be met first)?, or "Restrictive Peering Policy (meaning you generally will not peer with anybody else)?" > > If you have any questions, don't hesitate to send me an e-mail. > > Cheers, > > Aaron > > -- > > Aaron Hughes > aaronh at bind.com > (703) 244-0427 > Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 > http://www.bind.com/ -- Aaron Hughes aaronh at bind.com (703) 244-0427 Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 http://www.bind.com/ From jgreco at ns.sol.net Fri Dec 19 15:15:04 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 19 Dec 2008 15:15:04 -0600 (CST) Subject: Gigabit Linux Routers In-Reply-To: from "Ingo Flaschberger" at Dec 18, 2008 07:13:07 PM Message-ID: <200812192115.mBJLF44v042360@aurora.sol.net> > Dear Joe, > > Several different traffic shaping strategies are available, and I think > > all of them go far beyond "simple". > > ipfw 100 add pipe 1 all from 192.168.0.0/24 to any xmit vlan1 > ipfw pipe 1 config bw 95Mbit/s queue 200Kbytes > > thats simple. Yes, but the point was that the feature was listed as "simple traffic shaping." You can do *complicated* traffic shaping too, which was the reason I commented on that. Usually the ability to do complicated traffic shaping means you can do simple traffic shaping too. ;-) > >> cons: only 1 route for each network, vrrp failover is not easy to > >> implement with quagga and ospf, no multipath routing > > > > carp seems easy to implement, even with quagga and ospf. At least, it's > > set up on a lab setup here and everything appears to work as expected. > > example setup: > > A----(ospf)---B > \ / > \ / > \ / > \ / > \ / > lan1 > > A and B share 1 virtual ip for lan1 (192.168.0.1/24). > problems: > *) only 1 ip-net supported (no aliases) So, you want, what, like multiple aliases on the network? I just tried adding an alias with the normal alias syntax, and it looks to work. rtr0# ifconfig vlan20; ifconfig carp20 vlan20: flags=8943 metric 0 mtu 1500 options=3 ether 00:04:23:b7:8e:08 inet 206.55.68.194 netmask 0xffffffe0 broadcast 206.55.68.223 media: Ethernet autoselect status: active vlan: 20 parent interface: lagg0 carp20: flags=49 metric 0 mtu 1500 inet 206.55.68.193 netmask 0xffffffe0 inet 206.55.68.196 netmask 0xffffffff carp: BACKUP vhid 1 advbase 1 advskew 0 rtr1# ifconfig vlan20; ifconfig carp20 vlan20: flags=8943 metric 0 mtu 1500 ether 00:80:c8:cd:43:1d inet 206.55.68.195 netmask 0xffffffe0 broadcast 206.55.68.223 media: Ethernet autoselect status: active vlan: 20 parent interface: lagg1 carp20: flags=49 metric 0 mtu 1500 inet 206.55.68.193 netmask 0xffffffe0 inet 206.55.68.196 netmask 0xffffffff carp: MASTER vhid 1 advbase 1 advskew 0 switch20> ping 206.55.68.193 Pinging 206.55.68.193 with 56 bytes of data: 56 bytes from 206.55.68.193: icmp_seq=1. time=0 ms 56 bytes from 206.55.68.193: icmp_seq=2. time=0 ms 56 bytes from 206.55.68.193: icmp_seq=3. time=0 ms 56 bytes from 206.55.68.193: icmp_seq=4. time=0 ms ----206.55.68.193 PING Statistics---- 4 packets transmitted, 4 packets received, 0% packet loss round-trip (ms) min/avg/max = 0/0/0 switch20> ping 206.55.68.194 Pinging 206.55.68.194 with 56 bytes of data: 56 bytes from 206.55.68.194: icmp_seq=1. time=0 ms 56 bytes from 206.55.68.194: icmp_seq=2. time=0 ms 56 bytes from 206.55.68.194: icmp_seq=3. time=0 ms 56 bytes from 206.55.68.194: icmp_seq=4. time=0 ms ----206.55.68.194 PING Statistics---- 4 packets transmitted, 4 packets received, 0% packet loss round-trip (ms) min/avg/max = 0/0/0 switch20> ping 206.55.68.195 Pinging 206.55.68.195 with 56 bytes of data: 56 bytes from 206.55.68.195: icmp_seq=1. time=0 ms 56 bytes from 206.55.68.195: icmp_seq=2. time=0 ms 56 bytes from 206.55.68.195: icmp_seq=3. time=0 ms 56 bytes from 206.55.68.195: icmp_seq=4. time=0 ms ----206.55.68.195 PING Statistics---- 4 packets transmitted, 4 packets received, 0% packet loss round-trip (ms) min/avg/max = 0/0/0 switch20> ping 206.55.68.196 Pinging 206.55.68.196 with 56 bytes of data: 56 bytes from 206.55.68.196: icmp_seq=1. time=0 ms 56 bytes from 206.55.68.196: icmp_seq=2. time=0 ms 56 bytes from 206.55.68.196: icmp_seq=3. time=0 ms 56 bytes from 206.55.68.196: icmp_seq=4. time=0 ms ----206.55.68.196 PING Statistics---- 4 packets transmitted, 4 packets received, 0% packet loss round-trip (ms) min/avg/max = 0/0/0 switch20> Mmm, generally, it looks to me like it works, but the above is the entirety of my testing, so I could easily be wrong. > *) carp is i bound, carp-dev line openbsd is in development > (not shure if already stable) You mean inbound? Well, yes. That's reasonably practical. It isn't entirely clear what other paradigms would look like (i.e. if the host system didn't have a native address on the wire), though several ideas spring to mind. Am I correct in assuming that you mean to have no native interface on the network in question, and only a CARP interface? Or am I reading in between the lines incorrectly? > *) if carp switch over: > t=0: A is master, has route 192.168.0.1/24 > B has route 192.168.0.1/24 via ospf > t=1: A goes down, route disappear (need linkstate in ospf) > t=2: B carp takes over 192.168.0.1/24 > B can not add 192.168.0.1/24 route as it is still > known via ospf > t=3: B gets update to remove route 192.168.0.1/24 via ospf > t=4: 192.168.0.1/24 route has disappeared, failover broken. > > with ucarp, some special scripts and source code changed I was able > to handle this situation, but not with carp and ospf (at least at > freebsd 6.3) I agree that this is a problematic scenario. FreeBSD 5.* and 6.* are pretty worthless to us, so we've pretty much jumped from 4 to 7, and so my knowledge of the networking improvements in between are limited. Under FreeBSD 4, there is indeed a great deal of pain associated with routes coming in via a routing protocol that are also theoretically available on a directly-attached interface. I just tried downing rtr1: vlan20 on the above (which is FreeBSD 7, obviously) and from rtr1's PoV the network did move correctly to an alternate route via OSPF, but upon re-enabling the vlan20 interface, the OSPF route remained. Now, it seemed to "all work again" when I did the following: # ifconfig vlan20 up # route delete -net 206.55.68.192 # ifconfig vlan20 inet 206.55.68.195 netmask 0xffffffe0 which re-established the local link. That's not ideal, but it is a lot better than FreeBSD 4, where things were just breaking all over if you did "strange" things like this. For most important things around here, we use OSPF with stub routes so the failure of a particular ethernet is not necessarily of great concern, but it would be nice to see things like this know how to DTRT. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From if at xip.at Fri Dec 19 16:28:58 2008 From: if at xip.at (Ingo Flaschberger) Date: Fri, 19 Dec 2008 23:28:58 +0100 (CET) Subject: Gigabit Linux Routers In-Reply-To: <200812192115.mBJLF44v042360@aurora.sol.net> References: <200812192115.mBJLF44v042360@aurora.sol.net> Message-ID: Dear Joe, > Yes, but the point was that the feature was listed as "simple traffic > shaping." You can do *complicated* traffic shaping too, which was the > reason I commented on that. Usually the ability to do complicated > traffic shaping means you can do simple traffic shaping too. ;-) with linux? really? > Mmm, generally, it looks to me like it works, but the above is the > entirety of my testing, so I could easily be wrong. you have ospf between this 2 boxes? show me them routing table. do a failover and show the routing table again, >> *) carp is i bound, carp-dev line openbsd is in development >> (not shure if already stable) > > You mean inbound? Well, yes. That's reasonably practical. It isn't > entirely clear what other paradigms would look like (i.e. if the host > system didn't have a native address on the wire), though several ideas > spring to mind. > > Am I correct in assuming that you mean to have no native interface on > the network in question, and only a CARP interface? Or am I reading in > between the lines incorrectly? only carp-int has the ip's. >> *) if carp switch over: >> t=0: A is master, has route 192.168.0.1/24 >> B has route 192.168.0.1/24 via ospf >> t=1: A goes down, route disappear (need linkstate in ospf) >> t=2: B carp takes over 192.168.0.1/24 >> B can not add 192.168.0.1/24 route as it is still >> known via ospf >> t=3: B gets update to remove route 192.168.0.1/24 via ospf >> t=4: 192.168.0.1/24 route has disappeared, failover broken. >> >> with ucarp, some special scripts and source code changed I was able >> to handle this situation, but not with carp and ospf (at least at >> freebsd 6.3) > > I agree that this is a problematic scenario. FreeBSD 5.* and 6.* are > pretty worthless to us, so we've pretty much jumped from 4 to 7, and > so my knowledge of the networking improvements in between are limited. I have not yet tested freebsd 7, as the multicast kernel interface changed and quagge ospf breaked. also I need(ed) a stable platform. > Under FreeBSD 4, there is indeed a great deal of pain associated with > routes coming in via a routing protocol that are also theoretically > available on a directly-attached interface. > > I just tried downing rtr1: vlan20 on the above (which is FreeBSD 7, > obviously) and from rtr1's PoV the network did move correctly to an > alternate route via OSPF, but upon re-enabling the vlan20 interface, > the OSPF route remained. Now, it seemed to "all work again" when I > did the following: yes, thats the problem. > # ifconfig vlan20 up > # route delete -net 206.55.68.192 > # ifconfig vlan20 inet 206.55.68.195 netmask 0xffffffe0 I have changed ucarp todo so, but you also need gratious arp and such stuff to get a real, flawless failover. > which re-established the local link. That's not ideal, but it is a lot > better than FreeBSD 4, where things were just breaking all over if you > did "strange" things like this. > > For most important things around here, we use OSPF with stub routes so > the failure of a particular ethernet is not necessarily of great concern, > but it would be nice to see things like this know how to DTRT. DTRT? Kind regards, Ingo Flaschberger From jgreco at ns.sol.net Fri Dec 19 17:40:16 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 19 Dec 2008 17:40:16 -0600 (CST) Subject: Gigabit Linux Routers In-Reply-To: from "Ingo Flaschberger" at Dec 19, 2008 11:28:58 PM Message-ID: <200812192340.mBJNeHNN048264@aurora.sol.net> > Dear Joe, > > Yes, but the point was that the feature was listed as "simple traffic > > shaping." You can do *complicated* traffic shaping too, which was the > > reason I commented on that. Usually the ability to do complicated > > traffic shaping means you can do simple traffic shaping too. ;-) > > with linux? > really? Reread the message... the text was in reply to a discussion of FreeBSD features. And, yes, really. ipfw, pf, and ipf solutions are all trivially available, giving you a selection of rule types and altq or dummynet shaping options that can be tied into extremely flexible rules. > > Mmm, generally, it looks to me like it works, but the above is the > > entirety of my testing, so I could easily be wrong. > > you have ospf between this 2 boxes? Yes. vlan20 is OSPF-enabled, as a matter of fact, and both routers are on it. The goal was to see if I could get a network that was smart enough for both OSPF-enabled hosts ("no static gateway needs to be config'ed") and non-OSPF hosts (CARP as default gateway). > show me them routing table. > do a failover and show the routing table again, I did that experiment below. I didn't grab snapshots of the routing table at the time, but I described the effect. Essentially, upon downing of the interface, the local link via the vlan20 interface went away, and was promptly replaced by the OSPF route (generally good/desirable). Further discussion was in my previous message. > >> *) carp is i bound, carp-dev line openbsd is in development > >> (not shure if already stable) > > > > You mean inbound? Well, yes. That's reasonably practical. It isn't > > entirely clear what other paradigms would look like (i.e. if the host > > system didn't have a native address on the wire), though several ideas > > spring to mind. > > > > Am I correct in assuming that you mean to have no native interface on > > the network in question, and only a CARP interface? Or am I reading in > > between the lines incorrectly? > > only carp-int has the ip's. Really? Interesting. I'm trying to think of how that would be configured. How does the system identify which ethernet interface to use, or is this something that's specific to Linux? > >> *) if carp switch over: > >> t=0: A is master, has route 192.168.0.1/24 > >> B has route 192.168.0.1/24 via ospf > >> t=1: A goes down, route disappear (need linkstate in ospf) > >> t=2: B carp takes over 192.168.0.1/24 > >> B can not add 192.168.0.1/24 route as it is still > >> known via ospf > >> t=3: B gets update to remove route 192.168.0.1/24 via ospf > >> t=4: 192.168.0.1/24 route has disappeared, failover broken. > >> > >> with ucarp, some special scripts and source code changed I was able > >> to handle this situation, but not with carp and ospf (at least at > >> freebsd 6.3) > > > > I agree that this is a problematic scenario. FreeBSD 5.* and 6.* are > > pretty worthless to us, so we've pretty much jumped from 4 to 7, and > > so my knowledge of the networking improvements in between are limited. > > I have not yet tested freebsd 7, as the multicast kernel interface > changed and quagge ospf breaked. also I need(ed) a stable platform. I'm aware of the Quagga OSPF issues, having grinched about them a number of times in various places. For what it is worth, there's a patch that appears to work, but which was thought to not really be a "correct" fix. Several people, including us, however, are using it with apparent success. > > Under FreeBSD 4, there is indeed a great deal of pain associated with > > routes coming in via a routing protocol that are also theoretically > > available on a directly-attached interface. > > > > I just tried downing rtr1: vlan20 on the above (which is FreeBSD 7, > > obviously) and from rtr1's PoV the network did move correctly to an > > alternate route via OSPF, but upon re-enabling the vlan20 interface, > > the OSPF route remained. Now, it seemed to "all work again" when I > > did the following: > > yes, thats the problem. > > > # ifconfig vlan20 up > > # route delete -net 206.55.68.192 > > # ifconfig vlan20 inet 206.55.68.195 netmask 0xffffffe0 > > I have changed ucarp todo so, but you also need > gratious arp and such stuff to get a real, flawless failover. Don't know. > > which re-established the local link. That's not ideal, but it is a lot > > better than FreeBSD 4, where things were just breaking all over if you > > did "strange" things like this. > > > > For most important things around here, we use OSPF with stub routes so > > the failure of a particular ethernet is not necessarily of great concern, > > but it would be nice to see things like this know how to DTRT. > > DTRT? Do the right thing. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From mloftis at wgops.com Fri Dec 19 19:32:40 2008 From: mloftis at wgops.com (Michael Loftis) Date: Fri, 19 Dec 2008 18:32:40 -0700 Subject: Gigabit Linux Routers In-Reply-To: <494AE486.9080009@greatbasin.net> References: <36243D984F88BA4ABD1E0EFC1E61B9894DBA08@fudd.ad.maine.edu> <494AE486.9080009@greatbasin.net> Message-ID: --On December 18, 2008 4:02:14 PM -0800 Bruce Robertson wrote: > Imagestream does nice work as well. > I'll second the plug for imagestream as well. > Soucy, Ray wrote: >> If all you're looking for is basic routing though, it might be >> worthwhile just getting a Vyatta appliance. >> >> -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From if at xip.at Fri Dec 19 20:05:00 2008 From: if at xip.at (Ingo Flaschberger) Date: Sat, 20 Dec 2008 03:05:00 +0100 (CET) Subject: Gigabit Linux Routers In-Reply-To: <200812192340.mBJNeHNN048264@aurora.sol.net> References: <200812192340.mBJNeHNN048264@aurora.sol.net> Message-ID: Dear Joe, > I did that experiment below. I didn't grab snapshots of the routing table > at the time, but I described the effect. Essentially, upon downing of the > interface, the local link via the vlan20 interface went away, and was > promptly replaced by the OSPF route (generally good/desirable). Further > discussion was in my previous message. I'm not shure if this setup would ever be "stable". also with ucarp tweaks. hopefully freebsd supports soon more than 1 route. >> only carp-int has the ip's. > > Really? Interesting. I'm trying to think of how that would be configured. > How does the system identify which ethernet interface to use, or is this > something that's specific to Linux? I'm not shure how I have configured that (~6months ago). Now with ucarp I use a /32 for the interfaces as ip and the virtual ip is added as an alias. > I'm aware of the Quagga OSPF issues, having grinched about them a number > of times in various places. For what it is worth, there's a patch that > appears to work, but which was thought to not really be a "correct" fix. > Several people, including us, however, are using it with apparent success. As far I remember, freebsd changed the multicast-interface to linux-style. Source code seems to be already there, only makefile needs to be changed, to support freebsd <7 and 7. Kind regards, Ingo Flaschberger From henry at AegisInfoSys.com Fri Dec 19 20:13:55 2008 From: henry at AegisInfoSys.com (Henry Yen) Date: Fri, 19 Dec 2008 21:13:55 -0500 Subject: Gigabit Linux Routers In-Reply-To: ; from Michael Loftis on Fri, Dec 19, 2008 at 18:32:40PM -0700 References: <36243D984F88BA4ABD1E0EFC1E61B9894DBA08@fudd.ad.maine.edu> <494AE486.9080009@greatbasin.net> Message-ID: <20081219211355.N5534@AegisInfoSys.com> On Fri, Dec 19, 2008 at 18:32:40PM -0700, Michael Loftis wrote: > > --On December 18, 2008 4:02:14 PM -0800 Bruce Robertson > wrote: > > > Imagestream does nice work as well. > > > > I'll second the plug for imagestream as well. > > > Soucy, Ray wrote: > >> If all you're looking for is basic routing though, it might be > >> worthwhile just getting a Vyatta appliance. Aren't both Imagestream and Vyatta routers built atop a Linux platform? -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York From martin at airwire.ie Fri Dec 19 20:26:02 2008 From: martin at airwire.ie (Martin List-Petersen) Date: Sat, 20 Dec 2008 02:26:02 +0000 Subject: Gigabit Linux Routers In-Reply-To: <20081219211355.N5534@AegisInfoSys.com> References: <36243D984F88BA4ABD1E0EFC1E61B9894DBA08@fudd.ad.maine.edu> <494AE486.9080009@greatbasin.net> <20081219211355.N5534@AegisInfoSys.com> Message-ID: <494C57BA.3000004@airwire.ie> Henry Yen wrote: > On Fri, Dec 19, 2008 at 18:32:40PM -0700, Michael Loftis wrote: >> --On December 18, 2008 4:02:14 PM -0800 Bruce Robertson >> wrote: >> >>> Imagestream does nice work as well. >>> >> I'll second the plug for imagestream as well. >> >>> Soucy, Ray wrote: >>>> If all you're looking for is basic routing though, it might be >>>> worthwhile just getting a Vyatta appliance. > > Aren't both Imagestream and Vyatta routers built atop a Linux platform? > So is Juniper a BSD base (if I recall correct). The difference is the selection of hardware and added routing hardware. The issue is, that those additions, that Juniper, Imagestream and Vyatta add, are not available on the standard platform, so it can't be quite compared. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From randy at psg.com Fri Dec 19 20:51:43 2008 From: randy at psg.com (Randy Bush) Date: Sat, 20 Dec 2008 11:51:43 +0900 Subject: Gigabit Linux Routers In-Reply-To: <494C57BA.3000004@airwire.ie> References: <36243D984F88BA4ABD1E0EFC1E61B9894DBA08@fudd.ad.maine.edu> <494AE486.9080009@greatbasin.net> <20081219211355.N5534@AegisInfoSys.com> <494C57BA.3000004@airwire.ie> Message-ID: <494C5DBF.6090209@psg.com> > So is Juniper a BSD base (if I recall correct). The difference is the > selection of hardware and added routing hardware. juniper uses a freebsd base. but the stack, routing protocols, forwarding, drivers, ... are quite different. randy From lsc at prgmr.com Fri Dec 19 21:04:23 2008 From: lsc at prgmr.com (Luke S Crawford) Date: 19 Dec 2008 22:04:23 -0500 Subject: Security Intelligence [Was: Re: Netblock reassigned from Chile to US ISP...] In-Reply-To: <49437781.2000005@psg.com> References: <6cd462c00812130029k7b08b8d5rd92c68dc9550a94e@mail.gmail.com> <6cd462c00812130044k1178ba82kd0df6c3e7b2255d5@mail.gmail.com> <49437781.2000005@psg.com> Message-ID: Randy Bush writes: > be specific, like "if you run X tools the payoff will be Y." Yes. And where is the appropriate form for this? I find this sort of thing quite interesting; and yeah, it doesn't seem like the sort of thing NANOG is for, but most of the small ISP forms (like webhostingtalk, etc...) well, the average technical skill level seems to be ridicioulously low. Some people talk about ways to give spammers only one 'whack' at your service, such as requesting a faxed ID ahead of time, or putting more effort into preventing credit card fraud. Me, my focus has been on detecting abuse from my customers before the rest of the world starts complaining. speaking as a small provider, I can tell you that I find running snort against my inbound traffic does reduce the cost of running an abuse desk. I do catch offenders before I get abuse@ complaints, sometimes. Granted, my snort-fu is not awesome. just the other week I was reminded that I wasn't even checking for ssh dictionary attacks. There is a lot more work i need to do with snort before I can have it automatically switch off customers, or notify me at a high priority, rather than writing to a log I read once every few days. Still, I think I am on the right track, as even with my poor, neglected snort setup I still catch some problems before I get complaints. I don't see anyone else talking about doing anything similar... Everyone else seems to be focused on preventing spammers from signing up or going after them after the fact. It seems to me that some effort into detecting abuse as it happens (rather than waiting for an abuse@ complaint, something that, in my experience takes a rather large amount of abuse to trigger.) could yield quite a lot of 'low hanging fruit' simply because not much effort has been put out in that direction. On the other hand, I have a hard time believing I'm smarter than the guys running ec2. So maybe I'm missing something, and it's really not actually any cheaper than manning the abuse@ desk with a bunch of grunts. Or maybe other people are already doing this, and I've just missed the conversation. Maybe even if you tune snort optimally, it still can't detect enough of the attacks to be useful? From brandon.galbraith at gmail.com Fri Dec 19 21:12:43 2008 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Fri, 19 Dec 2008 21:12:43 -0600 Subject: Gigabit Linux Routers In-Reply-To: <494C57BA.3000004@airwire.ie> References: <36243D984F88BA4ABD1E0EFC1E61B9894DBA08@fudd.ad.maine.edu> <494AE486.9080009@greatbasin.net> <20081219211355.N5534@AegisInfoSys.com> <494C57BA.3000004@airwire.ie> Message-ID: <366100670812191912m3979408cg67c11013cc029b54@mail.gmail.com> I wasn't aware of imagestream using any custom (asic) hardware, except the T1/3 cards in the concentrator we bought from them (worked like a champ, btw). -brandon On 12/19/08, Martin List-Petersen wrote: > Henry Yen wrote: >> On Fri, Dec 19, 2008 at 18:32:40PM -0700, Michael Loftis wrote: >>> --On December 18, 2008 4:02:14 PM -0800 Bruce Robertson >>> wrote: >>> >>>> Imagestream does nice work as well. >>>> >>> I'll second the plug for imagestream as well. >>> >>>> Soucy, Ray wrote: >>>>> If all you're looking for is basic routing though, it might be >>>>> worthwhile just getting a Vyatta appliance. >> >> Aren't both Imagestream and Vyatta routers built atop a Linux platform? >> > > So is Juniper a BSD base (if I recall correct). The difference is the > selection of hardware and added routing hardware. > > The issue is, that those additions, that Juniper, Imagestream and Vyatta > add, are not available on the standard platform, so it can't be quite > compared. > > Kind regards, > Martin List-Petersen > > -- > Airwire - Ag Nascadh Pobal an Iarthar > http://www.airwire.ie > Phone: 091-865 968 > > -- Sent from my mobile device Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith at gmail.com From martin at airwire.ie Fri Dec 19 21:19:15 2008 From: martin at airwire.ie (Martin List-Petersen) Date: Sat, 20 Dec 2008 03:19:15 +0000 Subject: Gigabit Linux Routers In-Reply-To: <366100670812191912m3979408cg67c11013cc029b54@mail.gmail.com> References: <36243D984F88BA4ABD1E0EFC1E61B9894DBA08@fudd.ad.maine.edu> <494AE486.9080009@greatbasin.net> <20081219211355.N5534@AegisInfoSys.com> <494C57BA.3000004@airwire.ie> <366100670812191912m3979408cg67c11013cc029b54@mail.gmail.com> Message-ID: <494C6433.6000105@airwire.ie> Brandon Galbraith wrote: > I wasn't aware of imagestream using any custom (asic) hardware, except > the T1/3 cards in the concentrator we bought from them (worked like a > champ, btw). It doesn't have to be hardware. Even their custom developed drivers and software isn't available on anything but their platform. But true, their products show, what can be done even without custom hardware. It's a matter of optimizing the drivers and a careful selection of hardware. All I was referring to, is that if you take a Linux box, Quagga, stock hardware, you might not get quite the same results. And don't get me wrong, we use Quagga and are quite happy with it. Kind regards, Martin List-Petersen > > -brandon > > On 12/19/08, Martin List-Petersen wrote: >> Henry Yen wrote: >>> On Fri, Dec 19, 2008 at 18:32:40PM -0700, Michael Loftis wrote: >>>> --On December 18, 2008 4:02:14 PM -0800 Bruce Robertson >>>> wrote: >>>> >>>>> Imagestream does nice work as well. >>>>> >>>> I'll second the plug for imagestream as well. >>>> >>>>> Soucy, Ray wrote: >>>>>> If all you're looking for is basic routing though, it might be >>>>>> worthwhile just getting a Vyatta appliance. >>> Aren't both Imagestream and Vyatta routers built atop a Linux platform? >>> >> So is Juniper a BSD base (if I recall correct). The difference is the >> selection of hardware and added routing hardware. >> >> The issue is, that those additions, that Juniper, Imagestream and Vyatta >> add, are not available on the standard platform, so it can't be quite >> compared. >> >> Kind regards, >> Martin List-Petersen >> >> -- >> Airwire - Ag Nascadh Pobal an Iarthar >> http://www.airwire.ie >> Phone: 091-865 968 >> >> > -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From david at davidcoulson.net Fri Dec 19 21:19:55 2008 From: david at davidcoulson.net (David Coulson) Date: Fri, 19 Dec 2008 22:19:55 -0500 Subject: Gigabit Linux Routers In-Reply-To: <366100670812191912m3979408cg67c11013cc029b54@mail.gmail.com> References: <36243D984F88BA4ABD1E0EFC1E61B9894DBA08@fudd.ad.maine.edu> <494AE486.9080009@greatbasin.net> <20081219211355.N5534@AegisInfoSys.com> <494C57BA.3000004@airwire.ie> <366100670812191912m3979408cg67c11013cc029b54@mail.gmail.com> Message-ID: <494C645B.4040507@davidcoulson.net> It doesn't - It's just an x86 PC. I have Vyatta running inside VMware ESX, not well, but it works ;-) Comparing Imagestream and Vyatta to Juniper is crazy. The first two are software based platforms (with perhaps some hardware off-load for checksums and whatnot), where as the Juniper pretty much just uses BSD for control-plane features (BGP, for example, and controlling the hardware that actually does packet switching/routing). Brandon Galbraith wrote: > I wasn't aware of imagestream using any custom (asic) hardware, except > the T1/3 cards in the concentrator we bought from them (worked like a > champ, btw). From randy at psg.com Fri Dec 19 21:23:08 2008 From: randy at psg.com (Randy Bush) Date: Sat, 20 Dec 2008 12:23:08 +0900 Subject: Security Intelligence [Was: Re: Netblock reassigned from Chile to US ISP...] In-Reply-To: References: <6cd462c00812130029k7b08b8d5rd92c68dc9550a94e@mail.gmail.com> <6cd462c00812130044k1178ba82kd0df6c3e7b2255d5@mail.gmail.com> <49437781.2000005@psg.com> Message-ID: <494C651C.8020508@psg.com> >> be specific, like "if you run X tools the payoff will be Y." > Yes. And where is the appropriate form for this? there must be some operators' list somewhere. > it doesn't seem like the sort of thing NANOG is for yep. nanog is for whining about it, not doing/saying something actually constructive with technical content. > speaking as a small provider, I can tell you that I find running snort > against my inbound traffic does reduce the cost of running an abuse desk. > I do catch offenders before I get abuse@ complaints, sometimes. unfortunately snort does not really scale to a larger provider. and, to the best of my poor knowledge, good open source tools to black-hole/redirect botted users are not generally available. universities have some that are good at campus and enterprise scale. cymru and a few security researchers responded privately to my plea for solid open source tool sets and refs. knowing the folk involved, maybe we'll see some motion. patience is a virtue, within limits. randy From martin at airwire.ie Fri Dec 19 21:26:12 2008 From: martin at airwire.ie (Martin List-Petersen) Date: Sat, 20 Dec 2008 03:26:12 +0000 Subject: Gigabit Linux Routers In-Reply-To: <494C645B.4040507@davidcoulson.net> References: <36243D984F88BA4ABD1E0EFC1E61B9894DBA08@fudd.ad.maine.edu> <494AE486.9080009@greatbasin.net> <20081219211355.N5534@AegisInfoSys.com> <494C57BA.3000004@airwire.ie> <366100670812191912m3979408cg67c11013cc029b54@mail.gmail.com> <494C645B.4040507@davidcoulson.net> Message-ID: <494C65D4.4000403@airwire.ie> David Coulson wrote: > It doesn't - It's just an x86 PC. I have Vyatta running inside VMware > ESX, not well, but it works ;-) > > Comparing Imagestream and Vyatta to Juniper is crazy. The first two are > software based platforms (with perhaps some hardware off-load for > checksums and whatnot), where as the Juniper pretty much just uses BSD > for control-plane features (BGP, for example, and controlling the > hardware that actually does packet switching/routing). Sorry, but it's not crazy at all. They are all routers. The question is now, what your requirements are and what you are looking for. All I was pointing out was, that it doesn't matter, what platform the router is based on, but more, what hardware it's running on and how much work has been spend on optimizing it. You can use an Olive with JunOS on stock hardware, too and you'll probably be fine for gbit speeds, but you can't expect support for it. It's nice to see some development in the FOSS side of things to get past gbit speeds, but I don't think Imagestream or Vyatta could be mixed in there either, because that's the other end of the scale again (within the software routers that is). Kind regards, Martin List-Petersen > > Brandon Galbraith wrote: >> I wasn't aware of imagestream using any custom (asic) hardware, except >> the T1/3 cards in the concentrator we bought from them (worked like a >> champ, btw). -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From eslerj at gmail.com Fri Dec 19 21:31:34 2008 From: eslerj at gmail.com (Joel Esler) Date: Fri, 19 Dec 2008 22:31:34 -0500 Subject: Security Intelligence [Was: Re: Netblock reassigned from Chile to US ISP...] In-Reply-To: <494C651C.8020508@psg.com> References: <6cd462c00812130029k7b08b8d5rd92c68dc9550a94e@mail.gmail.com> <6cd462c00812130044k1178ba82kd0df6c3e7b2255d5@mail.gmail.com> <49437781.2000005@psg.com> <494C651C.8020508@psg.com> Message-ID: On Dec 19, 2008, at 10:23 PM, Randy Bush allegedly wrote: > unfortunately snort does not really scale to a larger provider. I respectfully disagree. I have very large entities with ALOT of traffic running through Snort. However, they are also using my company's products. I work for Sourcefire. We make Snort. -- Joel Esler ? http://www.joelesler.net [m] From nanog at daork.net Fri Dec 19 21:50:40 2008 From: nanog at daork.net (Nathan Ward) Date: Sat, 20 Dec 2008 16:50:40 +1300 Subject: Security Intelligence [Was: Re: Netblock reassigned from Chile to US ISP...] In-Reply-To: <494C651C.8020508@psg.com> References: <6cd462c00812130029k7b08b8d5rd92c68dc9550a94e@mail.gmail.com> <6cd462c00812130044k1178ba82kd0df6c3e7b2255d5@mail.gmail.com> <49437781.2000005@psg.com> <494C651C.8020508@psg.com> Message-ID: <519F0781-B563-4C53-95AB-563264FD35C9@daork.net> On 20/12/2008, at 4:23 PM, Randy Bush wrote: >>> speaking as a small provider, I can tell you that I find running >>> snort >> against my inbound traffic does reduce the cost of running an abuse >> desk. >> I do catch offenders before I get abuse@ complaints, sometimes. > > unfortunately snort does not really scale to a larger provider. > and, to the best of my poor knowledge, good open source tools to > black-hole/redirect botted users are not generally available. > universities have some that are good at campus and enterprise scale. > > cymru and a few security researchers responded privately to my plea > for solid open source tool sets and refs. knowing the folk > involved, maybe we'll see some motion. patience is a virtue, within > limits. If you're talking about throughput, Tilera recently (April) demonstrated 10Gbit/s snort on their TILE64 processors. http://tilera.com/news_&_events/press_release_080429_snort.php Not sure if anyone has them in products at the moment though. -- Nathan Ward From patrick at ianai.net Fri Dec 19 22:31:31 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 19 Dec 2008 23:31:31 -0500 Subject: What is the most standard subnet length on internet In-Reply-To: References: <15850784.26571229661837046.JavaMail.weblogic@epml12> <56F5BC5F404CF84896C447397A1AAF20B0F7D4@MAIL.nosi.netos.com> Message-ID: On Dec 19, 2008, at 10:53 AM, Joe Abley wrote: > It'd be nice if some grad student somewhere with friends in the > operations community was to experiment with /24s carved out of > larger blocks from all over the planet and present some empirical > data. We don't need a student. We have actual networks doing this every day without any issue, so we know it works. A research project could verify every last corner of the 'Net is accessible to /24s carved out of larger blocks, but the 'corners' tend to be more forgiving of things, it's the people in the "middle" who think they are too big or too important to listen to the little guys which cause problems. Little guys tend to not be so .. uh .. well, you can figure out what I mean. I believe there was a project on reachability of /24s which were _not_ carved out of larger blocks, although I can't find it right now. That might be more interesting. -- TTFN, patrick From patrick at ianai.net Fri Dec 19 22:37:30 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 19 Dec 2008 23:37:30 -0500 Subject: What is the most standard subnet length on internet In-Reply-To: <200812191548.mBJFmoFP029058@aurora.sol.net> References: <200812191548.mBJFmoFP029058@aurora.sol.net> Message-ID: <3F0B70F6-A8B2-4599-8441-2EB4A661E852@ianai.net> On Dec 19, 2008, at 10:48 AM, Joe Greco wrote: >> As for routing table size, no router which can handle 10s of Gbps is >> at all bothered by the size of the global table, > > ... as long as it isn't something like a Cisco Catalyst 6509 with > SUP720 > and doesn't have a PFC3BXL helping out ... > > ... or if we conveniently don't classify a Catalyst 65xx as a router > because it was primarily intended as a switch, despite how ISP's > commonly > use them ... > >> so only edge devices >> or stub networks are in danger of needing to filter /24s. And both >> of >> those can (should?) have something called a "default route", making >> it >> completely irrelevant whether they hear the /24s anyway. > > A more accurate statement is probably that "any router that can handle > 10s of Gbps is likely to be available in a configuration that is not > at > all bothered by the current size of the global table, most likely at > some > substantial additional cost." Good point! I should have said "10s of Gbps and tables associated with default-free networks". Or are there lots of people using 6500s without 3BXLs in the DFZ? I admit I have not audited every router in the DFZ, so perhaps someone with factual info can help out here. If not, then we're back to where we started. The DFZ isn't worried about table size this cycle, and the edges can (should?) have default. I'm sure that will change in a couple years, but everything always does. Oh, and before anyone jumps all over me, I am NOT implying you should deaggregate and blow up the table. Just that 300K prefixes is the DFZ is not a reason to start filtering /24s. Today. :) -- TTFN, patrick From randy at psg.com Fri Dec 19 23:20:26 2008 From: randy at psg.com (Randy Bush) Date: Sat, 20 Dec 2008 14:20:26 +0900 Subject: What is the most standard subnet length on internet In-Reply-To: <3F0B70F6-A8B2-4599-8441-2EB4A661E852@ianai.net> References: <200812191548.mBJFmoFP029058@aurora.sol.net> <3F0B70F6-A8B2-4599-8441-2EB4A661E852@ianai.net> Message-ID: <494C809A.9030104@psg.com> > Oh, and before anyone jumps all over me, I am NOT implying you should > deaggregate and blow up the table. Just that 300K prefixes is the DFZ is > not a reason to start filtering /24s. Today. :) given o ipv4 bits not scaling to internet growth o increase in multi-homing o internet growth nats, siit/nat-pt and ipv4/ipv4 nat will increase combined, this very well may create pressure to globally route longer ipv4 prefixes. randy From lsc at prgmr.com Sat Dec 20 00:55:11 2008 From: lsc at prgmr.com (Luke S Crawford) Date: 20 Dec 2008 01:55:11 -0500 Subject: Security Intelligence [Was: Re: Netblock reassigned from Chile to US ISP...] In-Reply-To: <494C651C.8020508@psg.com> References: <6cd462c00812130029k7b08b8d5rd92c68dc9550a94e@mail.gmail.com> <6cd462c00812130044k1178ba82kd0df6c3e7b2255d5@mail.gmail.com> <49437781.2000005@psg.com> <494C651C.8020508@psg.com> Message-ID: Randy Bush writes: > > speaking as a small provider, I can tell you that I find running snort > > against my inbound traffic does reduce the cost of running an abuse desk. > > I do catch offenders before I get abuse@ complaints, sometimes. > > unfortunately snort does not really scale to a larger provider. and, > to the best of my poor knowledge, good open source tools to > black-hole/redirect botted users are not generally > available. universities have some that are good at campus and > enterprise scale. I can't speak to the scaling of snort (I only eat around 20Mbps, and snort on a 256Mb Xen VM handles it just fine) but I'm not sure what you are getting at with regards to open-source tools to blackhole or redirect botted users. I mean, we've all got hooks in our billing system (or some other procedure) to manually disable abusive (or non-paying) customers now, right? I guess I'm not seeing how it is any harder to have a script watching snort disable the customer than it is to have freeside disable the customer when they dont pay their bill. My current setup (and I'm not saying this is the right way, or even a good way to do it) is just snort logging to a file. I then have a perl script tailing that file and 'doing stuff' - right now, 'doing stuff' consists of figuring out if it is abuse from one of my customers (in which case it puts it in the log for me) or to one of my customers (in which case, it puts it in a log for that customer. I figure it doesn't cost me any extra, so I might as well let customers see incoming attacks.) If I sat down at it long enough to say 'alert X (or alert X, y times in Z seconds) means the customer is definately botted (or abusive)' setting the perl script to run a script that uses ssh to connect to my router and blackhole the customer (or or to connect to my freeside system and suspend the account) is if not trivial, at least fairly easy. It's certainly something I could give to the junior guy on my team, and while I'd want to check his work and test carefully before going live, I'm confident he could implement. If you really need something pre-built, check out: http://www.snortsam.net/ (I haven't used it, but I don't think it's the only tool of its kind.) the hard parts (as I see them) are going to be 1. identifying the snort attacks that mean a box should be shut down. I mean, I don't want to shut you down for a simple port-scan. Maybe you are checking one of your own networks? things like that are probably more of a 'warning' for the customers I target. This is probably easier on a network targeting 'normal' customers, 'cause you can prohibit many of those things in your AUP. Also, at this point, it's pretty important that you don't have a noticable number of false positives. you probably want to run your thing in notify-only mode for a while until you are comfortable. 2. making sure that your system doesn't turn in to an easy way to DOS another server on the same network. BCP38, if implemented tightly enough (something I'm doing quite well on IPv4, but not on IPv6) can largely fix this problem, and as you are watching for abuse behind your own router, is a realistic solution. But it still takes some effort. From sethm at rollernet.us Sat Dec 20 01:49:03 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 19 Dec 2008 23:49:03 -0800 Subject: Security Intelligence [Was: Re: Netblock reassigned from Chile to US ISP...] In-Reply-To: References: <6cd462c00812130029k7b08b8d5rd92c68dc9550a94e@mail.gmail.com> <6cd462c00812130044k1178ba82kd0df6c3e7b2255d5@mail.gmail.com> <49437781.2000005@psg.com> <494C651C.8020508@psg.com> Message-ID: <494CA36F.6080103@rollernet.us> Luke S Crawford wrote: > Randy Bush writes: > >>> speaking as a small provider, I can tell you that I find running snort >>> against my inbound traffic does reduce the cost of running an abuse desk. >>> I do catch offenders before I get abuse@ complaints, sometimes. >> unfortunately snort does not really scale to a larger provider. and, >> to the best of my poor knowledge, good open source tools to >> black-hole/redirect botted users are not generally >> available. universities have some that are good at campus and >> enterprise scale. > > I can't speak to the scaling of snort (I only eat around 20Mbps, > and snort on a 256Mb Xen VM handles it just fine) but I'm not > sure what you are getting at with regards to open-source tools to > blackhole or redirect botted users. I mean, we've all got hooks > in our billing system (or some other procedure) to manually disable > abusive (or non-paying) customers now, right? I guess I'm not seeing > how it is any harder to have a script watching snort disable the > customer than it is to have freeside disable the customer when they > dont pay their bill. > I suppose it could lead to huge amounts of anger from an existing customer base if automatic cutoffs started showing up one day out of the blue (to their perspective). I automatically disable various things for a whole slew of reasons - but I've been doing it since day one and everyone is aware of it and expects it. Or slowly phase them in with warnings leading up to automated action. Repetitive, boring tasks are great for computers. I've only ever had one customer (a local advertising agency, who is no longer a customer) cry over automation because they thought they had a "special treatment" clause and didn't need to pay. It sent them warnings, of course, but they thought those didn't apply to them either. Automation isn't for everyone. I like automation. It has rules and follows them. The rules are posted ahead of time for all to see. Most of the time people are happy to see the automated system put a stop to some kind of potential disaster before it has time to cause more damage. It's like your credit card company calling you because suddenly there's abnormal charges on your card. ~Seth From brandon.galbraith at gmail.com Sat Dec 20 01:57:45 2008 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Sat, 20 Dec 2008 01:57:45 -0600 Subject: Security Intelligence [Was: Re: Netblock reassigned from Chile to US ISP...] In-Reply-To: <494CA36F.6080103@rollernet.us> References: <6cd462c00812130029k7b08b8d5rd92c68dc9550a94e@mail.gmail.com> <6cd462c00812130044k1178ba82kd0df6c3e7b2255d5@mail.gmail.com> <49437781.2000005@psg.com> <494C651C.8020508@psg.com> <494CA36F.6080103@rollernet.us> Message-ID: <366100670812192357r5331435fwc201a54bd409ee05@mail.gmail.com> On 12/20/08, Seth Mattinen wrote: > > > I like automation. It has rules and follows them. The rules are posted > ahead of time for all to see. Most of the time people are happy to see the > automated system put a stop to some kind of potential disaster before it has > time to cause more damage. It's like your credit card company calling you > because suddenly there's abnormal charges on your card. > > ~Seth > > But it's definitely not cool when my credit card company cuts off my card due to "abnormal charges" when I'm abroad and suddenly can't get ahold of customer service via their international phone number. Automation in the right places works wonders for both convenience and the bottom line. In the wrong places, it's a sawed off shotgun pointed at your feet. -brandon -- Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbraith at gmail.com From naveen at calpop.com Sat Dec 20 04:49:26 2008 From: naveen at calpop.com (Naveen Nathan) Date: Sat, 20 Dec 2008 10:49:26 +0000 Subject: Advice requested for OpenBSD vs. Linux/OpenBGP vs. Quagga router deployment. In-Reply-To: References: Message-ID: <20081220104926.GB12119@armakuni.lastninja.net> Hi Marc, > We are a software development firm that currently delivers our install ISOs via Sourceforge. We need to start serving them ourselves for marketing reasons and are therefore increasing our bandwidth and getting a 2nd ISP in our datacenter. Both ISPs will be delivering 100mbit/sec links. We don't expect to increase that for the next year or so and expect average traffic to be about 40-60mbit/sec. > > We are planning to run two OpenBSD based firewalls (with CARP and pf) running OpenBGP in order to connect to the two ISPs. > > I saw from previous email that Quagga was recommended as opposed to OpenBGP. Any further comments on that? Also, any comments on the choice of OpenBSD vs. Linux? I would suggset checking out Vyatta Linux as a possible Linux solution. It's designed to be configured as a routing/firewall platform. One caveat, I have never used it but it seems to be mentioned in this list from time to time. Now for my rant. I attempted a setup as you describe using two servers using pf, carp, and openbgp. I also had VLANs configured (each VLAN interface had it's own CARP interface). I tried both load-balanced and failover mode but the results weren't desirable. The routers were connected to a switch which connects the servers and the ISP connection. There was only one drop from the ISP but each router had it's own /30 and BGP session on it's own VLAN. The remaining servers were also VLANned appropriately. Each VLAN interface on the router that connects to the servers would also have an accompanying CARP interface. There were a myriad of problems when attempting my setup. These are some that I distinctly recall. * In load-balancing mode I would unplug a router. The other router would register as a CARP master but didn't forward the remaining traffic. * In failover mode when unplugging a router the other router would forward traffic for certain VLANs and wouldn't register as master for the others. In hindsight I should've reached out to the openbsd community for assistance. It's possible I was running into bugs in the CARP code or I was simply doing it all wrong. However I was under a time crunch and this was merely a favour for a friend in need. I didn't want to further disrupt the network by testing so I ended up going with a single router setup (still openbsd though). I haven't revisited the daul router setup since everything has been working fine and dandy with one router. Regardless of what OS choice you make be sure to thoroughly test your network setup and make sure it works as planned. Lastly don't hesitate to ask the appropriate people for help. You may have discovered oddities that noone else has. Good luck, Naveen From lsc at prgmr.com Sat Dec 20 07:13:35 2008 From: lsc at prgmr.com (Luke S Crawford) Date: 20 Dec 2008 08:13:35 -0500 Subject: Security Intelligence [Was: Re: Netblock reassigned from Chile to US ISP...] In-Reply-To: <366100670812192357r5331435fwc201a54bd409ee05@mail.gmail.com> References: <6cd462c00812130029k7b08b8d5rd92c68dc9550a94e@mail.gmail.com> <6cd462c00812130044k1178ba82kd0df6c3e7b2255d5@mail.gmail.com> <49437781.2000005@psg.com> <494C651C.8020508@psg.com> <494CA36F.6080103@rollernet.us> <366100670812192357r5331435fwc201a54bd409ee05@mail.gmail.com> Message-ID: "Brandon Galbraith" writes: > But it's definitely not cool when my credit card company cuts off my card > due to "abnormal charges" when I'm abroad and suddenly can't get ahold of > customer service via their international phone number. Automation in the > right places works wonders for both convenience and the bottom line. In the > wrong places, it's a sawed off shotgun pointed at your feet. Yeah, in this case, I think getting the rules right is the hard part... I don't think it matters that much if the rules are executed by a level-1 person vs. a script (the script, I think, would be more consistent, at least.) Sure, if you can afford to page someone good to deal with it, that's probably an even better answer, assuming they can get to it quickly, but that's much more expensive than just blocking it. (I imagine the right approach depends a lot on what you happen to be charging the customers in question.) Even if you do decide to wait around for an abuse@ complaint to take action, having the IDS logs of the outgoing traffic makes corroberating an abuse complaint much easier. And it's easy enough to email a human instead of shutting off a customer automatically. From fw at deneb.enyo.de Sat Dec 20 10:28:57 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 20 Dec 2008 17:28:57 +0100 Subject: Gigabit Linux Routers In-Reply-To: <494C645B.4040507@davidcoulson.net> (David Coulson's message of "Fri, 19 Dec 2008 22:19:55 -0500") References: <36243D984F88BA4ABD1E0EFC1E61B9894DBA08@fudd.ad.maine.edu> <494AE486.9080009@greatbasin.net> <20081219211355.N5534@AegisInfoSys.com> <494C57BA.3000004@airwire.ie> <366100670812191912m3979408cg67c11013cc029b54@mail.gmail.com> <494C645B.4040507@davidcoulson.net> Message-ID: <87vdtebyk6.fsf@mid.deneb.enyo.de> * David Coulson: > Comparing Imagestream and Vyatta to Juniper is crazy. The first two > are software based platforms (with perhaps some hardware off-load for > checksums and whatnot), where as the Juniper pretty much just uses BSD > for control-plane features (BGP, for example, and controlling the > hardware that actually does packet switching/routing). Juniper has software-based offerings, too. Not everybody pushes multi-gigabit traffic volumes at which (software on) special processors seem to be required. From danny at tcb.net Sat Dec 20 11:42:47 2008 From: danny at tcb.net (Danny McPherson) Date: Sat, 20 Dec 2008 10:42:47 -0700 Subject: What is the most standard subnet length on internet In-Reply-To: <15850784.26571229661837046.JavaMail.weblogic@epml12> References: <15850784.26571229661837046.JavaMail.weblogic@epml12> Message-ID: <075BBEDD-73CB-4F8B-BCB0-95D2FA54E909@tcb.net> On Dec 18, 2008, at 9:43 PM, ??? wrote: > Suresh, > > Yes, I guess my concern is close to the second meaning. > > It seems so simple. Currently annoucement of /24 seems to be okey, > most upstream providers accept this. > However I wonder if there is any ground rule based on any standard > or official recommandation. > If there is some standardized rule about prefix length to be > annouced, I will make my bgp & IP allocation policy of > each data center of my company, and I will be able to more fairly > and squarely speak to my customer like this > "You have to change your server's IP address if you want move your > server to other place" Some useful guidance is provided here (and in subsequent references) as well: An Architecture for IP Address Allocation with CIDR Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy Network Renumbering Overview A Framework for Inter-Domain Route Aggregation HTH, -danny From cmadams at hiwaay.net Sat Dec 20 13:34:34 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 20 Dec 2008 13:34:34 -0600 Subject: Gigabit Linux Routers In-Reply-To: <494C645B.4040507@davidcoulson.net> References: <36243D984F88BA4ABD1E0EFC1E61B9894DBA08@fudd.ad.maine.edu> <494AE486.9080009@greatbasin.net> <20081219211355.N5534@AegisInfoSys.com> <494C57BA.3000004@airwire.ie> <366100670812191912m3979408cg67c11013cc029b54@mail.gmail.com> <494C645B.4040507@davidcoulson.net> Message-ID: <20081220193434.GA632403@hiwaay.net> Once upon a time, David Coulson said: > Comparing Imagestream and Vyatta to Juniper is crazy. The first two are > software based platforms (with perhaps some hardware off-load for > checksums and whatnot), where as the Juniper pretty much just uses BSD > for control-plane features (BGP, for example, and controlling the > hardware that actually does packet switching/routing). Well, the J-series are fully software-based routers. Still, they have their own routing daemons and such. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From bennetb at gmail.com Sat Dec 20 15:17:33 2008 From: bennetb at gmail.com (Brandon Bennett) Date: Sat, 20 Dec 2008 14:17:33 -0700 Subject: Gigabit Linux Routers In-Reply-To: <20081220193434.GA632403@hiwaay.net> References: <36243D984F88BA4ABD1E0EFC1E61B9894DBA08@fudd.ad.maine.edu> <494AE486.9080009@greatbasin.net> <20081219211355.N5534@AegisInfoSys.com> <494C57BA.3000004@airwire.ie> <366100670812191912m3979408cg67c11013cc029b54@mail.gmail.com> <494C645B.4040507@davidcoulson.net> <20081220193434.GA632403@hiwaay.net> Message-ID: > Well, the J-series are fully software-based routers. Still, they have > their own routing daemons and such. The difference is that Juniper, even on th J-series box, completely separates the control plane and fowarding plane. The forwarding plane on a M or T series is going to be a ppc based chip along with ASIC to do the real lifitng. In the J-series it is a emulated FPC running on real-time BSD. The control plane on both platform is freebsd based. This is also what an Olive is. The control plane with no FPC. You'll also note horrible forwarding performance on an Olive. So a J-series it cannot be compared to a Vyatta or Imagestream even though it's software based. I think IOS can be compared more so (combined fowarding and control planes on software routers) -Brandon http://www.juniper.net/company/presscenter/pr/2005/pr-050131.html http://www.linuxdevices.com/news/NS4066781213.html From justin at justinshore.com Sat Dec 20 19:22:41 2008 From: justin at justinshore.com (Justin Shore) Date: Sat, 20 Dec 2008 19:22:41 -0600 Subject: Managing CE eBGP details & common/accepted CE-facing BGP practices Message-ID: <494D9A61.6080708@justinshore.com> Does anyone have any preferred ways to manage their customer-facing BGP details? I'm thinking about the customer's ASN (SP assigned private ASN or RIR assigned ASN), permitted prefixes, etc? While I'm sure this could be easily stored in a spreadsheet I'm not sure if there is any merit to storing some of these details outside of the configuration on the PE (assuming of course that the PE's config is regularly archived). Now if the PE's BGP config was auto-generated via a script then it would make sense for all the details to be stored off in a DB in the NOC. Beyond that is there a good reason to do archive it in a textual format off of the PE and if there is a sound reason to do it, is therea good or preferred way to do accomplish this? We're moving beyond our typical residential and very small SMB service to larger customers over the next few months. These areas have larger, more advanced customers and I'm sure we'll run into multi-homed environments and customer who will expect BGP peering options. I would like to be prepared with sound practices before we get our first customer that wants to get a default route via BGP, wants full tables, or has their own ASN and is bringing their own PI space with them. Some of this of course implies multiple processes to confirm that the ASN belongs to the customer in question, that the PI space belongs to the customer in question, notifying our upstreams to accept the customer's PI space, etc. It's hammering out the scalable and best practice config details that I'm concerned with at the moment. When assigning private ASNs to customers, are there any gotchas to be aware of? Is it possible to use the same private ASN for more than one customer on the same PE? What are common and accepted CE-facing BGP practices? MD5 AUTH, GTSM, max prefix limits? Which is preferred, route-maps or prefix-lists for controlling advertised and/or received routes? Do any SPs utilize AS-Path ACLs to check that prefixes from an customer's ASN are claimed to originate from there? Are there any SPs out there offering BFD support for BGP or CE-facing peering sessions? Should we have the customer announce their PA space to us or do we advertise it for them (redist a static)? Do SPs restrict access to tcp/179 on the CE from the Internet in the CE-facing ACL? Do SPs block access to the PE-CE subnet from the outside world like what was described in the Router Security Strategies book (pages 189-193)? What about dropping incoming traffic to everything but the CE IP? While I don't predict our CE-facing BGP load to be terribly significant at this point, I would like to establish sound practices now rather than down the road once we're neck deep in temporarily production workarounds. Is there any consensus on what's best practice for CE-facing BGP? I imagine most SP engineer's BGP practices could be better equated to a religious holy war on par with Chevy vs Ford or Mac vs PC. I would be interested in hearing what they are though and learning from the group's expertise. Thanks Justin From streiner at cluebyfour.org Sat Dec 20 20:11:56 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 20 Dec 2008 21:11:56 -0500 (EST) Subject: Managing CE eBGP details & common/accepted CE-facing BGP practices In-Reply-To: <494D9A61.6080708@justinshore.com> References: <494D9A61.6080708@justinshore.com> Message-ID: On Sat, 20 Dec 2008, Justin Shore wrote: > Does anyone have any preferred ways to manage their customer-facing BGP > details? I'm thinking about the customer's ASN (SP assigned private ASN or > RIR assigned ASN), permitted prefixes, etc? While I'm sure this could be > easily stored in a spreadsheet I'm not sure if there is any merit to storing > some of these details outside of the configuration on the PE (assuming of > course that the PE's config is regularly archived). Now if the PE's BGP > config was auto-generated via a script then it would make sense for all the > details to be stored off in a DB in the NOC. Beyond that is there a good > reason to do archive it in a textual format off of the PE and if there is a > sound reason to do it, is therea good or preferred way to do accomplish this? You could certainly store all of the relevant config details in a database of some sort, and it certainly can't hurt to do so. Same goes for backing up your device configurations - always a good idea. As far as storing things like ASNs, allowed prefixes, etc, you may want to look at storing that information in an RPSL format. Many providers require their customers to register route/AS/policy objects either in one of the Internet Routing Registries (RADB, AltDB, etc...), or in a similar system that's operated by the provider. They then use this information for pushing out configuraiton changes such as the list of prefixes that a customer is allowed to announce, etc. > We're moving beyond our typical residential and very small SMB service to > larger customers over the next few months. These areas have larger, more > advanced customers and I'm sure we'll run into multi-homed environments and > customer who will expect BGP peering options. I would like to be prepared > with sound practices before we get our first customer that wants to get a > default route via BGP, wants full tables, or has their own ASN and is > bringing their own PI space with them. Some of this of course implies > multiple processes to confirm that the ASN belongs to the customer in > question, that the PI space belongs to the customer in question, notifying > our upstreams to accept the customer's PI space, etc. It's hammering out the > scalable and best practice config details that I'm concerned with at the > moment. It's good that you're thinking about this now, particularly the "is this customer legitimately allowed to announce prefix ABC, or source their traffic from AS XYZ"? Most larger providers put at least some limitations on what they will allow a customer to announce, though the level of investigation done to attempt to establich legitimacy for those announcements varies. Some providers require customers to provide some sort of Letter of Authorization/Agency for the prefixes they want to announce. > When assigning private ASNs to customers, are there any gotchas to be aware > of? Is it possible to use the same private ASN for more than one customer on > the same PE? Yes. As long as the organizations that are using the private AS aren't 1. trying to advertise the same space, 2. possibly connect directly to each other directly, or 3. expecting to be able to connect to multiple upstream providers, then you should be OK. VZB (former UUNET) did something similar, using AS7046 (not a private AS, but the principle is the same), and I believe other carriers have had similar arrangements for customers. > What are common and accepted CE-facing BGP practices? MD5 AUTH, GTSM, max > prefix limits? Which is preferred, route-maps or prefix-lists for > controlling advertised and/or received routes? Do any SPs utilize AS-Path > ACLs to check that prefixes from an customer's ASN are claimed to originate > from there? Are there any SPs out there offering BFD support for BGP or > CE-facing peering sessions? MD5 is good, but most providers I've seen make this an opt-in feature - they don't force their customers to use it. Setting a reasonable max-prefix limit and adjusting it as the number of prefixes a customer announces is always a good idea, and I'd consider it to be a best practice. Prefix lists and route maps can do different things, or accomplish the same task in different ways. It also depends on what functionality you want to offer your customers. Do you plan to publish and support a consistent set of customer-settable BGP communities for doing things like selective AS prepends? Do you plan to tag incoming advertisements with communities to identify them as customer routes, and pass those communities to your customers and peers? Some providers use AS path ACLs, and others avoid them at all costs. > Should we have the customer announce their PA space to us or do we advertise > it for them (redist a static)? Do SPs restrict access to tcp/179 on the CE > from the Internet in the CE-facing ACL? Do SPs block access to the PE-CE > subnet from the outside world like what was described in the Router Security > Strategies book (pages 189-193)? What about dropping incoming traffic to > everything but the CE IP? If the customers need to connect to multiple upstream providers, it's much less hassle to have them originate their prefixes from their own AS, and then you just need to propagate them. If they are single-homed, you can announce the prefix(es) for them and then just statically route them to the customer. Other things to consider are sound ingress/egress filtering policies, loose/strict RPF etc. Implementing a Netflow based monitoring solution, and applying flow caching to PE-CE interfaces is also agood idea. > While I don't predict our CE-facing BGP load to be terribly significant at > this point, I would like to establish sound practices now rather than down > the road once we're neck deep in temporarily production workarounds. Again, it's great that you're being proactive about this. Setting up good policies now will make things much easier to maintain and provision in the future as your network grows. Don't forget to document those policies thoroughly, particularly if other people will be tasked with implementing it on a dat yo day basis, i.e. handling new customer turn-ups, making BGP prefix list modifications, etc. > Is there any consensus on what's best practice for CE-facing BGP? I imagine > most SP engineer's BGP practices could be better equated to a religious holy > war on par with Chevy vs Ford or Mac vs PC. I would be interested in hearing > what they are though and learning from the group's expertise. It seems like you have a pretty good handle on what you need to do. I don't know that there will be much of the holy war angle to the responses. Different people adopt different customer routing policies for different reasons - some technical, some business, some political. While there are different ways of accomplishing this task, most of the more scalable ways have already been a part of most large providers' policies for awhile. One-offs are bad, in my opinion, so the more you do to avoid them now, the fewer headaches you will have down the road. jms From ops.lists at gmail.com Sat Dec 20 20:11:04 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 21 Dec 2008 07:41:04 +0530 Subject: Managing CE eBGP details & common/accepted CE-facing BGP practices In-Reply-To: <494D9A61.6080708@justinshore.com> References: <494D9A61.6080708@justinshore.com> Message-ID: On Sun, Dec 21, 2008 at 6:52 AM, Justin Shore wrote: > Does anyone have any preferred ways to manage their customer-facing BGP > details? I'm thinking about the customer's ASN (SP assigned private ASN or > RIR assigned ASN), permitted prefixes, etc? While I'm sure this could be > easily stored in a spreadsheet I'm not sure if there is any merit to storing Heck, you could store all that in Rancid .. even cvs/svn http://homepage.mac.com/duling/halfdozen/RANCID-Howto.htm http://www.devx.com/enterprise/Article/21647 Or Alexi Roudnev used to post this to nanog often enough - nice tool though a bit old - CCR, cisco config repository http://sourceforge.net/projects/snmpstat srs From owenc at hubris.net Sat Dec 20 20:21:06 2008 From: owenc at hubris.net (Chris Owen) Date: Sat, 20 Dec 2008 20:21:06 -0600 Subject: Managing CE eBGP details & common/accepted CE-facing BGP practices In-Reply-To: References: <494D9A61.6080708@justinshore.com> Message-ID: <4E827E88-F120-4E8F-A15F-F488590B2689@hubris.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Dec 20, 2008, at 8:11 PM, Suresh Ramasubramanian wrote: > On Sun, Dec 21, 2008 at 6:52 AM, Justin Shore > wrote: >> Does anyone have any preferred ways to manage their customer-facing >> BGP >> details? I'm thinking about the customer's ASN (SP assigned >> private ASN or >> RIR assigned ASN), permitted prefixes, etc? While I'm sure this >> could be >> easily stored in a spreadsheet I'm not sure if there is any merit >> to storing > > Heck, you could store all that in Rancid .. even cvs/svn > > http://homepage.mac.com/duling/halfdozen/RANCID-Howto.htm http://homepage.mac.com/duling/halfdozen/RANCID-Howto.html Chris - ------------------------------------------------------------------------------ Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 - A stupidity tax Hubris Communications Inc www.hubris.net - ------------------------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Public Key: http://home.hubris.net/owenc/pgpkey.txt Comment: Public Key ID: 0xB513D9DD iEYEARECAAYFAklNqBIACgkQElUlCLUT2d3QtQCfeqvhtuvT2XtgmspuulvYnaTR NpUAn1KB9raSH/sXdCJ72wYh7LlqkKPX =1ZCh -----END PGP SIGNATURE----- From justin at justinshore.com Sat Dec 20 21:01:07 2008 From: justin at justinshore.com (Justin Shore) Date: Sat, 20 Dec 2008 21:01:07 -0600 Subject: Managing CE eBGP details & common/accepted CE-facing BGP practices In-Reply-To: References: <494D9A61.6080708@justinshore.com> Message-ID: <494DB173.2090305@justinshore.com> Suresh Ramasubramanian wrote: > Heck, you could store all that in Rancid .. even cvs/svn I should have said it earlier when I mentioned config backups. I'm already a heavy user of RANCID, archiving my configs hourly. Been using it since right around v2.0-2.1 which would be several years ago (feels like a lifetime). So my config backups are more than taken care of. What I'm interested in is if I should also document the PE-CE BGP config details elsewhere or if I should just leave them in the PE and let my backups cover me. Part of what's driving this is my desire to create a book of templates for our assorted product offerings that covers both PEs and CEs. Eventually I won't be able to handle everything myself and staff will have to be added. Eventually we'll have to separate operations, engineering, security and maybe even install/turnup tasks. I'd like there to be a solid practices established and documented in a solutions bible of sorts before that happens. My brain can only store so much info and I can only do so much in a day. Plus having all these details ironed out sooner rather than later, and documented, will help keep me honest (ie, no band-aides that I plan on removing when I get time ). The other added benefit is that as I figure out how to do something rather fancy or in a simple and elegant manner I can document it for my own benefit and others. So back to the original topics, does anyone have suggestions for CE-facing BGP config or the management and documentation of the CE details? I'm experimenting with peer-policy and peer-session templates right now. I'm sure with dozens or hundreds of peers their benefits would be more evident. So far they only seem to reduce my default-only test peers by 3 lines of config each. I'm sure this would be more saved lines of config if I was doing something more fancy. Thanks for the input Justin From ops.lists at gmail.com Sat Dec 20 21:46:15 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 21 Dec 2008 09:16:15 +0530 Subject: Managing CE eBGP details & common/accepted CE-facing BGP practices In-Reply-To: <494DB173.2090305@justinshore.com> References: <494D9A61.6080708@justinshore.com> <494DB173.2090305@justinshore.com> Message-ID: On Sun, Dec 21, 2008 at 8:31 AM, Justin Shore wrote: > I should have said it earlier when I mentioned config backups. I'm already > a heavy user of RANCID, archiving my configs hourly. Been using it since > right around v2.0-2.1 which would be several years ago (feels like a > lifetime). So my config backups are more than taken care of. What I'm > interested in is if I should also document the PE-CE BGP config details > elsewhere or if I should just leave them in the PE and let my backups cover > me. Sounds like a job for svn with a web based frontend to track configs. --srs From adrian at creative.net.au Sat Dec 20 21:58:42 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Sun, 21 Dec 2008 12:58:42 +0900 Subject: Gigabit Linux Routers In-Reply-To: References: <200812192340.mBJNeHNN048264@aurora.sol.net> Message-ID: <20081221035842.GB29381@skywalker.creative.net.au> On Sat, Dec 20, 2008, Ingo Flaschberger wrote: > I'm not shure if this setup would ever be "stable". > also with ucarp tweaks. > hopefully freebsd supports soon more than 1 route. > FreeBSD, like all good open source projects, gets features supported when people code them up. So if you'd like to see FreeBSD support it, either code it up, or pay soemone to code it up. Then everyone benefits. :) Adrian From d.thomas at its.uq.edu.au Sun Dec 21 15:47:23 2008 From: d.thomas at its.uq.edu.au (Danny Thomas) Date: Mon, 22 Dec 2008 07:47:23 +1000 Subject: Managing CE eBGP details & common/accepted CE-facing BGP practices In-Reply-To: References: <494D9A61.6080708@justinshore.com> <494DB173.2090305@justinshore.com> Message-ID: <494EB96B.4080605@its.uq.edu.au> Suresh Ramasubramanian wrote: > On Sun, Dec 21, 2008 at 8:31 AM, Justin Shore wrote: > > >> I should have said it earlier when I mentioned config backups. I'm already >> a heavy user of RANCID, archiving my configs hourly. Been using it since >> right around v2.0-2.1 which would be several years ago (feels like a >> lifetime). So my config backups are more than taken care of. What I'm >> interested in is if I should also document the PE-CE BGP config details >> elsewhere or if I should just leave them in the PE and let my backups cover >> me. >> > > Sounds like a job for svn with a web based frontend to track configs. > we've been using rancid for years and the configs are used by many scripts * rancid modified to no longer remove the lines at the top of "sh run" to identify times config and NVRAM last updated and send email if the NVRAM is substantially older than running config * ip-helpers are compared against our dhcp config * subnets, routers, vlans, gateway and hsrp addresses are compared against our database of network information * the configs are analysed by a script to identify items not matching our config standard; ideally configs would be generated from templates but I'm not in a position to make that happen * routed address-space is compared against reverse dns * when we had border bogon filtering, those ACLs and null-routes were compared against a freshly-downloaded aggregated bogon list one of the problems with rancid is that the code makes it hard to do other things, e.g. compare the active and standby configs in our 6500s I'd also like to add a feature that recognizes the significant blocks in a config and store in a database so you can do queries like "when was vlan777 modified" Danny From nanog at daork.net Sun Dec 21 16:41:42 2008 From: nanog at daork.net (Nathan Ward) Date: Mon, 22 Dec 2008 11:41:42 +1300 Subject: Managing CE eBGP details & common/accepted CE-facing BGP practices In-Reply-To: <494EB96B.4080605@its.uq.edu.au> References: <494D9A61.6080708@justinshore.com> <494DB173.2090305@justinshore.com> <494EB96B.4080605@its.uq.edu.au> Message-ID: <3B025F13-B4A0-4D1A-9F9E-45489BF01957@daork.net> On 22/12/2008, at 10:47 AM, Danny Thomas wrote: > I'd also like to add a feature that recognizes the significant > blocks in a config > and store in a database so you can do queries like "when was vlan777 > modified" This sounds like a job for captain SNMP(trap/inform) or RADIUS or TACACS+! -- Nathan Ward From sean at donelan.com Sun Dec 21 17:34:42 2008 From: sean at donelan.com (Sean Donelan) Date: Sun, 21 Dec 2008 18:34:42 -0500 (EST) Subject: Security Intelligence [Was: Re: Netblock reassigned from Chile to US ISP...] In-Reply-To: <494C651C.8020508@psg.com> References: <6cd462c00812130029k7b08b8d5rd92c68dc9550a94e@mail.gmail.com> <6cd462c00812130044k1178ba82kd0df6c3e7b2255d5@mail.gmail.com> <49437781.2000005@psg.com> <494C651C.8020508@psg.com> Message-ID: <200812211800240.32BF5B92.4507@clifden.donelan.com> On Sat, 20 Dec 2008, Randy Bush wrote: > unfortunately snort does not really scale to a larger provider. and, to the > best of my poor knowledge, good open source tools to black-hole/redirect > botted users are not generally available. universities have some that are > good at campus and enterprise scale. > > cymru and a few security researchers responded privately to my plea for solid > open source tool sets and refs. knowing the folk involved, maybe we'll see > some motion. patience is a virtue, within limits. Pretty much the same thing I've been telling "security vendors" since 2003. In 2003 the hard problem wasn't, and still isn't, detection (IDS, AV scanners, honeypots, etc), its customer remediation (fixing things). Unfortunately, if all you are selling are hammers.... A security vendor's sale person concept of "scaling" is "more commission." You may need to leave the network engineer's world and start talking to the customer care engineer's side of the house. Its a different set of systems, and a different set of scaling issues. How do you notify 50 million customers about an issue? Marketing people probably know how to do it better than network engineers. 1. Add flags to your customer support systems about different customer status, so when customers contact your call centers the agents can start on the best script for "known" problems. 2. Include customer status flags on your portals (details behind some level of authentication in case the account is being shared). 3. Obtain and communicate with your customers through multiple channels respecting their preferences (e.g. e-mail, alternate e-mail, postal mail, telephone). Even non-US ISPs may want to look at the US FTC "red flag" rules. Why do I mention those things? Because I've found out (mostly the hard way) the remediation part of the process is the bottleneck. It doesn't matter how many bad things you detect, if you can only fix a limited number at a time. Detecting stuff below the remediation threshold is going to be wasted; and those resources probably would have been better used for more remediation efforts. Yes, the bad guys may know that too. But if we got to the point where the bad guys actually worry about staying below the remediation threshold; that would be more progress than now. Hint: if you could prove to a large ISP you could shave 60 seconds off the average customer care call by fixing security problems faster; they would probably be beating down your door begging for it. From justin at justinshore.com Sun Dec 21 18:19:47 2008 From: justin at justinshore.com (Justin Shore) Date: Sun, 21 Dec 2008 18:19:47 -0600 Subject: Managing CE eBGP details & common/accepted CE-facing BGP practices In-Reply-To: References: <494D9A61.6080708@justinshore.com> Message-ID: <494EDD23.2050909@justinshore.com> Evening, Justin. Thanks for the reply. Justin M. Streiner wrote: > You could certainly store all of the relevant config details in a > database of some sort, and it certainly can't hurt to do so. Same goes > for backing up your device configurations - always a good idea. As far > as storing things like ASNs, allowed prefixes, etc, you may want to look > at storing that information in an RPSL format. Many providers require > their customers to register route/AS/policy objects either in one of the > Internet Routing Registries (RADB, AltDB, etc...), or in a similar > system that's operated by the provider. They then use this information > for pushing out configuraiton changes such as the list of prefixes that > a customer is allowed to announce, etc. RPSL could definitely be useful when we starting reaching that class of customer. It's probably too grand for our users at this point (especially having them register anything on their own). I'll definitely do more research on this though. > It's good that you're thinking about this now, particularly the "is this > customer legitimately allowed to announce prefix ABC, or source their > traffic from AS XYZ"? Most larger providers put at least some > limitations on what they will allow a customer to announce, though the > level of investigation done to attempt to establich legitimacy for those > announcements varies. Some providers require customers to provide some > sort of Letter of Authorization/Agency for the prefixes they want to > announce. The process hasn't been established yet for validating a request to permit a prefix announcement. I expect it will be a manual verification process involving WHOIS lookups on the prefix, route-view queries to see if it's currently being advertised and probably a historical check on that prefix to see if it was previously advertised and from where. The best way to avoid network abuse issues is to not let them happen to begin with. I think we will also require some sort of written legal agreement stating that the prefix in question belongs to the customer and that we're authorized to permit it's advertisement across our network. If anyone has any sample documents for use in this process I would be interested in seeing them. > Yes. As long as the organizations that are using the private AS aren't > 1. trying to advertise the same space, 2. possibly connect directly to > each other directly, or 3. expecting to be able to connect to multiple > upstream providers, then you should be OK. VZB (former UUNET) did > something similar, using AS7046 (not a private AS, but the principle is > the same), and I believe other carriers have had similar arrangements > for customers. Ah, yes connecting to each other could be a problem. I would think that it would only be an issue if I carried the private ASN across my iBGP infrastructure, each customer received full routes from me and I let them see the private ASNs as well. I could mitigate that problem with remove-private-as, I believe. I'd need to think on that some more. If the customer wants to be multi-homed and expect reachability then they should get an ASN. Otherwise both SPs are advertising their prefixes and the customer won't have much or possibly any control over which inbound path was preferred. > MD5 is good, but most providers I've seen make this an opt-in feature - > they don't force their customers to use it. Setting a reasonable > max-prefix limit and adjusting it as the number of prefixes a customer > announces is always a good idea, and I'd consider it to be a best > practice. Prefix lists and route maps can do different things, or > accomplish the same task in different ways. It also depends on what > functionality you want to offer your customers. Do you plan to publish > and support a consistent set of customer-settable BGP communities for > doing things like selective AS prepends? Do you plan to tag incoming > advertisements with communities to identify them as customer routes, and > pass those communities to your customers and peers? Some providers use > AS path ACLs, and others avoid them at all costs. I think I'll make MD5 part of the default config and let the customer ask for it to be removed if they choose to not have it. Same for GTSM. I'm a fan of max-prefixes. I think double the routes I expect to receive, 75% warning and a restart interval of 5m would be a good place to start. That would let me catch things happening before they got out of hand (in normal circumstances) and give me a fail-safe in case they decide to get crazy. I do plan on implementing a BGP community solution but for now I'm going to keep it simple. I have bigger fish to fry at the moment but I'll try to get it done before we get asked for it by a customer. I will tag transit and customer routes. The ISP Essentials book had some good insight on that if memory serves me correctly. How fancy it gets will depend on my time and customer demand. I've seen some extremely complex setups that I could not replicate if my life depended on it. The AS-Path filtering should only come into effect when we get a customer with their own ASN in which cases we'll actually pass on their advertisements (whereas with private ASNs we're only carrying them internally and summarizing on the upstream edges). That way I can ensure 1) that they claim to source the prefixes from their ASN and not someone else's and 2) that they don't insert BS ASNs into the path. > If the customers need to connect to multiple upstream providers, it's > much less hassle to have them originate their prefixes from their own > AS, and then you just need to propagate them. If they are single-homed, > you can announce the prefix(es) for them and then just statically route > them to the customer. Other things to consider are sound ingress/egress > filtering policies, loose/strict RPF etc. Implementing a Netflow based > monitoring solution, and applying flow caching to PE-CE interfaces is > also agood idea. I have a good set of residential and tiny SMB customer ACLs. I'm trying to decide what I should use for these larger SMBs. I'm sure some will be custom but I need to come up with a sane default set of ACLs. Some things I refuse to not block. The customer can find a different provider if they want certain things to not be blocked. Until we get a multi-homed customer that wants inbound reachability we'll go with strict uRPF; that's already in my interface templates. I have NFSen set up but all it's really doing right now is filling my hard drives. I haven't had much time to do anything else with it I'm afraid. I'll point NF to MARS box when it gets here though. I forget, does route-cache flow alter the packet switching capabilities of an interface these days or is that just to turn on NF on an interface? Seems like since CEF it only turns on NF. > Again, it's great that you're being proactive about this. Setting up > good policies now will make things much easier to maintain and provision > in the future as your network grows. Don't forget to document those > policies thoroughly, particularly if other people will be tasked with > implementing it on a dat yo day basis, i.e. handling new customer > turn-ups, making BGP prefix list modifications, etc. That's my goal. I prefer to be organized from the get go whenever possible. I don't like surprises in my work (unless it's a big, unexpected raise). > It seems like you have a pretty good handle on what you need to do. I > don't know that there will be much of the holy war angle to the > responses. Different people adopt different customer routing policies > for different reasons - some technical, some business, some political. > While there are different ways of accomplishing this task, most of the > more scalable ways have already been a part of most large providers' > policies for awhile. I have an idea of what all needs to be implemented but I'm short on time to hone my skills by trial and error. > One-offs are bad, in my opinion, so the more you do to avoid them now, > the fewer headaches you will have down the road. Definitely. One-offs are like using duct tape to repair a Porsche. It's just not right. Thanks for the input. It's much appreciated. Justin From mrz at velvet.org Sun Dec 21 21:24:09 2008 From: mrz at velvet.org (matthew zeier) Date: Sun, 21 Dec 2008 19:24:09 -0800 Subject: open source alternative to Internap's FCP? Message-ID: <711E9A98-83E0-4193-B730-E53C47305C90@velvet.org> Perhaps I just can't google right - does anyone know of any open source alternatives to Internap's FCP or the Avaya/RouteScience PathControl? From oberman at es.net Mon Dec 22 00:23:26 2008 From: oberman at es.net (Kevin Oberman) Date: Sun, 21 Dec 2008 22:23:26 -0800 Subject: Gigabit Linux Routers In-Reply-To: Your message of "Sun, 21 Dec 2008 12:58:42 +0900." <20081221035842.GB29381@skywalker.creative.net.au> Message-ID: <20081222062326.D370E45020@ptavv.es.net> > Date: Sun, 21 Dec 2008 12:58:42 +0900 > From: Adrian Chadd > > On Sat, Dec 20, 2008, Ingo Flaschberger wrote: > > > I'm not shure if this setup would ever be "stable". > > also with ucarp tweaks. > > hopefully freebsd supports soon more than 1 route. > > > > FreeBSD, like all good open source projects, gets features supported when > people code them up. > > So if you'd like to see FreeBSD support it, either code it up, or > pay someone to code it up. Then everyone benefits. :) I might mention that the development branch of FreeBSD (8-current) now supports multiple routing tables, so it looks like it is on the way. Note that these are being done for broader purposes than those being discussed in this thread, but I believe that they will do most of what is needed. If you are interested, I'm sure Julian would appreciate testing and input. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From nanog at daork.net Mon Dec 22 04:27:01 2008 From: nanog at daork.net (Nathan Ward) Date: Mon, 22 Dec 2008 23:27:01 +1300 Subject: Managing CE eBGP details & common/accepted CE-facing BGP practices In-Reply-To: <494D9A61.6080708@justinshore.com> References: <494D9A61.6080708@justinshore.com> Message-ID: <0362E669-2AD4-4E7A-9A9F-9484F0CB98DB@daork.net> On 21/12/2008, at 2:22 PM, Justin Shore wrote: > While I'm sure this could be easily stored in a spreadsheet I think the best piece of advice I ever saw RE network management, is teach your network ops people basic SQL. Spreadsheets work OK for one- off calculations, use SQL for any sort of data storage. This is a perfect example of where that would be useful. > What are common and accepted CE-facing BGP practices? MD5 AUTH, > GTSM, max prefix limits? Which is preferred, route-maps or prefix- > lists for controlling advertised and/or received routes? Do any SPs > utilize AS-Path ACLs to check that prefixes from an customer's ASN > are claimed to originate from there? Are there any SPs out there > offering BFD support for BGP or CE-facing peering sessions? My recommendation here, when talking about incoming advertisements from customers is to use prefix lists *and* route-maps. Use prefix lists for an overall accept/reject. Use route-maps to tag received prefixes with communities. Use these communities on your border/peering routers to control advertisements. This way, you make your border/peering routers low-touch - adding a new customer prefix only needs to be done on the customer edge, and that can be done by your provisioning guys leaving your more "important" routers to only be touched by people who *really* know what they're doing, in theory. Having some well known communities to allow your customers to control their advertisements would be nice as well - to encourage you to prefer/not prefer, and also control how you advertise their prefixes outside your network. Have a read after "Communities accepted from customers" in the RADB WHOIS for AS3356 for a fairly comprehensive example. Other's might have better examples, but I've often used this one as being pretty good. (whois -h whois.radb.net AS3356) -- Nathan Ward From michael.dillon at bt.com Mon Dec 22 04:53:58 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 22 Dec 2008 10:53:58 -0000 Subject: Managing CE eBGP details & common/accepted CE-facing BGP practices In-Reply-To: <0362E669-2AD4-4E7A-9A9F-9484F0CB98DB@daork.net> Message-ID: > Have a read after "Communities accepted from customers" in > the RADB WHOIS for AS3356 for a fairly comprehensive example. > Other's might have better examples, but I've often used this > one as being pretty good. > (whois -h whois.radb.net AS3356) You can also read this here: --Michael Dillon From eddy+public+spam at noc.everquick.net Mon Dec 22 09:03:12 2008 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Mon, 22 Dec 2008 15:03:12 +0000 (GMT) Subject: ICANN/Dotster emergency contacts? (hopefully not too OT) Message-ID: Greetings, Does anyone have any "emergency" contacts at ICANN? Dotster? I have a couple domains that were erroneously expired this year instead of next. (I have the CC statement and ref # in front of me, to be certain that I'm not hallucinating.) Automated web form failed to send (to different domain) account info, and hold time is getting annoying. I've already filed the ICANN complaint, but that doesn't restore service. I'd buy an extra year and worry about the dispute later, but see note about automated web form. Please CC me @brotsman.com, and I can't currently receive email via the address by which I'm subscribed. And off-list, please. I don't want to drag things even farther OT than I already have. Thanks, and sorry for the panicked OT noise, Eddy (please remember to s/noc.everquick.net/brotsman.com/) -- 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 at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From eddy+public+spam at noc.everquick.net Mon Dec 22 10:25:51 2008 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Mon, 22 Dec 2008 16:25:51 +0000 (GMT) Subject: ICANN/Dotster emergency contacts? (hopefully not too OT) Message-ID: Thanks, all. I have several responses, and finally got through. Again, sorry for the OT noise. 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 at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From ge at linuxbox.org Mon Dec 22 11:07:05 2008 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 22 Dec 2008 11:07:05 -0600 (CST) Subject: [USN-698-1] Nagios vulnerability (fwd) Message-ID: ---------- Forwarded message ---------- Date: Mon, 22 Dec 2008 09:35:54 -0500 From: Marc Deslauriers To: ubuntu-security-announce at lists.ubuntu.com Cc: bugtraq at securityfocus.com, full-disclosure at lists.grok.org.uk Subject: [USN-698-1] Nagios vulnerability =========================================================== Ubuntu Security Notice USN-698-1 December 22, 2008 nagios vulnerability CVE-2008-5027 =========================================================== A security issue affects the following Ubuntu releases: Ubuntu 6.06 LTS This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 6.06 LTS: nagios-common 2:1.3-cvs.20050402-8ubuntu8 After a standard system upgrade you need to restart Nagios to effect the necessary changes. Details follow: It was discovered that Nagios did not properly parse commands submitted using the web interface. An authenticated user could use a custom form or a browser addon to bypass security restrictions and submit unauthorized commands. Updated packages for Ubuntu 6.06 LTS: Source archives: http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios_1.3-cvs.20050402-8ubuntu8.diff.gz Size/MD5: 70914 96d8036bdb33aadd3141715039c91b24 http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios_1.3-cvs.20050402-8ubuntu8.dsc Size/MD5: 959 0393336015bf452f5dfeb74d75245311 http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios_1.3-cvs.20050402.orig.tar.gz Size/MD5: 1621251 0f92b7b8e705411b7881d3650cbb5d56 Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-common_1.3-cvs.20050402-8ubuntu8_all.deb Size/MD5: 1218132 d18e298ee16f4c6c6b7c5969c46044e6 amd64 architecture (Athlon64, Opteron, EM64T Xeon): http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-mysql_1.3-cvs.20050402-8ubuntu8_amd64.deb Size/MD5: 1030206 085483fdefd0d7bc43e55dbc5be2bcd6 http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-pgsql_1.3-cvs.20050402-8ubuntu8_amd64.deb Size/MD5: 1041656 09fc7bb2ff11062603680d09e290909b http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-text_1.3-cvs.20050402-8ubuntu8_amd64.deb Size/MD5: 1025618 61619d13effd9a4970486abf5933c756 i386 architecture (x86 compatible Intel/AMD): http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-mysql_1.3-cvs.20050402-8ubuntu8_i386.deb Size/MD5: 877846 544afaebec24e7e94d2ce1da3a89346c http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-pgsql_1.3-cvs.20050402-8ubuntu8_i386.deb Size/MD5: 886544 411d3ca5a204aa41a4a42ef6e5f56453 http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-text_1.3-cvs.20050402-8ubuntu8_i386.deb Size/MD5: 872936 aa31f6d1fb8a081a206eae3d6bfb3dd6 powerpc architecture (Apple Macintosh G3/G4/G5): http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-mysql_1.3-cvs.20050402-8ubuntu8_powerpc.deb Size/MD5: 1015630 540a27062c7f8612b7f460b2bcfd93b9 http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-pgsql_1.3-cvs.20050402-8ubuntu8_powerpc.deb Size/MD5: 1024374 47e0480006df0b20a83f67b56da7a9f8 http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-text_1.3-cvs.20050402-8ubuntu8_powerpc.deb Size/MD5: 993324 03a67a7675075050a672a4c515e8e0c3 sparc architecture (Sun SPARC/UltraSPARC): http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-mysql_1.3-cvs.20050402-8ubuntu8_sparc.deb Size/MD5: 918810 7340348f043dd884c88bd016ee30e41d http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-pgsql_1.3-cvs.20050402-8ubuntu8_sparc.deb Size/MD5: 926172 e9ccf388b828a17e868807aa39cb5b51 http://security.ubuntu.com/ubuntu/pool/main/n/nagios/nagios-text_1.3-cvs.20050402-8ubuntu8_sparc.deb Size/MD5: 917374 c88dec0d93f590f8a93ebbc701696f68 From lionair at samsung.com Mon Dec 22 18:10:24 2008 From: lionair at samsung.com (=?euc-kr?B?waTEob+1?=) Date: Tue, 23 Dec 2008 00:10:24 +0000 (GMT) Subject: What is the most standard subnet length on internet Message-ID: <10068989.128811229991024019.JavaMail.weblogic@epml06> Hi all, I appreciate many people gave me advices, Some of persons asked me about my questions, I'm sorry for that I couldn't reply to everyone. Because of your help, I could get many opinions and standards regarding IP allocation policy. by the way, in APNIC's IP allocation sizes policy, there is a comments like below. "Below are the minimum sizes for allocations and assignments, This information is provided at the request of the ISP community to assist in filtering policy decisions " Currently, is there any provider filtering routes under LIR's minimum allocation size such as /22 ? Best regards, ============================================= Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lionair at samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 ============================================= ------- Original Message ------- Sender : Danny McPherson Date : 2008-12-21 02:42 (GMT+09:00) Title : Re: What is the most standard subnet length on internet On Dec 18, 2008, at 9:43 PM, ??? wrote: > Suresh, > > Yes, I guess my concern is close to the second meaning. > > It seems so simple. Currently annoucement of /24 seems to be okey, > most upstream providers accept this. > However I wonder if there is any ground rule based on any standard > or official recommandation. > If there is some standardized rule about prefix length to be > annouced, I will make my bgp & IP allocation policy of > each data center of my company, and I will be able to more fairly > and squarely speak to my customer like this > "You have to change your server's IP address if you want move your > server to other place" Some useful guidance is provided here (and in subsequent references) as well: An Architecture for IP Address Allocation with CIDR Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy Network Renumbering Overview A Framework for Inter-Domain Route Aggregation HTH, -danny From sethm at rollernet.us Mon Dec 22 18:31:52 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 22 Dec 2008 16:31:52 -0800 Subject: What is the most standard subnet length on internet In-Reply-To: <10068989.128811229991024019.JavaMail.weblogic@epml06> References: <10068989.128811229991024019.JavaMail.weblogic@epml06> Message-ID: <49503178.3000304@rollernet.us> ??? wrote: > Hi all, > > I appreciate many people gave me advices, > Some of persons asked me about my questions, I'm sorry for that I couldn't reply to everyone. > Because of your help, I could get many opinions and standards regarding IP allocation policy. > > by the way, in APNIC's IP allocation sizes policy, there is a comments like below. > "Below are the minimum sizes for allocations and assignments, This information is provided at the request of the ISP community > to assist in filtering policy decisions " > Currently, is there any provider filtering routes under LIR's minimum allocation size such as /22 ? > Anyone running a platform that can't take a full table would apply such a filter to weed out anyone who likes to announce all of their space as /24's for "traffic engineering". If one does that and doesn't announce the aggregate as well, one could find themselves facing random black holes. ~Seth From nanog at daork.net Mon Dec 22 19:08:25 2008 From: nanog at daork.net (Nathan Ward) Date: Tue, 23 Dec 2008 14:08:25 +1300 Subject: What is the most standard subnet length on internet In-Reply-To: <49503178.3000304@rollernet.us> References: <10068989.128811229991024019.JavaMail.weblogic@epml06> <49503178.3000304@rollernet.us> Message-ID: <85D6FED5-AB83-4AFD-940F-3A8386216CDB@daork.net> On 23/12/2008, at 1:31 PM, Seth Mattinen wrote: > Anyone running a platform that can't take a full table would apply > such a filter to weed out anyone who likes to announce all of their > space as /24's for "traffic engineering". If one does that and > doesn't announce the aggregate as well, one could find themselves > facing random black holes. People are filtering /24s without a 0/0 route? -- Nathan Ward From jlewis at lewis.org Mon Dec 22 19:11:45 2008 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 22 Dec 2008 20:11:45 -0500 (EST) Subject: What is the most standard subnet length on internet In-Reply-To: <49503178.3000304@rollernet.us> References: <10068989.128811229991024019.JavaMail.weblogic@epml06> <49503178.3000304@rollernet.us> Message-ID: On Mon, 22 Dec 2008, Seth Mattinen wrote: > Anyone running a platform that can't take a full table would apply such a > filter to weed out anyone who likes to announce all of their space as /24's > for "traffic engineering". If one does that and doesn't announce the > aggregate as well, one could find themselves facing random black holes. There's no "if" about it. Months ago when I and others were looking into this, we found plenty of examples of networks with /19s, /20s, etc. announcing only the /24 deaggregates. If you plan to filter these people and have customers to answer to, you'll need to point default at someone who's not filtering them. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From sethm at rollernet.us Mon Dec 22 19:24:43 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 22 Dec 2008 17:24:43 -0800 Subject: What is the most standard subnet length on internet In-Reply-To: <85D6FED5-AB83-4AFD-940F-3A8386216CDB@daork.net> References: <10068989.128811229991024019.JavaMail.weblogic@epml06> <49503178.3000304@rollernet.us> <85D6FED5-AB83-4AFD-940F-3A8386216CDB@daork.net> Message-ID: <49503DDB.8030208@rollernet.us> Nathan Ward wrote: > On 23/12/2008, at 1:31 PM, Seth Mattinen wrote: >> Anyone running a platform that can't take a full table would apply >> such a filter to weed out anyone who likes to announce all of their >> space as /24's for "traffic engineering". If one does that and doesn't >> announce the aggregate as well, one could find themselves facing >> random black holes. > > > People are filtering /24s without a 0/0 route? > I was just referring to LIR boundaries, but yes, I've seen it happen where someone splits their /22 into only /24s and doesn't announce the covering /22. ~Seth From Valdis.Kletnieks at vt.edu Mon Dec 22 19:30:15 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 22 Dec 2008 20:30:15 -0500 Subject: What is the most standard subnet length on internet In-Reply-To: Your message of "Tue, 23 Dec 2008 14:08:25 +1300." <85D6FED5-AB83-4AFD-940F-3A8386216CDB@daork.net> References: <10068989.128811229991024019.JavaMail.weblogic@epml06> <49503178.3000304@rollernet.us> <85D6FED5-AB83-4AFD-940F-3A8386216CDB@daork.net> Message-ID: <11566.1229995815@turing-police.cc.vt.edu> On Tue, 23 Dec 2008 14:08:25 +1300, Nathan Ward said: > People are filtering /24s without a 0/0 route? Hell - people have been known to filter entire /8's and fail to notice the resulting damage. See the bogon filters for 69/8, then 70/8, then... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From nanog at daork.net Mon Dec 22 19:34:39 2008 From: nanog at daork.net (Nathan Ward) Date: Tue, 23 Dec 2008 14:34:39 +1300 Subject: What is the most standard subnet length on internet In-Reply-To: <49503DDB.8030208@rollernet.us> References: <10068989.128811229991024019.JavaMail.weblogic@epml06> <49503178.3000304@rollernet.us> <85D6FED5-AB83-4AFD-940F-3A8386216CDB@daork.net> <49503DDB.8030208@rollernet.us> Message-ID: On 23/12/2008, at 2:24 PM, Seth Mattinen wrote: > Nathan Ward wrote: >> On 23/12/2008, at 1:31 PM, Seth Mattinen wrote: >>> Anyone running a platform that can't take a full table would apply >>> such a filter to weed out anyone who likes to announce all of >>> their space as /24's for "traffic engineering". If one does that >>> and doesn't announce the aggregate as well, one could find >>> themselves facing random black holes. >> People are filtering /24s without a 0/0 route? > > I was just referring to LIR boundaries, but yes, I've seen it happen > where someone splits their /22 into only /24s and doesn't announce > the covering /22. Yes, it happens all the time. Let me rephrase; Are there people who are filtering /24s received from eBGP peers who do not have a default route? I mean the networks who receive those prefixes, not the ones who advertise them. -- Nathan Ward From nanog-post at rsuc.gweep.net Mon Dec 22 19:39:25 2008 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Mon, 22 Dec 2008 20:39:25 -0500 Subject: What is the most standard subnet length on internet In-Reply-To: References: <10068989.128811229991024019.JavaMail.weblogic@epml06> <49503178.3000304@rollernet.us> <85D6FED5-AB83-4AFD-940F-3A8386216CDB@daork.net> <49503DDB.8030208@rollernet.us> Message-ID: <20081223013925.GA42151@gweep.net> On Tue, Dec 23, 2008 at 02:34:39PM +1300, Nathan Ward wrote: [snip] > Let me rephrase; Are there people who are filtering /24s received from > eBGP peers who do not have a default route? of course. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From nanog at daork.net Mon Dec 22 19:44:46 2008 From: nanog at daork.net (Nathan Ward) Date: Tue, 23 Dec 2008 14:44:46 +1300 Subject: What is the most standard subnet length on internet In-Reply-To: <20081223013925.GA42151@gweep.net> References: <10068989.128811229991024019.JavaMail.weblogic@epml06> <49503178.3000304@rollernet.us> <85D6FED5-AB83-4AFD-940F-3A8386216CDB@daork.net> <49503DDB.8030208@rollernet.us> <20081223013925.GA42151@gweep.net> Message-ID: <41036FF1-4200-4D16-B69D-1D3A91DDFCC1@daork.net> On 23/12/2008, at 2:39 PM, Joe Provo wrote: > On Tue, Dec 23, 2008 at 02:34:39PM +1300, Nathan Ward wrote: > [snip] >> Let me rephrase; Are there people who are filtering /24s received >> from >> eBGP peers who do not have a default route? > > of course. Curiously, it was really meant as a rhetorical question where the answer was "no". Why are people doing this? Are they lacking clue, or, is there some reasonable purpose? -- Nathan Ward From lionair at samsung.com Mon Dec 22 20:35:37 2008 From: lionair at samsung.com (ChiYoung Joung) Date: Tue, 23 Dec 2008 02:35:37 +0000 (GMT) Subject: What is the most standard subnet length on internet Message-ID: <11563780.140481229999737082.JavaMail.weblogic@epml06> I would like to ask question more specifically. I know most of tier1 providers accept their customer prefixes smaller than /24. it means smaller than /24 routes always routable in that Tier1 provider. What about between Tier1 and another Tier1 ? Do they exchange their full customer's routes without any limitation of prefixes length ? or do they refer to some DB information like Regional Internet Registry and apply another filter on neighbor configuration with another Tier1 ? Chiyoung ============================================= Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lionair at samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 ============================================= ------- Original Message ------- Sender : Nathan Ward Date : 2008-12-23 10:44 (GMT+09:00) Title : Re: What is the most standard subnet length on internet On 23/12/2008, at 2:39 PM, Joe Provo wrote: > On Tue, Dec 23, 2008 at 02:34:39PM +1300, Nathan Ward wrote: > [snip] >> Let me rephrase; Are there people who are filtering /24s received >> from >> eBGP peers who do not have a default route? > > of course. Curiously, it was really meant as a rhetorical question where the answer was "no". Why are people doing this? Are they lacking clue, or, is there some reasonable purpose? -- Nathan Ward From tomb at byrneit.net Mon Dec 22 20:40:19 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Mon, 22 Dec 2008 18:40:19 -0800 Subject: What is the most standard subnet length on internet In-Reply-To: <41036FF1-4200-4D16-B69D-1D3A91DDFCC1@daork.net> References: <10068989.128811229991024019.JavaMail.weblogic@epml06><49503178.3000304@rollernet.us><85D6FED5-AB83-4AFD-940F-3A8386216CDB@daork.net><49503DDB.8030208@rollernet.us><20081223013925.GA42151@gweep.net> <41036FF1-4200-4D16-B69D-1D3A91DDFCC1@daork.net> Message-ID: <70D072392E56884193E3D2DE09C097A9FC05@pascal.zaphodb.org> BGP Hijacking. Fully peered network A accepts routes from its peers based on prefix allocation to AS maps. Network B, which is either pathological (criminal, or bent on censorship) or lacking clue, propagates /24 subnet of Network C's CIDR (Pakistan/YouTube anyone). If network A accepts Network B's announcement, then connectivity from network A to the /24 announced by Network B (which isn't really connected to network B) is either lost, or worse, hijacked. >-----Original Message----- >From: Nathan Ward [mailto:nanog at daork.net] >Sent: Monday, December 22, 2008 5:45 PM >To: nanog list >Subject: Re: What is the most standard subnet length on internet > >On 23/12/2008, at 2:39 PM, Joe Provo wrote: > >> On Tue, Dec 23, 2008 at 02:34:39PM +1300, Nathan Ward wrote: >> [snip] >>> Let me rephrase; Are there people who are filtering /24s received >>> from >>> eBGP peers who do not have a default route? >> >> of course. > > >Curiously, it was really meant as a rhetorical question where the >answer was "no". > >Why are people doing this? Are they lacking clue, or, is there some >reasonable purpose? > >-- >Nathan Ward > > > > From Skywing at valhallalegends.com Mon Dec 22 21:01:51 2008 From: Skywing at valhallalegends.com (Skywing) Date: Mon, 22 Dec 2008 21:01:51 -0600 Subject: What is the most standard subnet length on internet Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA25F0D@caralain.haven.nynaeve.net> I am sure that there are foolish people doing foolish things somewhere on the Internet. But perhaps Joe had knowledge of a specific example && possibly "reasoning" from said example as to why they were using a broken configuration as that? ? S -----Original Message----- From: Nathan Ward Sent: Monday, December 22, 2008 19:45 To: nanog list Subject: Re: What is the most standard subnet length on internet On 23/12/2008, at 2:39 PM, Joe Provo wrote: > On Tue, Dec 23, 2008 at 02:34:39PM +1300, Nathan Ward wrote: > [snip] >> Let me rephrase; Are there people who are filtering /24s received >> from >> eBGP peers who do not have a default route? > > of course. Curiously, it was really meant as a rhetorical question where the answer was "no". Why are people doing this? Are they lacking clue, or, is there some reasonable purpose? -- Nathan Ward From Valdis.Kletnieks at vt.edu Mon Dec 22 21:04:36 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 22 Dec 2008 22:04:36 -0500 Subject: What is the most standard subnet length on internet In-Reply-To: Your message of "Tue, 23 Dec 2008 14:44:46 +1300." <41036FF1-4200-4D16-B69D-1D3A91DDFCC1@daork.net> References: <10068989.128811229991024019.JavaMail.weblogic@epml06> <49503178.3000304@rollernet.us> <85D6FED5-AB83-4AFD-940F-3A8386216CDB@daork.net> <49503DDB.8030208@rollernet.us> <20081223013925.GA42151@gweep.net> <41036FF1-4200-4D16-B69D-1D3A91DDFCC1@daork.net> Message-ID: <27181.1230001476@turing-police.cc.vt.edu> On Tue, 23 Dec 2008 14:44:46 +1300, Nathan Ward said: > Why are people doing this? Are they lacking clue, or, is there some > reasonable purpose? The total number of routing cluons is apparently a fixed quantity. The number of AS's is known to be increasing. Do the math. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From Skywing at valhallalegends.com Mon Dec 22 21:07:51 2008 From: Skywing at valhallalegends.com (Skywing) Date: Mon, 22 Dec 2008 21:07:51 -0600 Subject: What is the most standard subnet length on internet In-Reply-To: <27181.1230001476@turing-police.cc.vt.edu> References: <10068989.128811229991024019.JavaMail.weblogic@epml06> <49503178.3000304@rollernet.us> <85D6FED5-AB83-4AFD-940F-3A8386216CDB@daork.net> <49503DDB.8030208@rollernet.us> <20081223013925.GA42151@gweep.net> <41036FF1-4200-4D16-B69D-1D3A91DDFCC1@daork.net> <27181.1230001476@turing-police.cc.vt.edu> Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA2A5A5@caralain.haven.nynaeve.net> Snarky replies aside, it might be interesting to hear if there are any real examples of this being done intentionally and not out of not knowing better or otherwise configuration error. For example, Tomas Byrnes's suggestion re: hijacking; although, I suspect that in that case, he's speaking of someone doing this filtering on a one-off basis and not on all /24's in the DFZ. - S -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Monday, December 22, 2008 10:05 PM To: Nathan Ward Cc: nanog list Subject: Re: What is the most standard subnet length on internet On Tue, 23 Dec 2008 14:44:46 +1300, Nathan Ward said: > Why are people doing this? Are they lacking clue, or, is there some > reasonable purpose? The total number of routing cluons is apparently a fixed quantity. The number of AS's is known to be increasing. Do the math. From bmanning at vacation.karoshi.com Mon Dec 22 23:21:10 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 23 Dec 2008 05:21:10 +0000 Subject: What is the most standard subnet length on internet In-Reply-To: <85D6FED5-AB83-4AFD-940F-3A8386216CDB@daork.net> References: <10068989.128811229991024019.JavaMail.weblogic@epml06> <49503178.3000304@rollernet.us> <85D6FED5-AB83-4AFD-940F-3A8386216CDB@daork.net> Message-ID: <20081223052110.GA12365@vacation.karoshi.com.> On Tue, Dec 23, 2008 at 02:08:25PM +1300, Nathan Ward wrote: > On 23/12/2008, at 1:31 PM, Seth Mattinen wrote: > >Anyone running a platform that can't take a full table would apply > >such a filter to weed out anyone who likes to announce all of their > >space as /24's for "traffic engineering". If one does that and > >doesn't announce the aggregate as well, one could find themselves > >facing random black holes. > > > People are filtering /24s without a 0/0 route? > actually, you should ask the more general question, "Are ISPs filtering when they don't have a 0/0 route?" and i suspect the answer is almost certainly. being default-free has its advantages as does not using some variable RIR metric as a basis for routing policy. --bill From cchurc05 at harris.com Mon Dec 22 23:40:31 2008 From: cchurc05 at harris.com (Church, Charles) Date: Mon, 22 Dec 2008 23:40:31 -0600 Subject: What is the most standard subnet length on internet In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA2A5A5@caralain.haven.nynaeve.net> References: <10068989.128811229991024019.JavaMail.weblogic@epml06><49503178.3000304@rollernet.us><85D6FED5-AB83-4AFD-940F-3A8386216CDB@daork.net><49503DDB.8030208@rollernet.us><20081223013925.GA42151@gweep.net><41036FF1-4200-4D16-B69D-1D3A91DDFCC1@daork.net><27181.1230001476@turing-police.cc.vt.edu> <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA2A5A5@caralain.haven.nynaeve.net> Message-ID: I help a buddy who works for a small ISP. I believe they're ignoring or null routing large chunks of APNIC. Their customers are aware of the policy, and cool with it. Port scanning and other malicious stuff dropped 50% afterwards. Chuck -----Original Message----- From: Skywing [mailto:Skywing at valhallalegends.com] Sent: Monday, December 22, 2008 10:08 PM To: Valdis.Kletnieks at vt.edu; Nathan Ward Cc: nanog list Subject: RE: What is the most standard subnet length on internet Snarky replies aside, it might be interesting to hear if there are any real examples of this being done intentionally and not out of not knowing better or otherwise configuration error. For example, Tomas Byrnes's suggestion re: hijacking; although, I suspect that in that case, he's speaking of someone doing this filtering on a one-off basis and not on all /24's in the DFZ. - S -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Monday, December 22, 2008 10:05 PM To: Nathan Ward Cc: nanog list Subject: Re: What is the most standard subnet length on internet On Tue, 23 Dec 2008 14:44:46 +1300, Nathan Ward said: > Why are people doing this? Are they lacking clue, or, is there some > reasonable purpose? The total number of routing cluons is apparently a fixed quantity. The number of AS's is known to be increasing. Do the math. From nanog at daork.net Tue Dec 23 03:02:27 2008 From: nanog at daork.net (Nathan Ward) Date: Tue, 23 Dec 2008 22:02:27 +1300 Subject: What is the most standard subnet length on internet In-Reply-To: References: <10068989.128811229991024019.JavaMail.weblogic@epml06><49503178.3000304@rollernet.us><85D6FED5-AB83-4AFD-940F-3A8386216CDB@daork.net><49503DDB.8030208@rollernet.us><20081223013925.GA42151@gweep.net><41036FF1-4200-4D16-B69D-1D3A91DDFCC1@daork.net><27181.1230001476@turing-police.cc.vt.edu> <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA2A5A5@caralain.haven.nynaeve.net> Message-ID: On 23/12/2008, at 6:40 PM, Church, Charles wrote: > I help a buddy who works for a small ISP. I believe they're > ignoring or > null routing large chunks of APNIC. Their customers are aware of the > policy, and cool with it. Port scanning and other malicious stuff > dropped 50% afterwards. That sort of thing is common, sure (unfortunately). My question (comment?) is more around why people would filter /24 (or whatever) prefixes (ie. when advertised a /24 prefix over BGP not accept it, so they do not get a route for that /24), and then not have a default. That route is used for outgoing packets, not incoming ones (modulo RPF, etc.). The purpose of filtering the /24s is to keep the size of their RIB/FIB down, not to limit abuse or something. If you are close to the edge of the network, filtering /24s is a low hanging fruit way to catch a whole lot of pointless routes that don't really gain you much performance benefit, but are going to cost you lots of RIB/FIB space. However, you really need to have a covering default, so you still have some way to reach the people in those /24s. > From: Skywing [mailto:Skywing at valhallalegends.com] > > Snarky replies aside, it might be interesting to hear if there are any > real examples of this being done intentionally and not out of not > knowing better or otherwise configuration error. For example, Tomas > Byrnes's suggestion re: hijacking; although, I suspect that in that > case, he's speaking of someone doing this filtering on a one-off basis > and not on all /24's in the DFZ. Yep, that is what I'm interested in. It would be perhaps an interesting exercise to only accept prefixes for which you do not have a covering prefix with the same next-hop, etc. I wonder if router vendors already do that internally as an optimisation when installing routes in to the forwarding hardware? You would have to still have the routes in your RIB but RIB RAM is cheap(er). -- Nathan Ward From Grzegorz at Janoszka.pl Tue Dec 23 07:49:00 2008 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Tue, 23 Dec 2008 14:49:00 +0100 Subject: What is the most standard subnet length on internet In-Reply-To: <41036FF1-4200-4D16-B69D-1D3A91DDFCC1@daork.net> References: <10068989.128811229991024019.JavaMail.weblogic@epml06> <49503178.3000304@rollernet.us> <85D6FED5-AB83-4AFD-940F-3A8386216CDB@daork.net> <49503DDB.8030208@rollernet.us> <20081223013925.GA42151@gweep.net> <41036FF1-4200-4D16-B69D-1D3A91DDFCC1@daork.net> Message-ID: <4950EC4C.5080504@Janoszka.pl> Nathan Ward wrote: >>> Let me rephrase; Are there people who are filtering /24s received from >>> eBGP peers who do not have a default route? >> >> of course. > > Curiously, it was really meant as a rhetorical question where the answer > was "no". > > Why are people doing this? Are they lacking clue, or, is there some > reasonable purpose? Memory mostly I think. /24 prefixes are ~ the half of all prefixes, but they cover only a small percent of the address space. If your router has > 6 full BGP sessions, you can filter /24 on half of them, your memory usage will drop significantly. -- Grzegorz Janoszka Leaseweb From r.hyunseog at ieee.org Tue Dec 23 08:25:40 2008 From: r.hyunseog at ieee.org (Alex H. Ryu) Date: Tue, 23 Dec 2008 08:25:40 -0600 Subject: What is the most standard subnet length on internet In-Reply-To: <4950EC4C.5080504@Janoszka.pl> References: <10068989.128811229991024019.JavaMail.weblogic@epml06> <49503178.3000304@rollernet.us> <85D6FED5-AB83-4AFD-940F-3A8386216CDB@daork.net> <49503DDB.8030208@rollernet.us> <20081223013925.GA42151@gweep.net> <41036FF1-4200-4D16-B69D-1D3A91DDFCC1@daork.net> <4950EC4C.5080504@Janoszka.pl> Message-ID: <4950F4E4.2080401@ieee.org> Also one of the reason why not putting default route may be because of recursive lookup from routing table. If you have multi-homed site within your network with static route, and if you use next-hop IP address instead of named interface, you will see the problem when you have default route in routing table. For an example, if you have "ip route 1.0.0.0 255.0.0.0 2.2.2.2". If the interface for 2.2.2.2 is down, 1.0.0.0/8 will be still be in the routing table because 2.2.2.2 can be reached via default route (0.0.0.0/0) from routing table recursive lookup. Therefore the traffic for 1.0.0.0/8 will be forwarded to "0.0.0.0/0" next-hop ip address, and customer fail-over scenario will not be working at all. Only way to resolve this problem is... Actually three... 1) Use named interface such as "serial 1/0" instead of "x.x.x.x" IP next-hop address. But sometimes this is not an option if you use ethernet circuit or something like Broadcast or NBMA network. 2) Use BGP with private ASN... 3) Do not install default route in your routing table Grzegorz Janoszka wrote: > Nathan Ward wrote: >>>> Let me rephrase; Are there people who are filtering /24s received from >>>> eBGP peers who do not have a default route? >>> >>> of course. >> >> Curiously, it was really meant as a rhetorical question where the >> answer was "no". >> >> Why are people doing this? Are they lacking clue, or, is there some >> reasonable purpose? > > Memory mostly I think. /24 prefixes are ~ the half of all prefixes, > but they cover only a small percent of the address space. > If your router has > 6 full BGP sessions, you can filter /24 on half > of them, your memory usage will drop significantly. > -------------- next part -------------- A non-text attachment was scrubbed... Name: r_hyunseog.vcf Type: text/x-vcard Size: 360 bytes Desc: not available URL: From kemp at network-services.uoregon.edu Tue Dec 23 11:22:05 2008 From: kemp at network-services.uoregon.edu (John Kemp) Date: Tue, 23 Dec 2008 09:22:05 -0800 Subject: [outage] archive.routeviews.org under maintenance Message-ID: <49511E3D.4010600@network-services.uoregon.edu> We are experiencing some unanticipated hardware issues with the machine archive.routeviews.org. This machine serves as the front-end to our primary data archive. It also hosts http://www.routeviews.org/ and is answering for route-views6.routeviews.org. We are currently working to deploy a replacement for this piece of hardware. NOTE: this outage will not affect the other routeviews collectors, or the data archive. Your patience during this time is appreciated. -- John Kemp RouteViews Engineer kemp at network-services.uoregon.edu 541-346-1714 From tomb at byrneit.net Tue Dec 23 13:12:13 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Tue, 23 Dec 2008 11:12:13 -0800 Subject: What is the most standard subnet length on internet In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA2A5A5@caralain.haven.nynaeve.net> References: <10068989.128811229991024019.JavaMail.weblogic@epml06><49503178.3000304@rollernet.us><85D6FED5-AB83-4AFD-940F-3A8386216CDB@daork.net><49503DDB.8030208@rollernet.us><20081223013925.GA42151@gweep.net><41036FF1-4200-4D16-B69D-1D3A91DDFCC1@daork.net><27181.1230001476@turing-police.cc.vt.edu> <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA2A5A5@caralain.haven.nynaeve.net> Message-ID: <70D072392E56884193E3D2DE09C097A9FC0B@pascal.zaphodb.org> What I was describing is filtering the announcements of /24s that are part of larger allocations. Not filtering the announcements of "The Swamp". >-----Original Message----- >From: Skywing [mailto:Skywing at valhallalegends.com] >Sent: Monday, December 22, 2008 7:08 PM >To: Valdis.Kletnieks at vt.edu; Nathan Ward >Cc: nanog list >Subject: RE: What is the most standard subnet length on internet > >Snarky replies aside, it might be interesting to hear if there are any >real examples of this being done intentionally and not out of not >knowing better or otherwise configuration error. For example, Tomas >Byrnes's suggestion re: hijacking; although, I suspect that in that >case, he's speaking of someone doing this filtering on a one-off basis >and not on all /24's in the DFZ. > >- S > >-----Original Message----- >From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] >Sent: Monday, December 22, 2008 10:05 PM >To: Nathan Ward >Cc: nanog list >Subject: Re: What is the most standard subnet length on internet > >On Tue, 23 Dec 2008 14:44:46 +1300, Nathan Ward said: > >> Why are people doing this? Are they lacking clue, or, is there some >> reasonable purpose? > >The total number of routing cluons is apparently a fixed quantity. The >number of AS's is known to be increasing. Do the math. > From sthaug at nethelp.no Tue Dec 23 13:55:34 2008 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 23 Dec 2008 20:55:34 +0100 (CET) Subject: Unallocated prefix 100.10.10.0/24 in the DFZ via Cogent Message-ID: <20081223.205534.74674699.sthaug@nethelp.no> Calling Cogent, Avantel (AS 6503) and Axtel (AS 14000): Axtel is announcing 100.10.10.0/24, which is within the 100.0.0.0/8 block, which is unallocated according to http://www.iana.org/assignments/ipv4-address-space/ I am seeing this from two of my transit providers, the common AS path is: 174 6503 6503 6503 6503 6503 14000 Prefix filtering is a good thing, please do it! Steinar Haug, Nethelp consulting, sthaug at nethelp.no From adrian at creative.net.au Tue Dec 23 14:09:13 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Wed, 24 Dec 2008 05:09:13 +0900 Subject: Unallocated prefix 100.10.10.0/24 in the DFZ via Cogent In-Reply-To: <20081223.205534.74674699.sthaug@nethelp.no> References: <20081223.205534.74674699.sthaug@nethelp.no> Message-ID: <20081223200913.GA29813@skywalker.creative.net.au> On Tue, Dec 23, 2008, sthaug at nethelp.no wrote: > Axtel is announcing 100.10.10.0/24, which is within the 100.0.0.0/8 block, > which is unallocated according to I'd love to see what that prefix is doing.. :) Anyone have anything they can share? adrian From jlewis at lewis.org Tue Dec 23 14:17:00 2008 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 23 Dec 2008 15:17:00 -0500 (EST) Subject: Unallocated prefix 100.10.10.0/24 in the DFZ via Cogent In-Reply-To: <20081223.205534.74674699.sthaug@nethelp.no> References: <20081223.205534.74674699.sthaug@nethelp.no> Message-ID: On Tue, 23 Dec 2008 sthaug at nethelp.no wrote: > Calling Cogent, Avantel (AS 6503) and Axtel (AS 14000): > > Axtel is announcing 100.10.10.0/24, which is within the 100.0.0.0/8 block, > which is unallocated according to > > http://www.iana.org/assignments/ipv4-address-space/ As long as someone's trying to bang a few clues into Axtel, they might suggest to them that they clean up their announcements and look into aggregating the /23s in 201.158.192/18 and maybe even announcing the covering CIDR if they refuse to get rid of the deaggregation. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From chris.stebner at gmail.com Tue Dec 23 14:19:07 2008 From: chris.stebner at gmail.com (Chris Stebner) Date: Tue, 23 Dec 2008 12:19:07 -0800 Subject: Unallocated prefix 100.10.10.0/24 in the DFZ via Cogent In-Reply-To: <20081223200913.GA29813@skywalker.creative.net.au> References: <20081223.205534.74674699.sthaug@nethelp.no> <20081223200913.GA29813@skywalker.creative.net.au> Message-ID: <941190370812231219n18c6a7f1y3b2c7f0f28876dd8@mail.gmail.com> What all good advertised, unallocated prefixes do... send mail... (senderbase shows a fair amount of volume) On Tue, Dec 23, 2008 at 12:09 PM, Adrian Chadd wrote: > On Tue, Dec 23, 2008, sthaug at nethelp.no wrote: > > > Axtel is announcing 100.10.10.0/24, which is within the 100.0.0.0/8block, > > which is unallocated according to > > I'd love to see what that prefix is doing.. :) > > Anyone have anything they can share? > > > adrian > > > From jeffshultz at wvi.com Tue Dec 23 16:47:50 2008 From: jeffshultz at wvi.com (Jeff Shultz) Date: Tue, 23 Dec 2008 14:47:50 -0800 Subject: [outages] Yahoo! mail having problems? In-Reply-To: References: Message-ID: <49516A96.7090200@wvi.com> Apparently they are - 219 of the 304 in the queue are for Yahoo - some over 1280 minutes. Or, as my boss put it when I mentioned that Yahoo was having e-mail issues: "What's new?" Chris Lauretano wrote: > Yep, experiencing the same here. The only e-mails stuck in the queue are outbound to Yahoo and the number is staggering. > > --C. Lauretano > > > On 12/23/08 3:34 PM, "iName.com" wrote: > > Our e-mail gateways are backing up with yahoo.com bound e-mail. I'm only > getting timeouts connecting to Yahoo's e-mail servers. I've tried these: > a.mx.mail.yahoo.com[67.195.168.31] > c.mx.mail.yahoo.com[216.39.53.3] > d.mx.mail.yahoo.com[66.196.82.7] > f.mx.mail.yahoo.com[68.142.202.247] > from the same subnet as the e-mail gateways. > > Anyone else having the same? > > Frank > > _______________________________________________ > outages mailing list > outages at outages.org > https://puck.nether.net/mailman/listinfo/outages > > _______________________________________________ > outages mailing list > outages at outages.org > https://puck.nether.net/mailman/listinfo/outages > -- Jeff Shultz From marc at let.de Wed Dec 24 05:48:17 2008 From: marc at let.de (macbroadcast) Date: Wed, 24 Dec 2008 12:48:17 +0100 Subject: Christmas spam from RESERVED IANA adressblock ? Message-ID: hello ladys and getlepersons just out of curiosity i looked a bit closer into this spammail header, because this company is really annoying and abusing a lot of internet citizens. Anfang der weitergeleiteten E-Mail: > Von: mailling at ualadys.com > Datum: 24. Dezember 2008 12:30:18 MEZ > An: marc at let.de > Betreff: E-Mail For You @ ualadys.com > Return-Path: > Received: from mx2.mail.vrmd.de ([10.0.1.21]) by vm42.mail.vrmd.de > (Cyrus v2.2.12-Invoca-RPM-2.2.12-9.RHEL4) with LMTPA; Wed, 24 Dec > 2008 12:30:25 +0100 > Received: from mx2.iispp.com ([76.74.250.247]) by mx2.mail.vrmd.de > with esmtp (Exim 4.69) (envelope-from ) id > 1LFRwW-00011o-DY for marc at let.de; Wed, 24 Dec 2008 12:30:25 +0100 > Received: from web1.iispp.com (w1 [172.16.21.244]) by mx2.iispp.com > (Postfix) with ESMTP id B71CF3504DB for ; Wed, 24 Dec > 2008 11:30:18 +0000 (UTC) > Received: by web1.iispp.com (Postfix, from userid 33) id > A5C7917A405C; Wed, 24 Dec 2008 06:30:18 -0500 (EST) ?Whois? wurde gestartet ? OrgName: Internet Assigned Numbers Authority OrgID: IANA Address: 4676 Admiralty Way, Suite 330 City: Marina del Rey StateProv: CA PostalCode: 90292-6695 Country: US NetRange: 172.16.0.0 - 172.31.255.255 CIDR: 172.16.0.0/12 NetName: IANA-BBLK-RESERVED NetHandle: NET-172-16-0-0-1 Parent: NET-172-0-0-0-0 NetType: IANA Special Use NameServer: BLACKHOLE-1.IANA.ORG NameServer: BLACKHOLE-2.IANA.ORG Comment: This block is reserved for special purposes. Comment: Please see RFC 1918 for additional information. Comment: http://www.arin.net/reference/rfc/rfc1918.txt RegDate: 1994-03-15 Updated: 2007-11-27 OrgAbuseHandle: IANA-IP-ARIN OrgAbuseName: Internet Corporation for Assigned Names and Number OrgAbusePhone: +1-310-301-5820 OrgAbuseEmail: abuse at iana.org OrgTechHandle: IANA-IP-ARIN OrgTechName: Internet Corporation for Assigned Names and Number OrgTechPhone: +1-310-301-5820 OrgTechEmail: abuse at iana.org # ARIN WHOIS database, last updated 2008-12-23 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. so how is this possible ? merry christmas anyway Marc > X-Sieve: CMU Sieve 2.2 > Envelope-To: marc at let.de > Delivery-Date: Wed, 24 Dec 2008 12:30:25 +0100 > X-Id-From: 1000 > X-Id-To: 238141 > X-Mail-Id: 203714382 > Mime-Version: 1.0 > Content-Type: text/html > Message-Id: <20081224113018.A5C7917A405C at web1.iispp.com> > X-Spam-Suspicion: No > X-Purgate: Clean X-purgate-ID: > 150741::081224123024-0FFB86C0-283E8BDE/0-0/0-1 X-purgate-Ad: For > more information about eXpurgate please visit http://www.expurgate.net/ > > > > > marc, You have new mail > This is to notify you that you have received an E-Mail from > > View Photos > DetailsIrina O #1000 > Subject: Destiny has linked us... > > Date: 24 December 2008 > > To read the message go here: > > PLEASE, DO NOT REPLY TO THIS E-MAIL - FOLLOW THE LINK > > http://www.ualadys.com/view_mail.rpx?hash=a71d2600f032ece232a391296f5f071e&mid=203714382&uid=238141 > > Thank you, > ualadys.com Support Team > > Favorites ualadys.com > > 24x7 Call center > > United States > +1 (315) 849-5814 > > United Kigdom > +44 (315) 849-5814 > > Skype support : ualadys > > > > For any question in english > about this site please call: > +1 (212) 226-8900 > Mon-Fri 9:00-16:00 (EST) From stevel at dedicatedservers.net.au Wed Dec 24 06:02:35 2008 From: stevel at dedicatedservers.net.au (Steven Lisson) Date: Wed, 24 Dec 2008 22:02:35 +1000 Subject: Christmas spam from RESERVED IANA adressblock ? In-Reply-To: References: Message-ID: Hi, It is private address space, like 10.0.0.0/8, completely valid for internal communication which it appears to be. Regards, Steve -----Original Message----- From: macbroadcast [mailto:marc at let.de] Sent: Wednesday, 24 December 2008 9:48 PM To: NANOG list Subject: Christmas spam from RESERVED IANA adressblock ? hello ladys and getlepersons just out of curiosity i looked a bit closer into this spammail header, because this company is really annoying and abusing a lot of internet citizens. Anfang der weitergeleiteten E-Mail: > Von: mailling at ualadys.com > Datum: 24. Dezember 2008 12:30:18 MEZ > An: marc at let.de > Betreff: E-Mail For You @ ualadys.com > Return-Path: > Received: from mx2.mail.vrmd.de ([10.0.1.21]) by vm42.mail.vrmd.de > (Cyrus v2.2.12-Invoca-RPM-2.2.12-9.RHEL4) with LMTPA; Wed, 24 Dec > 2008 12:30:25 +0100 > Received: from mx2.iispp.com ([76.74.250.247]) by mx2.mail.vrmd.de > with esmtp (Exim 4.69) (envelope-from ) id > 1LFRwW-00011o-DY for marc at let.de; Wed, 24 Dec 2008 12:30:25 +0100 > Received: from web1.iispp.com (w1 [172.16.21.244]) by mx2.iispp.com > (Postfix) with ESMTP id B71CF3504DB for ; Wed, 24 Dec > 2008 11:30:18 +0000 (UTC) > Received: by web1.iispp.com (Postfix, from userid 33) id > A5C7917A405C; Wed, 24 Dec 2008 06:30:18 -0500 (EST) "Whois" wurde gestartet ... OrgName: Internet Assigned Numbers Authority OrgID: IANA Address: 4676 Admiralty Way, Suite 330 City: Marina del Rey StateProv: CA PostalCode: 90292-6695 Country: US NetRange: 172.16.0.0 - 172.31.255.255 CIDR: 172.16.0.0/12 NetName: IANA-BBLK-RESERVED NetHandle: NET-172-16-0-0-1 Parent: NET-172-0-0-0-0 NetType: IANA Special Use NameServer: BLACKHOLE-1.IANA.ORG NameServer: BLACKHOLE-2.IANA.ORG Comment: This block is reserved for special purposes. Comment: Please see RFC 1918 for additional information. Comment: http://www.arin.net/reference/rfc/rfc1918.txt RegDate: 1994-03-15 Updated: 2007-11-27 OrgAbuseHandle: IANA-IP-ARIN OrgAbuseName: Internet Corporation for Assigned Names and Number OrgAbusePhone: +1-310-301-5820 OrgAbuseEmail: abuse at iana.org OrgTechHandle: IANA-IP-ARIN OrgTechName: Internet Corporation for Assigned Names and Number OrgTechPhone: +1-310-301-5820 OrgTechEmail: abuse at iana.org # ARIN WHOIS database, last updated 2008-12-23 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. so how is this possible ? merry christmas anyway Marc > X-Sieve: CMU Sieve 2.2 > Envelope-To: marc at let.de > Delivery-Date: Wed, 24 Dec 2008 12:30:25 +0100 > X-Id-From: 1000 > X-Id-To: 238141 > X-Mail-Id: 203714382 > Mime-Version: 1.0 > Content-Type: text/html > Message-Id: <20081224113018.A5C7917A405C at web1.iispp.com> > X-Spam-Suspicion: No > X-Purgate: Clean X-purgate-ID: > 150741::081224123024-0FFB86C0-283E8BDE/0-0/0-1 X-purgate-Ad: For > more information about eXpurgate please visit http://www.expurgate.net/ > > > > > marc, You have new mail > This is to notify you that you have received an E-Mail from > > View Photos > DetailsIrina O #1000 > Subject: Destiny has linked us... > > Date: 24 December 2008 > > To read the message go here: > > PLEASE, DO NOT REPLY TO THIS E-MAIL - FOLLOW THE LINK > > http://www.ualadys.com/view_mail.rpx?hash=a71d2600f032ece232a391296f5f07 1e&mid=203714382&uid=238141 > > Thank you, > ualadys.com Support Team > > Favorites ualadys.com > > 24x7 Call center > > United States > +1 (315) 849-5814 > > United Kigdom > +44 (315) 849-5814 > > Skype support : ualadys > > > > For any question in english > about this site please call: > +1 (212) 226-8900 > Mon-Fri 9:00-16:00 (EST) From jlewis at lewis.org Wed Dec 24 06:51:58 2008 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 24 Dec 2008 07:51:58 -0500 (EST) Subject: Christmas spam from RESERVED IANA adressblock ? In-Reply-To: References: Message-ID: Lots of networks use RFC1918 space _internally_, as iispp.com obviously does between their webmail server and their SMTP relay. It's no more suspicious than your own ISP's use of 10.0.1 between their MX and the mailstore to which your message was delivered. Recognizing this is pretty basic to reading SMTP headers. On Wed, 24 Dec 2008, macbroadcast wrote: > hello ladys and getlepersons > > > just out of curiosity i looked a bit closer into this spammail header, > because > this company is really annoying and abusing a lot of internet citizens. > > > Anfang der weitergeleiteten E-Mail: >> Von: mailling at ualadys.com >> Datum: 24. Dezember 2008 12:30:18 MEZ >> An: marc at let.de >> Betreff: E-Mail For You @ ualadys.com >> Return-Path: >> Received: from mx2.mail.vrmd.de ([10.0.1.21]) by vm42.mail.vrmd.de (Cyrus >> v2.2.12-Invoca-RPM-2.2.12-9.RHEL4) with LMTPA; Wed, 24 Dec 2008 12:30:25 >> +0100 >> Received: from mx2.iispp.com ([76.74.250.247]) by mx2.mail.vrmd.de with >> esmtp (Exim 4.69) (envelope-from ) id >> 1LFRwW-00011o-DY for marc at let.de; Wed, 24 Dec 2008 12:30:25 +0100 >> Received: from web1.iispp.com (w1 [172.16.21.244]) by mx2.iispp.com >> (Postfix) with ESMTP id B71CF3504DB for ; Wed, 24 Dec 2008 >> 11:30:18 +0000 (UTC) >> Received: by web1.iispp.com (Postfix, from userid 33) id A5C7917A405C; Wed, >> 24 Dec 2008 06:30:18 -0500 (EST) > > > Whois wurde gestartet & > > > OrgName: Internet Assigned Numbers Authority > OrgID: IANA > Address: 4676 Admiralty Way, Suite 330 > City: Marina del Rey > StateProv: CA > PostalCode: 90292-6695 > Country: US > > NetRange: 172.16.0.0 - 172.31.255.255 > CIDR: 172.16.0.0/12 > NetName: IANA-BBLK-RESERVED > NetHandle: NET-172-16-0-0-1 > Parent: NET-172-0-0-0-0 > NetType: IANA Special Use > NameServer: BLACKHOLE-1.IANA.ORG > NameServer: BLACKHOLE-2.IANA.ORG > Comment: This block is reserved for special purposes. > Comment: Please see RFC 1918 for additional information. > Comment: http://www.arin.net/reference/rfc/rfc1918.txt > RegDate: 1994-03-15 > Updated: 2007-11-27 > > OrgAbuseHandle: IANA-IP-ARIN > OrgAbuseName: Internet Corporation for Assigned Names and Number > OrgAbusePhone: +1-310-301-5820 > OrgAbuseEmail: abuse at iana.org > > OrgTechHandle: IANA-IP-ARIN > OrgTechName: Internet Corporation for Assigned Names and Number > OrgTechPhone: +1-310-301-5820 > OrgTechEmail: abuse at iana.org > > # ARIN WHOIS database, last updated 2008-12-23 19:10 > # Enter ? for additional hints on searching ARIN's WHOIS database. > > > so how is this possible ? > > merry christmas anyway > > > Marc > >> X-Sieve: CMU Sieve 2.2 >> Envelope-To: marc at let.de >> Delivery-Date: Wed, 24 Dec 2008 12:30:25 +0100 >> X-Id-From: 1000 >> X-Id-To: 238141 >> X-Mail-Id: 203714382 >> Mime-Version: 1.0 >> Content-Type: text/html >> Message-Id: <20081224113018.A5C7917A405C at web1.iispp.com> >> X-Spam-Suspicion: No >> X-Purgate: Clean X-purgate-ID: >> 150741::081224123024-0FFB86C0-283E8BDE/0-0/0-1 X-purgate-Ad: For more >> information about eXpurgate please visit http://www.expurgate.net/ >> >> >> >> >> marc, You have new mail >> This is to notify you that you have received an E-Mail from >> >> View Photos >> DetailsIrina O #1000 >> Subject: Destiny has linked us... >> >> Date: 24 December 2008 >> >> To read the message go here: >> >> PLEASE, DO NOT REPLY TO THIS E-MAIL - FOLLOW THE LINK >> >> http://www.ualadys.com/view_mail.rpx?hash=a71d2600f032ece232a391296f5f071e&mid=203714382&uid=238141 >> >> Thank you, >> ualadys.com Support Team >> >> Favorites ualadys.com >> >> 24x7 Call center >> >> United States >> +1 (315) 849-5814 >> >> United Kigdom >> +44 (315) 849-5814 >> >> Skype support : ualadys >> >> >> >> For any question in english >> about this site please call: >> +1 (212) 226-8900 >> Mon-Fri 9:00-16:00 (EST) > > ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From black at csulb.edu Wed Dec 24 09:50:18 2008 From: black at csulb.edu (Matthew Black) Date: Wed, 24 Dec 2008 07:50:18 -0800 Subject: What to do when your ISP off-shores tech support Message-ID: I've had difficulties reaching anyone with a brain at my DSL provider Verizon California. I can reliably ping the first hop from my home to the CO with a 25ms delay. But if I ping any other location, packets get dropped or significantly delayed. To me, this sounds like Verizon has an internal routing problem rather than a problem with my phone line. Note that it rained recently in our area and the cable vault in front of my is usually covered with stagnant water because the gutters don't drain it away. I have tried to explain this to tech support but they refuse to go off script, even the supervisors. They keep insisting on sending a tech to my home when I suggest this should be escalated to their network operations team. Anyhow, if I can reliably ping the first hop from my home, would that eliminate my telephone connection as part of the problem? Just a sanity check on my part. Thanks. matthew black california state university, long beach From swm at emanon.com Wed Dec 24 11:38:15 2008 From: swm at emanon.com (Scott Morris) Date: Wed, 24 Dec 2008 12:38:15 -0500 Subject: Christmas spam from RESERVED IANA adressblock ? In-Reply-To: References: Message-ID: <23DDCEBCBF4E486B933ACE0C78EBF556@scott66ed7b03d> Do you put public IP addresses on every single device of yours? Or are some devices configured with private ranges for internal movement (public bridghead e-mail vs. internal databases?) Or is everything internal private, and you simply NAT for public accessible parts. Seeing those addresses in the the e-mail header of an application is not an indication of what is seen out on the 'Net. Just an indication of what that specific device saw. I would guess (hope?) that most, if not all, providers filter the RFC1918 space addresses from entering or leaving their networks unchecked. But just my two cents there... Scott -----Original Message----- From: macbroadcast [mailto:marc at let.de] Sent: Wednesday, December 24, 2008 6:48 AM To: NANOG list Subject: Christmas spam from RESERVED IANA adressblock ? hello ladys and getlepersons just out of curiosity i looked a bit closer into this spammail header, because this company is really annoying and abusing a lot of internet citizens. Anfang der weitergeleiteten E-Mail: > Von: mailling at ualadys.com > Datum: 24. Dezember 2008 12:30:18 MEZ > An: marc at let.de > Betreff: E-Mail For You @ ualadys.com > Return-Path: > Received: from mx2.mail.vrmd.de ([10.0.1.21]) by vm42.mail.vrmd.de > (Cyrus v2.2.12-Invoca-RPM-2.2.12-9.RHEL4) with LMTPA; Wed, 24 Dec > 2008 12:30:25 +0100 > Received: from mx2.iispp.com ([76.74.250.247]) by mx2.mail.vrmd.de > with esmtp (Exim 4.69) (envelope-from ) id > 1LFRwW-00011o-DY for marc at let.de; Wed, 24 Dec 2008 12:30:25 +0100 > Received: from web1.iispp.com (w1 [172.16.21.244]) by mx2.iispp.com > (Postfix) with ESMTP id B71CF3504DB for ; Wed, 24 Dec > 2008 11:30:18 +0000 (UTC) > Received: by web1.iispp.com (Postfix, from userid 33) id A5C7917A405C; > Wed, 24 Dec 2008 06:30:18 -0500 (EST) "Whois" wurde gestartet . OrgName: Internet Assigned Numbers Authority OrgID: IANA Address: 4676 Admiralty Way, Suite 330 City: Marina del Rey StateProv: CA PostalCode: 90292-6695 Country: US NetRange: 172.16.0.0 - 172.31.255.255 CIDR: 172.16.0.0/12 NetName: IANA-BBLK-RESERVED NetHandle: NET-172-16-0-0-1 Parent: NET-172-0-0-0-0 NetType: IANA Special Use NameServer: BLACKHOLE-1.IANA.ORG NameServer: BLACKHOLE-2.IANA.ORG Comment: This block is reserved for special purposes. Comment: Please see RFC 1918 for additional information. Comment: http://www.arin.net/reference/rfc/rfc1918.txt RegDate: 1994-03-15 Updated: 2007-11-27 OrgAbuseHandle: IANA-IP-ARIN OrgAbuseName: Internet Corporation for Assigned Names and Number OrgAbusePhone: +1-310-301-5820 OrgAbuseEmail: abuse at iana.org OrgTechHandle: IANA-IP-ARIN OrgTechName: Internet Corporation for Assigned Names and Number OrgTechPhone: +1-310-301-5820 OrgTechEmail: abuse at iana.org # ARIN WHOIS database, last updated 2008-12-23 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. so how is this possible ? merry christmas anyway Marc > X-Sieve: CMU Sieve 2.2 > Envelope-To: marc at let.de > Delivery-Date: Wed, 24 Dec 2008 12:30:25 +0100 > X-Id-From: 1000 > X-Id-To: 238141 > X-Mail-Id: 203714382 > Mime-Version: 1.0 > Content-Type: text/html > Message-Id: <20081224113018.A5C7917A405C at web1.iispp.com> > X-Spam-Suspicion: No > X-Purgate: Clean X-purgate-ID: > 150741::081224123024-0FFB86C0-283E8BDE/0-0/0-1 X-purgate-Ad: For more > information about eXpurgate please visit http://www.expurgate.net/ > > > > > marc, You have new mail > This is to notify you that you have received an E-Mail from > > View Photos > DetailsIrina O #1000 > Subject: Destiny has linked us... > > Date: 24 December 2008 > > To read the message go here: > > PLEASE, DO NOT REPLY TO THIS E-MAIL - FOLLOW THE LINK > > http://www.ualadys.com/view_mail.rpx?hash=a71d2600f032ece232a391296f5f > 071e&mid=203714382&uid=238141 > > Thank you, > ualadys.com Support Team > > Favorites ualadys.com > > 24x7 Call center > > United States > +1 (315) 849-5814 > > United Kigdom > +44 (315) 849-5814 > > Skype support : ualadys > > > > For any question in english > about this site please call: > +1 (212) 226-8900 > Mon-Fri 9:00-16:00 (EST) From jay at west.net Wed Dec 24 11:43:20 2008 From: jay at west.net (Jay Hennigan) Date: Wed, 24 Dec 2008 09:43:20 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: References: Message-ID: <495274B8.9020806@west.net> Matthew Black wrote: > I've had difficulties reaching anyone with a brain > at my DSL provider Verizon California. Switch to a local ISP with local tech support. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From chaim.rieger at gmail.com Wed Dec 24 11:46:35 2008 From: chaim.rieger at gmail.com (chaim.rieger at gmail.com) Date: Wed, 24 Dec 2008 17:46:35 +0000 Subject: What to do when your ISP off-shores tech support Message-ID: <1873041366-1230140806-cardhu_decombobulator_blackberry.rim.net-945806518-@bxe325.bisx.prod.on.blackberry> In socal switch to dslextreme ------Original Message------ From: Jay Hennigan To: Matthew Black Cc: nanog at nanog.org Subject: Re: What to do when your ISP off-shores tech support Sent: Dec 24, 2008 09:43 Matthew Black wrote: > I've had difficulties reaching anyone with a brain > at my DSL provider Verizon California. Switch to a local ISP with local tech support. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV Sent via BlackBerry from T-Mobile From randy at psg.com Wed Dec 24 11:50:53 2008 From: randy at psg.com (Randy Bush) Date: Wed, 24 Dec 2008 12:50:53 -0500 Subject: What to do when your ISP off-shores tech support In-Reply-To: <495274B8.9020806@west.net> References: <495274B8.9020806@west.net> Message-ID: <4952767D.6040601@psg.com> On 08.12.24 12:43, Jay Hennigan wrote: > Matthew Black wrote: >> I've had difficulties reaching anyone with a brain >> at my DSL provider Verizon California. > Switch to a local ISP with local tech support. bingo. i have multiple offices. in each case, i buy layers one and two from the copper/fiber monopoly and layer three from local folk with clue and caring: lavanet (hawai`i), infinitiy internet (pnw), and iij (tokyo, and yes i work for iij). local packet pushers with clue are not only better at layer three support and delivery, but they carry more weight with the hellco to get your layer one and two problem fixed. randy From tomb at byrneit.net Wed Dec 24 11:51:41 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Wed, 24 Dec 2008 09:51:41 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: <1873041366-1230140806-cardhu_decombobulator_blackberry.rim.net-945806518-@bxe325.bisx.prod.on.blackberry> References: <1873041366-1230140806-cardhu_decombobulator_blackberry.rim.net-945806518-@bxe325.bisx.prod.on.blackberry> Message-ID: <70D072392E56884193E3D2DE09C097A9FC1C@pascal.zaphodb.org> Cox Communications has fully on-shore support. Here in SD they are actually LOCAL. Their TS staff are responsive and courteous. I only wish their network were more reliable. (They're better than SBC in my experience, however.) >-----Original Message----- >From: chaim.rieger at gmail.com [mailto:chaim.rieger at gmail.com] >Sent: Wednesday, December 24, 2008 9:47 AM >To: Jay Hennigan; Matthew Black >Cc: nanog at nanog.org >Subject: Re: What to do when your ISP off-shores tech support > >In socal switch to dslextreme > > >------Original Message------ >From: Jay Hennigan >To: Matthew Black >Cc: nanog at nanog.org >Subject: Re: What to do when your ISP off-shores tech support >Sent: Dec 24, 2008 09:43 > >Matthew Black wrote: >> I've had difficulties reaching anyone with a brain >> at my DSL provider Verizon California. > >Switch to a local ISP with local tech support. > >-- >Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net >Impulse Internet Service - http://www.impulse.net/ >Your local telephone and internet company - 805 884-6323 - WB6RDV > > > >Sent via BlackBerry from T-Mobile From herrin-nanog at dirtside.com Wed Dec 24 11:59:39 2008 From: herrin-nanog at dirtside.com (William Herrin) Date: Wed, 24 Dec 2008 12:59:39 -0500 Subject: Christmas spam from RESERVED IANA adressblock ? In-Reply-To: References: Message-ID: <3c3e3fca0812240959o672e0598l5599126f9c109162@mail.gmail.com> On Wed, Dec 24, 2008 at 6:48 AM, macbroadcast wrote: > just out of curiosity i looked a bit closer into this spammail header, > because this company is really annoying and abusing a lot of internet citizens. > >> Received: from web1.iispp.com (w1 [172.16.21.244]) by mx2.iispp.com >> (Postfix) with ESMTP id B71CF3504DB for ; Wed, 24 Dec 2008 >> 11:30:18 +0000 (UTC) > CIDR: 172.16.0.0/12 > NetName: IANA-BBLK-RESERVED > so how is this possible ? > Comment: Please see RFC 1918 for additional information. > Comment: http://www.arin.net/reference/rfc/rfc1918.txt Asked and answered. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From shrdlu at deaddrop.org Wed Dec 24 12:01:07 2008 From: shrdlu at deaddrop.org (Etaoin Shrdlu) Date: Wed, 24 Dec 2008 10:01:07 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: <4952767D.6040601@psg.com> References: <495274B8.9020806@west.net> <4952767D.6040601@psg.com> Message-ID: <495278E3.4070505@deaddrop.org> Randy Bush wrote: > On 08.12.24 12:43, Jay Hennigan wrote: > >> Matthew Black wrote: >> >>> I've had difficulties reaching anyone with a brain >>> at my DSL provider Verizon California. >> >> Switch to a local ISP with local tech support. > bingo. Uh, ditto? Having left SoCal a couple of years ago, my data is a bit stale. However, I happily used XO+Covad in three separate locations (in SoCal). DSLExtreme also has (or at least had) a good reputation. Verizon sucks. In fact, since you are in the Long Beach area, they suck even more than they do other places. Vote with your feet. -- The histories of mankind are histories only of the higher classes. Thomas Malthus From black at csulb.edu Wed Dec 24 12:01:42 2008 From: black at csulb.edu (Matthew Black) Date: Wed, 24 Dec 2008 10:01:42 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: <70D072392E56884193E3D2DE09C097A9FC1C@pascal.zaphodb.org> References: <1873041366-1230140806-cardhu_decombobulator_blackberry.rim.net-945806518-@bxe325.bisx.prod.on.blackberry> <70D072392E56884193E3D2DE09C097A9FC1C@pascal.zaphodb.org> Message-ID: On Wed, 24 Dec 2008 09:51:41 -0800 "Tomas L. Byrnes" wrote: > Cox Communications has fully on-shore support. Here in SD they are > actually LOCAL. > > Their TS staff are responsive and courteous. I only wish their network > were more reliable. (They're better than SBC in my experience, however.) In Verizon land, residential customers do not have CLEC voice or DSL alternatives. We do not have Cox. Our area is served by Charter Communications who has the broadband cable monopoly. Verizon has the fiber monopoly with their FIOS. AT&T fiber is not possible in Verizon land. Nobody competes against Verizon for residential service in Southern California. However, Charter cable customers can get dial tone and data services. matthew black e-mail postmaster bargaining unit 9 representative csueu chapter 315 network services BH-188 california state university, long beach 1250 bellflower boulevard long beach, ca 90840-0101 work phone: 562-985-5144 From auser at mind.net Wed Dec 24 12:03:44 2008 From: auser at mind.net (S. Ryan) Date: Wed, 24 Dec 2008 10:03:44 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: <495274B8.9020806@west.net> References: <495274B8.9020806@west.net> Message-ID: <49527980.1000003@mind.net> Much easier said than done. Verizon has a small territory within Qwest's 14 state region -- it's in Grants Pass, Oregon. No local ISP partners with Verizon because it's hideously expensive and obviously not enough of a demand or even a big enough service area for an ISP to partner with VZ. Not sure where Mr. Black is from but he's probably in the same boat. Regards, Steve Jay Hennigan wroteth on 12/24/2008 9:43 AM: > Matthew Black wrote: >> I've had difficulties reaching anyone with a brain >> at my DSL provider Verizon California. > > Switch to a local ISP with local tech support. > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > > From martin at airwire.ie Wed Dec 24 12:06:48 2008 From: martin at airwire.ie (Martin List-Petersen) Date: Wed, 24 Dec 2008 18:06:48 +0000 Subject: What to do when your ISP off-shores tech support In-Reply-To: <495278E3.4070505@deaddrop.org> References: <495274B8.9020806@west.net> <4952767D.6040601@psg.com> <495278E3.4070505@deaddrop.org> Message-ID: <49527A38.8070902@airwire.ie> Etaoin Shrdlu wrote: > Randy Bush wrote: > >> On 08.12.24 12:43, Jay Hennigan wrote: >> >>> Matthew Black wrote: >>> >>>> I've had difficulties reaching anyone with a brain >>>> at my DSL provider Verizon California. >>> >>> Switch to a local ISP with local tech support. > >> bingo. > > Uh, ditto? Having left SoCal a couple of years ago, my data is a bit > stale. However, I happily used XO+Covad in three separate locations (in > SoCal). DSLExtreme also has (or at least had) a good reputation. Verizon > sucks. In fact, since you are in the Long Beach area, they suck even > more than they do other places. Vote with your feet. > Layer 3 should indeed never be bought based on price or how big the provider is , but based on service. And if none of the options work out, you can always start your own. Verizon, no matter where in the world, always seems to be a nightmare to deal with. I second the suggestion to vote with your feet. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From shrdlu at deaddrop.org Wed Dec 24 12:10:33 2008 From: shrdlu at deaddrop.org (Etaoin Shrdlu) Date: Wed, 24 Dec 2008 10:10:33 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: References: <1873041366-1230140806-cardhu_decombobulator_blackberry.rim.net-945806518-@bxe325.bisx.prod.on.blackberry> <70D072392E56884193E3D2DE09C097A9FC1C@pascal.zaphodb.org> Message-ID: <49527B19.3080909@deaddrop.org> Matthew Black wrote: > On Wed, 24 Dec 2008 09:51:41 -0800 > "Tomas L. Byrnes" wrote: > >> Cox Communications has fully on-shore support. Here in SD they are >> actually LOCAL. > In Verizon land, residential customers do not have > CLEC voice or DSL alternatives. We do not have Cox. > Our area is served by Charter Communications who has > the broadband cable monopoly. Verizon has the fiber > monopoly with their FIOS. AT&T fiber is not possible > in Verizon land. Nobody competes against Verizon for > residential service in Southern California. Sir, both COVAD and DSLExtreme beg to differ. Seriously. I just checked. -- The histories of mankind are histories only of the higher classes. Thomas Malthus From zaid at zaidali.com Wed Dec 24 12:23:14 2008 From: zaid at zaidali.com (Zaid Ali) Date: Wed, 24 Dec 2008 10:23:14 -0800 (PST) Subject: Christmas spam from RESERVED IANA adressblock ? In-Reply-To: <12513112.5281230142753164.JavaMail.zaid@turing-2.local> Message-ID: <7999969.5301230142991791.JavaMail.zaid@turing-2.local> If you want to file a spam complaint I suggest you do a whois for 76.74.250.247. This is the external facing mail server that sent you the email. Most applications these days are built in layers so a web layer forwards the email to an email server, if the application is not designed to suppress the HELO from the web layer then you will see internal email routing information. As for the network side most networks filter out BOGONS so you would not get RFC1918 into your network. Zaid -----Original Message----- From: macbroadcast [mailto:marc at let.de] Sent: Wednesday, December 24, 2008 6:48 AM To: NANOG list Subject: Christmas spam from RESERVED IANA adressblock ? hello ladys and getlepersons just out of curiosity i looked a bit closer into this spammail header, because this company is really annoying and abusing a lot of internet citizens. Anfang der weitergeleiteten E-Mail: > Von: mailling at ualadys.com > Datum: 24. Dezember 2008 12:30:18 MEZ > An: marc at let.de > Betreff: E-Mail For You @ ualadys.com > Return-Path: > Received: from mx2.mail.vrmd.de ([10.0.1.21]) by vm42.mail.vrmd.de > (Cyrus v2.2.12-Invoca-RPM-2.2.12-9.RHEL4) with LMTPA; Wed, 24 Dec > 2008 12:30:25 +0100 > Received: from mx2.iispp.com ([76.74.250.247]) by mx2.mail.vrmd.de > with esmtp (Exim 4.69) (envelope-from ) id > 1LFRwW-00011o-DY for marc at let.de; Wed, 24 Dec 2008 12:30:25 +0100 > Received: from web1.iispp.com (w1 [172.16.21.244]) by mx2.iispp.com > (Postfix) with ESMTP id B71CF3504DB for ; Wed, 24 Dec > 2008 11:30:18 +0000 (UTC) > Received: by web1.iispp.com (Postfix, from userid 33) id A5C7917A405C; > Wed, 24 Dec 2008 06:30:18 -0500 (EST) "Whois" wurde gestartet . OrgName: Internet Assigned Numbers Authority OrgID: IANA Address: 4676 Admiralty Way, Suite 330 City: Marina del Rey StateProv: CA PostalCode: 90292-6695 Country: US NetRange: 172.16.0.0 - 172.31.255.255 CIDR: 172.16.0.0/12 NetName: IANA-BBLK-RESERVED NetHandle: NET-172-16-0-0-1 Parent: NET-172-0-0-0-0 NetType: IANA Special Use NameServer: BLACKHOLE-1.IANA.ORG NameServer: BLACKHOLE-2.IANA.ORG Comment: This block is reserved for special purposes. Comment: Please see RFC 1918 for additional information. Comment: http://www.arin.net/reference/rfc/rfc1918.txt RegDate: 1994-03-15 Updated: 2007-11-27 OrgAbuseHandle: IANA-IP-ARIN OrgAbuseName: Internet Corporation for Assigned Names and Number OrgAbusePhone: +1-310-301-5820 OrgAbuseEmail: abuse at iana.org OrgTechHandle: IANA-IP-ARIN OrgTechName: Internet Corporation for Assigned Names and Number OrgTechPhone: +1-310-301-5820 OrgTechEmail: abuse at iana.org # ARIN WHOIS database, last updated 2008-12-23 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. so how is this possible ? merry christmas anyway Marc > X-Sieve: CMU Sieve 2.2 > Envelope-To: marc at let.de > Delivery-Date: Wed, 24 Dec 2008 12:30:25 +0100 > X-Id-From: 1000 > X-Id-To: 238141 > X-Mail-Id: 203714382 > Mime-Version: 1.0 > Content-Type: text/html > Message-Id: <20081224113018.A5C7917A405C at web1.iispp.com> > X-Spam-Suspicion: No > X-Purgate: Clean X-purgate-ID: > 150741::081224123024-0FFB86C0-283E8BDE/0-0/0-1 X-purgate-Ad: For more > information about eXpurgate please visit http://www.expurgate.net/ > > > > > marc, You have new mail > This is to notify you that you have received an E-Mail from > > View Photos > DetailsIrina O #1000 > Subject: Destiny has linked us... > > Date: 24 December 2008 > > To read the message go here: > > PLEASE, DO NOT REPLY TO THIS E-MAIL - FOLLOW THE LINK > > http://www.ualadys.com/view_mail.rpx?hash=a71d2600f032ece232a391296f5f > 071e&mid=203714382&uid=238141 > > Thank you, > ualadys.com Support Team > > Favorites ualadys.com > > 24x7 Call center > > United States > +1 (315) 849-5814 > > United Kigdom > +44 (315) 849-5814 > > Skype support : ualadys > > > > For any question in english > about this site please call: > +1 (212) 226-8900 > Mon-Fri 9:00-16:00 (EST) From black at csulb.edu Wed Dec 24 12:31:42 2008 From: black at csulb.edu (Matthew Black) Date: Wed, 24 Dec 2008 10:31:42 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: <49527B19.3080909@deaddrop.org> References: <1873041366-1230140806-cardhu_decombobulator_blackberry.rim.net-945806518-@bxe325.bisx.prod.on.blackberry> <70D072392E56884193E3D2DE09C097A9FC1C@pascal.zaphodb.org> <49527B19.3080909@deaddrop.org> Message-ID: On Wed, 24 Dec 2008 10:10:33 -0800 Etaoin Shrdlu wrote: > Matthew Black wrote: > >> On Wed, 24 Dec 2008 09:51:41 -0800 >> "Tomas L. Byrnes" wrote: >> >>> Cox Communications has fully on-shore support. Here in SD they are >>> actually LOCAL. > >> In Verizon land, residential customers do not have >> CLEC voice or DSL alternatives. We do not have Cox. >> Our area is served by Charter Communications who has >> the broadband cable monopoly. Verizon has the fiber >> monopoly with their FIOS. AT&T fiber is not possible >> in Verizon land. Nobody competes against Verizon for >> residential service in Southern California. > > Sir, both COVAD and DSLExtreme beg to differ. Seriously. I just checked. > > -- > The histories of mankind are histories only of the higher classes. > > Thomas Malthus Going through COVAD's interactive DSL chooser, there are no options for RESIDENTIAL service. DSLextreme is charging a higher price than Verizon and I suspect they are simply reselling Verizon's DSL rather than connecting my copper to their network. That's hardly what I consider CLEC service. I could be wrong and would switch if I could. But I don't see them offering voice and that's why I conclude they are reselling Verizon's DSL service. matthew black california state university, long beach From mksmith at adhost.com Wed Dec 24 12:34:55 2008 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Wed, 24 Dec 2008 10:34:55 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: References: <1873041366-1230140806-cardhu_decombobulator_blackberry.rim.net-945806518-@bxe325.bisx.prod.on.blackberry><70D072392E56884193E3D2DE09C097A9FC1C@pascal.zaphodb.org> <49527B19.3080909@deaddrop.org> Message-ID: <17838240D9A5544AAA5FF95F8D52031605273564@ad-exh01.adhost.lan> > -----Original Message----- > From: Matthew Black [mailto:black at csulb.edu] > Sent: Wednesday, December 24, 2008 10:32 AM > To: Etaoin Shrdlu; nanog at nanog.org > Subject: Re: What to do when your ISP off-shores tech support > > On Wed, 24 Dec 2008 10:10:33 -0800 > Etaoin Shrdlu wrote: > > Matthew Black wrote: > > > >> On Wed, 24 Dec 2008 09:51:41 -0800 > >> "Tomas L. Byrnes" wrote: > >> > >>> Cox Communications has fully on-shore support. Here in SD they are > >>> actually LOCAL. > > > >> In Verizon land, residential customers do not have > >> CLEC voice or DSL alternatives. We do not have Cox. > >> Our area is served by Charter Communications who has > >> the broadband cable monopoly. Verizon has the fiber > >> monopoly with their FIOS. AT&T fiber is not possible > >> in Verizon land. Nobody competes against Verizon for > >> residential service in Southern California. > > > > Sir, both COVAD and DSLExtreme beg to differ. Seriously. I just checked. > > > > -- > > The histories of mankind are histories only of the higher classes. > > > > Thomas Malthus > > > Going through COVAD's interactive DSL chooser, > there are no options for RESIDENTIAL service. > > > > > DSLextreme is charging a higher price than Verizon > and I suspect they are simply reselling Verizon's > DSL rather than connecting my copper to their > network. That's hardly what I consider CLEC service. > I could be wrong and would switch if I could. But I > don't see them offering voice and that's why I conclude > they are reselling Verizon's DSL service. > > matthew black > california state university, long beach They are probably using Verizon for the local loop, but they also have their own DSLAM's and Layer 3 network to transport your data. That would be a good question to ask them. It sounds like you have a price/quality issue going on. Do you want to pay a little more for better service? If price is your main qualifier then you may be stuck vis a vis quality. Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 474 bytes Desc: not available URL: From chaim.rieger at gmail.com Wed Dec 24 12:36:09 2008 From: chaim.rieger at gmail.com (chaim.rieger at gmail.com) Date: Wed, 24 Dec 2008 18:36:09 +0000 Subject: What to do when your ISP off-shores tech support In-Reply-To: References: <1873041366-1230140806-cardhu_decombobulator_blackberry.rim.net-945806518-@bxe325.bisx.prod.on.blackberry><70D072392E56884193E3D2DE09C097A9FC1C@pascal.zaphodb.org> <49527B19.3080909@deaddrop.org> Message-ID: <538040823-1230143779-cardhu_decombobulator_blackberry.rim.net-821552651-@bxe325.bisx.prod.on.blackberry> Actually the resell sbc primarily. Sent via BlackBerry from T-Mobile -----Original Message----- From: "Matthew Black" Date: Wed, 24 Dec 2008 10:31:42 To: Etaoin Shrdlu; Subject: Re: What to do when your ISP off-shores tech support On Wed, 24 Dec 2008 10:10:33 -0800 Etaoin Shrdlu wrote: > Matthew Black wrote: > >> On Wed, 24 Dec 2008 09:51:41 -0800 >> "Tomas L. Byrnes" wrote: >> >>> Cox Communications has fully on-shore support. Here in SD they are >>> actually LOCAL. > >> In Verizon land, residential customers do not have >> CLEC voice or DSL alternatives. We do not have Cox. >> Our area is served by Charter Communications who has >> the broadband cable monopoly. Verizon has the fiber >> monopoly with their FIOS. AT&T fiber is not possible >> in Verizon land. Nobody competes against Verizon for >> residential service in Southern California. > > Sir, both COVAD and DSLExtreme beg to differ. Seriously. I just checked. > > -- > The histories of mankind are histories only of the higher classes. > > Thomas Malthus Going through COVAD's interactive DSL chooser, there are no options for RESIDENTIAL service. DSLextreme is charging a higher price than Verizon and I suspect they are simply reselling Verizon's DSL rather than connecting my copper to their network. That's hardly what I consider CLEC service. I could be wrong and would switch if I could. But I don't see them offering voice and that's why I conclude they are reselling Verizon's DSL service. matthew black california state university, long beach From David_Hankins at isc.org Wed Dec 24 12:38:23 2008 From: David_Hankins at isc.org (David W. Hankins) Date: Wed, 24 Dec 2008 10:38:23 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: <495274B8.9020806@west.net> References: <495274B8.9020806@west.net> Message-ID: <20081224183823.GB5467@isc.org> On Wed, Dec 24, 2008 at 09:43:20AM -0800, Jay Hennigan wrote: > Matthew Black wrote: >> I've had difficulties reaching anyone with a brain >> at my DSL provider Verizon California. > > Switch to a local ISP with local tech support. Actually, and I know this kind of experience is really subjective, but lately I have been getting better service from residents of India via web-based chat tools than I have been getting from residents of the US via telephone. At the same company. My impression as a customer is that only one of these two individuals genuinely wanted to do or keep the job they were given, and desired to do it well. That's really what you should be looking for, locality is irrelevant. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From tomb at byrneit.net Wed Dec 24 12:57:39 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Wed, 24 Dec 2008 10:57:39 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: References: <1873041366-1230140806-cardhu_decombobulator_blackberry.rim.net-945806518-@bxe325.bisx.prod.on.blackberry> <70D072392E56884193E3D2DE09C097A9FC1C@pascal.zaphodb.org> Message-ID: <70D072392E56884193E3D2DE09C097A9FC23@pascal.zaphodb.org> Sounds like a business opportunity to me. Given any thought to Sprint EV-DO? >-----Original Message----- >From: Matthew Black [mailto:black at csulb.edu] >Sent: Wednesday, December 24, 2008 10:02 AM >To: Tomas L. Byrnes; chaim.rieger at gmail.com; Jay Hennigan >Cc: nanog at nanog.org >Subject: Re: What to do when your ISP off-shores tech support > >On Wed, 24 Dec 2008 09:51:41 -0800 > "Tomas L. Byrnes" wrote: >> Cox Communications has fully on-shore support. Here in SD they are >> actually LOCAL. >> >> Their TS staff are responsive and courteous. I only wish their network >> were more reliable. (They're better than SBC in my experience, >however.) > > >In Verizon land, residential customers do not have >CLEC voice or DSL alternatives. We do not have Cox. >Our area is served by Charter Communications who has >the broadband cable monopoly. Verizon has the fiber >monopoly with their FIOS. AT&T fiber is not possible >in Verizon land. Nobody competes against Verizon for >residential service in Southern California. However, >Charter cable customers can get dial tone and data >services. > >matthew black >e-mail postmaster > >bargaining unit 9 representative >csueu chapter 315 > >network services BH-188 >california state university, long beach >1250 bellflower boulevard >long beach, ca 90840-0101 > >work phone: 562-985-5144 From Skywing at valhallalegends.com Wed Dec 24 13:00:42 2008 From: Skywing at valhallalegends.com (Skywing) Date: Wed, 24 Dec 2008 13:00:42 -0600 Subject: What to do when your ISP off-shores tech support Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA25F34@caralain.haven.nynaeve.net> The 5GB/month cutoff would be a bit of a damper there... ? S -----Original Message----- From: Tomas L. Byrnes Sent: Wednesday, December 24, 2008 12:58 To: Matthew Black ; chaim.rieger at gmail.com ; Jay Hennigan Cc: nanog at nanog.org Subject: RE: What to do when your ISP off-shores tech support Sounds like a business opportunity to me. Given any thought to Sprint EV-DO? >-----Original Message----- >From: Matthew Black [mailto:black at csulb.edu] >Sent: Wednesday, December 24, 2008 10:02 AM >To: Tomas L. Byrnes; chaim.rieger at gmail.com; Jay Hennigan >Cc: nanog at nanog.org >Subject: Re: What to do when your ISP off-shores tech support > >On Wed, 24 Dec 2008 09:51:41 -0800 > "Tomas L. Byrnes" wrote: >> Cox Communications has fully on-shore support. Here in SD they are >> actually LOCAL. >> >> Their TS staff are responsive and courteous. I only wish their network >> were more reliable. (They're better than SBC in my experience, >however.) > > >In Verizon land, residential customers do not have >CLEC voice or DSL alternatives. We do not have Cox. >Our area is served by Charter Communications who has >the broadband cable monopoly. Verizon has the fiber >monopoly with their FIOS. AT&T fiber is not possible >in Verizon land. Nobody competes against Verizon for >residential service in Southern California. However, >Charter cable customers can get dial tone and data >services. > >matthew black >e-mail postmaster > >bargaining unit 9 representative >csueu chapter 315 > >network services BH-188 >california state university, long beach >1250 bellflower boulevard >long beach, ca 90840-0101 > >work phone: 562-985-5144 From rbf+nanog at panix.com Wed Dec 24 13:02:17 2008 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Wed, 24 Dec 2008 13:02:17 -0600 Subject: What is the most standard subnet length on internet In-Reply-To: <4950F4E4.2080401@ieee.org> References: <10068989.128811229991024019.JavaMail.weblogic@epml06> <49503178.3000304@rollernet.us> <85D6FED5-AB83-4AFD-940F-3A8386216CDB@daork.net> <49503DDB.8030208@rollernet.us> <20081223013925.GA42151@gweep.net> <41036FF1-4200-4D16-B69D-1D3A91DDFCC1@daork.net> <4950EC4C.5080504@Janoszka.pl> <4950F4E4.2080401@ieee.org> Message-ID: <20081224190217.GA14639@panix.com> On Tue, Dec 23, 2008 at 08:25:40AM -0600, Alex H. Ryu wrote: > Also one of the reason why not putting default route may be because of > recursive lookup from routing table. > If you have multi-homed site within your network with static route, and > if you use next-hop IP address instead of named interface, you will see > the problem when you have default route in routing table. > For an example, if you have "ip route 1.0.0.0 255.0.0.0 2.2.2.2". > If the interface for 2.2.2.2 is down, 1.0.0.0/8 will be still be in the > routing table because 2.2.2.2 can be reached via default route > (0.0.0.0/0) from routing table recursive lookup. > Therefore the traffic for 1.0.0.0/8 will be forwarded to "0.0.0.0/0" > next-hop ip address, and customer fail-over scenario will not be working > at all. > > Only way to resolve this problem is... Actually three... > 1) Use named interface such as "serial 1/0" instead of "x.x.x.x" IP > next-hop address. > But sometimes this is not an option if you use ethernet circuit or > something like Broadcast or NBMA network. ip route 1.0.0.0 255.0.0.0 fa0/0 2.2.2.2 -- Brett From swm at emanon.com Wed Dec 24 13:03:38 2008 From: swm at emanon.com (Scott Morris) Date: Wed, 24 Dec 2008 14:03:38 -0500 Subject: What is the most standard subnet length on internet In-Reply-To: References: <10068989.128811229991024019.JavaMail.weblogic@epml06><49503178.3000304@rollernet.us> Message-ID: <4509342F74214B2B9E706FE84F9D1A50@scott66ed7b03d> In case anyone cares... From my router's perspective: /1 0 /2 0 /3 0 /4 0 /5 0 /6 0 /7 0 /8 20 /9 9 /10 20 /11 53 /12 159 /13 310 /14 560 /15 1,096 /16 10,235 /17 4,461 /18 7,593 /19 16,284 /20 19,075 /21 18,598 /22 23,941 /23 24,615 /24 144,832 /25 1 /26 1 /27 1 /28 3 /29 1 /30 1,234 /31 13 /32 23 Total 273,138 No, I wasn't bored enough to count them by hand. JUNOS has a "count" feature. :) Scott -----Original Message----- From: Jon Lewis [mailto:jlewis at lewis.org] Sent: Monday, December 22, 2008 8:12 PM To: Seth Mattinen Cc: NANOG list Subject: Re: What is the most standard subnet length on internet On Mon, 22 Dec 2008, Seth Mattinen wrote: > Anyone running a platform that can't take a full table would apply > such a filter to weed out anyone who likes to announce all of their > space as /24's for "traffic engineering". If one does that and doesn't > announce the aggregate as well, one could find themselves facing random black holes. There's no "if" about it. Months ago when I and others were looking into this, we found plenty of examples of networks with /19s, /20s, etc. announcing only the /24 deaggregates. If you plan to filter these people and have customers to answer to, you'll need to point default at someone who's not filtering them. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From martin at airwire.ie Wed Dec 24 13:05:50 2008 From: martin at airwire.ie (Martin List-Petersen) Date: Wed, 24 Dec 2008 19:05:50 +0000 Subject: What to do when your ISP off-shores tech support In-Reply-To: <70D072392E56884193E3D2DE09C097A9FC23@pascal.zaphodb.org> References: <1873041366-1230140806-cardhu_decombobulator_blackberry.rim.net-945806518-@bxe325.bisx.prod.on.blackberry> <70D072392E56884193E3D2DE09C097A9FC1C@pascal.zaphodb.org> <70D072392E56884193E3D2DE09C097A9FC23@pascal.zaphodb.org> Message-ID: <4952880E.5070804@airwire.ie> Tomas L. Byrnes wrote: > Sounds like a business opportunity to me. > > Given any thought to Sprint EV-DO? You can not seriously consider a 3G technology as broadband replacement. It is midband at best, especially because there is no control on contention. Kind regards, Martin List-Petersen Airwire -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From r.engehausen at gmail.com Wed Dec 24 13:42:08 2008 From: r.engehausen at gmail.com (Roy) Date: Wed, 24 Dec 2008 11:42:08 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: <495278E3.4070505@deaddrop.org> References: <495274B8.9020806@west.net> <4952767D.6040601@psg.com> <495278E3.4070505@deaddrop.org> Message-ID: <49529090.10704@gmail.com> Etaoin Shrdlu wrote: > Randy Bush wrote: > >> On 08.12.24 12:43, Jay Hennigan wrote: >> >>> Matthew Black wrote: >>> >>>> I've had difficulties reaching anyone with a brain >>>> at my DSL provider Verizon California. >>> >>> Switch to a local ISP with local tech support. > >> bingo. > > Uh, ditto? Having left SoCal a couple of years ago, my data is a bit > stale. However, I happily used XO+Covad in three separate locations > (in SoCal). DSLExtreme also has (or at least had) a good reputation. > Verizon sucks. In fact, since you are in the Long Beach area, they > suck even more than they do other places. Vote with your feet. > I am pretty sure that COVAD is offshore now.... From shrdlu at deaddrop.org Wed Dec 24 14:09:14 2008 From: shrdlu at deaddrop.org (Etaoin Shrdlu) Date: Wed, 24 Dec 2008 12:09:14 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: <49529090.10704@gmail.com> References: <495274B8.9020806@west.net> <4952767D.6040601@psg.com> <495278E3.4070505@deaddrop.org> <49529090.10704@gmail.com> Message-ID: <495296EA.4020802@deaddrop.org> Roy wrote: > Etaoin Shrdlu wrote: >>...However, I happily used XO+Covad in three separate locations >>(in SoCal). DSLExtreme also has (or at least had) a good reputation. >>Verizon sucks. In fact, since you are in the Long Beach area, they >>suck even more than they do other places. Vote with your feet. > I am pretty sure that COVAD is offshore now.... Might be, but the quality of customer service was the issue, I believe, not just where it was located (at least I hope that wasn't the only objection). I think Mr. Black has already made plain that cost is an issue, in any case. I used to have the lowest business class they provided (even though it was just to my house). Currently, I am the only customer for my local ISP with the service level I have, going to a residential address. We all spend our $$$ on what's important to us. Packets are important to me. I like 'em. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. Brian W. Kernighan From tomb at byrneit.net Wed Dec 24 14:22:46 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Wed, 24 Dec 2008 12:22:46 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: <4952880E.5070804@airwire.ie> References: <1873041366-1230140806-cardhu_decombobulator_blackberry.rim.net-945806518-@bxe325.bisx.prod.on.blackberry> <70D072392E56884193E3D2DE09C097A9FC1C@pascal.zaphodb.org> <70D072392E56884193E3D2DE09C097A9FC23@pascal.zaphodb.org> <4952880E.5070804@airwire.ie> Message-ID: <70D072392E56884193E3D2DE09C097A9FC25@pascal.zaphodb.org> Hence my positing that there was a business opportunity, for real wireless broadband. He's in Long Beach CA. The Verizon service are in So-Cal is actually many of the most affluent communities. Nollaig Shona Duit! >-----Original Message----- >From: Martin List-Petersen [mailto:martin at airwire.ie] >Sent: Wednesday, December 24, 2008 11:06 AM >To: Tomas L. Byrnes >Cc: nanog at nanog.org >Subject: Re: What to do when your ISP off-shores tech support > >Tomas L. Byrnes wrote: >> Sounds like a business opportunity to me. >> >> Given any thought to Sprint EV-DO? > > >You can not seriously consider a 3G technology as broadband replacement. >It is midband at best, especially because there is no control on >contention. > >Kind regards, >Martin List-Petersen >Airwire >-- >Airwire - Ag Nascadh Pobal an Iarthar >http://www.airwire.ie >Phone: 091-865 968 From sethm at rollernet.us Wed Dec 24 14:43:02 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 24 Dec 2008 12:43:02 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: References: <1873041366-1230140806-cardhu_decombobulator_blackberry.rim.net-945806518-@bxe325.bisx.prod.on.blackberry> <70D072392E56884193E3D2DE09C097A9FC1C@pascal.zaphodb.org> <49527B19.3080909@deaddrop.org> Message-ID: <49529ED6.3040109@rollernet.us> Matthew Black wrote: > > > Going through COVAD's interactive DSL chooser, > there are no options for RESIDENTIAL service. > > > > > DSLextreme is charging a higher price than Verizon > and I suspect they are simply reselling Verizon's > DSL rather than connecting my copper to their > network. That's hardly what I consider CLEC service. > I could be wrong and would switch if I could. But I > don't see them offering voice and that's why I conclude > they are reselling Verizon's DSL service. > You get what you pay for (most of the time). Most locals do resell the ILEC service. However, they have more access to the ILEC than you do (bigger customer and all that), and they take over at layer 2. If you think you'll get worse service from a local ISP because they aren't a CLEC, you'd be dead wrong. ~Seth From orion at pirk.com Wed Dec 24 19:43:40 2008 From: orion at pirk.com (Steve Pirk) Date: Wed, 24 Dec 2008 17:43:40 -0800 (PST) Subject: HUMOR: NANOG stop the economic downturn :-) Message-ID: Heard this on NPR's All Things Considered today... Get busy people! :-) http://www.npr.org/templates/story/story.php?storyId=98694231 Poet on Call by Andrei Codrescu The Machines Haven't Taken Over All Things Considered, December 24, 2008 With one pull of a switch, the ocean of junk that spilled out of my mailbox every day, was swooshed back into the speechless abyss. If you had asked me before this news, what hand human or divine could stop spam, I'd have answered like Heraclitus, "Who can stop the sea from rising?" It turns out that somebody before a keyboard can, thank you. There is hope. Machines haven't yet taken over. If it's that easy to stop what seemed like unstoppable, why can't other seemingly unstoppable human-generated and computer-driven phenomena be switched off the same way? Why isn't somebody pulling the switch on the collapsing world trade going on in the cracks between time zones? What's going on while I sleep and my retirement money slips down some unfathomable hole? Why don't the providers capable of such cosmic gestures as making the spam-ocean vanish, not exercise their benevolent force against other oceans that threaten us: the automatic unfair trades, the silent streams of world capital vanishing into invisible dead zones, the globe-circling panics? -- Steve Equal bytes for women. From dave.nanog at alfordmedia.com Wed Dec 24 20:14:54 2008 From: dave.nanog at alfordmedia.com (Dave Pooser) Date: Wed, 24 Dec 2008 20:14:54 -0600 Subject: What to do when your ISP off-shores tech support In-Reply-To: <49529090.10704@gmail.com> Message-ID: >> Uh, ditto? Having left SoCal a couple of years ago, my data is a bit >> stale. However, I happily used XO+Covad in three separate locations >> (in SoCal). DSLExtreme also has (or at least had) a good reputation. >> Verizon sucks. In fact, since you are in the Long Beach area, they >> suck even more than they do other places. Vote with your feet. >> > I am pretty sure that COVAD is offshore now.... Last time I talked to them the helpdesk people were Canadian. That's for T1s; I'm not sure if they do DSL support in the same location. -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com From jfmezei at vaxination.ca Thu Dec 25 00:26:56 2008 From: jfmezei at vaxination.ca (JF Mezei) Date: Thu, 25 Dec 2008 01:26:56 -0500 Subject: What to do when your ISP off-shores tech support In-Reply-To: References: Message-ID: <495327B0.8060508@vaxination.ca> You cannot blame the script readers. Whether they are next door to you or in India, the employer has decided to provide low training levels and script based support. You might consider calling their sales department. Explain that you are technically oriented and experienced and that the level of support they provide is inadequate for you and that you understand how networks run. Ask if it is possible to give you access to higher level support since this would result in less time being wasted by you and them when there are problems. They may suggest you get a business account. From mysidia at gmail.com Thu Dec 25 00:33:48 2008 From: mysidia at gmail.com (James Hess) Date: Thu, 25 Dec 2008 00:33:48 -0600 Subject: Christmas spam from RESERVED IANA adressblock ? In-Reply-To: <23DDCEBCBF4E486B933ACE0C78EBF556@scott66ed7b03d> References: <23DDCEBCBF4E486B933ACE0C78EBF556@scott66ed7b03d> Message-ID: <6eb799ab0812242233v2ad6f74aq5eb9ee9847663459@mail.gmail.com> On Wed, Dec 24, 2008 at 11:38 AM, Scott Morris wrote: > I would guess (hope?) that most, if not all, providers filter the RFC1918 > space addresses from entering or leaving their networks unchecked. But just > my two cents there... All sites (not just providers) should, but many just don't do what they should. In some cases it may not even be practical for people to do what they should (due to poor software/hardware, or the poor availability of IPv4 addresses) RFC1918 addresses should also never be found in mail headers of any messages being exchanged over the internet.. For the very reason that it creates this confusion. Another case of many implementations not doing anything close to what they should. RFC1918 says on page 4: " Indirect references to such addresses should be contained within the enterprise. Prominent examples of such references are DNS Resource Records and other information referring to internal private addresses. In particular, Internet service providers should take measures to prevent such leakage. " Private IPs in mail headers are just fine inside the enterprise, but messages with headers referencing private IPs should not be exchanged over the internet. RC1918 specifically says indirect references should not leave the enterprise. The only thing that would be worse or more confusing to other sites would be to not add a mail header at all, or to use a real IP address shared by other hosts that use 1918 addresses on the LAN. Mail servers that deal with internet mail should always add headers that contain a distinct public IP address that belongs to that mail server, for distinctively showing any abuse or mail server problem, even if all access to that public IP is actually blocked by a firewall. Not sharing mail server public IPs isn't part of the RFC1918 though, it's just the right way(TM). -- -J From jfmezei at vaxination.ca Thu Dec 25 01:09:19 2008 From: jfmezei at vaxination.ca (JF Mezei) Date: Thu, 25 Dec 2008 02:09:19 -0500 Subject: Christmas spam from RESERVED IANA adressblock ? In-Reply-To: <6eb799ab0812242233v2ad6f74aq5eb9ee9847663459@mail.gmail.com> References: <23DDCEBCBF4E486B933ACE0C78EBF556@scott66ed7b03d> <6eb799ab0812242233v2ad6f74aq5eb9ee9847663459@mail.gmail.com> Message-ID: <4953319F.7@vaxination.ca> James Hess wrote: > RFC1918 addresses should also never be found in mail headers of any > messages being exchanged over the internet.. One need to understand the Received: headers and their order. Private address space is perfectly legitimate. Very common in the early part of transport and often seen in the last delivery in large organisations that have multiple distributed SMTP servers. What is important is for a recipient to know which Received: header he can trust. The only IP address you can trust are the one inside your own organisation, and the IP address that sent the message to your organisation. All other Received: headers below that to be considered fake unless proven otherwise. In the above case, it appears that the message arrived within the organisation from a public IP address, and then was sent to another host within the organisation via private address space. It is also important to note that the topmost header was able to reverse translate the 10.*.*.* IP which implies that it was internal to the organisation, using an internal DNS server which makes it more legitimate since it is within that organisation. From hutton at sdsc.edu Thu Dec 25 02:47:41 2008 From: hutton at sdsc.edu (Tom Hutton) Date: Thu, 25 Dec 2008 00:47:41 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: <538040823-1230143779-cardhu_decombobulator_blackberry.rim.net-821552651-@bxe325.bisx.prod.on.blackberry> References: <1873041366-1230140806-cardhu_decombobulator_blackberry.rim.net-945806518-@bxe325.bisx.prod.on.blackberry> <70D072392E56884193E3D2DE09C097A9FC1C@pascal.zaphodb.org> <49527B19.3080909@deaddrop.org> <538040823-1230143779-cardhu_decombobulator_blackberry.rim.net-821552651-@bxe325.bisx.prod.on.blackberry> Message-ID: I believe they are using SBC and Verizon's dslams and just have an ATM cloud that touches their routers. Still, I see better throughput from them than I did from SBC. When I had my own RLAN (private DSL network on SBC dslams) I actually got great bandwidth. On Wed, Dec 24, 2008 at 10:36 AM, wrote: > Actually the resell sbc primarily. > > > Sent via BlackBerry from T-Mobile > > -----Original Message----- > From: "Matthew Black" > > Date: Wed, 24 Dec 2008 10:31:42 > To: Etaoin Shrdlu; > Subject: Re: What to do when your ISP off-shores tech support > > > On Wed, 24 Dec 2008 10:10:33 -0800 > Etaoin Shrdlu wrote: >> Matthew Black wrote: >> >>> On Wed, 24 Dec 2008 09:51:41 -0800 >>> "Tomas L. Byrnes" wrote: >>> >>>> Cox Communications has fully on-shore support. Here in SD they are >>>> actually LOCAL. >> >>> In Verizon land, residential customers do not have >>> CLEC voice or DSL alternatives. We do not have Cox. >>> Our area is served by Charter Communications who has >>> the broadband cable monopoly. Verizon has the fiber >>> monopoly with their FIOS. AT&T fiber is not possible >>> in Verizon land. Nobody competes against Verizon for >>> residential service in Southern California. >> >> Sir, both COVAD and DSLExtreme beg to differ. Seriously. I just checked. >> >> -- >> The histories of mankind are histories only of the higher classes. >> >> Thomas Malthus > > > Going through COVAD's interactive DSL chooser, > there are no options for RESIDENTIAL service. > > > > > DSLextreme is charging a higher price than Verizon > and I suspect they are simply reselling Verizon's > DSL rather than connecting my copper to their > network. That's hardly what I consider CLEC service. > I could be wrong and would switch if I could. But I > don't see them offering voice and that's why I conclude > they are reselling Verizon's DSL service. > > matthew black > california state university, long beach > > From kngspook at gmail.com Thu Dec 25 04:01:31 2008 From: kngspook at gmail.com (Neil) Date: Thu, 25 Dec 2008 02:01:31 -0800 Subject: Christmas spam from RESERVED IANA adressblock ? In-Reply-To: <6eb799ab0812242233v2ad6f74aq5eb9ee9847663459@mail.gmail.com> References: <23DDCEBCBF4E486B933ACE0C78EBF556@scott66ed7b03d> <6eb799ab0812242233v2ad6f74aq5eb9ee9847663459@mail.gmail.com> Message-ID: <77e4079b0812250201w356481c2hca04e5ca6d22f2c4@mail.gmail.com> Maybe I'm showing my newb-ness here.... On Wed, Dec 24, 2008 at 10:33 PM, James Hess wrote: [snip] > > RFC1918 addresses should also never be found in mail headers of any > messages being exchanged over the internet.. For the very reason that it > creates this confusion. Another case of many implementations not doing > anything close to what they should. > > RFC1918 says on page 4: > " Indirect references to such addresses should be contained within the > enterprise. Prominent examples of such references are DNS Resource > Records and other information referring to internal private > addresses. In particular, Internet service providers should take > measures to prevent such leakage. > " > > Private IPs in mail headers are just fine inside the enterprise, but messages > with headers referencing private IPs should not be exchanged over the > internet. > RC1918 specifically says indirect references should not leave the enterprise. > > > The only thing that would be worse or more confusing to other sites would be to > not add a mail header at all, or to use a real IP address shared by other hosts > that use 1918 addresses on the LAN. > So what are you suggesting an admin should do (assuming, for example, he doesn't have enough IPv4 addresses to go around)? If he shouldn't strip headers, and he shouldn't use the NAT'd addresses, then he's running rather low on options. And no matter what he does, it's going to involve modification of the headers, which is generally considered A Bad Thing(TM). Especially since some, not many, but enough, sysadmins are going to do the modification badly, and either accidentally mangle the rest of the email or do something to make tracking down problems more difficult. I think a big difference between the example you quoted about RFC 1918 and Received: headers is that DNS records will be used by various programs automatically, whereas mail headers are generally not; as JF Mezei pointed out, all you have to do is learn to read mail headers properly. > Not sharing mail server public IPs isn't part of the RFC1918 though, > it's just the right way(TM). I didn't understand what you meant here... Not sharing my mail server's public IP is going to make it a little difficult for me to receive mail, I suspect... From hescominsoon at emmanuelcomputerconsulting.com Thu Dec 25 08:47:01 2008 From: hescominsoon at emmanuelcomputerconsulting.com (William Warren) Date: Thu, 25 Dec 2008 09:47:01 -0500 Subject: What to do when your ISP off-shores tech support In-Reply-To: References: <1873041366-1230140806-cardhu_decombobulator_blackberry.rim.net-945806518-@bxe325.bisx.prod.on.blackberry> <70D072392E56884193E3D2DE09C097A9FC1C@pascal.zaphodb.org> <49527B19.3080909@deaddrop.org> Message-ID: <49539CE5.60202@emmanuelcomputerconsulting.com> Matthew Black wrote: > On Wed, 24 Dec 2008 10:10:33 -0800 > Etaoin Shrdlu wrote: >> Matthew Black wrote: >> >>> On Wed, 24 Dec 2008 09:51:41 -0800 >>> "Tomas L. Byrnes" wrote: >>> >>>> Cox Communications has fully on-shore support. Here in SD they are >>>> actually LOCAL. >> >>> In Verizon land, residential customers do not have >>> CLEC voice or DSL alternatives. We do not have Cox. >>> Our area is served by Charter Communications who has >>> the broadband cable monopoly. Verizon has the fiber >>> monopoly with their FIOS. AT&T fiber is not possible >>> in Verizon land. Nobody competes against Verizon for >>> residential service in Southern California. >> >> Sir, both COVAD and DSLExtreme beg to differ. Seriously. I just checked. >> >> -- >> The histories of mankind are histories only of the higher classes. >> >> Thomas Malthus > > > Going through COVAD's interactive DSL chooser, > there are no options for RESIDENTIAL service. > > > > > DSLextreme is charging a higher price than Verizon > and I suspect they are simply reselling Verizon's > DSL rather than connecting my copper to their > network. That's hardly what I consider CLEC service. > I could be wrong and would switch if I could. But I > don't see them offering voice and that's why I conclude > they are reselling Verizon's DSL service. > > matthew black > california state university, long beach > > voice on landline? drop it..go cellular. I'm totally verizon free. Comcast does my internet and tv and sprint does my three business lines. From mailvortex at gmail.com Thu Dec 25 09:52:24 2008 From: mailvortex at gmail.com (Ben Scott) Date: Thu, 25 Dec 2008 10:52:24 -0500 Subject: What to do when your ISP off-shores tech support In-Reply-To: References: <1873041366-1230140806-cardhu_decombobulator_blackberry.rim.net-945806518-@bxe325.bisx.prod.on.blackberry> <70D072392E56884193E3D2DE09C097A9FC1C@pascal.zaphodb.org> <49527B19.3080909@deaddrop.org> Message-ID: <59f980d60812250752l82ee0a4x5994f4ec5e821ca9@mail.gmail.com> On Wed, Dec 24, 2008 at 1:31 PM, Matthew Black wrote: > Going through COVAD's interactive DSL chooser, > there are no options for RESIDENTIAL service. So choose "business". In the world of mass-market ISPs, "residential" means "end-user without clue who cares only about price, not service". You actually want business. Yes, you will pay more. You've established that you don't like the service level you receive at the rate you are currently paying. > DSLextreme is charging a higher price than Verizon > and I suspect they are simply reselling Verizon's > DSL ... If their customer service/tech support is better, why do you care how they get the packets to your equipment? > I don't see them offering voice and that's why I conclude > they are reselling Verizon's DSL service. Pure speculation on my part, but maybe they just aren't interested in the voice market. -- Ben From herrin-nanog at dirtside.com Thu Dec 25 10:47:49 2008 From: herrin-nanog at dirtside.com (William Herrin) Date: Thu, 25 Dec 2008 11:47:49 -0500 Subject: Christmas spam from RESERVED IANA adressblock ? In-Reply-To: <6eb799ab0812242233v2ad6f74aq5eb9ee9847663459@mail.gmail.com> References: <23DDCEBCBF4E486B933ACE0C78EBF556@scott66ed7b03d> <6eb799ab0812242233v2ad6f74aq5eb9ee9847663459@mail.gmail.com> Message-ID: <3c3e3fca0812250847t4784c299q793b42b6b2eca43b@mail.gmail.com> On Thu, Dec 25, 2008 at 1:33 AM, James Hess wrote: > RFC1918 addresses should also never be found > in mail headers of any messages being exchanged over the internet.. > RFC1918 says on page 4: James, If you want to be dogmatic about it, the must and must nots in RFC2821, 3.8.2 supersede the "should" in RFC 1918. The lines with the 1918 addresses must remain. Pragmatically speaking, when you want to trace a spam, you have to ignore both irrelevant information and intentionally false information. For example, I've seen spams which contain Received lines alleging receipt from a completely innocent network. You have to pay close attention because the only clue that it's a lie is that the Received line doesn't connect with any later ones. The system which allegedly accepted the message doesn't appear in another received line as having sent it to the next server in the chain. As for the incident spam, there's probably an abusable web form on www.iispp.com that some remote spammer has discovered and is using to relay spam. When you see a message which appears to have originated from a generic web server, that's often what's going on. This one has that feel to it. Were it properly programmed, the form would have appended a Received line of its own indicating the source of the http request. Then again, if it was properly programmed it wouldn't be useful for relaying spam in the first place. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From martin at theicelandguy.com Thu Dec 25 15:54:37 2008 From: martin at theicelandguy.com (Martin Hannigan) Date: Thu, 25 Dec 2008 16:54:37 -0500 Subject: What to do when your ISP off-shores tech support In-Reply-To: <495274B8.9020806@west.net> References: <495274B8.9020806@west.net> Message-ID: On Wed, Dec 24, 2008 at 12:43 PM, Jay Hennigan wrote: > Matthew Black wrote: > >> I've had difficulties reaching anyone with a brain >> at my DSL provider Verizon California. >> > > Switch to a local ISP with local tech support. Hi Jay: Is there really anything wrong with sending first-level technical support offshore? Macs are macs, Windows is windows and mail is mail whether you're in Mumbai or Memphis. As long as the language skills are good and the people are well trained, it should be mostly irrelevant, IMHO. Happy Holidays, -M< From simon at slimey.org Thu Dec 25 16:01:04 2008 From: simon at slimey.org (Simon Lockhart) Date: Thu, 25 Dec 2008 22:01:04 +0000 Subject: What to do when your ISP off-shores tech support In-Reply-To: References: <495274B8.9020806@west.net> Message-ID: <20081225220104.GI14718@virtual.bogons.net> On Thu Dec 25, 2008 at 04:54:37PM -0500, Martin Hannigan wrote: > As long as the language skills are good [...] Because, generally, this is not the case. Oh, and when there's 3 fibre cuts between you and India, and your voice gets shrunk to a 9kbps VoIP channel, it's doubly bad. Simon From dave.nanog at alfordmedia.com Thu Dec 25 16:36:30 2008 From: dave.nanog at alfordmedia.com (Dave Pooser) Date: Thu, 25 Dec 2008 17:36:30 -0500 Subject: What to do when your ISP off-shores tech support In-Reply-To: Message-ID: > Macs are macs, Windows is windows and mail is mail whether you're in Mumbai > or Memphis. As long as the language skills are good and the people are well > trained, it should be mostly irrelevant, IMHO. The problem, IMO is that the sort of organization that wants to reduce labor costs from $11/hr to $1.50/hr (all numbers made up out of thin air) by moving tech support offshore is likely to be the sort of organization that reduces labor costs from $1.50 to $1.15/hr by moving tech support from an offshoring house that provides well-trained people with good language skills to one that provides warm bodies and asinine scripts. I'm know there are good tech support people in India-- I've dealt with some of them-- but the overwhelming majority of times I've ended talking to Indian tech support I've gotten people who are as fluent in English as I am in Hindi and as familiar with the technology they are "supporting" as I am with rebuilding transmissions ("not at all" and "not at all" respectively). That said, Merry Christmas to all and I hope Santa brought extra eggnog to any poor souls working tech support this evening, on any continent. :^) -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com From jay at west.net Thu Dec 25 16:37:48 2008 From: jay at west.net (Jay Hennigan) Date: Thu, 25 Dec 2008 14:37:48 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: References: <495274B8.9020806@west.net> Message-ID: <49540B3C.8020709@west.net> Martin Hannigan wrote: > Hi Jay: > > Is there really anything wrong with sending first-level technical > support offshore? > Macs are macs, Windows is windows and mail is mail whether you're in > Mumbai or Memphis. As long as the language skills are good and the > people are well trained, it should be mostly irrelevant, IMHO. In and of itself and setting aside patriotic/nationalistic issues, probably not, assuming adequate technical and product knowledge and language skills. I suppose that it would be possible that if it were done well enough one wouldn't be able to tell. However, there is something about dealing with a local company that adds value. People seem to care more about their community and neighbors than a random, barely understandable voice on a G.729 8k codec at the other end of a satellite link. I have generally found dealing with most offshore tech support to be very frustrating. The language issues are burdensome, some accents so thick as to be barely understandable, and the lack of clue and scripted menu-driven responses are obvious and usually of no value. I wouldn't be calling if the problem could be solved by reading the documentation and some judicious web searching. There are some exceptions, including Cisco TAC which is very good. I've talked to Cisco engineers in Australia and Europe on occasion. I've had mixed results with Linksys support, which I believe is in the Philippines. Dealing with one offshore AT&T billing representative who was clearly a non-English speaker was extremely painful. The latency and nonsense of the person's responses suggested either some type of auto-translator or satellite link, or both. The person wasn't capable of getting the hint when I asked after several minutes of frustration what the "A" in "AT&T" stood for, and in fact claimed to have no idea. I suspect that this level of disservice may be deliberate so that people will pay bogus charges on bills because the frustration level of disputing them is intentionally high. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From frnkblk at iname.com Thu Dec 25 17:00:53 2008 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Thu, 25 Dec 2008 17:00:53 -0600 Subject: What to do when your ISP off-shores tech support In-Reply-To: References: <495274B8.9020806@west.net> Message-ID: <001601c966e4$a3bc8ef0$eb35acd0$@com> I don't think there would be a concern about off-shore support if we couldn't tell it was "off-shore". That term has all derogatory bias of describing of persons with foreign accents who are difficult to understand and provide support for consumer-oriented products but have the most rudimentary knowledge of the product and how to support/fix it. I had a most positive experience on a weekend a few months ago when I received support from Microsoft technician who was working on the other side of the world, and although was difficult to understand (I had to ask him to repeat himself two or three times on many occasions), knew the product and helped me out of a tight spot. I've had similar positive experiences working with Motorola personnel out of Australia, and Cisco personnel out of Belgium, the Middle East, and Australia. Frank -----Original Message----- From: Martin Hannigan [mailto:martin at theicelandguy.com] Sent: Thursday, December 25, 2008 3:55 PM To: Jay Hennigan Cc: nanog at nanog.org Subject: Re: What to do when your ISP off-shores tech support On Wed, Dec 24, 2008 at 12:43 PM, Jay Hennigan wrote: > Matthew Black wrote: > >> I've had difficulties reaching anyone with a brain >> at my DSL provider Verizon California. >> > > Switch to a local ISP with local tech support. Hi Jay: Is there really anything wrong with sending first-level technical support offshore? Macs are macs, Windows is windows and mail is mail whether you're in Mumbai or Memphis. As long as the language skills are good and the people are well trained, it should be mostly irrelevant, IMHO. Happy Holidays, -M< From martin at theicelandguy.com Thu Dec 25 23:55:22 2008 From: martin at theicelandguy.com (Martin Hannigan) Date: Fri, 26 Dec 2008 00:55:22 -0500 Subject: What to do when your ISP off-shores tech support In-Reply-To: <001601c966e4$a3bc8ef0$eb35acd0$@com> References: <495274B8.9020806@west.net> <001601c966e4$a3bc8ef0$eb35acd0$@com> Message-ID: On Thu, Dec 25, 2008 at 6:00 PM, Frank Bulk - iName.com wrote: > I don't think there would be a concern about off-shore support if we > couldn't tell it was "off-shore". You can't tell most of the time. The point that is relevant operationally is that off shoring can be a solid method to help significantly reduce costs. It can work easier for some functions than others. Level 1/Tier1 support seems like an excellent candidate for off shoring and I think that the measure is still quality of service from the provider verses if they off shore or not. Just my humble opinion. Happy Holidays! -M< From blakjak at blakjak.net Fri Dec 26 01:01:59 2008 From: blakjak at blakjak.net (Mark Foster) Date: Fri, 26 Dec 2008 20:01:59 +1300 (NZDT) Subject: What to do when your ISP off-shores tech support In-Reply-To: References: <495274B8.9020806@west.net> <001601c966e4$a3bc8ef0$eb35acd0$@com> Message-ID: On Fri, 26 Dec 2008, Martin Hannigan wrote: > On Thu, Dec 25, 2008 at 6:00 PM, Frank Bulk - iName.com > wrote: > >> I don't think there would be a concern about off-shore support if we >> couldn't tell it was "off-shore". > > > You can't tell most of the time. > > The point that is relevant operationally is that off shoring can be a solid > method to help significantly reduce costs. It can work easier for some > functions than others. Level 1/Tier1 support seems like an excellent > candidate for off shoring and I think that the measure is still quality of > service from the provider verses if they off shore or not. > > Just my humble opinion. > Hi Martin, Seemingly a rational viewpoint (what, on NANOG? Surely not!) but the problem with the gradual depletion of Level/Tier 1 support environments in your home country is the (eventual) gradual depletion of expertise available to the higher levels. A hellovalot of the clueful engineers that i've come to know over the past few years are people who started off on Helpdesks, and moved up the tiers, to finally land in NOC type slots and from there to engineering and design, perhaps skipping some or all of the 'tiers'... but you've gotta start somewhere. Aside from the typical Degree or Diploma that tertiary outfits offer, there's not a lot of good ways to 'break in' to the Network and Systems Operations communities other than good ol experience, working-from-the-bottom-up. So as you move your Tier 1's offshore, you cut off the channel by which people can gain experience and move on up the chain... (The issues around the advantages from a cultural sense of having access to people who actually know your environs, current events, etc, are probably far more obvious..) Could offshoring be considered a 'short term fix' and be hindering our ability to employ clooful operators in a few years time? (else, are we limiting ourselves to employing immigrants from 'offshore locations' because we don't locally build the right experience?) Mark. From cidr-report at potaroo.net Fri Dec 26 05:00:10 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 26 Dec 2008 22:00:10 +1100 (EST) Subject: BGP Update Report Message-ID: <200812261100.mBQB0AEh015063@wattle.apnic.net> BGP Update Report Interval: 05-Nov-08 -to- 06-Dec-08 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4538 232133 1.9% 45.7 -- ERX-CERNET-BKB China Education and Research Network Center 2 - AS9583 228435 1.9% 180.9 -- SIFY-AS-IN Sify Limited 3 - AS6389 130689 1.1% 29.6 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 4 - AS29282 101489 0.8% 33829.7 -- EMENTOR-AS Enfo Oyj 5 - AS1803 94573 0.8% 66.6 -- ICMNET-5 - Sprint 6 - AS6629 84972 0.7% 1307.3 -- NOAA-AS - NOAA 7 - AS6298 83856 0.7% 38.4 -- ASN-CXA-PH-6298-CBS - Cox Communications Inc. 8 - AS24863 83220 0.7% 121.8 -- LINKdotNET-AS 9 - AS8151 73001 0.6% 33.2 -- Uninet S.A. de C.V. 10 - AS209 71988 0.6% 23.2 -- ASN-QWEST - Qwest Communications Corporation 11 - AS20115 63026 0.5% 30.4 -- CHARTER-NET-HKY-NC - Charter Communications 12 - AS6478 61690 0.5% 35.2 -- ATT-INTERNET3 - AT&T WorldNet Services 13 - AS4323 54750 0.5% 12.9 -- TWTC - tw telecom holdings, inc. 14 - AS6458 54576 0.5% 121.8 -- Telgua 15 - AS7643 52459 0.4% 32.4 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 16 - AS2386 51415 0.4% 31.0 -- INS-AS - AT&T Data Communications Services 17 - AS3462 49113 0.4% 244.3 -- HINET Data Communication Business Group 18 - AS17488 48606 0.4% 33.4 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 19 - AS1785 45555 0.4% 26.6 -- AS-PAETEC-NET - PaeTec Communications, Inc. 20 - AS35805 42761 0.3% 206.6 -- UTG-AS United Telecom AS TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS29282 101489 0.8% 33829.7 -- EMENTOR-AS Enfo Oyj 2 - AS14106 32024 0.3% 16012.0 -- LEPMED01 - Leprechaun, LLC 3 - AS30287 4928 0.0% 4928.0 -- ALON-USA - ALON USA, LP 4 - AS30306 19541 0.2% 3908.2 -- AfOL-Sz-AS 5 - AS41007 18540 0.1% 3708.0 -- CTCASTANA CTC ASTANA, KZ 6 - AS46115 36509 0.3% 3650.9 -- LUTHER - Luther College 7 - AS4130 16771 0.1% 3354.2 -- UPITT-AS - University of Pittsburgh 8 - AS32398 26554 0.2% 3319.2 -- REALNET-ASN-1 9 - AS15561 2969 0.0% 2969.0 -- CDS-ITALY C.D.S. Informatica S.r.l. 10 - AS23917 2755 0.0% 2755.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 11 - AS47731 2735 0.0% 2735.0 -- ISDC-AS SC ISDC ROMANIA SRL 12 - AS30969 21860 0.2% 2732.5 -- TAN-NET TransAfrica Networks 13 - AS5033 21730 0.2% 2414.4 -- ISW - Internet Specialties West Inc. 14 - AS28519 7180 0.1% 2393.3 -- Universidad Autonoma de Guadalajara 15 - AS43925 4293 0.0% 2146.5 -- MOLDCELL_AS Moldcell SA Autonomous System 16 - AS48131 2096 0.0% 2096.0 -- VANGUARD-BG-AS Vanguard SA 17 - AS31901 2083 0.0% 2083.0 -- THECHIMES - The Chimes, Inc. 18 - AS25799 2000 0.0% 2000.0 -- HOLMAN - Holman Enterprises 19 - AS19017 1988 0.0% 1988.0 -- QUALCOMM-QWBS-LV - Qualcomm Wireless Business Solutions 20 - AS149 1725 0.0% 1725.0 -- DNIC - DoD Network Information Center TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 77.95.144.0/22 71003 0.6% AS29282 -- EMENTOR-AS Enfo Oyj 2 - 221.134.222.0/24 60022 0.5% AS9583 -- SIFY-AS-IN Sify Limited 3 - 210.214.151.0/24 58695 0.5% AS9583 -- SIFY-AS-IN Sify Limited 4 - 221.135.80.0/24 38881 0.3% AS9583 -- SIFY-AS-IN Sify Limited 5 - 124.7.201.0/24 34334 0.3% AS9583 -- SIFY-AS-IN Sify Limited 6 - 217.69.48.0/20 30450 0.2% AS29282 -- EMENTOR-AS Enfo Oyj 7 - 192.102.88.0/24 27094 0.2% AS6629 -- NOAA-AS - NOAA 8 - 192.35.129.0/24 26804 0.2% AS6629 -- NOAA-AS - NOAA 9 - 198.77.177.0/24 26722 0.2% AS6629 -- NOAA-AS - NOAA 10 - 41.204.2.0/24 25863 0.2% AS32398 -- REALNET-ASN-1 11 - 64.162.116.0/24 21556 0.2% AS5033 -- ISW - Internet Specialties West Inc. 12 - 8.192.154.0/24 17463 0.1% AS14106 -- LEPMED01 - Leprechaun, LLC 13 - 150.212.224.0/19 16681 0.1% AS4130 -- UPITT-AS - University of Pittsburgh 14 - 192.12.120.0/24 16423 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 15 - 65.44.76.0/24 14561 0.1% AS14106 -- LEPMED01 - Leprechaun, LLC 16 - 89.4.131.0/24 11665 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 17 - 203.63.26.0/24 11403 0.1% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 18 - 196.27.104.0/21 10553 0.1% AS30969 -- TAN-NET TransAfrica Networks 19 - 196.27.108.0/22 10508 0.1% AS30969 -- TAN-NET TransAfrica Networks 20 - 195.189.68.0/24 9247 0.1% AS41007 -- CTCASTANA CTC ASTANA, KZ Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Dec 26 05:00:00 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 26 Dec 2008 22:00:00 +1100 (EST) Subject: The Cidr Report Message-ID: <200812261100.mBQB003H015039@wattle.apnic.net> This report has been generated at Fri Dec 26 21:36:05 2008 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 19-12-08 284488 176165 20-12-08 284886 176110 21-12-08 286454 176286 22-12-08 285356 176551 23-12-08 285575 174818 24-12-08 283855 175041 25-12-08 283945 175020 26-12-08 284016 175040 AS Summary 30272 Number of ASes in routing system 12884 Number of ASes announcing only one prefix 4383 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89819392 Largest address span announced by an AS (/32s) AS27064: DDN-ASNBLK1 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 26Dec08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 283752 175027 108725 38.3% All ASes AS6389 4383 357 4026 91.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4198 1716 2482 59.1% TWTC - tw telecom holdings, inc. AS209 2846 1267 1579 55.5% ASN-QWEST - Qwest Communications Corporation AS4766 1746 486 1260 72.2% KIXS-AS-KR Korea Telecom AS17488 1345 330 1015 75.5% HATHWAY-NET-AP Hathway IP Over Cable Internet AS1785 1707 707 1000 58.6% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1184 200 984 83.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 995 62 933 93.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1401 548 853 60.9% Uninet S.A. de C.V. AS6478 1611 818 793 49.2% ATT-INTERNET3 - AT&T WorldNet Services AS11492 1220 446 774 63.4% CABLEONE - CABLE ONE, INC. AS19262 943 258 685 72.6% VZGNI-TRANSIT - Verizon Internet Services Inc. AS2386 1585 902 683 43.1% INS-AS - AT&T Data Communications Services AS18101 782 113 669 85.5% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS3356 1109 461 648 58.4% LEVEL3 Level 3 Communications AS18566 1060 478 582 54.9% COVAD - Covad Communications Co. AS9583 904 368 536 59.3% SIFY-AS-IN Sify Limited AS2706 543 21 522 96.1% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS7545 677 171 506 74.7% TPG-INTERNET-AP TPG Internet Pty Ltd AS4808 625 159 466 74.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS855 593 129 464 78.2% CANET-ASN-4 - Bell Aliant AS17676 523 65 458 87.6% GIGAINFRA BB TECHNOLOGY Corp. AS4134 892 443 449 50.3% CHINANET-BACKBONE No.31,Jin-rong Street AS9443 525 83 442 84.2% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7018 1427 988 439 30.8% ATT-INTERNET4 - AT&T WorldNet Services AS22047 565 127 438 77.5% VTR BANDA ANCHA S.A. AS20115 1851 1433 418 22.6% CHARTER-NET-HKY-NC - Charter Communications AS4668 693 278 415 59.9% LGNET-AS-KR LG CNS AS24560 636 223 413 64.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS17908 586 179 407 69.5% TCISL Tata Communications Total 39155 13816 25339 64.7% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 62.61.220.0/23 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 87.244.128.0/18 AS8733 CHELLO-BELGIUM UPC Belgium - Chello Belgium 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 119.31.232.0/21 AS38870 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 124.0.0.0/8 AS17550 SMC-AS-AP San Miguel Corporation 137.0.0.0/13 AS27064 DDN-ASNBLK1 - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 193.9.30.0/24 AS41457 A1-AS A1 Ltd. 193.9.31.0/24 AS41457 A1-AS A1 Ltd. 193.23.142.0/24 AS47885 HOSTOFFICE-AS HostOffice Kft. 193.23.143.0/24 AS47885 HOSTOFFICE-AS HostOffice Kft. 194.0.68.0/22 AS41704 OGS-AS ZAO "Orenburgskaya Gorodskaya Set", Orenburg, Russia 195.190.146.0/24 AS9167 WEBPARTNER WEBPARTNER A/S is a Danish Internet Service Provider 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.80.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.0.187.0/24 AS19132 200.5.32.0/21 AS19132 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.58.224.0/19 AS17925 202.58.224.0/20 AS17925 202.58.240.0/20 AS17925 202.58.240.0/24 AS17925 202.58.244.0/24 AS17925 202.58.249.0/24 AS17925 202.58.250.0/24 AS17925 202.58.253.0/24 AS17925 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.46.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.122.120.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications Ltd 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.48.32.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.229.51.0/24 AS15211 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cscora at apnic.net Fri Dec 26 12:12:22 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 27 Dec 2008 04:12:22 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200812261812.mBQICMgE024930@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 27 Dec, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 275775 Prefixes after maximum aggregation: 131490 Deaggregation factor: 2.10 Unique aggregates announced to Internet: 133298 Total ASes present in the Internet Routing Table: 30186 Prefixes per ASN: 9.14 Origin-only ASes present in the Internet Routing Table: 26269 Origin ASes announcing only one prefix: 12810 Transit ASes present in the Internet Routing Table: 3917 Transit-only ASes present in the Internet Routing Table: 98 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 23 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 524 Unregistered ASNs in the Routing Table: 195 Number of 32-bit ASNs allocated by the RIRs: 70 Prefixes from 32-bit ASNs in the Routing Table: 12 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 211 Number of addresses announced to Internet: 1979718688 Equivalent to 118 /8s, 0 /16s and 28 /24s Percentage of available address space announced: 53.4 Percentage of allocated address space announced: 63.1 Percentage of available address space allocated: 84.6 Percentage of address space in use by end-sites: 75.0 Total number of prefixes smaller than registry allocations: 135418 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 63555 Total APNIC prefixes after maximum aggregation: 22690 APNIC Deaggregation factor: 2.80 Prefixes being announced from the APNIC address blocks: 60451 Unique aggregates announced from the APNIC address blocks: 26032 APNIC Region origin ASes present in the Internet Routing Table: 3500 APNIC Prefixes per ASN: 17.27 APNIC Region origin ASes announcing only one prefix: 959 APNIC Region transit ASes present in the Internet Routing Table: 537 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 23 Number of APNIC addresses announced to Internet: 394956192 Equivalent to 23 /8s, 138 /16s and 141 /24s Percentage of available APNIC address space announced: 78.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 123300 Total ARIN prefixes after maximum aggregation: 64626 ARIN Deaggregation factor: 1.91 Prefixes being announced from the ARIN address blocks: 92403 Unique aggregates announced from the ARIN address blocks: 35088 ARIN Region origin ASes present in the Internet Routing Table: 12672 ARIN Prefixes per ASN: 7.29 ARIN Region origin ASes announcing only one prefix: 4886 ARIN Region transit ASes present in the Internet Routing Table: 1215 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 20 Number of ARIN addresses announced to Internet: 405361440 Equivalent to 24 /8s, 41 /16s and 83 /24s Percentage of available ARIN address space announced: 77.9 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 61339 Total RIPE prefixes after maximum aggregation: 36726 RIPE Deaggregation factor: 1.67 Prefixes being announced from the RIPE address blocks: 56967 Unique aggregates announced from the RIPE address blocks: 37920 RIPE Region origin ASes present in the Internet Routing Table: 12423 RIPE Prefixes per ASN: 4.59 RIPE Region origin ASes announcing only one prefix: 6542 RIPE Region transit ASes present in the Internet Routing Table: 1888 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 17 Number of RIPE addresses announced to Internet: 383880800 Equivalent to 22 /8s, 225 /16s and 142 /24s Percentage of available RIPE address space announced: 88.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-49151 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 23044 Total LACNIC prefixes after maximum aggregation: 5649 LACNIC Deaggregation factor: 4.08 Prefixes being announced from the LACNIC address blocks: 21061 Unique aggregates announced from the LACNIC address blocks: 11616 LACNIC Region origin ASes present in the Internet Routing Table: 1040 LACNIC Prefixes per ASN: 20.25 LACNIC Region origin ASes announcing only one prefix: 336 LACNIC Region transit ASes present in the Internet Routing Table: 168 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 59283840 Equivalent to 3 /8s, 136 /16s and 153 /24s Percentage of available LACNIC address space announced: 58.9 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4031 Total AfriNIC prefixes after maximum aggregation: 1380 AfriNIC Deaggregation factor: 2.92 Prefixes being announced from the AfriNIC address blocks: 4254 Unique aggregates announced from the AfriNIC address blocks: 2184 AfriNIC Region origin ASes present in the Internet Routing Table: 274 AfriNIC Prefixes per ASN: 15.53 AfriNIC Region origin ASes announcing only one prefix: 87 AfriNIC Region transit ASes present in the Internet Routing Table: 56 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 22 Number of AfriNIC addresses announced to Internet: 13105408 Equivalent to 0 /8s, 199 /16s and 249 /24s Percentage of available AfriNIC address space announced: 26.0 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1642 6409 368 Korea Telecom (KIX) 17488 1466 102 101 Hathway IP Over Cable Interne 4755 1177 475 152 TATA Communications formerly 9583 904 131 66 Sify Limited 4134 892 15833 358 CHINANET-BACKBONE 18101 782 168 31 Reliance Infocom Ltd Internet 9498 756 291 45 BHARTI BT INTERNET LTD. 4780 725 358 64 Digital United Inc. 7545 658 152 81 TPG Internet Pty Ltd 24560 641 226 165 Bharti Airtel Ltd. Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4382 3435 345 bellsouth.net, inc. 209 2845 4032 623 Qwest 20115 1851 1473 743 Charter Communications 1785 1707 717 155 PaeTec Communications, Inc. 6478 1613 372 274 AT&T Worldnet Services 4323 1608 1067 379 Time Warner Telecom 2386 1586 706 897 AT&T Data Communications Serv 7018 1424 5872 984 AT&T WorldNet Services 11492 1220 192 12 Cable One 3356 1104 10994 431 Level 3 Communications, LLC Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 433 1764 382 TDC Tele Danmark 30890 391 80 203 SC Kappa Invexim SRL 12479 379 578 6 Uni2 Autonomous System 3301 336 1413 303 TeliaNet Sweden 3320 333 7065 282 Deutsche Telekom AG 8866 331 109 22 Bulgarian Telecommunication C 29049 323 26 3 AzerSat LLC. 3215 321 2856 95 France Telecom Transpac 8551 304 287 35 Bezeq International 25233 289 44 24 Awalnet Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1402 2832 224 UniNet S.A. de C.V. 11830 671 299 9 Instituto Costarricense de El 10620 658 138 57 TVCABLE BOGOTA 22047 565 302 14 VTR PUNTO NET S.A. 7303 503 249 74 Telecom Argentina Stet-France 6471 429 86 43 ENTEL CHILE S.A. 16814 426 27 10 NSS, S.A. 11172 400 118 72 Servicios Alestra S.A de C.V 28573 365 491 24 NET Servicos de Comunicao S.A 7738 360 730 27 Telecomunicacoes da Bahia S.A Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 439 72 54 LINKdotNET AS number 3741 270 857 227 The Internet Solution 20858 256 34 3 This AS will be used to conne 2018 239 215 140 Tertiary Education Network 6713 145 139 12 Itissalat Al-MAGHRIB 33783 143 10 17 EEPAD TISP TELECOM & INTERNET 29571 121 15 8 Ci Telecom Autonomous system 5536 120 8 17 Internet Egypt Network 5713 119 555 68 Telkom SA Ltd 33776 118 6 3 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4382 3435 345 bellsouth.net, inc. 209 2845 4032 623 Qwest 20115 1851 1473 743 Charter Communications 1785 1707 717 155 PaeTec Communications, Inc. 4766 1642 6409 368 Korea Telecom (KIX) 6478 1613 372 274 AT&T Worldnet Services 4323 1608 1067 379 Time Warner Telecom 2386 1586 706 897 AT&T Data Communications Serv 17488 1466 102 101 Hathway IP Over Cable Interne 7018 1424 5872 984 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2845 2222 Qwest 1785 1707 1552 PaeTec Communications, Inc. 17488 1466 1365 Hathway IP Over Cable Interne 6478 1613 1339 AT&T Worldnet Services 4766 1642 1274 Korea Telecom (KIX) 4323 1608 1229 Time Warner Telecom 11492 1220 1208 Cable One 8151 1402 1178 UniNet S.A. de C.V. 20115 1851 1108 Charter Communications 18566 1060 1050 Covad Communications Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.251.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:9 /10:20 /11:54 /12:158 /13:309 /14:562 /15:1099 /16:10278 /17:4531 /18:7748 /19:16669 /20:19590 /21:19150 /22:24337 /23:24847 /24:144305 /25:650 /26:809 /27:518 /28:96 /29:8 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2865 4382 bellsouth.net, inc. 209 1591 2845 Qwest 4766 1374 1642 Korea Telecom (KIX) 2386 1263 1586 AT&T Data Communications Serv 17488 1256 1466 Hathway IP Over Cable Interne 11492 1190 1220 Cable One 1785 1168 1707 PaeTec Communications, Inc. 6478 1131 1613 AT&T Worldnet Services 18566 1041 1060 Covad Communications 20115 930 1851 Charter Communications Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:12 8:172 12:2229 13:2 15:21 16:3 17:5 20:35 24:1104 32:54 38:528 40:96 41:825 43:1 44:2 47:9 52:3 55:3 56:3 57:26 58:519 59:597 60:456 61:1107 62:1086 63:2002 64:3416 65:2447 66:3611 67:1444 68:655 69:2430 70:531 71:173 72:1589 73:7 74:1338 75:193 76:306 77:899 78:522 79:309 80:940 81:838 82:543 83:382 84:592 85:1058 86:494 87:651 88:349 89:1383 90:41 91:1801 92:303 93:1077 94:828 95:141 96:95 97:151 98:173 99:10 110:1 111:1 113:56 114:146 115:173 116:1095 117:421 118:248 119:587 120:120 121:700 122:883 123:464 124:765 125:1337 128:359 129:220 130:135 131:410 132:72 133:9 134:323 135:33 136:224 137:133 138:144 139:92 140:414 141:110 142:381 143:290 144:315 145:53 146:371 147:142 148:606 149:219 150:139 151:208 152:149 153:131 154:10 155:250 156:168 157:304 158:163 159:300 160:274 161:131 162:255 163:142 164:516 165:501 166:364 167:348 168:666 169:159 170:461 171:38 172:10 173:138 174:17 187:17 188:1 189:353 190:2532 192:5812 193:4152 194:3291 195:2663 196:1029 198:3696 199:3316 200:5578 201:1505 202:7775 203:8073 204:3922 205:2161 206:2323 207:2771 208:3786 209:3498 210:2673 211:1165 212:1554 213:1618 214:69 215:29 216:4519 217:1196 218:377 219:402 220:1226 221:410 222:299 End of report From tv at pobox.com Fri Dec 26 13:14:50 2008 From: tv at pobox.com (Todd Vierling) Date: Fri, 26 Dec 2008 14:14:50 -0500 Subject: What to do when your ISP off-shores tech support In-Reply-To: References: <495274B8.9020806@west.net> <001601c966e4$a3bc8ef0$eb35acd0$@com> Message-ID: <7883eeaf0812261114o220bd8f0n4160c713e5664994@mail.gmail.com> On Fri, Dec 26, 2008 at 2:01 AM, Mark Foster wrote: > Aside from the typical Degree or Diploma that tertiary outfits offer, > there's not a lot of good ways to 'break in' to the Network and Systems > Operations communities other than good ol experience, > working-from-the-bottom-up. I'm working in management of software engineering now, and in my experience, the only worthwhile candidates for hiring -- who have not gone through the self-teaching and self-experimentation phases that mirror working at a helpdesk on a small scale -- have progressed through exactly this chain. They have developed the necessary instincts to know when a bug could become a serious problem at 2 a.m. on a Sunday, instincts that are an absolute prerequisite to working on software intended to be used 24/7. In software development, new college grads can be OK for non-operationally-facing applications, but they tend to have high ideals, and just haven't "had their hearts broken" by business contradictions or operational emergencies yet. On the opposite side of the spectrum, those who have gone through only regimented software processes between school and the present tend not to be aware of operational impacts at all, as they've been shielded from that aspect all along. > So as you move your Tier 1's offshore, you cut off the channel by which > people can gain experience and move on up the chain... We're seeing this more and more as time goes on. What's worse is that offshoring of software development was becoming just as rampant, resulting in the double-whammy of "engineers" not knowing the consequences of their actions, and operations caught unaware when those consequences manifest as critical problems. Many businesses have at least partially learned from this mistake the Hard Way, by losing customers when there was no one capable of fixing a critical problem within 24 or even 72 hours. Alas, this hasn't been heeded by all of the market yet. All of the above is solely my opinion, and definitely represents an experience-diluted version of my personal ideals. While I generally agree from a business perspective that offshoring of operations can be a lucrative cost-cutting measure, the key problem in most such arrangements is that the operations and systems (hardware/software/networks as applicable) are not *all* offshored at once. When these bits do not exist in relatively close proximity to each other, communications between their responsible folks grinds to a halt. -- -- Todd Vierling From cscora at apnic.net Fri Dec 26 12:12:22 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 27 Dec 2008 04:12:22 +1000 (EST) Subject: [SANOG] Weekly Routing Table Report Message-ID: <200812261812.mBQICMgE024930@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 27 Dec, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 275775 Prefixes after maximum aggregation: 131490 Deaggregation factor: 2.10 Unique aggregates announced to Internet: 133298 Total ASes present in the Internet Routing Table: 30186 Prefixes per ASN: 9.14 Origin-only ASes present in the Internet Routing Table: 26269 Origin ASes announcing only one prefix: 12810 Transit ASes present in the Internet Routing Table: 3917 Transit-only ASes present in the Internet Routing Table: 98 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 23 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 524 Unregistered ASNs in the Routing Table: 195 Number of 32-bit ASNs allocated by the RIRs: 70 Prefixes from 32-bit ASNs in the Routing Table: 12 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 211 Number of addresses announced to Internet: 1979718688 Equivalent to 118 /8s, 0 /16s and 28 /24s Percentage of available address space announced: 53.4 Percentage of allocated address space announced: 63.1 Percentage of available address space allocated: 84.6 Percentage of address space in use by end-sites: 75.0 Total number of prefixes smaller than registry allocations: 135418 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 63555 Total APNIC prefixes after maximum aggregation: 22690 APNIC Deaggregation factor: 2.80 Prefixes being announced from the APNIC address blocks: 60451 Unique aggregates announced from the APNIC address blocks: 26032 APNIC Region origin ASes present in the Internet Routing Table: 3500 APNIC Prefixes per ASN: 17.27 APNIC Region origin ASes announcing only one prefix: 959 APNIC Region transit ASes present in the Internet Routing Table: 537 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 23 Number of APNIC addresses announced to Internet: 394956192 Equivalent to 23 /8s, 138 /16s and 141 /24s Percentage of available APNIC address space announced: 78.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 123300 Total ARIN prefixes after maximum aggregation: 64626 ARIN Deaggregation factor: 1.91 Prefixes being announced from the ARIN address blocks: 92403 Unique aggregates announced from the ARIN address blocks: 35088 ARIN Region origin ASes present in the Internet Routing Table: 12672 ARIN Prefixes per ASN: 7.29 ARIN Region origin ASes announcing only one prefix: 4886 ARIN Region transit ASes present in the Internet Routing Table: 1215 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 20 Number of ARIN addresses announced to Internet: 405361440 Equivalent to 24 /8s, 41 /16s and 83 /24s Percentage of available ARIN address space announced: 77.9 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 61339 Total RIPE prefixes after maximum aggregation: 36726 RIPE Deaggregation factor: 1.67 Prefixes being announced from the RIPE address blocks: 56967 Unique aggregates announced from the RIPE address blocks: 37920 RIPE Region origin ASes present in the Internet Routing Table: 12423 RIPE Prefixes per ASN: 4.59 RIPE Region origin ASes announcing only one prefix: 6542 RIPE Region transit ASes present in the Internet Routing Table: 1888 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 17 Number of RIPE addresses announced to Internet: 383880800 Equivalent to 22 /8s, 225 /16s and 142 /24s Percentage of available RIPE address space announced: 88.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-49151 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 23044 Total LACNIC prefixes after maximum aggregation: 5649 LACNIC Deaggregation factor: 4.08 Prefixes being announced from the LACNIC address blocks: 21061 Unique aggregates announced from the LACNIC address blocks: 11616 LACNIC Region origin ASes present in the Internet Routing Table: 1040 LACNIC Prefixes per ASN: 20.25 LACNIC Region origin ASes announcing only one prefix: 336 LACNIC Region transit ASes present in the Internet Routing Table: 168 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 59283840 Equivalent to 3 /8s, 136 /16s and 153 /24s Percentage of available LACNIC address space announced: 58.9 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4031 Total AfriNIC prefixes after maximum aggregation: 1380 AfriNIC Deaggregation factor: 2.92 Prefixes being announced from the AfriNIC address blocks: 4254 Unique aggregates announced from the AfriNIC address blocks: 2184 AfriNIC Region origin ASes present in the Internet Routing Table: 274 AfriNIC Prefixes per ASN: 15.53 AfriNIC Region origin ASes announcing only one prefix: 87 AfriNIC Region transit ASes present in the Internet Routing Table: 56 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 22 Number of AfriNIC addresses announced to Internet: 13105408 Equivalent to 0 /8s, 199 /16s and 249 /24s Percentage of available AfriNIC address space announced: 26.0 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1642 6409 368 Korea Telecom (KIX) 17488 1466 102 101 Hathway IP Over Cable Interne 4755 1177 475 152 TATA Communications formerly 9583 904 131 66 Sify Limited 4134 892 15833 358 CHINANET-BACKBONE 18101 782 168 31 Reliance Infocom Ltd Internet 9498 756 291 45 BHARTI BT INTERNET LTD. 4780 725 358 64 Digital United Inc. 7545 658 152 81 TPG Internet Pty Ltd 24560 641 226 165 Bharti Airtel Ltd. Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4382 3435 345 bellsouth.net, inc. 209 2845 4032 623 Qwest 20115 1851 1473 743 Charter Communications 1785 1707 717 155 PaeTec Communications, Inc. 6478 1613 372 274 AT&T Worldnet Services 4323 1608 1067 379 Time Warner Telecom 2386 1586 706 897 AT&T Data Communications Serv 7018 1424 5872 984 AT&T WorldNet Services 11492 1220 192 12 Cable One 3356 1104 10994 431 Level 3 Communications, LLC Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 433 1764 382 TDC Tele Danmark 30890 391 80 203 SC Kappa Invexim SRL 12479 379 578 6 Uni2 Autonomous System 3301 336 1413 303 TeliaNet Sweden 3320 333 7065 282 Deutsche Telekom AG 8866 331 109 22 Bulgarian Telecommunication C 29049 323 26 3 AzerSat LLC. 3215 321 2856 95 France Telecom Transpac 8551 304 287 35 Bezeq International 25233 289 44 24 Awalnet Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1402 2832 224 UniNet S.A. de C.V. 11830 671 299 9 Instituto Costarricense de El 10620 658 138 57 TVCABLE BOGOTA 22047 565 302 14 VTR PUNTO NET S.A. 7303 503 249 74 Telecom Argentina Stet-France 6471 429 86 43 ENTEL CHILE S.A. 16814 426 27 10 NSS, S.A. 11172 400 118 72 Servicios Alestra S.A de C.V 28573 365 491 24 NET Servicos de Comunicao S.A 7738 360 730 27 Telecomunicacoes da Bahia S.A Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 439 72 54 LINKdotNET AS number 3741 270 857 227 The Internet Solution 20858 256 34 3 This AS will be used to conne 2018 239 215 140 Tertiary Education Network 6713 145 139 12 Itissalat Al-MAGHRIB 33783 143 10 17 EEPAD TISP TELECOM & INTERNET 29571 121 15 8 Ci Telecom Autonomous system 5536 120 8 17 Internet Egypt Network 5713 119 555 68 Telkom SA Ltd 33776 118 6 3 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4382 3435 345 bellsouth.net, inc. 209 2845 4032 623 Qwest 20115 1851 1473 743 Charter Communications 1785 1707 717 155 PaeTec Communications, Inc. 4766 1642 6409 368 Korea Telecom (KIX) 6478 1613 372 274 AT&T Worldnet Services 4323 1608 1067 379 Time Warner Telecom 2386 1586 706 897 AT&T Data Communications Serv 17488 1466 102 101 Hathway IP Over Cable Interne 7018 1424 5872 984 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2845 2222 Qwest 1785 1707 1552 PaeTec Communications, Inc. 17488 1466 1365 Hathway IP Over Cable Interne 6478 1613 1339 AT&T Worldnet Services 4766 1642 1274 Korea Telecom (KIX) 4323 1608 1229 Time Warner Telecom 11492 1220 1208 Cable One 8151 1402 1178 UniNet S.A. de C.V. 20115 1851 1108 Charter Communications 18566 1060 1050 Covad Communications Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.251.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:9 /10:20 /11:54 /12:158 /13:309 /14:562 /15:1099 /16:10278 /17:4531 /18:7748 /19:16669 /20:19590 /21:19150 /22:24337 /23:24847 /24:144305 /25:650 /26:809 /27:518 /28:96 /29:8 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2865 4382 bellsouth.net, inc. 209 1591 2845 Qwest 4766 1374 1642 Korea Telecom (KIX) 2386 1263 1586 AT&T Data Communications Serv 17488 1256 1466 Hathway IP Over Cable Interne 11492 1190 1220 Cable One 1785 1168 1707 PaeTec Communications, Inc. 6478 1131 1613 AT&T Worldnet Services 18566 1041 1060 Covad Communications 20115 930 1851 Charter Communications Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:12 8:172 12:2229 13:2 15:21 16:3 17:5 20:35 24:1104 32:54 38:528 40:96 41:825 43:1 44:2 47:9 52:3 55:3 56:3 57:26 58:519 59:597 60:456 61:1107 62:1086 63:2002 64:3416 65:2447 66:3611 67:1444 68:655 69:2430 70:531 71:173 72:1589 73:7 74:1338 75:193 76:306 77:899 78:522 79:309 80:940 81:838 82:543 83:382 84:592 85:1058 86:494 87:651 88:349 89:1383 90:41 91:1801 92:303 93:1077 94:828 95:141 96:95 97:151 98:173 99:10 110:1 111:1 113:56 114:146 115:173 116:1095 117:421 118:248 119:587 120:120 121:700 122:883 123:464 124:765 125:1337 128:359 129:220 130:135 131:410 132:72 133:9 134:323 135:33 136:224 137:133 138:144 139:92 140:414 141:110 142:381 143:290 144:315 145:53 146:371 147:142 148:606 149:219 150:139 151:208 152:149 153:131 154:10 155:250 156:168 157:304 158:163 159:300 160:274 161:131 162:255 163:142 164:516 165:501 166:364 167:348 168:666 169:159 170:461 171:38 172:10 173:138 174:17 187:17 188:1 189:353 190:2532 192:5812 193:4152 194:3291 195:2663 196:1029 198:3696 199:3316 200:5578 201:1505 202:7775 203:8073 204:3922 205:2161 206:2323 207:2771 208:3786 209:3498 210:2673 211:1165 212:1554 213:1618 214:69 215:29 216:4519 217:1196 218:377 219:402 220:1226 221:410 222:299 End of report -- This is the SANOG (http://www.sanog.org/) mailing list. From joshpotter at gmail.com Fri Dec 26 13:24:15 2008 From: joshpotter at gmail.com (Josh Potter) Date: Fri, 26 Dec 2008 13:24:15 -0600 Subject: What to do when your ISP off-shores tech support In-Reply-To: <49540B3C.8020709@west.net> References: <495274B8.9020806@west.net> <49540B3C.8020709@west.net> Message-ID: <4a64e2f70812261124n24161266sdef919927483773a@mail.gmail.com> I think I've touched at least 15+ countries with Cisco HTTPS, and minus a few language issues, they're pretty decent. On Thu, Dec 25, 2008 at 4:37 PM, Jay Hennigan wrote: > Martin Hannigan wrote: > > Hi Jay: >> >> Is there really anything wrong with sending first-level technical support >> offshore? >> > > Macs are macs, Windows is windows and mail is mail whether you're in >> Mumbai or Memphis. As long as the language skills are good and the people >> are well trained, it should be mostly irrelevant, IMHO. >> > > In and of itself and setting aside patriotic/nationalistic issues, probably > not, assuming adequate technical and product knowledge and language skills. > I suppose that it would be possible that if it were done well enough one > wouldn't be able to tell. > > However, there is something about dealing with a local company that adds > value. People seem to care more about their community and neighbors than a > random, barely understandable voice on a G.729 8k codec at the other end of > a satellite link. > > I have generally found dealing with most offshore tech support to be very > frustrating. The language issues are burdensome, some accents so thick as > to be barely understandable, and the lack of clue and scripted menu-driven > responses are obvious and usually of no value. I wouldn't be calling if the > problem could be solved by reading the documentation and some judicious web > searching. There are some exceptions, including Cisco TAC which is very > good. I've talked to Cisco engineers in Australia and Europe on occasion. > I've had mixed results with Linksys support, which I believe is in the > Philippines. > > Dealing with one offshore AT&T billing representative who was clearly a > non-English speaker was extremely painful. The latency and nonsense of the > person's responses suggested either some type of auto-translator or > satellite link, or both. The person wasn't capable of getting the hint when > I asked after several minutes of frustration what the "A" in "AT&T" stood > for, and in fact claimed to have no idea. I suspect that this level of > disservice may be deliberate so that people will pay bogus charges on bills > because the frustration level of disputing them is intentionally high. > > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > > -- Josh Potter From eddy+public+spam at noc.everquick.net Fri Dec 26 16:00:28 2008 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Fri, 26 Dec 2008 22:00:28 +0000 (GMT) Subject: CES / TDM-over-PSN equipment recommendations Message-ID: Greetings all, Does anyone care to share good (or bad, but hopefully good) experiences with specific CES / TDM-over-PSN gear? PSN can be: * (802.1q-tagged|raw) ethernet * MPLS * UDP with the first being preferrable. TIA, 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 at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From martin at theicelandguy.com Fri Dec 26 16:16:03 2008 From: martin at theicelandguy.com (Martin Hannigan) Date: Fri, 26 Dec 2008 17:16:03 -0500 Subject: What to do when your ISP off-shores tech support In-Reply-To: <7883eeaf0812261114o220bd8f0n4160c713e5664994@mail.gmail.com> References: <495274B8.9020806@west.net> <001601c966e4$a3bc8ef0$eb35acd0$@com> <7883eeaf0812261114o220bd8f0n4160c713e5664994@mail.gmail.com> Message-ID: On Fri, Dec 26, 2008 at 2:14 PM, Todd Vierling wrote: > On Fri, Dec 26, 2008 at 2:01 AM, Mark Foster wrote: > > > > All of the above is solely my opinion, and definitely represents an > experience-diluted version of my personal ideals. While I generally > agree from a business perspective that offshoring of operations can be > a lucrative cost-cutting measure, the key problem in most such > arrangements is that the operations and systems > (hardware/software/networks as applicable) are not *all* offshored at > once. When these bits do not exist in relatively close proximity to > each other, communications between their responsible folks grinds to a > halt. > > Thanks, this makes sense. I'm not sure if I support off shoring or not as related to quality, but there is certainly a a business case to to be made supporting it as this thread ending up pointing out. There are trade offs which matter more to some than others. Overall, my own off shoring experience is a mixed bag. United Airlines does it and I usually suspect they are off shored when bad recommendations for reservations or changes are relayed and I end up asking the possibly off shore agents to make no changes and let me get online or stand in line to get it done right. Cisco does this and while I haven't spoken to the Belgium TAC in some time, it was pretty darn good and an example of how to do it right. YMMV, Martin -- Martin Hannigan martin at theicelandguy.com p: +16178216079 From mmc at internode.com.au Fri Dec 26 16:42:41 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sat, 27 Dec 2008 09:12:41 +1030 Subject: What to do when your ISP off-shores tech support In-Reply-To: References: <495274B8.9020806@west.net> <001601c966e4$a3bc8ef0$eb35acd0$@com> <7883eeaf0812261114o220bd8f0n4160c713e5664994@mail.gmail.com> Message-ID: <49555DE1.50206@internode.com.au> Martin Hannigan wrote: > > I'm not sure if I support off shoring or not as > related to quality, but there is certainly a a business case to to be made > supporting it as this thread ending up pointing out. There are trade offs > which matter more to some than others. > > I'm quite fascinated by some of the examples given of "offshoring". Cisco use Sydney as one of their locations for around the world coverage. From our point of view (being Australians) this isn't offshore - we have a local TAC who are closer and we tend to be able to get the same group of SP TAC people everytime to deal with our issues. My experience is that, given global companies like Cisco rely on locations to provide wide language support to people everywhere that the language issue is a bit moot. Some people in the Belgium TAC are easier to understand over the phone then people in the US TAC because the US TAC people have been employed for their Spanish skills or other language skills where as many Europeans have better English skills than, well, a lot of people. Some of the people in the TAC in Australia don't have English as their first language and are tricky to explain why my GSR crashed with an IPv6 issue over the phone (but fine via email). Some people on the other end of the phone just suck no matter which country or land of origin. (I use Cisco's TAC as an example purely because I'm familar - but the example can be reused). I think offshoring is more an issue because often it's built around a lie. If I'm talking to someone in another country, then I'm okay with that but I hate it when they're forced to lie about who they are and where they are. They're representing a company I deal with and as a customer I want it to be a good experience - if a company doesn't care about the overall customer experience and looks at it as a cost to be squashed and reduced then that (as someone else has said) is really the problem. Give them the tools and desire to help me as a customer no matter where they are or which god they pray to. The offshoring I think can be a problem isn't the customer facing part, but the anonymous part where backends of companies are taken offshore where data privacy laws etc aren't the same and suddenly my private data can be compromised in a way that is out of control of the laws of the country where I live. (I'm thinking banks, health care etc). Matthew From exstatica at gmail.com Fri Dec 26 19:00:23 2008 From: exstatica at gmail.com (Andrew Matthews) Date: Fri, 26 Dec 2008 17:00:23 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: <49555DE1.50206@internode.com.au> References: <495274B8.9020806@west.net> <001601c966e4$a3bc8ef0$eb35acd0$@com> <7883eeaf0812261114o220bd8f0n4160c713e5664994@mail.gmail.com> <49555DE1.50206@internode.com.au> Message-ID: <10f379910812261700u314c2877k1122e782574b495a@mail.gmail.com> I used to work for DSL Extreme for about just over 3 years. They use local loops and connect via DS3's and OC3's to get into the partners networks. In area's outside of california they may resell, but at least in norcal and socal they run their own network. From jgreco at ns.sol.net Fri Dec 26 19:10:13 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 26 Dec 2008 19:10:13 -0600 (CST) Subject: What to do when your ISP off-shores tech support In-Reply-To: <49540B3C.8020709@west.net> from "Jay Hennigan" at Dec 25, 2008 02:37:48 PM Message-ID: <200812270110.mBR1ADCu011589@aurora.sol.net> > Martin Hannigan wrote: > > Hi Jay: > > > > Is there really anything wrong with sending first-level technical > > support offshore? > > > Macs are macs, Windows is windows and mail is mail whether you're in > > Mumbai or Memphis. As long as the language skills are good and the > > people are well trained, it should be mostly irrelevant, IMHO. > > In and of itself and setting aside patriotic/nationalistic issues, > probably not, assuming adequate technical and product knowledge and > language skills. I suppose that it would be possible that if it were > done well enough one wouldn't be able to tell. Sure. Blaming off-shore tech support is pretty easy stuff, but the reality is that the trouble is more along the line of appropriate training. For example, we maintain a Road Runner connection at the house, which has been generally flawless over the years, with some notable exceptions. I'll skip the DHCP-server-allocating-an-IP-address-from-a-netblk-recently- vanished-from-the-global-routing-table story. Just *try* explaining that to a tier 1... apparently my UNIX box was one of only a very few boxes that hadn't re-DHCP'd in a year or two :-) At one point, Road Runner introduced their "turbo" service here for a mere $10/month more. Since it's nice to be able to download the occasional ISO at high speed, and because it included a greater upstream speed, it was a no-brainer. Worked great for maybe about a year. Then, suddenly, one day, I began to see the modem crash anytime a largish amount of data was being pushed through it. Spend time characterizing the problem. Spend time on the phone. Get told the modem must be bad, get a replacement. You know the runaround, so I'll omit the gory details. After a replacement modem and the same problem, having spent several hours over the period of two days on it, start raising enough noise through both the local and national support services, talked to even the supposedly clueful people who were puzzled, and one finally suggested calling some direct line to "a network engineer." Well, that actually turned out to be TWC Business. The guy was a bit puzzled why I was calling *him*, but a brief explanation sufficed, and within a minute or two he had the problem located ... the modem had been only marginally sufficient for Turbo, and they had changed on the local cable that had broken it. Needed a *different* kind of modem. Told me what to demand from the local cableco store, provided a ticket number and everything. Some discussion suggested that the RR people were highly script-oriented and not necessarily capable of complicated problem solving. It appears that the TWC Business tier 1 people actually have a fair amount of technical training and clue, and resources to tap if that's not good enough. Further, he was bright enough to let me know that they had a "better than turbo" package available with a higher upstream speed, for only a little more, that'd make me a business customer, so I'd never have to deal with Road Runner again. Based on this one experience, we were more than happy to sign an annual contract and pay just $10/mo more, and have direct access to people who know what words like "DHCP" and "route" actually mean. I did ask, and all the local people are, in fact, local. It's a matter of training and technical knowledge. None of them was really putting together the fact that the modem was sketchy for the service class we had. My point is that you not only need the language skills and a good phone connection, but also a reasonable process to deal with knowledgeable people. I understand the need to provide scripted support, but there should also be a reasonable path to determine that someone has an exceptional problem and isn't being well-served by the script. > However, there is something about dealing with a local company that adds > value. People seem to care more about their community and neighbors > than a random, barely understandable voice on a G.729 8k codec at the > other end of a satellite link. > > I have generally found dealing with most offshore tech support to be > very frustrating. The language issues are burdensome, some accents so > thick as to be barely understandable, and the lack of clue and scripted > menu-driven responses are obvious and usually of no value. I wouldn't > be calling if the problem could be solved by reading the documentation > and some judicious web searching. That'll be the typical problem for this audience, yes. > There are some exceptions, including > Cisco TAC which is very good. I've talked to Cisco engineers in > Australia and Europe on occasion. I've had mixed results with Linksys > support, which I believe is in the Philippines. > > Dealing with one offshore AT&T billing representative who was clearly a > non-English speaker was extremely painful. The latency and nonsense of > the person's responses suggested either some type of auto-translator or > satellite link, or both. The person wasn't capable of getting the hint > when I asked after several minutes of frustration what the "A" in "AT&T" > stood for, and in fact claimed to have no idea. I suspect that this > level of disservice may be deliberate so that people will pay bogus > charges on bills because the frustration level of disputing them is > intentionally high. Yeah, ahaha. Like the "let's charge a late fee because we didn't promptly process your payment" thing (another fun story). Reminds me of the good old days of trying to contact somebody clueful at some random network's NOC. Many of the same problems. However, the operator community seems to have made good progress towards solving this problem. So now I'm wondering why we're discussing this. :-) ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From devangnp at gmail.com Fri Dec 26 20:47:21 2008 From: devangnp at gmail.com (devang patel) Date: Fri, 26 Dec 2008 19:47:21 -0700 Subject: IPv6: IS-IS or OSPFv3 Message-ID: Hello, I do have some confusion about which one is better for IPv6 in Service Provider networks as far as IP routing and MPLS application is concern! 1. Which protocol should i use to support the IPv6 in network: ISIS or OSPFv3? As ISIS has multi-topology feature that can give us capability to run IPv4 network separate from IPv6 right! and same thing with OSPF: OSPFv2 will be used for IPv4 routing and OSPFv3 will be used for IPv6 routing! again Its look like resource utilization for both the protocol will be same as they are going to use separate database for storing the routing or topology information. ISIS still has advantage over OSPF as it does use the TLV structure which can help in expanding network to support the new feature! 2. MPLS is not distributing label for IPv6 protocol so again there will not be any IGP best path calcuated for any MPLS related application for IPv6! 3. what if i have already running OSPFv2 for IPv4 in the network then should i think for migrating to ISIS? if yes then what are the advantages that I can look at for migrating my network to IS-IS? regards Devang Patel From trejrco at gmail.com Fri Dec 26 21:15:13 2008 From: trejrco at gmail.com (TJ) Date: Fri, 26 Dec 2008 22:15:13 -0500 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: References: Message-ID: <004a01c967d1$55da3780$018ea680$@com> >I do have some confusion about which one is better for IPv6 in Service >Provider networks as far as IP routing and MPLS application is concern! General rule of thumb - use whichever you / your operation is most familiar with. Using IS-IS today, use it for IPv6. Using OSPFv2 today, use OSPFv3 for IPv6. If that isn't good enough for you, then you need to understand the operational differences between the protocols, and which aspects are most relevant to your environment. I can't answer that for you ... > >1. Which protocol should i use to support the IPv6 in network: ISIS or >OSPFv3? > As ISIS has multi-topology feature that can give us capability to run >IPv4 network separate from IPv6 right! and same thing with OSPF: OSPFv2 will Yes, MT could be a benefit ... but "not the same thing" for OSPF. >be used for IPv4 routing and OSPFv3 will be used for IPv6 routing! again Its >look like resource utilization for both the protocol will be same as they >are going to use separate database for storing the routing or topology >information. ISIS still has advantage over OSPF as it does use the TLV >structure which can help in expanding network to support the new feature! ISIS is generally considered easier to extend, but OSPF has proven to be quite extensible itself ... a wash, for the most part. > >2. MPLS is not distributing label for IPv6 protocol so again there will not >be any IGP best path calcuated for any MPLS related application for IPv6! Yes, lack of a native IPv6 "control plane" could be something of (cough) problem. > >3. what if i have already running OSPFv2 for IPv4 in the network then should >i think for migrating to ISIS? > if yes then what are the advantages that I can look at for migrating my >network to IS-IS? Again, IMHO this depends on way too many factors to make a simple, blanket statement. > > > >regards >Devang Patel HTH! /TJ From phil.pierotti at gmail.com Fri Dec 26 21:39:43 2008 From: phil.pierotti at gmail.com (Phil Pierotti) Date: Sat, 27 Dec 2008 14:39:43 +1100 Subject: Real World OpenBSD/OpenBGPd statistics Message-ID: <5574b2240812261939o5f64fa77o75c5be59b12cb21f@mail.gmail.com> Recently on this list there's been many and various discussions about high-throughput on *some random OpenSource platform* aka software-routing-on-a-PC. And it's been a very interesting discussion, ranging from noting "vendors claims" and discussing why (or not) they work (and how that differs from 'the PC universe") to detailed OS Kernel/IP stack implementations and their isues/benefits. Some of the statistics quoted are dated (eg 2006/2007 timeframe). Some of the statistics quoted are "in theory" (eg in a remote lab, isolated from anything resembling the real world) I would like to invite people to comment on their real-world aka "doing this in production" results. Not just "I've tested it" , but "we use this as our production routing every day". Yes, I am assuming there's more than just talk going on out there. Please Provide Hard Numbers: - system description (cpus, bus, nics, memory, OS, Version) - packets per second as well as throughput - average packet size - how much did you have to tweak to achieve that Ideally we're talking about a "router doing BGP and forwarding packets" scale of implementation. Pure and simple routing packets in a real-world usage scenario. Admittedly being "just a PC" you'll want some base firewalling rules to secure the box itself, maybe Anti-Spoofing rules. But nothing along the lines of "a do-everything box, load-balancing, fireall, nat, complex and long ruleset, 12 routing protocols" etc. Consensus *seems* to be that filling "a few" 1Gbps nics even full duplex should not be difficult on "decent server class hardware" (eg Dual 2.3GHz Xeon with 4GB RAM and good nics), even for real-world traffic patterns. There is still some dispute/uncertainty on how far you can push that into 10Gbps (or even multiples of that), or at least on what it takes to get there. Thanks, Phil P From jay at west.net Fri Dec 26 21:41:58 2008 From: jay at west.net (Jay Hennigan) Date: Fri, 26 Dec 2008 19:41:58 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: <200812270110.mBR1ADCu011589@aurora.sol.net> References: <200812270110.mBR1ADCu011589@aurora.sol.net> Message-ID: <4955A406.4000901@west.net> Joe Greco wrote: > Sure. Blaming off-shore tech support is pretty easy stuff, but the > reality is that the trouble is more along the line of appropriate > training. But, the reason that US-based $TELCO and $CABLECO use off-shore tech support is that they don't want to pay for the training and supervision to do it right in-house. The same person diagnosing your IP routing issues may indeed be asking, "Would you like fries with that?" thirty seconds later. [1] And, for purposes of, "Would you like fries with that?", off-shore is good enough that most customers can't tell, nor do they care. It may often be better than a newbie local ten feet from you. It's the ultimate scripted application, a literal menu. People expect half-duplex-low-fi audio when talking to a tin speaker buried inside of a plastic clown. ;-) > Some discussion suggested that the RR people were highly script-oriented > and not necessarily capable of complicated problem solving. And they are afraid to admit (or don't realize) that they are not capable of complicated problem solving. They're following a script, just like the fast food order-takers. Or maybe they don't have the authority to escalate it to someone with clue, even if/when they do realize they're over their heads. > It appears > that the TWC Business tier 1 people actually have a fair amount of > technical training and clue, and resources to tap if that's not good > enough. Further, he was bright enough to let me know that they had a > "better than turbo" package available with a higher upstream speed, for > only a little more, that'd make me a business customer, so I'd never have > to deal with Road Runner again. Based on this one experience, we were > more than happy to sign an annual contract and pay just $10/mo more, and > have direct access to people who know what words like "DHCP" and "route" > actually mean. > > I did ask, and all the local people are, in fact, local. It's a matter > of training and technical knowledge. None of them was really putting > together the fact that the modem was sketchy for the service class we > had. So, regardless of geographic location, using scripted clueless order-takers without the ability to escalate for customer support is a bad thing. And, scripted clueless order-takers exist solely because they're cheap, not because they provide anything remotely resembling good service. Cheap, from a US-centric perspective, generally means offshore. The interesting thing about your experience is that your service problems resulted in an up-sell, but only because you were persistent enough to fight through the system. Furthermore, it took a person with clue to do the up-sell. How many customers and up-sell opportunities does RR lose because of their decision to go with cheap, scripted, clueless off-shore support? > My point is that you not only need the language skills and a good phone > connection, but also a reasonable process to deal with knowledgeable > people. I understand the need to provide scripted support, but there > should also be a reasonable path to determine that someone has an > exceptional problem and isn't being well-served by the script. Precisely. Or for better service have reasonably clueful people at level 1 so that they can quickly and expeditiously deal with the easy problems that could be scripted. The scripted part could (and often is) being done with IVR, no humans at all. But, please, if you do this, use DTMF menus and not that God-awful worthless "Tell-me" speech-guessing machine. And make sure that every menu has a "0-to-human-being" option. [1] http://broncocommunications.com/ -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From jgreco at ns.sol.net Fri Dec 26 22:17:25 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 26 Dec 2008 22:17:25 -0600 (CST) Subject: What to do when your ISP off-shores tech support In-Reply-To: <4955A406.4000901@west.net> from "Jay Hennigan" at Dec 26, 2008 07:41:58 PM Message-ID: <200812270417.mBR4HPbn018225@aurora.sol.net> > Joe Greco wrote: > > Sure. Blaming off-shore tech support is pretty easy stuff, but the > > reality is that the trouble is more along the line of appropriate > > training. > > But, the reason that US-based $TELCO and $CABLECO use off-shore tech > support is that they don't want to pay for the training and supervision > to do it right in-house. Jay, that's an interesting misstatement. It implies that they're going to be paying a lesser rate to do it right somewhere else, which typically does not seem to be what happens. > The same person diagnosing your IP routing > issues may indeed be asking, "Would you like fries with that?" thirty > seconds later. [1] Does Bronco actually do that? :-) > And, for purposes of, "Would you like fries with > that?", off-shore is good enough that most customers can't tell, nor do > they care. It may often be better than a newbie local ten feet from > you. It's the ultimate scripted application, a literal menu. People > expect half-duplex-low-fi audio when talking to a tin speaker buried > inside of a plastic clown. ;-) Right. > > Some discussion suggested that the RR people were highly script-oriented > > and not necessarily capable of complicated problem solving. > > And they are afraid to admit (or don't realize) that they are not > capable of complicated problem solving. They're following a script, > just like the fast food order-takers. Don't-realize. The number of times I've been talked down to by people who don't have any clue what the "4" in "IPv4" means is depressingly high. I do not need to reboot my Windows PC to know that the DHCP answer my UNIX box is getting from the DHCP server, dumped in gory detail, is providing an IP address in a prefix that's not appearing in the global routing table now. > Or maybe they don't have the > authority to escalate it to someone with clue, even if/when they do > realize they're over their heads. That's definitely a problem. > > It appears > > that the TWC Business tier 1 people actually have a fair amount of > > technical training and clue, and resources to tap if that's not good > > enough. Further, he was bright enough to let me know that they had a > > "better than turbo" package available with a higher upstream speed, for > > only a little more, that'd make me a business customer, so I'd never have > > to deal with Road Runner again. Based on this one experience, we were > > more than happy to sign an annual contract and pay just $10/mo more, and > > have direct access to people who know what words like "DHCP" and "route" > > actually mean. > > > > I did ask, and all the local people are, in fact, local. It's a matter > > of training and technical knowledge. None of them was really putting > > together the fact that the modem was sketchy for the service class we > > had. > > So, regardless of geographic location, using scripted clueless > order-takers without the ability to escalate for customer support is a > bad thing. And, scripted clueless order-takers exist solely because > they're cheap, not because they provide anything remotely resembling > good service. Cheap, from a US-centric perspective, generally means > offshore. > > The interesting thing about your experience is that your service > problems resulted in an up-sell, but only because you were persistent > enough to fight through the system. Plausible interpretation, but not really accurate. An upsell would normally be convincing someone to buy something that they would not otherwise have thought to be useful; is it really an "upsell" when you fail to advertise your new service offerings on your web site, and so leave your potential business customers with the impression that the only offerings you have are the same in-excess-of-T1 prices that you offered last time they talked to you? Come to think of it, I just looked and I still can't find any solid information about the plan we've got. I *think* it's some variation on the "teleworker" package. There's a "home business solution" pkg for $100/mo that includes 15M/2M broadband, but we're paying less than that... > Furthermore, it took a person with > clue to do the up-sell. How many customers and up-sell opportunities > does RR lose because of their decision to go with cheap, scripted, > clueless off-shore support? ... or in this case, cheap, scripted, clueless in-house support ... The thing that is really unfortunate is that I had told the agent at the time we went to Turbo that I was primarily interested in upstream speed. > > My point is that you not only need the language skills and a good phone > > connection, but also a reasonable process to deal with knowledgeable > > people. I understand the need to provide scripted support, but there > > should also be a reasonable path to determine that someone has an > > exceptional problem and isn't being well-served by the script. > > Precisely. Or for better service have reasonably clueful people at > level 1 so that they can quickly and expeditiously deal with the easy > problems that could be scripted. > > The scripted part could (and often is) being done with IVR, no humans at > all. But, please, if you do this, use DTMF menus and not that God-awful > worthless "Tell-me" speech-guessing machine. And make sure that every > menu has a "0-to-human-being" option. I don't know, I've seen some relatively impressive "speech-guessing machines." It is clear that the technology still needs some work, but Amtrak's "Julie" is fairly impressive and useful. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From Skywing at valhallalegends.com Fri Dec 26 22:36:52 2008 From: Skywing at valhallalegends.com (Skywing) Date: Fri, 26 Dec 2008 22:36:52 -0600 Subject: What to do when your ISP off-shores tech support In-Reply-To: <200812270417.mBR4HPbn018225@aurora.sol.net> References: <4955A406.4000901@west.net> from "Jay Hennigan" at Dec 26, 2008 07:41:58 PM <200812270417.mBR4HPbn018225@aurora.sol.net> Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA2A5BC@caralain.haven.nynaeve.net> I find those speech recognition menus quite annoying. American Airlines has one that's just not good enough over a lower bitrate cell voice link in a crowded situation when you're trying to determine what's the deal with cancelled flights or whatnot along with everyone else in the plane. Always have to waste a minute for it to decide that it's going to punt to a real person. It would be nice if there was a way to bypass it. - S -----Original Message----- From: Joe Greco [mailto:jgreco at ns.sol.net] Sent: Friday, December 26, 2008 11:17 PM To: Jay Hennigan Cc: nanog at nanog.org Subject: Re: What to do when your ISP off-shores tech support > Joe Greco wrote: > > Sure. Blaming off-shore tech support is pretty easy stuff, but the > > reality is that the trouble is more along the line of appropriate > > training. > > But, the reason that US-based $TELCO and $CABLECO use off-shore tech > support is that they don't want to pay for the training and supervision > to do it right in-house. Jay, that's an interesting misstatement. It implies that they're going to be paying a lesser rate to do it right somewhere else, which typically does not seem to be what happens. > The same person diagnosing your IP routing > issues may indeed be asking, "Would you like fries with that?" thirty > seconds later. [1] Does Bronco actually do that? :-) > And, for purposes of, "Would you like fries with > that?", off-shore is good enough that most customers can't tell, nor do > they care. It may often be better than a newbie local ten feet from > you. It's the ultimate scripted application, a literal menu. People > expect half-duplex-low-fi audio when talking to a tin speaker buried > inside of a plastic clown. ;-) Right. > > Some discussion suggested that the RR people were highly script-oriented > > and not necessarily capable of complicated problem solving. > > And they are afraid to admit (or don't realize) that they are not > capable of complicated problem solving. They're following a script, > just like the fast food order-takers. Don't-realize. The number of times I've been talked down to by people who don't have any clue what the "4" in "IPv4" means is depressingly high. I do not need to reboot my Windows PC to know that the DHCP answer my UNIX box is getting from the DHCP server, dumped in gory detail, is providing an IP address in a prefix that's not appearing in the global routing table now. > Or maybe they don't have the > authority to escalate it to someone with clue, even if/when they do > realize they're over their heads. That's definitely a problem. > > It appears > > that the TWC Business tier 1 people actually have a fair amount of > > technical training and clue, and resources to tap if that's not good > > enough. Further, he was bright enough to let me know that they had a > > "better than turbo" package available with a higher upstream speed, for > > only a little more, that'd make me a business customer, so I'd never have > > to deal with Road Runner again. Based on this one experience, we were > > more than happy to sign an annual contract and pay just $10/mo more, and > > have direct access to people who know what words like "DHCP" and "route" > > actually mean. > > > > I did ask, and all the local people are, in fact, local. It's a matter > > of training and technical knowledge. None of them was really putting > > together the fact that the modem was sketchy for the service class we > > had. > > So, regardless of geographic location, using scripted clueless > order-takers without the ability to escalate for customer support is a > bad thing. And, scripted clueless order-takers exist solely because > they're cheap, not because they provide anything remotely resembling > good service. Cheap, from a US-centric perspective, generally means > offshore. > > The interesting thing about your experience is that your service > problems resulted in an up-sell, but only because you were persistent > enough to fight through the system. Plausible interpretation, but not really accurate. An upsell would normally be convincing someone to buy something that they would not otherwise have thought to be useful; is it really an "upsell" when you fail to advertise your new service offerings on your web site, and so leave your potential business customers with the impression that the only offerings you have are the same in-excess-of-T1 prices that you offered last time they talked to you? Come to think of it, I just looked and I still can't find any solid information about the plan we've got. I *think* it's some variation on the "teleworker" package. There's a "home business solution" pkg for $100/mo that includes 15M/2M broadband, but we're paying less than that... > Furthermore, it took a person with > clue to do the up-sell. How many customers and up-sell opportunities > does RR lose because of their decision to go with cheap, scripted, > clueless off-shore support? ... or in this case, cheap, scripted, clueless in-house support ... The thing that is really unfortunate is that I had told the agent at the time we went to Turbo that I was primarily interested in upstream speed. > > My point is that you not only need the language skills and a good phone > > connection, but also a reasonable process to deal with knowledgeable > > people. I understand the need to provide scripted support, but there > > should also be a reasonable path to determine that someone has an > > exceptional problem and isn't being well-served by the script. > > Precisely. Or for better service have reasonably clueful people at > level 1 so that they can quickly and expeditiously deal with the easy > problems that could be scripted. > > The scripted part could (and often is) being done with IVR, no humans at > all. But, please, if you do this, use DTMF menus and not that God-awful > worthless "Tell-me" speech-guessing machine. And make sure that every > menu has a "0-to-human-being" option. I don't know, I've seen some relatively impressive "speech-guessing machines." It is clear that the technology still needs some work, but Amtrak's "Julie" is fairly impressive and useful. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From oberman at es.net Fri Dec 26 22:37:41 2008 From: oberman at es.net (Kevin Oberman) Date: Fri, 26 Dec 2008 20:37:41 -0800 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: Your message of "Fri, 26 Dec 2008 19:47:21 MST." Message-ID: <20081227043742.008B44500F@ptavv.es.net> > Date: Fri, 26 Dec 2008 19:47:21 -0700 > From: "devang patel" > > Hello, > > I do have some confusion about which one is better for IPv6 in Service > Provider networks as far as IP routing and MPLS application is concern! > > 1. Which protocol should i use to support the IPv6 in network: ISIS or > OSPFv3? > As ISIS has multi-topology feature that can give us capability to run > IPv4 network separate from IPv6 right! and same thing with OSPF: OSPFv2 will > be used for IPv4 routing and OSPFv3 will be used for IPv6 routing! again Its > look like resource utilization for both the protocol will be same as they > are going to use separate database for storing the routing or topology > information. ISIS still has advantage over OSPF as it does use the TLV > structure which can help in expanding network to support the new feature! > > 2. MPLS is not distributing label for IPv6 protocol so again there will not > be any IGP best path calcuated for any MPLS related application for IPv6! > > 3. what if i have already running OSPFv2 for IPv4 in the network then should > i think for migrating to ISIS? > if yes then what are the advantages that I can look at for migrating my > network to IS-IS? FWIW, we run OSPF for IPv4 and ISIS for IPv6. We started with ISIS for v6 because we were routing IPv6 before OSPFv3 was available. The main reason I prefer ISIS is that it uses CLNS packets for communications and we don't route CLNS. (I don't think ANYONE is routing CLNS today.) That makes it pretty secure. I would hope you have a backbone well enough secured that you don't need to rely on this, but it does make me a bit more relaxed and makes me wish we were using ISIS for IPv4, as well. The time and disruption involved in converting is something that will keep us running OSPF for IPv4 for a long time, though. I remember the 'fun' of converting from IGRP to OSPF about 13 years ago and I'd prefer to retire before a repeat. The real issue is that you need to run something you understand and can manage effectively. It that is OSPF, it will certainly do the job. If it is ISIS, it will, too. The real differences are few and not significant for most. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From devangnp at gmail.com Fri Dec 26 22:56:39 2008 From: devangnp at gmail.com (devang patel) Date: Fri, 26 Dec 2008 21:56:39 -0700 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: <20081227043742.008B44500F@ptavv.es.net> References: <20081227043742.008B44500F@ptavv.es.net> Message-ID: Kevin, Thanks for pointing out other good part of having CLNS as a transport for ISIS as a security point! regards Devang Patel On Fri, Dec 26, 2008 at 9:37 PM, Kevin Oberman wrote: > > Date: Fri, 26 Dec 2008 19:47:21 -0700 > > From: "devang patel" > > > > Hello, > > > > I do have some confusion about which one is better for IPv6 in Service > > Provider networks as far as IP routing and MPLS application is concern! > > > > 1. Which protocol should i use to support the IPv6 in network: ISIS or > > OSPFv3? > > As ISIS has multi-topology feature that can give us capability to run > > IPv4 network separate from IPv6 right! and same thing with OSPF: OSPFv2 > will > > be used for IPv4 routing and OSPFv3 will be used for IPv6 routing! again > Its > > look like resource utilization for both the protocol will be same as > they > > are going to use separate database for storing the routing or topology > > information. ISIS still has advantage over OSPF as it does use the TLV > > structure which can help in expanding network to support the new feature! > > > > 2. MPLS is not distributing label for IPv6 protocol so again there will > not > > be any IGP best path calcuated for any MPLS related application for IPv6! > > > > 3. what if i have already running OSPFv2 for IPv4 in the network then > should > > i think for migrating to ISIS? > > if yes then what are the advantages that I can look at for migrating > my > > network to IS-IS? > > FWIW, we run OSPF for IPv4 and ISIS for IPv6. We started with ISIS for > v6 because we were routing IPv6 before OSPFv3 was available. > > The main reason I prefer ISIS is that it uses CLNS packets for > communications and we don't route CLNS. (I don't think ANYONE is routing > CLNS today.) That makes it pretty secure. > > I would hope you have a backbone well enough secured that you don't need > to rely on this, but it does make me a bit more relaxed and makes me > wish we were using ISIS for IPv4, as well. The time and disruption > involved in converting is something that will keep us running OSPF for > IPv4 for a long time, though. I remember the 'fun' of converting from > IGRP to OSPF about 13 years ago and I'd prefer to retire before a > repeat. > > The real issue is that you need to run something you understand and can > manage effectively. It that is OSPF, it will certainly do the job. If it > is ISIS, it will, too. The real differences are few and not significant for > most. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman at es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > From jfmezei at vaxination.ca Fri Dec 26 23:59:34 2008 From: jfmezei at vaxination.ca (JF Mezei) Date: Sat, 27 Dec 2008 00:59:34 -0500 Subject: What to do when your ISP off-shores tech support In-Reply-To: <4955A406.4000901@west.net> References: <200812270110.mBR1ADCu011589@aurora.sol.net> <4955A406.4000901@west.net> Message-ID: <4955C446.3080204@vaxination.ca> The problem with oursourced first level support is that they are totally disconnected from real time operations and wouldn't be aware of problems that network engineers are currently working on. They have their scripts to answer the standard questions ("it tells me to press the ANY key to continue, but there is no "ANY" key on my keyboard"). But they are not trained nor do they have access to serious diagnostic tools to help knowledgeable customers. A good support person is someone who knows more about their own network/product/serrvice than you do. A bad support person is someone who only has access to the same documents as end users (eg: the standard user guide) and is only of use to clueless customers. A good company would oursource entry level support to the lowest common denominator, but make the script such that it is very easy for a knowledgeable customer to get transfered to a "good" tech support. From drais at icantclick.org Sat Dec 27 00:07:13 2008 From: drais at icantclick.org (david raistrick) Date: Sat, 27 Dec 2008 06:07:13 +0000 (UTC) Subject: What to do when your ISP off-shores tech support In-Reply-To: <4955C446.3080204@vaxination.ca> References: <200812270110.mBR1ADCu011589@aurora.sol.net> <4955A406.4000901@west.net> <4955C446.3080204@vaxination.ca> Message-ID: On Sat, 27 Dec 2008, JF Mezei wrote: > The problem with oursourced first level support is that they are totally > disconnected from real time operations and wouldn't be aware of problems > that network engineers are currently working on. Not always true. Our outsourced support in India were also our first layer of network troubleshooting, and they monitored everything related to the products they supported. They were almost always the first to call the engineers (in .us and .ca) to alert them of issues. It's all about /what/ you hire them to do..... ...david --- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From mtinka at globaltransit.net Sat Dec 27 04:33:09 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Sat, 27 Dec 2008 18:33:09 +0800 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: References: <20081227043742.008B44500F@ptavv.es.net> Message-ID: <200812271833.10233.mtinka@globaltransit.net> On Saturday 27 December 2008 12:56:39 pm devang patel wrote: > Thanks for pointing out other good part of having CLNS as > a transport for ISIS as a security point! We've been happy with IS-IS, having migrated from OSPF ealrier on in the year. We like it because it lets us "stretch" the network without worrying about connectivity to the "backbone" area. However, as most others have said, go with what you're comfortable with. The knobs and switches really aren't that different nowadays, just a few fundamentals that you can easily use to decide which makes (more) sense to you. For v6, using a single routing protocol for both address families is not so bad (although running both OSPFv2 and OSPFv3 really isn't a big deal, or bad thing, having done it at my previous employment and so on). For IS-IS, highly recommend MT to avoid any nasties while turning up v6 in a dual-stack environment. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From swmike at swm.pp.se Sat Dec 27 05:22:45 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 27 Dec 2008 12:22:45 +0100 (CET) Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: References: Message-ID: On Fri, 26 Dec 2008, devang patel wrote: > I do have some confusion about which one is better for IPv6 in Service > Provider networks as far as IP routing and MPLS application is concern! Both work and have advantages and disadvantages. Personally, I like the fact that IPv4 and IPv6 control plane are different, thus I'd go for OSPv3. ISIS-MT means you have to know that all your ISIS speakers will handle the MT packets gracefully. I know products from large vendors in the market which do not (IPv6 not enabled, it receives IPv6 MT packets, affects IPv4 ISIS control plane badly). -- Mikael Abrahamsson email: swmike at swm.pp.se From martin at airwire.ie Sat Dec 27 05:53:18 2008 From: martin at airwire.ie (Martin List-Petersen) Date: Sat, 27 Dec 2008 11:53:18 +0000 Subject: What to do when your ISP off-shores tech support In-Reply-To: References: <200812270110.mBR1ADCu011589@aurora.sol.net> <4955A406.4000901@west.net> <4955C446.3080204@vaxination.ca> Message-ID: <4956172E.1070706@airwire.ie> david raistrick wrote: > On Sat, 27 Dec 2008, JF Mezei wrote: > >> The problem with oursourced first level support is that they are totally >> disconnected from real time operations and wouldn't be aware of problems >> that network engineers are currently working on. > > Not always true. Our outsourced support in India were also our first > layer of network troubleshooting, and they monitored everything related > to the products they supported. They were almost always the first to > call the engineers (in .us and .ca) to alert them of issues. > > It's all about /what/ you hire them to do..... Not only that. It also depends on the call center. I used to work for a quite large call center, that would deal with anything from computer support for vendors, cellphone support, cable-tv, cable-broadband, etc. And just as an example for cellphones, the people on the floor had access to internal systems of the telco's and where able to send real-time commands to the switches. When $TELCO decides to use this call center, it can sometimes take 2-3 years, before the calls end up in the call center. This is down to the fact, that the call center has to implement structures with $TELCO that will make a handover possible in the first place. Also stuff with enough technical knowledge needed to be located within the agents or new staff hired in. Some customers had to be told, that it is impossible to do support for them on the expectations, that they have, because their own internal structures simply are a mess. Outsouring and off-shoring is never the problem. The problem is, and this was stated by the original poster, that the lads off-shore he deals with have no clue and simply stick to the script. No intention of looking what the real problem is. And that problem lies not in the call center. It is the deal, that $TELCO struck with $CALLCENTER and the procedures, that were put in place, that are the problem. Only solution: find a provider, who's support (off-shore or not) does have a clue, has an escalation process and is willing to find a solution. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From trejrco at gmail.com Sat Dec 27 06:59:37 2008 From: trejrco at gmail.com (TJ) Date: Sat, 27 Dec 2008 07:59:37 -0500 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: References: Message-ID: <006601c96822$f9cb0b20$ed612160$@com> >Personally, I like the fact that IPv4 and IPv6 control plane are >different, thus I'd go for OSPv3. I totally agree on the discrete/segregated control planes, although note that - for those who want it - OSPFv3 will "soon" be able to do IPv4 route exchange as well ... /TJ >-----Original Message----- >From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] >Sent: Saturday, December 27, 2008 6:23 AM >To: devang patel >Cc: nanog at nanog.org >Subject: Re: IPv6: IS-IS or OSPFv3 > >On Fri, 26 Dec 2008, devang patel wrote: > >> I do have some confusion about which one is better for IPv6 in Service >> Provider networks as far as IP routing and MPLS application is concern! > >Both work and have advantages and disadvantages. > >Personally, I like the fact that IPv4 and IPv6 control plane are >different, thus I'd go for OSPv3. ISIS-MT means you have to know that all >your ISIS speakers will handle the MT packets gracefully. I know products >from large vendors in the market which do not (IPv6 not enabled, it >receives IPv6 MT packets, affects IPv4 ISIS control plane badly). > >-- >Mikael Abrahamsson email: swmike at swm.pp.se From martin at airwire.ie Sat Dec 27 07:08:50 2008 From: martin at airwire.ie (Martin List-Petersen) Date: Sat, 27 Dec 2008 13:08:50 +0000 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: <006601c96822$f9cb0b20$ed612160$@com> References: <006601c96822$f9cb0b20$ed612160$@com> Message-ID: <495628E2.9050501@airwire.ie> TJ wrote: >> Personally, I like the fact that IPv4 and IPv6 control plane are >> different, thus I'd go for OSPv3. > > I totally agree on the discrete/segregated control planes, although note > that - for those who want it - OSPFv3 will "soon" be able to do IPv4 route > exchange as well ... Only if the vendors pick up on those changes. Kind regards, Martin List-Petersen > > > /TJ > > >> -----Original Message----- >> From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] >> Sent: Saturday, December 27, 2008 6:23 AM >> To: devang patel >> Cc: nanog at nanog.org >> Subject: Re: IPv6: IS-IS or OSPFv3 >> >> On Fri, 26 Dec 2008, devang patel wrote: >> >>> I do have some confusion about which one is better for IPv6 in Service >>> Provider networks as far as IP routing and MPLS application is concern! >> Both work and have advantages and disadvantages. >> >> Personally, I like the fact that IPv4 and IPv6 control plane are >> different, thus I'd go for OSPv3. ISIS-MT means you have to know that all >> your ISIS speakers will handle the MT packets gracefully. I know products >>from large vendors in the market which do not (IPv6 not enabled, it >> receives IPv6 MT packets, affects IPv4 ISIS control plane badly). >> >> -- >> Mikael Abrahamsson email: swmike at swm.pp.se > > -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From randy at psg.com Sat Dec 27 07:27:05 2008 From: randy at psg.com (Randy Bush) Date: Sat, 27 Dec 2008 08:27:05 -0500 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: <200812271833.10233.mtinka@globaltransit.net> References: <20081227043742.008B44500F@ptavv.es.net> <200812271833.10233.mtinka@globaltransit.net> Message-ID: <49562D29.8030003@psg.com> > For IS-IS, highly recommend MT to avoid any nasties while > turning up v6 in a dual-stack environment. as one who has been burned when topologies are not congruent, i gotta ask. if i do not anticipate v4 and v6 having different topologies, and all my devices are dual-capable, would you still recommend mt for other than future-proofing? randy From ge at linuxbox.org Sat Dec 27 07:27:31 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 27 Dec 2008 07:27:31 -0600 (CST) Subject: Attacking a critical Internet infrastructure Message-ID: Hi folks and happy new year! I am emailing to spam about a talk about to be given at the CCC conference (25c3). I apologize for the cross-posting. At the 4th day of CCC (30th), there is an interesting as-of-yet no details disclosed talk by a couple of good people. http://events.ccc.de/congress/2008/Fahrplan/events/3023.en.html Making the theoretical possible Attacking a critical piece of Internet infrastructure * Jacob Appelbaum * Alexander Sotirov There are no details provided on the web page which means both good and bad things depending on your point of view. Regardless, if you are not down here I'd tune in to the web casts if you have the time. It's bound to be _very_ interesting. Live streaming information can be found here: http://events.ccc.de/congress/2008/wiki/Streaming Gadi. From mtinka at globaltransit.net Sat Dec 27 09:55:27 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Sat, 27 Dec 2008 23:55:27 +0800 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: <495628E2.9050501@airwire.ie> References: <006601c96822$f9cb0b20$ed612160$@com> <495628E2.9050501@airwire.ie> Message-ID: <200812272355.37975.mtinka@globaltransit.net> On Saturday 27 December 2008 09:08:50 pm Martin List- Petersen wrote: > Only if the vendors pick up on those changes. Juniper support this since JunOS 9.2 (draft-ietf-ospf-af- alt-06.txt). Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From trejrco at gmail.com Sat Dec 27 10:17:27 2008 From: trejrco at gmail.com (TJ) Date: Sat, 27 Dec 2008 11:17:27 -0500 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: <495628E2.9050501@airwire.ie> References: <006601c96822$f9cb0b20$ed612160$@com> <495628E2.9050501@airwire.ie> Message-ID: <001301c9683e$9fb944f0$df2bced0$@com> >>> Personally, I like the fact that IPv4 and IPv6 control plane are >>> different, thus I'd go for OSPv3. >> >> I totally agree on the discrete/segregated control planes, although note >> that - for those who want it - OSPFv3 will "soon" be able to do IPv4 route >> exchange as well ... > >Only if the vendors pick up on those changes. Well, of course - just like anything else. That was part of the reason for the scary-quotes around soon ... /TJ From shrdlu at deaddrop.org Sat Dec 27 10:22:23 2008 From: shrdlu at deaddrop.org (Etaoin Shrdlu) Date: Sat, 27 Dec 2008 08:22:23 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA2A5BC@caralain.haven.nynaeve.net> References: <4955A406.4000901@west.net> from "Jay Hennigan" at Dec 26, 2008 07:41:58 PM <200812270417.mBR4HPbn018225@aurora.sol.net> <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA2A5BC@caralain.haven.nynaeve.net> Message-ID: <4956563F.4030402@deaddrop.org> Skywing wrote: > I find those speech recognition menus quite annoying. American > Airlines has one that's just not good enough over a lower bitrate > cell voice link in a crowded situation when you're trying to > determine what's the deal with cancelled flights or whatnot along > with everyone else in the plane. Always have to waste a minute for > it to decide that it's going to punt to a real person. It would be > nice if there was a way to bypass it. say "agent" and keep repeating that word until it understands you. That will bypass the menus, and take you to a person. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. Brian W. Kernighan From deleskie at gmail.com Sat Dec 27 10:29:39 2008 From: deleskie at gmail.com (deleskie at gmail.com) Date: Sat, 27 Dec 2008 16:29:39 +0000 Subject: IPv6: IS-IS or OSPFv3 Message-ID: <1045694157-1230395459-cardhu_decombobulator_blackberry.rim.net-720381911-@bxe125.bisx.prod.on.blackberry> Having worked for seveal SP's 'tier 1' and otherwise along with a couple of router vendors IMO MT is one of those thing people ask for just in case. Sure we _could_ always find a use for it, but we don't always look at the potential diffrent IGP topologies are going to cause for our NOC staff @ 2am over a holiday weekend when some does decide to break. -jim ------Original Message------ From: Randy Bush To: Mark Tinka Cc: nanog at nanog.org Subject: Re: IPv6: IS-IS or OSPFv3 Sent: Dec 27, 2008 9:27 AM > For IS-IS, highly recommend MT to avoid any nasties while > turning up v6 in a dual-stack environment. as one who has been burned when topologies are not congruent, i gotta ask. if i do not anticipate v4 and v6 having different topologies, and all my devices are dual-capable, would you still recommend mt for other than future-proofing? randy Sent from my BlackBerry device on the Rogers Wireless Network From devangnp at gmail.com Sat Dec 27 11:28:49 2008 From: devangnp at gmail.com (devang patel) Date: Sat, 27 Dec 2008 11:28:49 -0600 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: <1045694157-1230395459-cardhu_decombobulator_blackberry.rim.net-720381911-@bxe125.bisx.prod.on.blackberry> References: <1045694157-1230395459-cardhu_decombobulator_blackberry.rim.net-720381911-@bxe125.bisx.prod.on.blackberry> Message-ID: Hi, Thanks all of you to provide your inputs on my questions! The main idea behind Multitopology in IS-IS is to enabling the IPv6 routing in the redundant part of the network so that way I will not mess around with the current IPv4 routing or services which is running or serving to customers currently! so by migrating redundant part of the topology to IPv6 using Multitopology IS-IS and make it that part as a active for IPv6 for testing how it works! and then I can enable the IPv6 on my whole network! I guess that might be the good benefit. Same thing we can do with OSPFv3 also as I can enable IPv6 routing using OSPFv3 on my redundant part of the network and after successful migration i can enable it on my whole network! But again as far as expansion is concern IS-IS is good protocol to consider. OSPF does have bit more complexity in terms of operation. again the one question is how about the router resource utilization for both the protocol if I will be running IPv6 and IPv4 in the network! One more question: do we need to enable the IPv6 on each and every router of the service provider network including P routers also? does it really required to run IPv6 on each and every router? or running it on only PE router is sufficient to support the customers needs? regards Devang Patel On Sat, Dec 27, 2008 at 10:29 AM, wrote: > Having worked for seveal SP's 'tier 1' and otherwise along with a couple of > router vendors IMO MT is one of those thing people ask for just in case. > Sure we _could_ always find a use for it, but we don't always look at the > potential diffrent IGP topologies are going to cause for our NOC staff @ 2am > over a holiday weekend when some does decide to break. > > -jim > ------Original Message------ > From: Randy Bush > To: Mark Tinka > Cc: nanog at nanog.org > Subject: Re: IPv6: IS-IS or OSPFv3 > Sent: Dec 27, 2008 9:27 AM > > > For IS-IS, highly recommend MT to avoid any nasties while > > turning up v6 in a dual-stack environment. > > as one who has been burned when topologies are not congruent, i gotta > ask. if i do not anticipate v4 and v6 having different topologies, and > all my devices are dual-capable, would you still recommend mt for other > than future-proofing? > > randy > > > > Sent from my BlackBerry device on the Rogers Wireless Network > > From jay at west.net Sat Dec 27 12:42:03 2008 From: jay at west.net (Jay Hennigan) Date: Sat, 27 Dec 2008 10:42:03 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA2A5BC@caralain.haven.nynaeve.net> References: <4955A406.4000901@west.net> from "Jay Hennigan" at Dec 26, 2008 07:41:58 PM <200812270417.mBR4HPbn018225@aurora.sol.net> <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA2A5BC@caralain.haven.nynaeve.net> Message-ID: <495676FB.7040802@west.net> Skywing wrote: > I find those speech recognition menus quite annoying. American Airlines has one that's just not good enough over a lower bitrate cell voice link in a crowded situation when you're trying to determine what's the deal with cancelled flights or whatnot along with everyone else in the plane. Always have to waste a minute for it to decide that it's going to punt to a real person. It would be nice if there was a way to bypass it. http://www.get2human.com/gethuman_list.asp > Jay wrote: >> But, the reason that US-based $TELCO and $CABLECO use off-shore tech >> support is that they don't want to pay for the training and supervision >> to do it right in-house. > > Jay, that's an interesting misstatement. It implies that they're going to > be paying a lesser rate to do it right somewhere else, which typically does > not seem to be what happens. Perhaps my wording didn't convey my meaning. They don't care about doing it right nearly as much as they care about doing it cheap. This often means outsourced, which often means offshore. >> The same person diagnosing your IP routing >> issues may indeed be asking, "Would you like fries with that?" thirty >> seconds later. [1] > > Does Bronco actually do that? :-) They actually do outsourced offshore order-taking for fast food drive-through restaurants. Several big-name chains in fact. And they're quite good at it, the customer probably doesn't know. Whether the same people also answer the phones for $TELCO and $CABLECO, I don't know. >> And they are afraid to admit (or don't realize) that they are not >> capable of complicated problem solving. They're following a script, >> just like the fast food order-takers. > > Don't-realize. The number of times I've been talked down to by people who > don't have any clue what the "4" in "IPv4" means is depressingly high. I > do not need to reboot my Windows PC to know that the DHCP answer my UNIX > box is getting from the DHCP server, dumped in gory detail, is providing an > IP address in a prefix that's not appearing in the global routing table now. > >> Or maybe they don't have the >> authority to escalate it to someone with clue, even if/when they do >> realize they're over their heads. > > That's definitely a problem. Yep. I suspect it's a culture of "What are we paying you for if you can't solve the problems?" aimed at the scripted call center people. Call center work is a miserable job. The people are thoroughly timed and scrutinized, graded on the number of calls they take per hour, time on the phone to each caller (less is better), etc. Automated metrics with the goal of pushing as many calls at as few people as possible. I wouldn't be surprised if many of them are penalized for escalating issues. >> The interesting thing about your experience is that your service >> problems resulted in an up-sell, but only because you were persistent >> enough to fight through the system. > > Plausible interpretation, but not really accurate. An upsell would > normally be convincing someone to buy something that they would not > otherwise have thought to be useful; is it really an "upsell" when > you fail to advertise your new service offerings on your web site, > and so leave your potential business customers with the impression > that the only offerings you have are the same in-excess-of-T1 prices > that you offered last time they talked to you? You remained a customer and signed up for for a higher tier of services at increased cost based on a conversation with a clueful person, and you were only able to reach that person after some persistence. How many others gave up before getting that far and went elsewhere? -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From swmike at swm.pp.se Sat Dec 27 12:42:21 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 27 Dec 2008 19:42:21 +0100 (CET) Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: <49562D29.8030003@psg.com> References: <20081227043742.008B44500F@ptavv.es.net> <200812271833.10233.mtinka@globaltransit.net> <49562D29.8030003@psg.com> Message-ID: On Sat, 27 Dec 2008, Randy Bush wrote: > as one who has been burned when topologies are not congruent, i gotta > ask. if i do not anticipate v4 and v6 having different topologies, and > all my devices are dual-capable, would you still recommend mt for other > than future-proofing? Personally, if my v4 and v6 topologies are not different, I'd run ISIS and not run MT. MT for me is to make v4 and v6 have different control planes (even though it's using the same protocol), thus I see little difference in running OSPFv3+ISIS, or running ISIS-MT for v4+v6. I argue that it's better to have different control planes for v4 and v6 and make it obvious (OSPv3 / ISIS), than to use ISIS-MT and "obfuscate". -- Mikael Abrahamsson email: swmike at swm.pp.se From randy at psg.com Sat Dec 27 12:52:03 2008 From: randy at psg.com (Randy Bush) Date: Sat, 27 Dec 2008 13:52:03 -0500 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: References: <20081227043742.008B44500F@ptavv.es.net> <200812271833.10233.mtinka@globaltransit.net> <49562D29.8030003@psg.com> Message-ID: <49567953.8000404@psg.com> >> as one who has been burned when topologies are not congruent, i gotta >> ask. if i do not anticipate v4 and v6 having different topologies, and >> all my devices are dual-capable, would you still recommend mt for >> other than future-proofing? > > Personally, if my v4 and v6 topologies are not different, I'd run ISIS > and not run MT. MT for me is to make v4 and v6 have different control > planes (even though it's using the same protocol), thus I see little > difference in running OSPFv3+ISIS, or running ISIS-MT for v4+v6. > > I argue that it's better to have different control planes for v4 and v6 > and make it obvious (OSPv3 / ISIS), than to use ISIS-MT and "obfuscate". the real control plane is bgp. is-is is for recursive resolution to find bgp's next hop interface, fertig. so the simpler the better. i am annoyed enough that bgp4 and bgp6 peerings and configs are overly divergent. running a different igp for 6 and 4 would not make me happy. randy From lists at memetic.org Sat Dec 27 13:57:54 2008 From: lists at memetic.org (Adam Armstrong) Date: Sat, 27 Dec 2008 19:57:54 +0000 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: <004a01c967d1$55da3780$018ea680$@com> References: <004a01c967d1$55da3780$018ea680$@com> Message-ID: <495688C2.6030109@memetic.org> TJ wrote: >> I do have some confusion about which one is better for IPv6 in Service >> Provider networks as far as IP routing and MPLS application is concern! >> > > General rule of thumb - use whichever you / your operation is most familiar > with. > Using IS-IS today, use it for IPv6. > Using OSPFv2 today, use OSPFv3 for IPv6. > Well, OSPFv3 has enough differences from OSPFv2 to make switching to IS-IS a benefit to stop people making mistakes through expected operational similarity (if that makes sense). Also it means that once you're doing v6 everywhere you can dump OSPFv2 and only have one IGP for both v4 and v6. I personally think that'll save a lot of headaches down the line, not to mention that fact that IS-IS is, IMHO, a much nicer IGP to work with. adam. From andy at nosignal.org Sat Dec 27 13:58:07 2008 From: andy at nosignal.org (Andy Davidson) Date: Sat, 27 Dec 2008 19:58:07 +0000 Subject: What to do when your ISP off-shores tech support In-Reply-To: <4955C446.3080204@vaxination.ca> References: <200812270110.mBR1ADCu011589@aurora.sol.net> <4955A406.4000901@west.net> <4955C446.3080204@vaxination.ca> Message-ID: <3B06CDCB-F703-41A4-BEF3-D1D418864BBA@nosignal.org> On 27 Dec 2008, at 05:59, JF Mezei wrote: > The problem with oursourced first level support is that they are > totally disconnected from real time operations and wouldn't be aware > of problems that network engineers are currently working on. That's a problem with a lot of internal first line teams too.. Offshore and outsource are different things, and when done right are irrelevant to the quality of service delivered. A willingness to offshore means you can deliver follow-the-sun NOC or support service, which can drive down delivery costs and health/safety risks for the organisation and drive up service quality by meaning that callers reach someone alert and awake ;-). Outsourcing offshore service makes it cheap and easy to do that. Doing this well relies on building a process, and actually a different process for each network being supported, though I don't want to give away all the hints that I learned the hard way ! Andy From smb at cs.columbia.edu Sat Dec 27 14:23:25 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Sat, 27 Dec 2008 15:23:25 -0500 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: <20081227043742.008B44500F@ptavv.es.net> References: <20081227043742.008B44500F@ptavv.es.net> Message-ID: <20081227152325.59d5b391@cs.columbia.edu> On Fri, 26 Dec 2008 20:37:41 -0800 "Kevin Oberman" wrote: > The main reason I prefer ISIS is that it uses CLNS packets for > communications and we don't route CLNS. (I don't think ANYONE is > routing CLNS today.) That makes it pretty secure. Unless, of course, someone one hop away -- a peer? a customer? an upstream or downstream? someone on the same LAN at certain exchange points? -- sends you a CLNP packet at link level... --Steve Bellovin, http://www.cs.columbia.edu/~smb From smb at cs.columbia.edu Sat Dec 27 14:34:32 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Sat, 27 Dec 2008 15:34:32 -0500 Subject: What to do when your ISP off-shores tech support In-Reply-To: <200812270110.mBR1ADCu011589@aurora.sol.net> References: <49540B3C.8020709@west.net> <200812270110.mBR1ADCu011589@aurora.sol.net> Message-ID: <20081227153432.0c1e3cd7@cs.columbia.edu> On Fri, 26 Dec 2008 19:10:13 -0600 (CST) Joe Greco wrote: > I did ask, and all the local people are, in fact, local. It's a > matter of training and technical knowledge. None of them was really > putting together the fact that the modem was sketchy for the service > class we had. Yup -- I've had similar fun with Comcast. Once, I was seeing 15-20% packet loss on the local loop and 90% (you read that correctly) packet duplication. The advice I received translated to "clear your IE browser cache". I demurred, and I was told that (a) generally, performance problems were solvable that way, and (b) 15% packet loss was pretty good. I escalated... Then there was the time they upgraded the firmware in my cable modem/NAT to a buggy release that didn't understand the activity timer in the NAT table. Every 30 minutes, like clockwork, my ssh sessions would die. I had to try to explain that to someone who didn't know how to spell IP, let alone TCP. Oh yes -- judging from their accents, everyone I spoke with was American. In both cases, once I reached the clueful people, things were resolved pretty quickly. (Well, not the packet duplication; that took *weeks* to resolve, but once the packet loss problem was solved I could at least get decent throughput.) > > My point is that you not only need the language skills and a good > phone connection, but also a reasonable process to deal with > knowledgeable people. I understand the need to provide scripted > support, but there should also be a reasonable path to determine that > someone has an exceptional problem and isn't being well-served by the > script. Customer records often include an optional data field that says things about particular customers. I heard a story -- and I'll leave out the names, since it's second- or third-hand and it does involve people and companies most of us know -- that one very clueful person's record had a note saying more or less "if you don't understand what he's saying, he's right and you're wrong, and you should route his call immediately to Tier N, where N is large"... But getting on that list is the hard part. --Steve Bellovin, http://www.cs.columbia.edu/~smb From trejrco at gmail.com Sat Dec 27 14:36:01 2008 From: trejrco at gmail.com (TJ) Date: Sat, 27 Dec 2008 15:36:01 -0500 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: <495688C2.6030109@memetic.org> References: <004a01c967d1$55da3780$018ea680$@com> <495688C2.6030109@memetic.org> Message-ID: <002e01c96862$bbe8f520$33badf60$@com> > ... not to mention that fact that IS-IS is, IMHO, a much nicer IGP to work with. WRT that last sentence, that is an almost religious debate I was trying to avoid starting ... :) /TJ From swmike at swm.pp.se Sat Dec 27 14:37:51 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 27 Dec 2008 21:37:51 +0100 (CET) Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: References: <20081227043742.008B44500F@ptavv.es.net> Message-ID: On Fri, 26 Dec 2008, devang patel wrote: > Thanks for pointing out other good part of having CLNS as a transport > for ISIS as a security point! It's also a potential hassle, where you can have IS-IS up and running, but have IP completely hosed. With OSPF this is harder as it actually runs over IP; no IP, no IGP adjacancy. There is good reason why neither OSPF nor IS-IS rules the IGP world, they both have their advantages and disadvantages. Differences are usually in what the organisation is used to, not because one is fundamentally better than the other. -- Mikael Abrahamsson email: swmike at swm.pp.se From hcb at netcases.net Sat Dec 27 15:04:43 2008 From: hcb at netcases.net (Howard C. Berkowitz) Date: Sat, 27 Dec 2008 16:04:43 -0500 (EST) Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: <002e01c96862$bbe8f520$33badf60$@com> References: <004a01c967d1$55da3780$018ea680$@com> <495688C2.6030109@memetic.org> <002e01c96862$bbe8f520$33badf60$@com> Message-ID: <2330.76.118.12.107.1230411883.squirrel@webmail7.pair.com> TJ wrote: >> ... not to mention that fact that IS-IS is, IMHO, a much nicer IGP to >> work > with. > > WRT that last sentence, that is an almost religious debate I was trying to > avoid starting ... :) > I will offer a mantra that has helped me, over the years, about the indeed religious wars that emerge when a New Technology or Youthful feature comes to these two link state protocols. I begin to mutter "ISNT and OySPF". From jmalcolm at uraeus.com Sat Dec 27 15:24:18 2008 From: jmalcolm at uraeus.com (Joe Malcolm) Date: Sat, 27 Dec 2008 21:24:18 +0000 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: <20081227152325.59d5b391@cs.columbia.edu> References: <20081227043742.008B44500F@ptavv.es.net> <20081227152325.59d5b391@cs.columbia.edu> Message-ID: <18774.40194.154266.531390@shoggoth.uraeus.com> Steven M. Bellovin writes: >Unless, of course, someone one hop away -- a peer? a customer? an >upstream or downstream? someone on the same LAN at certain exchange >points? -- sends you a CLNP packet at link level... True enough, and mistakenly enabling ISIS on external ports has been known to happen though in the absence of malice it usually causes no problems. If it does cause problems, generally the source can be more easily localized given that it has to be L2-adjacent to one of your routers. Joe From mylists at battleop.com Sat Dec 27 16:43:44 2008 From: mylists at battleop.com (Richey) Date: Sat, 27 Dec 2008 17:43:44 -0500 Subject: What to do when your ISP off-shores tech support In-Reply-To: <20081227153432.0c1e3cd7@cs.columbia.edu> References: <49540B3C.8020709@west.net> <200812270110.mBR1ADCu011589@aurora.sol.net> <20081227153432.0c1e3cd7@cs.columbia.edu> Message-ID: <019701c96874$939c2a30$bad47e90$@com> I once had an @home rep insist that my connection was down because there was ice in the lines. No matter how many times I told him it was 58 degrees outside he stuck to his guns and insisted that was the problem. Richey -----Original Message----- From: Steven M. Bellovin [mailto:smb at cs.columbia.edu] Sent: Saturday, December 27, 2008 3:35 PM To: Joe Greco Cc: nanog at nanog.org Subject: Re: What to do when your ISP off-shores tech support On Fri, 26 Dec 2008 19:10:13 -0600 (CST) Joe Greco wrote: > I did ask, and all the local people are, in fact, local. It's a > matter of training and technical knowledge. None of them was really > putting together the fact that the modem was sketchy for the service > class we had. Yup -- I've had similar fun with Comcast. Once, I was seeing 15-20% packet loss on the local loop and 90% (you read that correctly) packet duplication. The advice I received translated to "clear your IE browser cache". I demurred, and I was told that (a) generally, performance problems were solvable that way, and (b) 15% packet loss was pretty good. I escalated... Then there was the time they upgraded the firmware in my cable modem/NAT to a buggy release that didn't understand the activity timer in the NAT table. Every 30 minutes, like clockwork, my ssh sessions would die. I had to try to explain that to someone who didn't know how to spell IP, let alone TCP. Oh yes -- judging from their accents, everyone I spoke with was American. In both cases, once I reached the clueful people, things were resolved pretty quickly. (Well, not the packet duplication; that took *weeks* to resolve, but once the packet loss problem was solved I could at least get decent throughput.) > > My point is that you not only need the language skills and a good > phone connection, but also a reasonable process to deal with > knowledgeable people. I understand the need to provide scripted > support, but there should also be a reasonable path to determine that > someone has an exceptional problem and isn't being well-served by the > script. Customer records often include an optional data field that says things about particular customers. I heard a story -- and I'll leave out the names, since it's second- or third-hand and it does involve people and companies most of us know -- that one very clueful person's record had a note saying more or less "if you don't understand what he's saying, he's right and you're wrong, and you should route his call immediately to Tier N, where N is large"... But getting on that list is the hard part. --Steve Bellovin, http://www.cs.columbia.edu/~smb From lists at memetic.org Sat Dec 27 17:45:46 2008 From: lists at memetic.org (Adam Armstrong) Date: Sat, 27 Dec 2008 23:45:46 +0000 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: <002e01c96862$bbe8f520$33badf60$@com> References: <004a01c967d1$55da3780$018ea680$@com> <495688C2.6030109@memetic.org> <002e01c96862$bbe8f520$33badf60$@com> Message-ID: <4956BE2A.4040701@memetic.org> TJ wrote: >> ... not to mention that fact that IS-IS is, IMHO, a much nicer IGP to work >> > with. > > WRT that last sentence, that is an almost religious debate I was trying to > avoid starting ... :) > Well IMHO it's a very important point to consider. This is a great chance to switch your IGP, if you've ever wanted to. You *need* to deploy a new one anyways, so it's a great opportunity to see if you can simplify your network by migrating. Especially as OSPFv3 *isnt* the same as OSPFv2, so you will have to learn new things either way! Oh, and I *am* in the process of organising a Crusade to wipe out those heretical OSPF supporters once and for all... ;) adam. From oberman at es.net Sat Dec 27 17:53:41 2008 From: oberman at es.net (Kevin Oberman) Date: Sat, 27 Dec 2008 15:53:41 -0800 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: Your message of "Sat, 27 Dec 2008 15:23:25 EST." <20081227152325.59d5b391@cs.columbia.edu> Message-ID: <20081227235341.827294500F@ptavv.es.net> > Date: Sat, 27 Dec 2008 15:23:25 -0500 > From: "Steven M. Bellovin" > > On Fri, 26 Dec 2008 20:37:41 -0800 > "Kevin Oberman" wrote: > > > The main reason I prefer ISIS is that it uses CLNS packets for > > communications and we don't route CLNS. (I don't think ANYONE is > > routing CLNS today.) That makes it pretty secure. > > Unless, of course, someone one hop away -- a peer? a customer? an > upstream or downstream? someone on the same LAN at certain exchange > points? -- sends you a CLNP packet at link level... You mean that someone is silly enough to enable CLNS on external interfaces? I mean, it's not by default on either Cisco or Juniper. I don't imagine any other routers do that, either. (Of course, SOMEONE is always that silly. But I hope the folks reading this are not.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From hannigan at gmail.com Sat Dec 27 19:22:43 2008 From: hannigan at gmail.com (Martin Hannigan) Date: Sat, 27 Dec 2008 20:22:43 -0500 Subject: Cap'n Bubba the marine backhoe driver - SEA-ME-WE 3 and 4, FLAG cut In-Reply-To: References: Message-ID: <2d106eb50812271722r6956ca26pe63d2001f343286d@mail.gmail.com> On Fri, Dec 19, 2008 at 12:17 PM, Suresh Ramasubramanian wrote: > On Dave Farber's IP list. > >> >> From: France Telecom / Press >> To: France Telecom / Press >> Subject: Three undersea cables cut: traffic greatly disturbed between >> Europe and Asia/Near East zone >> Date: Fri, 19 Dec 2008 17:09:03 +0100 (CET) >> X-Concentric-MX-Info: s=0AKNHR84D300:1 ts=0 td=53 dt=0 tro=1 tra=2 >> trb=1 sro=1 sra=2 ic=0 >> X-Concentric-DKIM: SigStatus="No signature", PolSusp="No", >> PolTest="No", Policy="none", Handling="none" >> X-Virus-Status: No >> >> If you can't read this email, please go to : http://www.orange.com/en_EN/press/press_releases/cp081219en.html >> Paris, December 19, 2008 >> Three undersea cables cut: traffic greatly disturbed between Europe and >> Asia/Near East zone >> >> 3 cables cut this morning (Sea Me We3 partly + Sea Me We4 + FLAG) >> France Telecom Marine cable ship about to depart >> >> France Telecom observed today that 3 major underwater cables were cut: >> ?Sea Me We 4? at 7:28am, ?Sea Me We3? at 7:33am and FLAG at 8:06am. >> The causes of the cut, which is located in the Mediterranean between >> Sicily and Tunisia, on sections linking Sicily to Egypt, remain >> unclear. >> >> Most of the B to B traffic between Europe and Asia is rerouted through >> the USA. >> Traffic from Europe to Algeria and Tunisia is not affected, but traffic >> from Europe to the Near East and Asia is interrupted to a greater or >> lesser extent (see country list below). >> Part of the internet traffic towards R?union is affected as well as 50% >> towards Jordan. >> A first appraisal at 7:44 am UTC gave an estimate of the following >> impact on the voice traffic (in percentage of out of service capacity): >> - Saudi Arabia: 55% out of service >> - Djibouti: 71% out of service >> - Egypt: 52% out of service >> - United Arab Emirates: 68% out of service >> - India: 82% out of service >> - Lebanon: 16% out of service >> - Malaysia: 42% out of service >> - Maldives: 100% out of service >> - Pakistan: 51% out of service >> - Qatar: 73% out of service >> - Syria: 36% out of service >> - Taiwan: 39% out of service >> - Yemen: 38% out of service >> - Zambia: 62% out of service >> And it looks like they are going back to square one on SMW4. AMMAN - Internet users in the Kingdom and elsewhere in the region are expected to continue experiencing slower services as repair teams continue their attempts to fix cut cables in the Mediterranean. Raslan Diranieh, chief financial officer of the Jordan Telecom Group (JTG), said that a few hours after SMW-4 Internet cable which links the Kingdom to the International Internet Network was fixed, it experienced another cut on Saturday. http://www.jordantimes.com/?news=13079 From virendra.rode at gmail.com Sat Dec 27 20:53:58 2008 From: virendra.rode at gmail.com (virendra rode) Date: Sat, 27 Dec 2008 18:53:58 -0800 Subject: Cap'n Bubba the marine backhoe driver - SEA-ME-WE 3 and 4, FLAG cut In-Reply-To: <2d106eb50812271722r6956ca26pe63d2001f343286d@mail.gmail.com> References: <2d106eb50812271722r6956ca26pe63d2001f343286d@mail.gmail.com> Message-ID: <4956EA46.70404@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Hannigan wrote: > On Fri, Dec 19, 2008 at 12:17 PM, Suresh Ramasubramanian > wrote: >> On Dave Farber's IP list. >> >>> From: France Telecom / Press >>> To: France Telecom / Press >>> Subject: Three undersea cables cut: traffic greatly disturbed between >>> Europe and Asia/Near East zone >>> Date: Fri, 19 Dec 2008 17:09:03 +0100 (CET) >>> X-Concentric-MX-Info: s=0AKNHR84D300:1 ts=0 td=53 dt=0 tro=1 tra=2 >>> trb=1 sro=1 sra=2 ic=0 >>> X-Concentric-DKIM: SigStatus="No signature", PolSusp="No", >>> PolTest="No", Policy="none", Handling="none" >>> X-Virus-Status: No >>> >>> If you can't read this email, please go to : http://www.orange.com/en_EN/press/press_releases/cp081219en.html >>> Paris, December 19, 2008 >>> Three undersea cables cut: traffic greatly disturbed between Europe and >>> Asia/Near East zone >>> >>> 3 cables cut this morning (Sea Me We3 partly + Sea Me We4 + FLAG) >>> France Telecom Marine cable ship about to depart >>> >>> France Telecom observed today that 3 major underwater cables were cut: >>> ?Sea Me We 4? at 7:28am, ?Sea Me We3? at 7:33am and FLAG at 8:06am. >>> The causes of the cut, which is located in the Mediterranean between >>> Sicily and Tunisia, on sections linking Sicily to Egypt, remain >>> unclear. >>> >>> Most of the B to B traffic between Europe and Asia is rerouted through >>> the USA. >>> Traffic from Europe to Algeria and Tunisia is not affected, but traffic >>> from Europe to the Near East and Asia is interrupted to a greater or >>> lesser extent (see country list below). >>> Part of the internet traffic towards R?union is affected as well as 50% >>> towards Jordan. >>> A first appraisal at 7:44 am UTC gave an estimate of the following >>> impact on the voice traffic (in percentage of out of service capacity): >>> - Saudi Arabia: 55% out of service >>> - Djibouti: 71% out of service >>> - Egypt: 52% out of service >>> - United Arab Emirates: 68% out of service >>> - India: 82% out of service >>> - Lebanon: 16% out of service >>> - Malaysia: 42% out of service >>> - Maldives: 100% out of service >>> - Pakistan: 51% out of service >>> - Qatar: 73% out of service >>> - Syria: 36% out of service >>> - Taiwan: 39% out of service >>> - Yemen: 38% out of service >>> - Zambia: 62% out of service >>> > > > And it looks like they are going back to square one on SMW4. > > AMMAN - Internet users in the Kingdom and elsewhere in the region are > expected to continue experiencing slower services as repair teams > continue their attempts to fix cut cables in the Mediterranean. > > Raslan Diranieh, chief financial officer of the Jordan Telecom Group > (JTG), said that a few hours after SMW-4 Internet cable which links > the Kingdom to the International Internet Network was fixed, it > experienced another cut on Saturday. - ---------------------------- I wonder how many km apart smw4 & smw3 are of eachother as my understanding is they follow same path. My understanding is repairing is extremely tedious process by which robot has to scour the seabed and dig out the broken cable and solder individual fiber and check for connectivity not that this is an excuse for another cut. regards, /virendra > > > http://www.jordantimes.com/?news=13079 > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJVupFpbZvCIJx1bcRApz7AJ9r5ZzXOUZ7fa30R+hDqrMfzS9hPQCeMYwN DZglqvleGT3gkaDc1v6DDsw= =L8xJ -----END PGP SIGNATURE----- From martin at theicelandguy.com Sat Dec 27 21:23:09 2008 From: martin at theicelandguy.com (Martin Hannigan) Date: Sat, 27 Dec 2008 22:23:09 -0500 Subject: Cap'n Bubba the marine backhoe driver - SEA-ME-WE 3 and 4, FLAG cut In-Reply-To: <4956EA46.70404@gmail.com> References: <2d106eb50812271722r6956ca26pe63d2001f343286d@mail.gmail.com> <4956EA46.70404@gmail.com> Message-ID: The repair is done out of the water. They cut the damage out and bring and end onto the ship and, using a common joint that all the vendors use so that any available lay/repair ship in the maintenance consortium can be dispatched for repair, they fusion splice the new section and coat in LDPE and re lay. They do the same with the other end. IIRC, They have to cut the damage out at different ends in most cases because the cable would be difficult to lift due to weight. Rod Beck could probably add some detail here. I recall the last release said it was a seismic event that caused the initial multi cable break. I haven't looked at the charts, but I'd think they were probably close, like a lot of East Coast to London cable runs are. (Exception: Hibernia Atlantic). Best, -M< On 12/27/08, virendra rode wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Martin Hannigan wrote: >> On Fri, Dec 19, 2008 at 12:17 PM, Suresh Ramasubramanian >> wrote: >>> On Dave Farber's IP list. >>> >>>> From: France Telecom / Press >>>> To: France Telecom / Press >>>> Subject: Three undersea cables cut: traffic greatly disturbed between >>>> Europe and Asia/Near East zone >>>> Date: Fri, 19 Dec 2008 17:09:03 +0100 (CET) >>>> X-Concentric-MX-Info: s=0AKNHR84D300:1 ts=0 td=53 dt=0 tro=1 tra=2 >>>> trb=1 sro=1 sra=2 ic=0 >>>> X-Concentric-DKIM: SigStatus="No signature", PolSusp="No", >>>> PolTest="No", Policy="none", Handling="none" >>>> X-Virus-Status: No >>>> >>>> If you can't read this email, please go to : >>>> http://www.orange.com/en_EN/press/press_releases/cp081219en.html >>>> Paris, December 19, 2008 >>>> Three undersea cables cut: traffic greatly disturbed between Europe and >>>> Asia/Near East zone >>>> >>>> 3 cables cut this morning (Sea Me We3 partly + Sea Me We4 + FLAG) >>>> France Telecom Marine cable ship about to depart >>>> >>>> France Telecom observed today that 3 major underwater cables were cut: >>>> ?Sea Me We 4? at 7:28am, ?Sea Me We3? at 7:33am and FLAG at 8:06am. >>>> The causes of the cut, which is located in the Mediterranean between >>>> Sicily and Tunisia, on sections linking Sicily to Egypt, remain >>>> unclear. >>>> >>>> Most of the B to B traffic between Europe and Asia is rerouted through >>>> the USA. >>>> Traffic from Europe to Algeria and Tunisia is not affected, but traffic >>>> from Europe to the Near East and Asia is interrupted to a greater or >>>> lesser extent (see country list below). >>>> Part of the internet traffic towards R?union is affected as well as 50% >>>> towards Jordan. >>>> A first appraisal at 7:44 am UTC gave an estimate of the following >>>> impact on the voice traffic (in percentage of out of service capacity): >>>> - Saudi Arabia: 55% out of service >>>> - Djibouti: 71% out of service >>>> - Egypt: 52% out of service >>>> - United Arab Emirates: 68% out of service >>>> - India: 82% out of service >>>> - Lebanon: 16% out of service >>>> - Malaysia: 42% out of service >>>> - Maldives: 100% out of service >>>> - Pakistan: 51% out of service >>>> - Qatar: 73% out of service >>>> - Syria: 36% out of service >>>> - Taiwan: 39% out of service >>>> - Yemen: 38% out of service >>>> - Zambia: 62% out of service >>>> >> >> >> And it looks like they are going back to square one on SMW4. >> >> AMMAN - Internet users in the Kingdom and elsewhere in the region are >> expected to continue experiencing slower services as repair teams >> continue their attempts to fix cut cables in the Mediterranean. >> >> Raslan Diranieh, chief financial officer of the Jordan Telecom Group >> (JTG), said that a few hours after SMW-4 Internet cable which links >> the Kingdom to the International Internet Network was fixed, it >> experienced another cut on Saturday. > - ---------------------------- > I wonder how many km apart smw4 & smw3 are of eachother as my > understanding is they follow same path. > > My understanding is repairing is extremely tedious process by which > robot has to scour the seabed and dig out the broken cable and solder > individual fiber and check for connectivity not that this is an excuse > for another cut. > > > regards, > /virendra > > >> >> >> http://www.jordantimes.com/?news=13079 >> >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFJVupFpbZvCIJx1bcRApz7AJ9r5ZzXOUZ7fa30R+hDqrMfzS9hPQCeMYwN > DZglqvleGT3gkaDc1v6DDsw= > =L8xJ > -----END PGP SIGNATURE----- > > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 From martin at theicelandguy.com Sat Dec 27 21:28:32 2008 From: martin at theicelandguy.com (Martin Hannigan) Date: Sat, 27 Dec 2008 22:28:32 -0500 Subject: Cap'n Bubba the marine backhoe driver - SEA-ME-WE 3 and 4, FLAG cut In-Reply-To: <4956EA46.70404@gmail.com> References: <2d106eb50812271722r6956ca26pe63d2001f343286d@mail.gmail.com> <4956EA46.70404@gmail.com> Message-ID: Apology in advance for the additional followup; The other 'exception' to add to my previous post is Hibernia terrestrial+marine via Halifax to Greenland Conect interconnected with either Danice or Farice via Iceland. Hibernia Ireland+London would be lower latency for US route, with the second potential Hibernia route being second lowest alternate. Best, -M< On 12/27/08, virendra rode wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Martin Hannigan wrote: >> On Fri, Dec 19, 2008 at 12:17 PM, Suresh Ramasubramanian >> wrote: >>> On Dave Farber's IP list. >>> >>>> From: France Telecom / Press >>>> To: France Telecom / Press >>>> Subject: Three undersea cables cut: traffic greatly disturbed between >>>> Europe and Asia/Near East zone >>>> Date: Fri, 19 Dec 2008 17:09:03 +0100 (CET) >>>> X-Concentric-MX-Info: s=0AKNHR84D300:1 ts=0 td=53 dt=0 tro=1 tra=2 >>>> trb=1 sro=1 sra=2 ic=0 >>>> X-Concentric-DKIM: SigStatus="No signature", PolSusp="No", >>>> PolTest="No", Policy="none", Handling="none" >>>> X-Virus-Status: No >>>> >>>> If you can't read this email, please go to : >>>> http://www.orange.com/en_EN/press/press_releases/cp081219en.html >>>> Paris, December 19, 2008 >>>> Three undersea cables cut: traffic greatly disturbed between Europe and >>>> Asia/Near East zone >>>> >>>> 3 cables cut this morning (Sea Me We3 partly + Sea Me We4 + FLAG) >>>> France Telecom Marine cable ship about to depart >>>> >>>> France Telecom observed today that 3 major underwater cables were cut: >>>> ?Sea Me We 4? at 7:28am, ?Sea Me We3? at 7:33am and FLAG at 8:06am. >>>> The causes of the cut, which is located in the Mediterranean between >>>> Sicily and Tunisia, on sections linking Sicily to Egypt, remain >>>> unclear. >>>> >>>> Most of the B to B traffic between Europe and Asia is rerouted through >>>> the USA. >>>> Traffic from Europe to Algeria and Tunisia is not affected, but traffic >>>> from Europe to the Near East and Asia is interrupted to a greater or >>>> lesser extent (see country list below). >>>> Part of the internet traffic towards R?union is affected as well as 50% >>>> towards Jordan. >>>> A first appraisal at 7:44 am UTC gave an estimate of the following >>>> impact on the voice traffic (in percentage of out of service capacity): >>>> - Saudi Arabia: 55% out of service >>>> - Djibouti: 71% out of service >>>> - Egypt: 52% out of service >>>> - United Arab Emirates: 68% out of service >>>> - India: 82% out of service >>>> - Lebanon: 16% out of service >>>> - Malaysia: 42% out of service >>>> - Maldives: 100% out of service >>>> - Pakistan: 51% out of service >>>> - Qatar: 73% out of service >>>> - Syria: 36% out of service >>>> - Taiwan: 39% out of service >>>> - Yemen: 38% out of service >>>> - Zambia: 62% out of service >>>> >> >> >> And it looks like they are going back to square one on SMW4. >> >> AMMAN - Internet users in the Kingdom and elsewhere in the region are >> expected to continue experiencing slower services as repair teams >> continue their attempts to fix cut cables in the Mediterranean. >> >> Raslan Diranieh, chief financial officer of the Jordan Telecom Group >> (JTG), said that a few hours after SMW-4 Internet cable which links >> the Kingdom to the International Internet Network was fixed, it >> experienced another cut on Saturday. > - ---------------------------- > I wonder how many km apart smw4 & smw3 are of eachother as my > understanding is they follow same path. > > My understanding is repairing is extremely tedious process by which > robot has to scour the seabed and dig out the broken cable and solder > individual fiber and check for connectivity not that this is an excuse > for another cut. > > > regards, > /virendra > > >> >> >> http://www.jordantimes.com/?news=13079 >> >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFJVupFpbZvCIJx1bcRApz7AJ9r5ZzXOUZ7fa30R+hDqrMfzS9hPQCeMYwN > DZglqvleGT3gkaDc1v6DDsw= > =L8xJ > -----END PGP SIGNATURE----- > > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 From mtinka at globaltransit.net Sat Dec 27 23:00:28 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Sun, 28 Dec 2008 13:00:28 +0800 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: <49562D29.8030003@psg.com> References: <200812271833.10233.mtinka@globaltransit.net> <49562D29.8030003@psg.com> Message-ID: <200812281300.34387.mtinka@globaltransit.net> On Saturday 27 December 2008 09:27:05 pm Randy Bush wrote: > as one who has been burned when topologies are not > congruent, i gotta ask. if i do not anticipate v4 and v6 > having different topologies, and all my devices are > dual-capable, would you still recommend mt for other than > future-proofing? In practice, we realized that enabling IS-ISv6 on interfaces already running IS-ISv4 was problematic without MT pre- configured. Those links surely lost IS-IS adjacency which threatened stability of the network. Things could probably have been easier if all routers accepted all transition commands at the same time (or if all routers were pre-configured and powered on at the same time), but that's not possible. MT allowed us to bring up individual v6 links on the same and different routers, at different times, without bringing down the v4 network, considering that several routers had as many as 4 - 6 links into the core. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From morrowc.lists at gmail.com Sun Dec 28 00:30:41 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 28 Dec 2008 01:30:41 -0500 Subject: Cap'n Bubba the marine backhoe driver - SEA-ME-WE 3 and 4, FLAG cut In-Reply-To: References: <2d106eb50812271722r6956ca26pe63d2001f343286d@mail.gmail.com> <4956EA46.70404@gmail.com> Message-ID: <75cb24520812272230x13dbfeb4he8300cc71bb15f31@mail.gmail.com> On Sat, Dec 27, 2008 at 10:23 PM, Martin Hannigan wrote: > The repair is done out of the water. They cut the damage out and bring there was a nice flash video thingy presented in Toronto during Sylvie LaPerri?re's preso: I believe the flash thing is: (top search result for 'undersea cable repair flash' on your favorite search engine) -chris From martin at theicelandguy.com Sun Dec 28 00:42:34 2008 From: martin at theicelandguy.com (Martin Hannigan) Date: Sun, 28 Dec 2008 01:42:34 -0500 Subject: Cap'n Bubba the marine backhoe driver - SEA-ME-WE 3 and 4, FLAG cut In-Reply-To: <75cb24520812272230x13dbfeb4he8300cc71bb15f31@mail.gmail.com> References: <2d106eb50812271722r6956ca26pe63d2001f343286d@mail.gmail.com> <4956EA46.70404@gmail.com> <75cb24520812272230x13dbfeb4he8300cc71bb15f31@mail.gmail.com> Message-ID: On Sun, Dec 28, 2008 at 1:30 AM, Christopher Morrow wrote: > On Sat, Dec 27, 2008 at 10:23 PM, Martin Hannigan > wrote: > > The repair is done out of the water. They cut the damage out and bring > > there was a nice flash video thingy presented in Toronto during Sylvie > LaPerri?re's preso: > > > > I believe the flash thing is: > > < > http://www1.alcatel-lucent.com/submarine/products/marine/index.htm;jsessionid=IEJIVJOKNSXPZLAWFRUE1CVMCYWGI3GC# > > > > (top search result for 'undersea cable repair flash' on your favorite > search engine) I think that these are much more interesting and informative myself: http://www.youtube.com/results?search_query=Hibernia+Atlantic&search_type=&aq=f This one specifically address cable joins. Sort of looks like Tyco's lab in New Jersey, but I think it's a Global Marine shipboard lab. http://www.youtube.com/watch?v=_E7CfQXhcY0 They don't show the LDPE application post splice, but it's kind of uninteresting. This stuff is a whole lot simpler than most people think. -M< -- Martin Hannigan martin at theicelandguy.com p: +16178216079 From eddies at softhome.net Sun Dec 28 00:45:15 2008 From: eddies at softhome.net (Eddie) Date: Sat, 27 Dec 2008 22:45:15 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: References: <1873041366-1230140806-cardhu_decombobulator_blackberry.rim.net-945806518-@bxe325.bisx.prod.on.blackberry> <70D072392E56884193E3D2DE09C097A9FC1C@pascal.zaphodb.org> <49527B19.3080909@deaddrop.org> Message-ID: <4957207B.1080100@softhome.net> Matthew Black wrote: > On Wed, 24 Dec 2008 10:10:33 -0800 > Etaoin Shrdlu wrote: >> Matthew Black wrote: >> >>> On Wed, 24 Dec 2008 09:51:41 -0800 >>> "Tomas L. Byrnes" wrote: >>> >>>> Cox Communications has fully on-shore support. Here in SD they are >>>> actually LOCAL. >> >>> In Verizon land, residential customers do not have >>> CLEC voice or DSL alternatives. We do not have Cox. >>> Our area is served by Charter Communications who has >>> the broadband cable monopoly. Verizon has the fiber >>> monopoly with their FIOS. AT&T fiber is not possible >>> in Verizon land. Nobody competes against Verizon for >>> residential service in Southern California. >> >> Sir, both COVAD and DSLExtreme beg to differ. Seriously. I just checked. >> >> -- >> The histories of mankind are histories only of the higher classes. >> >> Thomas Malthus > > > Going through COVAD's interactive DSL chooser, > there are no options for RESIDENTIAL service. > > > > > DSLextreme is charging a higher price than Verizon > and I suspect they are simply reselling Verizon's > DSL rather than connecting my copper to their > network. That's hardly what I consider CLEC service. > I could be wrong and would switch if I could. But I > don't see them offering voice and that's why I conclude > they are reselling Verizon's DSL service. > > matthew black > california state university, long beach > > I have 25 DSLExtreme lines along with 3 other providers in businesses all around the SoCal area. The local loop is whatever the telco is, but the network is their own. The service was better a few years ago, but it's still far exceeds what the big telco provides. The DSLX techs know their stuff and only once did I have a tech not believe me. On the last call, the tech asked me if I checked the DSL filters and I told them I had a hole house Selco box at the MPOE and ran a dedicated cat5 wire as the phone like for the DSL modem. The tech understood what I had did. No ATT, SBC, or Verizon tech has ever understood that. For one location, because of the distance, I had to order an IDSL line from Covad (SBC owned the wires). I ran a cat5 drop from MPOE to the office to make the tech's job easier. (yes I use cat5 for phone and everything. Why not?) Well, the install date came, the Covad tech came out and installed it, but left with it not working. So the blame game went on between SBC and Covad for 2 months before a time could be arranged when both could be at the location at the same time. When Covad connects the DSL modem to the pair at the MPOE the modem makes a hissing sound. Covad proclaims the pair is bad. SBC guy says the pair test good. SBC swaps to a new pair, but hissing remains. During this time they are both on hold to the same call center, with their cell phones on speaker. It was the same on hold music so it was sort of like listening in stereo. Both basically sat around for 3 hours on hold until the SBC guy gave up and left. Covad guy's phone battery went dead 10 minutes later. Nobody ever got a tech on the phone. To prove that the hissing noise was causing the problem, Covad guy connected his laptop up and quickly got on the internet. Everything was working fine. I guess nobody checked 3 hours ago and just assumed it didn't work. He tossed me a box with the modem and left. I was left to punch down the phone lines and put the modem in the office. It was then I discovered IDSL has about 130 volts running in the lines. Outch. The IDSL line stopped working 2 years later so I replaced it with an EVDO modem. Been fine since. ATT is worse. I had a DSL guy install the DSL in a vacant abandoned building twice. The business moved down the block, but the ATT guy just went to the old building again and again. it took 4 months for that ATT install. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From steve at ibctech.ca Wed Dec 24 10:04:43 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 24 Dec 2008 11:04:43 -0500 Subject: What to do when your ISP off-shores tech support In-Reply-To: References: Message-ID: <49525D9B.6080807@ibctech.ca> Matthew Black wrote: > I've had difficulties reaching anyone with a brain > at my DSL provider Verizon California. > > I can reliably ping the first hop from my home to > the CO with a 25ms delay. But if I ping any other > location, packets get dropped or significantly > delayed. To me, this sounds like Verizon has an > internal routing problem rather than a problem > with my phone line. Note that it rained recently > in our area and the cable vault in front of my > is usually covered with stagnant water because > the gutters don't drain it away. > > I have tried to explain this to tech support but > they refuse to go off script, even the supervisors. > They keep insisting on sending a tech to my home > when I suggest this should be escalated to their > network operations team. > > Anyhow, if I can reliably ping the first hop > from my home, would that eliminate my telephone > connection as part of the problem? Just a sanity > check on my part. Thanks. Is your DSL modem of the type that you can log into and check the line stats? Even if there are phone line problems, you still have sync, and regardless what the sync rate, line noise etc are, if you can ping across the link and get a reply, replies should come back from distant gear as well. Perhaps an op from another relatively local provider could supply you with a temporary DSL auth account to see if that will route you around the problem. I could supply you one, but I'm in southern Ontario, Canada, so I don't know if the realm would properly route all the way back here or not. Steve From nanog2 at adns.net Sat Dec 27 18:35:37 2008 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Sat, 27 Dec 2008 18:35:37 -0600 Subject: 100MB connectivity in Detroit area Message-ID: <07ae01c968df$1025d3c0$8001010a@TAKA> Wondering about the availability of 100mb connectivity in Macomb county (Clinton Twp) Michigan. Please reply off-list. From trejrco at gmail.com Sun Dec 28 08:08:46 2008 From: trejrco at gmail.com (TJ) Date: Sun, 28 Dec 2008 09:08:46 -0500 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: <4956BE2A.4040701@memetic.org> References: <004a01c967d1$55da3780$018ea680$@com> <495688C2.6030109@memetic.org> <002e01c96862$bbe8f520$33badf60$@com> <4956BE2A.4040701@memetic.org> Message-ID: <001001c968f5$cd2cc7b0$67865710$@com> >>> ... not to mention that fact that IS-IS is, IMHO, a much nicer IGP to work with. >> >> WRT that last sentence, that is an almost religious debate I was trying to >> avoid starting ... :) >> >Well IMHO it's a very important point to consider. This is a great chance to switch your IGP, if you've ever wanted to. You *need* to And that is what I tell people too - if you are looking to change (in either direction (or others!), mind you), this could be an excuse / opportunity. >deploy a new one anyways, so it's a great opportunity to see if you can >simplify your network by migrating. Especially as OSPFv3 *isnt* the same >as OSPFv2, so you will have to learn new things either way! Well from a pragmatic/operational perspective OSPFv3 and OSPFv2 are "close enough" that you would require _very_ little re-training. > >Oh, and I *am* in the process of organising a Crusade to wipe out those >heretical OSPF supporters once and for all... ;) Funny, that is how most ISIS proponents seem to feel - but without the smiley! /TJ From trejrco at gmail.com Sun Dec 28 08:10:44 2008 From: trejrco at gmail.com (TJ) Date: Sun, 28 Dec 2008 09:10:44 -0500 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: <200812281300.34387.mtinka@globaltransit.net> References: <200812271833.10233.mtinka@globaltransit.net> <49562D29.8030003@psg.com> <200812281300.34387.mtinka@globaltransit.net> Message-ID: <001a01c968f6$1c26acf0$547406d0$@com> >> as one who has been burned when topologies are not congruent, i gotta >> ask. if i do not anticipate v4 and v6 having different topologies, >> and all my devices are dual-capable, would you still recommend mt for >> other than future-proofing? > >In practice, we realized that enabling IS-ISv6 on interfaces already running >IS-ISv4 was problematic without MT pre- configured. > >Those links surely lost IS-IS adjacency which threatened stability of the >network. Yup, that is the rub: if rolling out your v6 routing impacts your v4 routing you are not "winning". /TJ From randy at psg.com Sun Dec 28 08:23:11 2008 From: randy at psg.com (Randy Bush) Date: Sun, 28 Dec 2008 09:23:11 -0500 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: <001a01c968f6$1c26acf0$547406d0$@com> References: <200812271833.10233.mtinka@globaltransit.net> <49562D29.8030003@psg.com> <200812281300.34387.mtinka@globaltransit.net> <001a01c968f6$1c26acf0$547406d0$@com> Message-ID: <49578BCF.3060805@psg.com> >> In practice, we realized that enabling IS-ISv6 on interfaces >> already running IS-ISv4 was problematic without MT pre- >> configured. >> Those links surely lost IS-IS adjacency which threatened stability >> of the network. > Yup, that is the rub: if rolling out your v6 routing impacts your v4 > routing you are not "winning". this is not very deep. mark did point out how to avoid it, pointing out why mt was very useful as opposed to just another bell and whistle. during a transition, in fact, topologies are not congruent due to inability to have a flag millisecond, a very very useful observation. randy From marco at zero11.com Sun Dec 28 11:58:34 2008 From: marco at zero11.com (marco) Date: Sun, 28 Dec 2008 09:58:34 -0800 Subject: Level 3 issues Message-ID: <4957BE4A.3080008@zero11.com> is anyone having issues with Level3? From pstewart at nexicomgroup.net Sun Dec 28 12:00:42 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Sun, 28 Dec 2008 13:00:42 -0500 Subject: Level 3 issues In-Reply-To: <4957BE4A.3080008@zero11.com> References: <4957BE4A.3080008@zero11.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A01DDCA30@nexus.nexicomgroup.net> What country, location, where you fed from?? -----Original Message----- From: marco [mailto:marco at zero11.com] Sent: December 28, 2008 12:59 PM To: nanog at nanog.org Subject: Level 3 issues is anyone having issues with Level3? ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From david at davidcoulson.net Sun Dec 28 12:05:14 2008 From: david at davidcoulson.net (David Coulson) Date: Sun, 28 Dec 2008 13:05:14 -0500 Subject: Level 3 issues In-Reply-To: <4957BE4A.3080008@zero11.com> References: <4957BE4A.3080008@zero11.com> Message-ID: <4957BFDA.5000304@davidcoulson.net> http://www.internetpulse.net/ (if you can get to it). Does not look pretty for L3. I can't get to most web sites if I go via Level3 (Cleveland, OH). Ping/traceroute look good though. marco wrote: > is anyone having issues with Level3? > > From mjkelly at gmail.com Sun Dec 28 12:05:17 2008 From: mjkelly at gmail.com (Matt Kelly) Date: Sun, 28 Dec 2008 13:05:17 -0500 Subject: Level 3 issues In-Reply-To: <4957BE4A.3080008@zero11.com> References: <4957BE4A.3080008@zero11.com> Message-ID: Yes. We just experienced an outage in Philadelphia. We shut down the circuit pending further investigation. On Dec 28, 2008, at 12:58 PM, marco wrote: > is anyone having issues with Level3? > From marco at zero11.com Sun Dec 28 12:05:41 2008 From: marco at zero11.com (marco) Date: Sun, 28 Dec 2008 10:05:41 -0800 Subject: Level 3 issues In-Reply-To: <014d01c96916$42361f50$c6a25df0$@com> References: <4957BE4A.3080008@zero11.com> <014d01c96916$42361f50$c6a25df0$@com> Message-ID: <4957BFF5.2050000@zero11.com> jajogega at gmail.com wrote: > Yes sir. > > >> -----Original Message----- >> From: marco [mailto:marco at zero11.com] >> Sent: Sunday, December 28, 2008 12:59 PM >> To: nanog at nanog.org >> Subject: Level 3 issues >> >> is anyone having issues with Level3? >> > > do you have any more details? From phach34 at gmail.com Sun Dec 28 12:05:54 2008 From: phach34 at gmail.com (Pierre-Henri) Date: Sun, 28 Dec 2008 19:05:54 +0100 Subject: Level 3 issues In-Reply-To: <4957BE4A.3080008@zero11.com> References: <4957BE4A.3080008@zero11.com> Message-ID: <4957C002.2030001@gmail.com> marco a ?crit : > is anyone having issues with Level3? > > hi, theplanet.com and many websites (cnn.com ; amazon.com ; ... ) have not been accessible from France (Orange, home connection) for about 30 minutes. Don't know if there is a link with your question, but . Pierre-Henri From phach34 at gmail.com Sun Dec 28 12:06:10 2008 From: phach34 at gmail.com (Pierre-Henri) Date: Sun, 28 Dec 2008 19:06:10 +0100 Subject: Level 3 issues In-Reply-To: <4957BE4A.3080008@zero11.com> References: <4957BE4A.3080008@zero11.com> Message-ID: <4957C012.4050205@gmail.com> marco a ?crit : > is anyone having issues with Level3? > > hi, theplanet.com and many websites (cnn.com ; amazon.com ; ... ) have not been accessible from France (Orange, home connection) for about 30 minutes. Don't know if there is a link with your question, but it's strange... Pierre-Henri From pstewart at nexicomgroup.net Sun Dec 28 12:15:14 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Sun, 28 Dec 2008 13:15:14 -0500 Subject: Level 3 issues In-Reply-To: <4957C012.4050205@gmail.com> References: <4957BE4A.3080008@zero11.com> <4957C012.4050205@gmail.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A01DDCA33@nexus.nexicomgroup.net> Ahh.. yes seeing that now here from Toronto ON - didn't see this issue when the original poster sent the first message... it's now happening here too... Shutting down their session until something looks "better" -----Original Message----- From: Pierre-Henri [mailto:phach34 at gmail.com] Sent: December 28, 2008 1:06 PM To: marco Cc: nanog at nanog.org Subject: Re: Level 3 issues marco a ?crit : > is anyone having issues with Level3? > > hi, theplanet.com and many websites (cnn.com ; amazon.com ; ... ) have not been accessible from France (Orange, home connection) for about 30 minutes. Don't know if there is a link with your question, but it's strange... Pierre-Henri ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From bpfankuch at cpgreeley.com Sun Dec 28 12:15:57 2008 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Sun, 28 Dec 2008 11:15:57 -0700 Subject: Level 3 issues In-Reply-To: <4957C002.2030001@gmail.com> References: <4957BE4A.3080008@zero11.com> <4957C002.2030001@gmail.com> Message-ID: <01759D50DC387C45A018FE1817CE27D7540C2B5FE2@CPExchange1.cpgreeley.com> Ive got connection issues from Colorado to new York on level3 that have been restored, but still nothing from Chicago to Colorado, and way too many other places to list. Anyone have a ticket number with level3? -----Original Message----- From: Pierre-Henri [mailto:phach34 at gmail.com] Sent: Sunday, December 28, 2008 11:06 AM To: marco Cc: nanog at nanog.org Subject: Re: Level 3 issues marco a ?crit : > is anyone having issues with Level3? > > hi, theplanet.com and many websites (cnn.com ; amazon.com ; ... ) have not been accessible from France (Orange, home connection) for about 30 minutes. Don't know if there is a link with your question, but . Pierre-Henri From paul at gtcomm.net Sun Dec 28 12:24:19 2008 From: paul at gtcomm.net (Paul) Date: Sun, 28 Dec 2008 13:24:19 -0500 Subject: Level 3 issues In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01DDCA33@nexus.nexicomgroup.net> References: <4957BE4A.3080008@zero11.com> <4957C012.4050205@gmail.com> <89D27DE3375BB6428DDCC2927489826A01DDCA33@nexus.nexicomgroup.net> Message-ID: <4957C453.7070406@gtcomm.net> Same issue here from Chicago and Montreal. Seems anything routing through Washington.Level3 is going to null. The rest of the level3 network seems to be ok. 6 ae-32-52.ebr2.Chicago1.Level3.net (4.68.101.62) 0.976 ms 10.344 ms 0.866 ms 7 ae-5.ebr2.Chicago2.Level3.net (4.69.140.194) 1.245 ms 0.991 ms 0.978 ms 8 ae-2-2.ebr2.Washington1.Level3.net (4.69.132.70) 18.608 ms 18.961 ms 18.583 ms 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * ... 4 car1.Montreal2.Level3.net (67.215.0.146) 0.657 ms 0.791 ms 0.699 ms 5 ae-5-5.ebr4.NewYork1.Level3.net (4.69.141.6) 17.764 ms 8.490 ms 18.197 ms 6 ae-94-94.csw4.NewYork1.Level3.net (4.69.134.126) 15.541 ms 8.286 ms 17.098 ms 7 ae-93-93.ebr3.NewYork1.Level3.net (4.69.134.109) 11.384 ms ae-61-61.ebr1.NewYork1.Level3.net (4.69.134.65) 9.100 ms 8.614 ms 8 ae-3-3.ebr4.Washington1.Level3.net (4.69.132.93) 13.840 ms 15.584 ms 17.443 ms 9 ae-94-94.csw4.Washington1.Level3.net (4.69.134.190) 23.420 ms 25.569 ms 18.042 ms 10 ae-4-99.edge2.Washington4.Level3.net (4.68.17.211) 14.052 ms 14.028 ms 13.610 ms 11 * * * 12 * * * 13 * * * 14 * * * 15 * Paul Stewart wrote: > Ahh.. yes seeing that now here from Toronto ON - didn't see this issue when the original poster sent the first message... it's now happening here too... > > Shutting down their session until something looks "better" > > -----Original Message----- > From: Pierre-Henri [mailto:phach34 at gmail.com] > Sent: December 28, 2008 1:06 PM > To: marco > Cc: nanog at nanog.org > Subject: Re: Level 3 issues > > marco a ?crit : > >> is anyone having issues with Level3? >> >> >> > hi, > theplanet.com and many websites (cnn.com ; amazon.com ; ... ) have not > been accessible from France (Orange, home connection) for about 30 minutes. > Don't know if there is a link with your question, but it's strange... > > > Pierre-Henri > > > > > > ---------------------------------------------------------------------------- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." > > > -- GloboTech Communications Phone: 1-514-907-0050 x 215 Toll Free: 1-(888)-GTCOMM1 Fax: 1-(514)-907-0750 paul at gtcomm.net http://www.gtcomm.net From marco at zero11.com Sun Dec 28 12:21:27 2008 From: marco at zero11.com (marco) Date: Sun, 28 Dec 2008 10:21:27 -0800 Subject: Level 3 issues In-Reply-To: <01759D50DC387C45A018FE1817CE27D7540C2B5FE2@CPExchange1.cpgreeley.com> References: <4957BE4A.3080008@zero11.com> <4957C002.2030001@gmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE2@CPExchange1.cpgreeley.com> Message-ID: <4957C3A7.3050603@zero11.com> Blake Pfankuch wrote: > Ive got connection issues from Colorado to new York on level3 that have been restored, but still nothing from Chicago to Colorado, and way too many other places to list. Anyone have a ticket number with level3? > > -----Original Message----- > From: Pierre-Henri [mailto:phach34 at gmail.com] > Sent: Sunday, December 28, 2008 11:06 AM > To: marco > Cc: nanog at nanog.org > Subject: Re: Level 3 issues > > marco a ?crit : > >> is anyone having issues with Level3? >> >> >> > hi, > theplanet.com and many websites (cnn.com ; amazon.com ; ... ) have not > been accessible from France (Orange, home connection) for about 30 minutes. > Don't know if there is a link with your question, but . > > > Pierre-Henri > > I have a ticket in with L3, their NOC is pretty overwhelmed with phone calls. From tbeecher at localnet.com Sun Dec 28 12:15:49 2008 From: tbeecher at localnet.com (Thomas Beecher) Date: Sun, 28 Dec 2008 13:15:49 -0500 Subject: Level 3 issues In-Reply-To: <4957C012.4050205@gmail.com> References: <4957BE4A.3080008@zero11.com> <4957C012.4050205@gmail.com> Message-ID: <4957C255.70701@localnet.com> I'm showing significant latency and loss over my L3 stuff. interetpulse.net showing the same thing too, seems to be a substantial problem. Pierre-Henri wrote: > marco a ?crit : >> is anyone having issues with Level3? >> >> > hi, > theplanet.com and many websites (cnn.com ; amazon.com ; ... ) have not > been accessible from France (Orange, home connection) for about 30 > minutes. > Don't know if there is a link with your question, but it's strange... > > > Pierre-Henri > From marco at zero11.com Sun Dec 28 12:30:38 2008 From: marco at zero11.com (marco) Date: Sun, 28 Dec 2008 10:30:38 -0800 Subject: Level 3 issues In-Reply-To: <4957C453.7070406@gtcomm.net> References: <4957BE4A.3080008@zero11.com> <4957C012.4050205@gmail.com> <89D27DE3375BB6428DDCC2927489826A01DDCA33@nexus.nexicomgroup.net> <4957C453.7070406@gtcomm.net> Message-ID: <4957C5CE.5040106@zero11.com> Paul wrote: > Same issue here from Chicago and Montreal. Seems anything routing > through Washington.Level3 is going to null. The rest of the level3 > network seems to be ok. > 6 ae-32-52.ebr2.Chicago1.Level3.net (4.68.101.62) 0.976 ms 10.344 > ms 0.866 ms > 7 ae-5.ebr2.Chicago2.Level3.net (4.69.140.194) 1.245 ms 0.991 ms > 0.978 ms > 8 ae-2-2.ebr2.Washington1.Level3.net (4.69.132.70) 18.608 ms 18.961 > ms 18.583 ms > 9 * * * > 10 * * * > 11 * * * > 12 * * * > 13 * * * > 14 * * * > 15 * * * > 16 * * * > > ... > 4 car1.Montreal2.Level3.net (67.215.0.146) 0.657 ms 0.791 ms 0.699 ms > 5 ae-5-5.ebr4.NewYork1.Level3.net (4.69.141.6) 17.764 ms 8.490 ms > 18.197 ms > 6 ae-94-94.csw4.NewYork1.Level3.net (4.69.134.126) 15.541 ms 8.286 > ms 17.098 ms > 7 ae-93-93.ebr3.NewYork1.Level3.net (4.69.134.109) 11.384 ms > ae-61-61.ebr1.NewYork1.Level3.net (4.69.134.65) 9.100 ms 8.614 ms > 8 ae-3-3.ebr4.Washington1.Level3.net (4.69.132.93) 13.840 ms 15.584 > ms 17.443 ms > 9 ae-94-94.csw4.Washington1.Level3.net (4.69.134.190) 23.420 ms > 25.569 ms 18.042 ms > 10 ae-4-99.edge2.Washington4.Level3.net (4.68.17.211) 14.052 ms > 14.028 ms 13.610 ms > 11 * * * > 12 * * * > 13 * * * > 14 * * * > 15 * > > > Paul Stewart wrote: >> Ahh.. yes seeing that now here from Toronto ON - didn't see this >> issue when the original poster sent the first message... it's now >> happening here too... >> >> Shutting down their session until something looks "better" >> >> -----Original Message----- >> From: Pierre-Henri [mailto:phach34 at gmail.com] Sent: December 28, 2008 >> 1:06 PM >> To: marco >> Cc: nanog at nanog.org >> Subject: Re: Level 3 issues >> >> marco a ?crit : >> >>> is anyone having issues with Level3? >>> >>> >> hi, >> theplanet.com and many websites (cnn.com ; amazon.com ; ... ) have >> not been accessible from France (Orange, home connection) for about >> 30 minutes. >> Don't know if there is a link with your question, but it's strange... >> >> >> Pierre-Henri >> >> >> >> >> >> ---------------------------------------------------------------------------- >> >> >> "The information transmitsted is intended only for the person or >> entity to which it is addressed and contains confidential and/or >> privileged material. If you received this in error, please contact >> the sender immediately and then destroy this transmission, including >> all attachments, without copying, distributing or disclosing same. >> Thank you." >> >> >> > According to L3, this issue should be fixed and we should start seeing the traffic normalizing. Can anyone confirm? From sangreviento at gmail.com Sun Dec 28 12:35:45 2008 From: sangreviento at gmail.com (Jason Cheslock) Date: Sun, 28 Dec 2008 13:35:45 -0500 Subject: Level 3 issues In-Reply-To: <4957C5CE.5040106@zero11.com> References: <4957BE4A.3080008@zero11.com> <4957C012.4050205@gmail.com> <89D27DE3375BB6428DDCC2927489826A01DDCA33@nexus.nexicomgroup.net> <4957C453.7070406@gtcomm.net> <4957C5CE.5040106@zero11.com> Message-ID: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> According to L3, this issue should be fixed and we should start seeing > the traffic normalizing. > Can anyone confirm? Here in Richmond Virginia, everything seems to be back to normal now. Traffic coming from my Comcast connection can get through L3 now. 7 11 ms 13 ms 11 ms te-0-3-0-0-cr01.mclean.va.ibone.comcast.net [68. 86.91.121] 8 10 ms 11 ms 12 ms xe-11-1-0.edge1.Washington1.Level3.net [4.79.231 .9] 9 12 ms 17 ms 18 ms vlan89.csw3.Washington1.Level3.net [4.68.17.190] 10 12 ms 17 ms 17 ms ae-84-84.ebr4.Washington1.Level3.net [4.69.134.1 85] 11 16 ms 26 ms 16 ms ae-3-3.ebr1.NewYork1.Level3.net [4.69.132.94] 12 32 ms 30 ms 17 ms ae-81-81.csw3.NewYork1.Level3.net [4.69.134.74] 13 15 ms 19 ms 16 ms ae-3-89.edge1.NewYork1.Level3.net [4.68.16.142] From jdenoy at jdlabs.fr Sun Dec 28 12:39:39 2008 From: jdenoy at jdlabs.fr (Johan Denoyer) Date: Sun, 28 Dec 2008 19:39:39 +0100 Subject: Level 3 issues In-Reply-To: <4957C5CE.5040106@zero11.com> References: <4957BE4A.3080008@zero11.com> <4957C012.4050205@gmail.com> <89D27DE3375BB6428DDCC2927489826A01DDCA33@nexus.nexicomgroup.net> <4957C453.7070406@gtcomm.net> <4957C5CE.5040106@zero11.com> Message-ID: 2008/12/28 marco > Paul wrote: > > Same issue here from Chicago and Montreal. Seems anything routing > > through Washington.Level3 is going to null. The rest of the level3 > > network seems to be ok. > > 6 ae-32-52.ebr2.Chicago1.Level3.net (4.68.101.62) 0.976 ms 10.344 > > ms 0.866 ms > > 7 ae-5.ebr2.Chicago2.Level3.net (4.69.140.194) 1.245 ms 0.991 ms > > 0.978 ms > > 8 ae-2-2.ebr2.Washington1.Level3.net (4.69.132.70) 18.608 ms 18.961 > > ms 18.583 ms > > 9 * * * > > 10 * * * > > 11 * * * > > 12 * * * > > 13 * * * > > 14 * * * > > 15 * * * > > 16 * * * > > > > ... > > 4 car1.Montreal2.Level3.net (67.215.0.146) 0.657 ms 0.791 ms 0.699 > ms > > 5 ae-5-5.ebr4.NewYork1.Level3.net (4.69.141.6) 17.764 ms 8.490 ms > > 18.197 ms > > 6 ae-94-94.csw4.NewYork1.Level3.net (4.69.134.126) 15.541 ms 8.286 > > ms 17.098 ms > > 7 ae-93-93.ebr3.NewYork1.Level3.net (4.69.134.109) 11.384 ms > > ae-61-61.ebr1.NewYork1.Level3.net (4.69.134.65) 9.100 ms 8.614 ms > > 8 ae-3-3.ebr4.Washington1.Level3.net (4.69.132.93) 13.840 ms 15.584 > > ms 17.443 ms > > 9 ae-94-94.csw4.Washington1.Level3.net (4.69.134.190) 23.420 ms > > 25.569 ms 18.042 ms > > 10 ae-4-99.edge2.Washington4.Level3.net (4.68.17.211) 14.052 ms > > 14.028 ms 13.610 ms > > 11 * * * > > 12 * * * > > 13 * * * > > 14 * * * > > 15 * > > > > > > Paul Stewart wrote: > >> Ahh.. yes seeing that now here from Toronto ON - didn't see this > >> issue when the original poster sent the first message... it's now > >> happening here too... > >> > >> Shutting down their session until something looks "better" > >> > >> -----Original Message----- > >> From: Pierre-Henri [mailto:phach34 at gmail.com] Sent: December 28, 2008 > >> 1:06 PM > >> To: marco > >> Cc: nanog at nanog.org > >> Subject: Re: Level 3 issues > >> > >> marco a ?crit : > >> > >>> is anyone having issues with Level3? > >>> > >>> > >> hi, > >> theplanet.com and many websites (cnn.com ; amazon.com ; ... ) have > >> not been accessible from France (Orange, home connection) for about > >> 30 minutes. > >> Don't know if there is a link with your question, but it's strange... > >> > >> > >> Pierre-Henri > >> > >> > >> > >> > >> > >> > ---------------------------------------------------------------------------- > >> > >> > >> "The information transmitsted is intended only for the person or > >> entity to which it is addressed and contains confidential and/or > >> privileged material. If you received this in error, please contact > >> the sender immediately and then destroy this transmission, including > >> all attachments, without copying, distributing or disclosing same. > >> Thank you." > >> > >> > >> > > > According to L3, this issue should be fixed and we should start seeing > the traffic normalizing. > Can anyone confirm? > > Everything seems to be back to normal in France -- Johan Denoyer jdenoy at jdlabs.fr JD Labs Linkedin: www.linkedin.com/in/jdenoy From jon at defenderhosting.com Sun Dec 28 12:40:09 2008 From: jon at defenderhosting.com (Jon Wolberg) Date: Sun, 28 Dec 2008 13:40:09 -0500 (EST) Subject: Level 3 issues In-Reply-To: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> Message-ID: <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> Confirmed here as well. Jon ----- Original Message ----- From: "Jason Cheslock" To: "marco" Cc: nanog at nanog.org Sent: Sunday, December 28, 2008 1:35:45 PM GMT -05:00 US/Canada Eastern Subject: Re: Level 3 issues According to L3, this issue should be fixed and we should start seeing > the traffic normalizing. > Can anyone confirm? Here in Richmond Virginia, everything seems to be back to normal now. Traffic coming from my Comcast connection can get through L3 now. 7 11 ms 13 ms 11 ms te-0-3-0-0-cr01.mclean.va.ibone.comcast.net [68. 86.91.121] 8 10 ms 11 ms 12 ms xe-11-1-0.edge1.Washington1.Level3.net [4.79.231 .9] 9 12 ms 17 ms 18 ms vlan89.csw3.Washington1.Level3.net [4.68.17.190] 10 12 ms 17 ms 17 ms ae-84-84.ebr4.Washington1.Level3.net [4.69.134.1 85] 11 16 ms 26 ms 16 ms ae-3-3.ebr1.NewYork1.Level3.net [4.69.132.94] 12 32 ms 30 ms 17 ms ae-81-81.csw3.NewYork1.Level3.net [4.69.134.74] 13 15 ms 19 ms 16 ms ae-3-89.edge1.NewYork1.Level3.net [4.68.16.142] From bpfankuch at cpgreeley.com Sun Dec 28 12:47:45 2008 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Sun, 28 Dec 2008 11:47:45 -0700 Subject: Level 3 issues In-Reply-To: <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> Message-ID: <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> Seems to be normalizing here in Colorado as well, however still having occasional packet loss to NY. -----Original Message----- From: Jon Wolberg [mailto:jon at defenderhosting.com] Sent: Sunday, December 28, 2008 11:40 AM To: Jason Cheslock Cc: nanog at nanog.org Subject: Re: Level 3 issues Confirmed here as well. Jon ----- Original Message ----- From: "Jason Cheslock" To: "marco" Cc: nanog at nanog.org Sent: Sunday, December 28, 2008 1:35:45 PM GMT -05:00 US/Canada Eastern Subject: Re: Level 3 issues According to L3, this issue should be fixed and we should start seeing > the traffic normalizing. > Can anyone confirm? Here in Richmond Virginia, everything seems to be back to normal now. Traffic coming from my Comcast connection can get through L3 now. 7 11 ms 13 ms 11 ms te-0-3-0-0-cr01.mclean.va.ibone.comcast.net [68. 86.91.121] 8 10 ms 11 ms 12 ms xe-11-1-0.edge1.Washington1.Level3.net [4.79.231 .9] 9 12 ms 17 ms 18 ms vlan89.csw3.Washington1.Level3.net [4.68.17.190] 10 12 ms 17 ms 17 ms ae-84-84.ebr4.Washington1.Level3.net [4.69.134.1 85] 11 16 ms 26 ms 16 ms ae-3-3.ebr1.NewYork1.Level3.net [4.69.132.94] 12 32 ms 30 ms 17 ms ae-81-81.csw3.NewYork1.Level3.net [4.69.134.74] 13 15 ms 19 ms 16 ms ae-3-89.edge1.NewYork1.Level3.net [4.68.16.142] From black at csulb.edu Sun Dec 28 12:47:45 2008 From: black at csulb.edu (Matthew Black) Date: Sun, 28 Dec 2008 10:47:45 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: <4956172E.1070706@airwire.ie> References: <200812270110.mBR1ADCu011589@aurora.sol.net> <4955A406.4000901@west.net> <4955C446.3080204@vaxination.ca> <4956172E.1070706@airwire.ie> Message-ID: On Sat, 27 Dec 2008 11:53:18 +0000 Martin List-Petersen wrote: > > The problem is, and this was stated by the original poster, that the > lads off-shore he deals with have no clue and simply stick to the > script. No intention of looking what the real problem is. And that > problem lies not in the call center. It is the deal, that $TELCO struck > with $CALLCENTER and the procedures, that were put in place, that are > the problem. > > Only solution: find a provider, who's support (off-shore or not) does > have a clue, has an escalation process and is willing to find a solution. How does one find such a provider? I'm unaware of any company that lets potential customers test drive their $SERVICE call center before purchase. Even if one did, how is a potential customer supposed to evaluate the competence of said call center when customer has no clue as to what problems may arise 5 years after purchase of provider's service, whether said test drive provided an accurate and appropriate solution, and whether said call center quality will exist 5 years after purchase of the service. matthew black long beach, ca From subscribedlists at derekbodner.com Sun Dec 28 12:53:28 2008 From: subscribedlists at derekbodner.com (Derek Bodner) Date: Sun, 28 Dec 2008 13:53:28 -0500 Subject: Level 3 issues In-Reply-To: <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> Message-ID: <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> Looks like most providers here in the east coast are routing through level3 again, and I'm not seeing any packet loss or latency anymore. On Sun, Dec 28, 2008 at 1:47 PM, Blake Pfankuch wrote: > Seems to be normalizing here in Colorado as well, however still having > occasional packet loss to NY. > > -----Original Message----- > From: Jon Wolberg [mailto:jon at defenderhosting.com] > Sent: Sunday, December 28, 2008 11:40 AM > To: Jason Cheslock > Cc: nanog at nanog.org > Subject: Re: Level 3 issues > > Confirmed here as well. > > > Jon > > > ----- Original Message ----- > From: "Jason Cheslock" > To: "marco" > Cc: nanog at nanog.org > Sent: Sunday, December 28, 2008 1:35:45 PM GMT -05:00 US/Canada Eastern > Subject: Re: Level 3 issues > > According to L3, this issue should be fixed and we should start seeing > > > the traffic normalizing. > > Can anyone confirm? > > Here in Richmond Virginia, everything seems to be back to normal now. > Traffic coming from my Comcast connection can get through L3 now. > > > 7 11 ms 13 ms 11 ms te-0-3-0-0-cr01.mclean.va.ibone.comcast.net [68. > 86.91.121] > 8 10 ms 11 ms 12 ms xe-11-1-0.edge1.Washington1.Level3.net [4.79.231 > .9] > 9 12 ms 17 ms 18 ms vlan89.csw3.Washington1.Level3.net [4.68.17.190] > > 10 12 ms 17 ms 17 ms ae-84-84.ebr4.Washington1.Level3.net [4.69.134.1 > 85] > 11 16 ms 26 ms 16 ms ae-3-3.ebr1.NewYork1.Level3.net [4.69.132.94] > 12 32 ms 30 ms 17 ms ae-81-81.csw3.NewYork1.Level3.net [4.69.134.74] > > 13 15 ms 19 ms 16 ms ae-3-89.edge1.NewYork1.Level3.net [4.68.16.142] > > -- Derek Bodner subscribedlists at derekbodner.com From bpfankuch at cpgreeley.com Sun Dec 28 12:56:03 2008 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Sun, 28 Dec 2008 11:56:03 -0700 Subject: Level 3 issues In-Reply-To: <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> Message-ID: <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> Any word on the actual cause of the issue? From: Derek Bodner [mailto:subscribedlists at derekbodner.com] Sent: Sunday, December 28, 2008 11:53 AM To: Blake Pfankuch Cc: Jon Wolberg; Jason Cheslock; nanog at nanog.org Subject: Re: Level 3 issues Looks like most providers here in the east coast are routing through level3 again, and I'm not seeing any packet loss or latency anymore. On Sun, Dec 28, 2008 at 1:47 PM, Blake Pfankuch > wrote: Seems to be normalizing here in Colorado as well, however still having occasional packet loss to NY. -----Original Message----- From: Jon Wolberg [mailto:jon at defenderhosting.com] Sent: Sunday, December 28, 2008 11:40 AM To: Jason Cheslock Cc: nanog at nanog.org Subject: Re: Level 3 issues Confirmed here as well. Jon ----- Original Message ----- From: "Jason Cheslock" > To: "marco" > Cc: nanog at nanog.org Sent: Sunday, December 28, 2008 1:35:45 PM GMT -05:00 US/Canada Eastern Subject: Re: Level 3 issues According to L3, this issue should be fixed and we should start seeing > the traffic normalizing. > Can anyone confirm? Here in Richmond Virginia, everything seems to be back to normal now. Traffic coming from my Comcast connection can get through L3 now. 7 11 ms 13 ms 11 ms te-0-3-0-0-cr01.mclean.va.ibone.comcast.net [68. 86.91.121] 8 10 ms 11 ms 12 ms xe-11-1-0.edge1.Washington1.Level3.net [4.79.231 .9] 9 12 ms 17 ms 18 ms vlan89.csw3.Washington1.Level3.net [4.68.17.190] 10 12 ms 17 ms 17 ms ae-84-84.ebr4.Washington1.Level3.net [4.69.134.1 85] 11 16 ms 26 ms 16 ms ae-3-3.ebr1.NewYork1.Level3.net [4.69.132.94] 12 32 ms 30 ms 17 ms ae-81-81.csw3.NewYork1.Level3.net [4.69.134.74] 13 15 ms 19 ms 16 ms ae-3-89.edge1.NewYork1.Level3.net [4.68.16.142] -- Derek Bodner subscribedlists at derekbodner.com From sethm at rollernet.us Sun Dec 28 13:05:28 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 28 Dec 2008 11:05:28 -0800 Subject: What to do when your ISP off-shores tech support In-Reply-To: References: <200812270110.mBR1ADCu011589@aurora.sol.net> <4955A406.4000901@west.net> <4955C446.3080204@vaxination.ca> <4956172E.1070706@airwire.ie> Message-ID: <4957CDF8.4020404@rollernet.us> Matthew Black wrote: > On Sat, 27 Dec 2008 11:53:18 +0000 > Martin List-Petersen wrote: >> >> The problem is, and this was stated by the original poster, that the >> lads off-shore he deals with have no clue and simply stick to the >> script. No intention of looking what the real problem is. And that >> problem lies not in the call center. It is the deal, that $TELCO struck >> with $CALLCENTER and the procedures, that were put in place, that are >> the problem. >> >> Only solution: find a provider, who's support (off-shore or not) does >> have a clue, has an escalation process and is willing to find a solution. > > > How does one find such a provider? I'm unaware of any company > that lets potential customers test drive their $SERVICE call center > before purchase. Even if one did, how is a potential customer > supposed to evaluate the competence of said call center when > customer has no clue as to what problems may arise 5 years after > purchase of provider's service, whether said test drive provided > an accurate and appropriate solution, and whether said call center > quality will exist 5 years after purchase of the service. > Ask people for recomendations. There were several early in this thread you dismissed (i.e. dslextreme) because they weren't a CLEC or were too expensive. ~Seth From marco at zero11.com Sun Dec 28 13:11:13 2008 From: marco at zero11.com (marco) Date: Sun, 28 Dec 2008 11:11:13 -0800 Subject: Level 3 issues In-Reply-To: <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> Message-ID: <4957CF51.30003@zero11.com> Blake Pfankuch wrote: > Any word on the actual cause of the issue? > > From: Derek Bodner [mailto:subscribedlists at derekbodner.com] > Sent: Sunday, December 28, 2008 11:53 AM > To: Blake Pfankuch > Cc: Jon Wolberg; Jason Cheslock; nanog at nanog.org > Subject: Re: Level 3 issues > > Looks like most providers here in the east coast are routing through level3 again, and I'm not seeing any packet loss or latency anymore. > On Sun, Dec 28, 2008 at 1:47 PM, Blake Pfankuch > wrote: > Seems to be normalizing here in Colorado as well, however still having occasional packet loss to NY. > > -----Original Message----- > From: Jon Wolberg [mailto:jon at defenderhosting.com] > Sent: Sunday, December 28, 2008 11:40 AM > To: Jason Cheslock > Cc: nanog at nanog.org > Subject: Re: Level 3 issues > > Confirmed here as well. > > > Jon > > > ----- Original Message ----- > From: "Jason Cheslock" > > To: "marco" > > Cc: nanog at nanog.org > Sent: Sunday, December 28, 2008 1:35:45 PM GMT -05:00 US/Canada Eastern > Subject: Re: Level 3 issues > > According to L3, this issue should be fixed and we should start seeing > > >> the traffic normalizing. >> Can anyone confirm? >> > > Here in Richmond Virginia, everything seems to be back to normal now. > Traffic coming from my Comcast connection can get through L3 now. > > > 7 11 ms 13 ms 11 ms te-0-3-0-0-cr01.mclean.va.ibone.comcast.net [68. > 86.91.121] > 8 10 ms 11 ms 12 ms xe-11-1-0.edge1.Washington1.Level3.net [4.79.231 > .9] > 9 12 ms 17 ms 18 ms vlan89.csw3.Washington1.Level3.net [4.68.17.190] > > 10 12 ms 17 ms 17 ms ae-84-84.ebr4.Washington1.Level3.net [4.69.134.1 > 85] > 11 16 ms 26 ms 16 ms ae-3-3.ebr1.NewYork1.Level3.net [4.69.132.94] > 12 32 ms 30 ms 17 ms ae-81-81.csw3.NewYork1.Level3.net [4.69.134.74] > > 13 15 ms 19 ms 16 ms ae-3-89.edge1.NewYork1.Level3.net [4.68.16.142] > > > > -- > Derek Bodner > subscribedlists at derekbodner.com > >From what I heard, it was some some malfunction with a router in Washington D.C. which terminated a 100GB bundle from Paris. It was carring about 50GB at the time of the failure. Not sure why routes within the US would be effected. From mpetach at netflight.com Sun Dec 28 13:21:50 2008 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 28 Dec 2008 11:21:50 -0800 Subject: Level 3 issues In-Reply-To: <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> Message-ID: <63ac96a50812281121r31aabf91s55fde55176d2cb72@mail.gmail.com> On 12/28/08, Blake Pfankuch wrote: > Any word on the actual cause of the issue? Given the lurking presence of wannabe press vultures here, I doubt you'll see anything forthcoming from the technical folks about what actually happened. This is not to say that people haven't been informed of the issue, it's simply that NANOG is no longer a friendly hapy techie-only place where such information can be shared without it being seized on and quoted without permission by the press. Bitter? Just a bit, yes. After having what I mentioned here get quoted by the press without permission, it's very clear that there will be no more technical commentary/feedback/information flow through this channel from me or any of the other people at the company for which I work, more's the pity. If you can find a forum where engineers can share information freely without having to worry about being quoted by the press, you might try enquiring there. ^_^; Matt From kloch at kl.net Sun Dec 28 13:21:57 2008 From: kloch at kl.net (Kevin Loch) Date: Sun, 28 Dec 2008 14:21:57 -0500 Subject: Level 3 issues In-Reply-To: <4957CF51.30003@zero11.com> References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> <4957CF51.30003@zero11.com> Message-ID: <4957D1D5.6060702@kl.net> marco wrote: >>From what I heard, it was some some malfunction with a router in > Washington D.C. which terminated a 100GB bundle from Paris. It was > carring about 50GB at the time of the failure. > > Not sure why routes within the US would be effected. We connect to level3 in Ashburn/DC and saw traffic drop 50% in both directions on that port. Testing showed 100% loss on 50% of the flows. We shut that port down and now it won't come back up. I have link but no arp for their IP. This is a new link that was turned up in the past few weeks. - Kevin From sking at kingrst.com Sun Dec 28 13:32:26 2008 From: sking at kingrst.com (Steven King) Date: Sun, 28 Dec 2008 14:32:26 -0500 Subject: Level 3 issues In-Reply-To: <4957D1D5.6060702@kl.net> References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> <4957CF51.30003@zero11.com> <4957D1D5.6060702@kl.net> Message-ID: <4957D44A.7050005@kingrst.com> We saw our bandwidth drop on our Level3 OC-48 to about half of what we were doing. We had to stop announcing our subnets to Level3 to get traffic to fail over properly throughout the world. We have a ticket open with Level3's NOC but have not received word on what happened or when to expect a resolution. Kevin Loch wrote: > marco wrote: > >>> From what I heard, it was some some malfunction with a router in >> Washington D.C. which terminated a 100GB bundle from Paris. It was >> carring about 50GB at the time of the failure. >> >> Not sure why routes within the US would be effected. > > We connect to level3 in Ashburn/DC and saw traffic drop 50% in both > directions on that port. Testing showed 100% loss on 50% of the > flows. We shut that port down and now it won't come back up. I have > link but no arp for their IP. This is a new link that was turned > up in the past few weeks. > > - Kevin > -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From marco at zero11.com Sun Dec 28 13:47:23 2008 From: marco at zero11.com (marco) Date: Sun, 28 Dec 2008 11:47:23 -0800 Subject: Level 3 issues In-Reply-To: <4957D44A.7050005@kingrst.com> References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> <4957CF51.30003@zero11.com> <4957D1D5.6060702@kl.net> <4957D44A.7050005@kingrst.com> Message-ID: <4957D7CB.4050707@zero11.com> Steven King wrote: > We saw our bandwidth drop on our Level3 OC-48 to about half of what we > were doing. We had to stop announcing our subnets to Level3 to get > traffic to fail over properly throughout the world. We have a ticket > open with Level3's NOC but have not received word on what happened or > when to expect a resolution. > > Kevin Loch wrote: > >> marco wrote: >> >> >>>> From what I heard, it was some some malfunction with a router in >>>> >>> Washington D.C. which terminated a 100GB bundle from Paris. It was >>> carring about 50GB at the time of the failure. >>> >>> Not sure why routes within the US would be effected. >>> >> We connect to level3 in Ashburn/DC and saw traffic drop 50% in both >> directions on that port. Testing showed 100% loss on 50% of the >> flows. We shut that port down and now it won't come back up. I have >> link but no arp for their IP. This is a new link that was turned >> up in the past few weeks. >> >> - Kevin >> http://www.internetpulse.net/Main.aspx shows that everything is back to normal. From trejrco at gmail.com Sun Dec 28 14:41:46 2008 From: trejrco at gmail.com (TJ) Date: Sun, 28 Dec 2008 15:41:46 -0500 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: <49578BCF.3060805@psg.com> References: <200812271833.10233.mtinka@globaltransit.net> <49562D29.8030003@psg.com> <200812281300.34387.mtinka@globaltransit.net> <001a01c968f6$1c26acf0$547406d0$@com> <49578BCF.3060805@psg.com> Message-ID: <003301c9692c$b3b2d950$1b188bf0$@com> >>> In practice, we realized that enabling IS-ISv6 on interfaces >>> already running IS-ISv4 was problematic without MT pre- >>> configured. >>> Those links surely lost IS-IS adjacency which threatened stability >>> of the network. >> Yup, that is the rub: if rolling out your v6 routing impacts your v4 >> routing you are not "winning". > >this is not very deep. Is it untrue? > >mark did point out how to avoid it, pointing out why mt was very useful >as opposed to just another bell and whistle. during a transition, in >fact, topologies are not congruent due to inability to have a flag >millisecond, a very very useful observation. Indeed, and not creating the problem is good thing. I don't think we are disagreeing on anything here ... Although I don't believe anyone has mentioned "multi-topology" + "transition" just yet, the goal being that when you go from ST to MT (assuming you aren't already there, that is) you don't impact ongoing operations / neighborships. /TJ From virendra.rode at gmail.com Sun Dec 28 14:44:04 2008 From: virendra.rode at gmail.com (virendra rode) Date: Sun, 28 Dec 2008 12:44:04 -0800 Subject: Level 3 issues In-Reply-To: <63ac96a50812281121r31aabf91s55fde55176d2cb72@mail.gmail.com> References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> <63ac96a50812281121r31aabf91s55fde55176d2cb72@mail.gmail.com> Message-ID: <4957E514.1090203@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 IMHO, this is exactly what service providers love to hear in order for them not to be forth coming. regards, /virendra Matthew Petach wrote: > On 12/28/08, Blake Pfankuch wrote: >> Any word on the actual cause of the issue? > > Given the lurking presence of wannabe press vultures here, I > doubt you'll see anything forthcoming from the technical folks > about what actually happened. This is not to say that people > haven't been informed of the issue, it's simply that NANOG is > no longer a friendly hapy techie-only place where such information > can be shared without it being seized on and quoted without > permission by the press. > > Bitter? Just a bit, yes. After having what I mentioned here get > quoted by the press without permission, it's very clear that there > will be no more technical commentary/feedback/information flow > through this channel from me or any of the other people at the > company for which I work, more's the pity. If you can find a > forum where engineers can share information freely without > having to worry about being quoted by the press, you might > try enquiring there. ^_^; > > Matt > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJV+UUpbZvCIJx1bcRAoxfAKCFn9inJ1Pq2Z0W9uuu1YeMGjf0LACeJVca GkejywYfBp2yUjTFJwrOLFU= =d1BQ -----END PGP SIGNATURE----- From martin at airwire.ie Sun Dec 28 14:59:19 2008 From: martin at airwire.ie (Martin List-Petersen) Date: Sun, 28 Dec 2008 20:59:19 +0000 Subject: What to do when your ISP off-shores tech support In-Reply-To: References: <200812270110.mBR1ADCu011589@aurora.sol.net> <4955A406.4000901@west.net> <4955C446.3080204@vaxination.ca> <4956172E.1070706@airwire.ie> Message-ID: <4957E8A7.9020804@airwire.ie> Matthew Black wrote: > On Sat, 27 Dec 2008 11:53:18 +0000 > Martin List-Petersen wrote: >> >> The problem is, and this was stated by the original poster, that the >> lads off-shore he deals with have no clue and simply stick to the >> script. No intention of looking what the real problem is. And that >> problem lies not in the call center. It is the deal, that $TELCO struck >> with $CALLCENTER and the procedures, that were put in place, that are >> the problem. >> >> Only solution: find a provider, who's support (off-shore or not) does >> have a clue, has an escalation process and is willing to find a solution. > > > How does one find such a provider? I'm unaware of any company > that lets potential customers test drive their $SERVICE call center > before purchase. Ask others for their experience :), like for example here. > Even if one did, how is a potential customer > supposed to evaluate the competence of said call center when > customer has no clue as to what problems may arise 5 years after > purchase of provider's service, whether said test drive provided > an accurate and appropriate solution, and whether said call center > quality will exist 5 years after purchase of the service. Well, if you're not any happy longer with the service, vote with your feet again and find a better option. It's as easy as that. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From Skywing at valhallalegends.com Sun Dec 28 15:08:01 2008 From: Skywing at valhallalegends.com (Skywing) Date: Sun, 28 Dec 2008 15:08:01 -0600 Subject: What to do when your ISP off-shores tech support In-Reply-To: <4957E8A7.9020804@airwire.ie> References: <200812270110.mBR1ADCu011589@aurora.sol.net> <4955A406.4000901@west.net> <4955C446.3080204@vaxination.ca> <4956172E.1070706@airwire.ie> <4957E8A7.9020804@airwire.ie> Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA2A5D2@caralain.haven.nynaeve.net> Of course, in much of the US, "vote with your feet" on residential ISP service might as well be as realistic advice as "pack up and move to a different city". [Perhaps not in the OP's case, though, if they are fortunate. Which it seems like they might be.] - S -----Original Message----- From: Martin List-Petersen [mailto:martin at airwire.ie] Sent: Sunday, December 28, 2008 3:59 PM To: Matthew Black Cc: nanog at nanog.org Subject: Re: What to do when your ISP off-shores tech support Matthew Black wrote: > On Sat, 27 Dec 2008 11:53:18 +0000 > Martin List-Petersen wrote: >> >> The problem is, and this was stated by the original poster, that the >> lads off-shore he deals with have no clue and simply stick to the >> script. No intention of looking what the real problem is. And that >> problem lies not in the call center. It is the deal, that $TELCO struck >> with $CALLCENTER and the procedures, that were put in place, that are >> the problem. >> >> Only solution: find a provider, who's support (off-shore or not) does >> have a clue, has an escalation process and is willing to find a solution. > > > How does one find such a provider? I'm unaware of any company > that lets potential customers test drive their $SERVICE call center > before purchase. Ask others for their experience :), like for example here. > Even if one did, how is a potential customer > supposed to evaluate the competence of said call center when > customer has no clue as to what problems may arise 5 years after > purchase of provider's service, whether said test drive provided > an accurate and appropriate solution, and whether said call center > quality will exist 5 years after purchase of the service. Well, if you're not any happy longer with the service, vote with your feet again and find a better option. It's as easy as that. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From martin at airwire.ie Sun Dec 28 15:20:27 2008 From: martin at airwire.ie (Martin List-Petersen) Date: Sun, 28 Dec 2008 21:20:27 +0000 Subject: What to do when your ISP off-shores tech support In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA2A5D2@caralain.haven.nynaeve.net> References: <200812270110.mBR1ADCu011589@aurora.sol.net> <4955A406.4000901@west.net> <4955C446.3080204@vaxination.ca> <4956172E.1070706@airwire.ie> <4957E8A7.9020804@airwire.ie> <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA2A5D2@caralain.haven.nynaeve.net> Message-ID: <4957ED9B.3090700@airwire.ie> Skywing wrote: > Of course, in much of the US, "vote with your feet" on residential ISP service might as well be as realistic advice as "pack up and move to a different city". [Perhaps not in the OP's case, though, if they are fortunate. Which it seems like they might be.] It isn't different here either :) Solution: if there is no alternative, it might be an idea to create one. We had to do that here and works like a treat. You might find, that you get more custom, that you wished for. Kind regards, Martin List-Petersen > > - S > > -----Original Message----- > From: Martin List-Petersen [mailto:martin at airwire.ie] > Sent: Sunday, December 28, 2008 3:59 PM > To: Matthew Black > Cc: nanog at nanog.org > Subject: Re: What to do when your ISP off-shores tech support > > Matthew Black wrote: >> On Sat, 27 Dec 2008 11:53:18 +0000 >> Martin List-Petersen wrote: >>> The problem is, and this was stated by the original poster, that the >>> lads off-shore he deals with have no clue and simply stick to the >>> script. No intention of looking what the real problem is. And that >>> problem lies not in the call center. It is the deal, that $TELCO struck >>> with $CALLCENTER and the procedures, that were put in place, that are >>> the problem. >>> >>> Only solution: find a provider, who's support (off-shore or not) does >>> have a clue, has an escalation process and is willing to find a solution. >> >> How does one find such a provider? I'm unaware of any company >> that lets potential customers test drive their $SERVICE call center >> before purchase. > > > Ask others for their experience :), like for example here. > > >> Even if one did, how is a potential customer >> supposed to evaluate the competence of said call center when >> customer has no clue as to what problems may arise 5 years after >> purchase of provider's service, whether said test drive provided >> an accurate and appropriate solution, and whether said call center >> quality will exist 5 years after purchase of the service. > > > Well, if you're not any happy longer with the service, vote with your > feet again and find a better option. It's as easy as that. > > Kind regards, > Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968 From r.hyunseog at ieee.org Sun Dec 28 15:43:42 2008 From: r.hyunseog at ieee.org (Alex H. Ryu) Date: Sun, 28 Dec 2008 15:43:42 -0600 Subject: Level 3 issues In-Reply-To: <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> Message-ID: <4957F30E.8030701@ieee.org> It seems that there was fiber cut because of train derailment around NY area. Alex Blake Pfankuch wrote: > Any word on the actual cause of the issue? > > From: Derek Bodner [mailto:subscribedlists at derekbodner.com] > Sent: Sunday, December 28, 2008 11:53 AM > To: Blake Pfankuch > Cc: Jon Wolberg; Jason Cheslock; nanog at nanog.org > Subject: Re: Level 3 issues > > Looks like most providers here in the east coast are routing through level3 again, and I'm not seeing any packet loss or latency anymore. > On Sun, Dec 28, 2008 at 1:47 PM, Blake Pfankuch > wrote: > Seems to be normalizing here in Colorado as well, however still having occasional packet loss to NY. > > -----Original Message----- > From: Jon Wolberg [mailto:jon at defenderhosting.com] > Sent: Sunday, December 28, 2008 11:40 AM > To: Jason Cheslock > Cc: nanog at nanog.org > Subject: Re: Level 3 issues > > Confirmed here as well. > > > Jon > > > ----- Original Message ----- > From: "Jason Cheslock" > > To: "marco" > > Cc: nanog at nanog.org > Sent: Sunday, December 28, 2008 1:35:45 PM GMT -05:00 US/Canada Eastern > Subject: Re: Level 3 issues > > According to L3, this issue should be fixed and we should start seeing > > >> the traffic normalizing. >> Can anyone confirm? >> > > Here in Richmond Virginia, everything seems to be back to normal now. > Traffic coming from my Comcast connection can get through L3 now. > > > 7 11 ms 13 ms 11 ms te-0-3-0-0-cr01.mclean.va.ibone.comcast.net [68. > 86.91.121] > 8 10 ms 11 ms 12 ms xe-11-1-0.edge1.Washington1.Level3.net [4.79.231 > .9] > 9 12 ms 17 ms 18 ms vlan89.csw3.Washington1.Level3.net [4.68.17.190] > > 10 12 ms 17 ms 17 ms ae-84-84.ebr4.Washington1.Level3.net [4.69.134.1 > 85] > 11 16 ms 26 ms 16 ms ae-3-3.ebr1.NewYork1.Level3.net [4.69.132.94] > 12 32 ms 30 ms 17 ms ae-81-81.csw3.NewYork1.Level3.net [4.69.134.74] > > 13 15 ms 19 ms 16 ms ae-3-89.edge1.NewYork1.Level3.net [4.68.16.142] > > > > -- > Derek Bodner > subscribedlists at derekbodner.com > > > > From bpfankuch at cpgreeley.com Sun Dec 28 16:17:40 2008 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Sun, 28 Dec 2008 15:17:40 -0700 Subject: Level 3 issues In-Reply-To: <4957F30E.8030701@ieee.org> References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> <4957F30E.8030701@ieee.org> Message-ID: <01759D50DC387C45A018FE1817CE27D7540C2B5FE8@CPExchange1.cpgreeley.com> I have heard this story several times. The train derailment was yesterday in New York unless it has not made it to news.google.com on a search for train derail. Issues did not start until 1030 MST. It seems highly unlikely that a train derailment yesterday caused major network issues today. -----Original Message----- From: Alex H. Ryu [mailto:r.hyunseog at ieee.org] Sent: Sunday, December 28, 2008 2:44 PM To: Blake Pfankuch Cc: Derek Bodner; nanog at nanog.org Subject: Re: Level 3 issues It seems that there was fiber cut because of train derailment around NY area. Alex Blake Pfankuch wrote: > Any word on the actual cause of the issue? > > From: Derek Bodner [mailto:subscribedlists at derekbodner.com] > Sent: Sunday, December 28, 2008 11:53 AM > To: Blake Pfankuch > Cc: Jon Wolberg; Jason Cheslock; nanog at nanog.org > Subject: Re: Level 3 issues > > Looks like most providers here in the east coast are routing through level3 again, and I'm not seeing any packet loss or latency anymore. > On Sun, Dec 28, 2008 at 1:47 PM, Blake Pfankuch > wrote: > Seems to be normalizing here in Colorado as well, however still having occasional packet loss to NY. > > -----Original Message----- > From: Jon Wolberg [mailto:jon at defenderhosting.com] > Sent: Sunday, December 28, 2008 11:40 AM > To: Jason Cheslock > Cc: nanog at nanog.org > Subject: Re: Level 3 issues > > Confirmed here as well. > > > Jon > > > ----- Original Message ----- > From: "Jason Cheslock" > > To: "marco" > > Cc: nanog at nanog.org > Sent: Sunday, December 28, 2008 1:35:45 PM GMT -05:00 US/Canada Eastern > Subject: Re: Level 3 issues > > According to L3, this issue should be fixed and we should start seeing > > >> the traffic normalizing. >> Can anyone confirm? >> > > Here in Richmond Virginia, everything seems to be back to normal now. > Traffic coming from my Comcast connection can get through L3 now. > > > 7 11 ms 13 ms 11 ms te-0-3-0-0-cr01.mclean.va.ibone.comcast.net [68. > 86.91.121] > 8 10 ms 11 ms 12 ms xe-11-1-0.edge1.Washington1.Level3.net [4.79.231 > .9] > 9 12 ms 17 ms 18 ms vlan89.csw3.Washington1.Level3.net [4.68.17.190] > > 10 12 ms 17 ms 17 ms ae-84-84.ebr4.Washington1.Level3.net [4.69.134.1 > 85] > 11 16 ms 26 ms 16 ms ae-3-3.ebr1.NewYork1.Level3.net [4.69.132.94] > 12 32 ms 30 ms 17 ms ae-81-81.csw3.NewYork1.Level3.net [4.69.134.74] > > 13 15 ms 19 ms 16 ms ae-3-89.edge1.NewYork1.Level3.net [4.68.16.142] > > > > -- > Derek Bodner > subscribedlists at derekbodner.com > > > > From yahoo at jimpop.com Sun Dec 28 16:20:58 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Sun, 28 Dec 2008 17:20:58 -0500 Subject: Level 3 issues In-Reply-To: <01759D50DC387C45A018FE1817CE27D7540C2B5FE8@CPExchange1.cpgreeley.com> References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> <4957F30E.8030701@ieee.org> <01759D50DC387C45A018FE1817CE27D7540C2B5FE8@CPExchange1.cpgreeley.com> Message-ID: <7ff145960812281420u739330capf0c99a6f653b0900@mail.gmail.com> On Sun, Dec 28, 2008 at 17:17, Blake Pfankuch wrote: > It seems highly unlikely that a train derailment yesterday caused major network issues today. Have you ever seen cleanup efforts after a major accident. Cleanup usually involves more backhoes, and other major equipment, than a normal well planned construction site. -Jim P. From streiner at cluebyfour.org Sun Dec 28 22:53:15 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sun, 28 Dec 2008 23:53:15 -0500 (EST) Subject: Level 3 issues In-Reply-To: <7ff145960812281420u739330capf0c99a6f653b0900@mail.gmail.com> References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> <4957F30E.8030701@ieee.org> <01759D50DC387C45A018FE1817CE27D7540C2B5FE8@CPExchange1.cpgreeley.com> <7ff145960812281420u739330capf0c99a6f653b0900@mail.gmail.com> Message-ID: On Sun, 28 Dec 2008, Jim Popovitch wrote: > On Sun, Dec 28, 2008 at 17:17, Blake Pfankuch wrote: >> It seems highly unlikely that a train derailment yesterday caused major network issues today. > > Have you ever seen cleanup efforts after a major accident. Cleanup > usually involves more backhoes, and other major equipment, than a > normal well planned construction site. True enough. In their haste to clean up from that derailment, it's possible that the backhoes severed the other side of that diverse (cough) optical ring, which was probably on the other side of the same set of railroad tracks, if not in the same conduit/bank as the cable that got hit :) jms From rs at seastrom.com Mon Dec 29 06:36:21 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Mon, 29 Dec 2008 07:36:21 -0500 Subject: What to do when your ISP off-shores tech support In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA2A5BC@caralain.haven.nynaeve.net> (Skywing@valhallalegends.com's message of "Fri, 26 Dec 2008 22:36:52 -0600") References: <4955A406.4000901@west.net> <200812270417.mBR4HPbn018225@aurora.sol.net> <982D8D05B6407A49AD506E6C3AC8E7D6BFEEA2A5BC@caralain.haven.nynaeve.net> Message-ID: <864p0nxinu.fsf@seastrom.com> Skywing writes: > Always have to waste a minute for it to decide that it's going to > punt to a real person. It would be nice if there was a way to > bypass it. A lot (but not all) of them are implemented in such a way that they will yield encouraging results if you start dropping f-bombs on them. Avoiding an arrest for disorderly conduct if you are on your cell phone in public is left as an exercise to the reader. -r From rsk at gsp.org Mon Dec 29 07:20:22 2008 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 29 Dec 2008 08:20:22 -0500 Subject: Level 3 issues In-Reply-To: <63ac96a50812281121r31aabf91s55fde55176d2cb72@mail.gmail.com> References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> <63ac96a50812281121r31aabf91s55fde55176d2cb72@mail.gmail.com> Message-ID: <20081229132021.GA13832@gsp.org> On Sun, Dec 28, 2008 at 11:21:50AM -0800, Matthew Petach wrote: > Given the lurking presence of wannabe press vultures here, I > doubt you'll see anything forthcoming from the technical folks > about what actually happened. This is not to say that people > haven't been informed of the issue, it's simply that NANOG is > no longer a friendly hapy techie-only place where such information > can be shared without it being seized on and quoted without > permission by the press. It was good advice then; it's even better advice now: Never say anything in an electronic message that you wouldn't want appearing, and attributed to you, in tomorrow morning's front-page headline in the New York Times. --- Colonel David Russell, former head of DARPA's Information Processing Techniques Office ---Rsk From Jay.Murphy at state.nm.us Mon Dec 29 10:33:12 2008 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Mon, 29 Dec 2008 09:33:12 -0700 Subject: Level 3 issues In-Reply-To: <01759D50DC387C45A018FE1817CE27D7540C2B5FE8@CPExchange1.cpgreeley.com> References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com><697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com><01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com><1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com><01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com><4957F30E.8030701@ieee.org> <01759D50DC387C45A018FE1817CE27D7540C2B5FE8@CPExchange1.cpgreeley.com> Message-ID: You know, it gets pretty thick through here, when all you people slam on someone, to justify pent up angst or whatever the cause may be. I worked for Level 3 as a NOC engr, and they follow standards as other companies do, and for that matter a standard that I AM SURE all of you follow in some form, degree, or another within the employ you are with, so shut up already won't you. Give me a 10-minute break already. Half of the crap that you guys serve up is crap, just that, CRAP! Get to talking real 'net stuff, not filler, fodder, just facts man. Oh yeah the other thing, quit your whining. Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: Blake Pfankuch [mailto:bpfankuch at cpgreeley.com] Sent: Sunday, December 28, 2008 3:18 PM To: Alex H. Ryu Cc: nanog at nanog.org Subject: RE: Level 3 issues I have heard this story several times. The train derailment was yesterday in New York unless it has not made it to news.google.com on a search for train derail. Issues did not start until 1030 MST. It seems highly unlikely that a train derailment yesterday caused major network issues today. -----Original Message----- From: Alex H. Ryu [mailto:r.hyunseog at ieee.org] Sent: Sunday, December 28, 2008 2:44 PM To: Blake Pfankuch Cc: Derek Bodner; nanog at nanog.org Subject: Re: Level 3 issues It seems that there was fiber cut because of train derailment around NY area. Alex Blake Pfankuch wrote: > Any word on the actual cause of the issue? > > From: Derek Bodner [mailto:subscribedlists at derekbodner.com] > Sent: Sunday, December 28, 2008 11:53 AM > To: Blake Pfankuch > Cc: Jon Wolberg; Jason Cheslock; nanog at nanog.org > Subject: Re: Level 3 issues > > Looks like most providers here in the east coast are routing through level3 again, and I'm not seeing any packet loss or latency anymore. > On Sun, Dec 28, 2008 at 1:47 PM, Blake Pfankuch > wrote: > Seems to be normalizing here in Colorado as well, however still having occasional packet loss to NY. > > -----Original Message----- > From: Jon Wolberg > [mailto:jon at defenderhosting.com] > Sent: Sunday, December 28, 2008 11:40 AM > To: Jason Cheslock > Cc: nanog at nanog.org > Subject: Re: Level 3 issues > > Confirmed here as well. > > > Jon > > > ----- Original Message ----- > From: "Jason Cheslock" > > > To: "marco" > > Cc: nanog at nanog.org > Sent: Sunday, December 28, 2008 1:35:45 PM GMT -05:00 US/Canada > Eastern > Subject: Re: Level 3 issues > > According to L3, this issue should be fixed and we should start seeing > > >> the traffic normalizing. >> Can anyone confirm? >> > > Here in Richmond Virginia, everything seems to be back to normal now. > Traffic coming from my Comcast connection can get through L3 now. > > > 7 11 ms 13 ms 11 ms te-0-3-0-0-cr01.mclean.va.ibone.comcast.net [68. > 86.91.121] > 8 10 ms 11 ms 12 ms > xe-11-1-0.edge1.Washington1.Level3.net on1.Level3.net> [4.79.231 .9] > 9 12 ms 17 ms 18 ms > vlan89.csw3.Washington1.Level3.net l3.net> [4.68.17.190] > > 10 12 ms 17 ms 17 ms > ae-84-84.ebr4.Washington1.Level3.net Level3.net> [4.69.134.1 85] > 11 16 ms 26 ms 16 ms > ae-3-3.ebr1.NewYork1.Level3.net > [4.69.132.94] > 12 32 ms 30 ms 17 ms > ae-81-81.csw3.NewYork1.Level3.net .net> [4.69.134.74] > > 13 15 ms 19 ms 16 ms > ae-3-89.edge1.NewYork1.Level3.net .net> [4.68.16.142] > > > > -- > Derek Bodner > subscribedlists at derekbodner.com > > > > > ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From Jay.Murphy at state.nm.us Mon Dec 29 10:50:55 2008 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Mon, 29 Dec 2008 09:50:55 -0700 Subject: Level 3 issues In-Reply-To: <4957D1D5.6060702@kl.net> References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com><4957CF51.30003@zero11.com> <4957D1D5.6060702@kl.net> Message-ID: Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: Kevin Loch [mailto:kloch at kl.net] Sent: Sunday, December 28, 2008 12:22 PM Cc: nanog at nanog.org Subject: Re: Level 3 issues marco wrote: >>From what I heard, it was some some malfunction with a router in > Washington D.C. which terminated a 100GB bundle from Paris. It was > carring about 50GB at the time of the failure. > > Not sure why routes within the US would be effected. <<<<<<<<<<<<<<<<<<<< did ya think about BGP extensions... It could be a host of things, like communitites, MEDs, you name it. We connect to level3 in Ashburn/DC and saw traffic drop 50% in both directions on that port. Testing showed 100% loss on 50% of the flows. We shut that port down and now it won't come back up. I have link but no arp for their IP. This is a new link that was turned up in the past few weeks. - Kevin ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From tv at duh.org Mon Dec 29 11:10:40 2008 From: tv at duh.org (Todd Vierling) Date: Mon, 29 Dec 2008 12:10:40 -0500 Subject: Level 3 issues In-Reply-To: References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> <4957F30E.8030701@ieee.org> <01759D50DC387C45A018FE1817CE27D7540C2B5FE8@CPExchange1.cpgreeley.com> Message-ID: <7883eeaf0812290910t14f7046en1e229c28a4768169@mail.gmail.com> On Mon, Dec 29, 2008 at 11:33 AM, Murphy, Jay, DOH wrote: > You know, it gets pretty thick through here, when all you people slam on > someone, to justify pent up angst or whatever the cause may be. I > worked for Level 3 as a NOC engr, and they follow standards as other > companies do, and for that matter a standard that I AM SURE all of you > follow in some form, degree, or another within the employ you are with, > so shut up already won't you. Give me a 10-minute break already. Half of > the crap that you guys serve up is crap, just that, CRAP! Get to talking > real 'net stuff, not filler, fodder, just facts man. Oh yeah the other > thing, quit your whining. -- -- Todd Vierling From marco at zero11.com Mon Dec 29 12:20:26 2008 From: marco at zero11.com (marco) Date: Mon, 29 Dec 2008 10:20:26 -0800 Subject: Level 3 issues In-Reply-To: <7883eeaf0812290910t14f7046en1e229c28a4768169@mail.gmail.com> References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> <4957F30E.8030701@ieee.org> <01759D50DC387C45A018FE1817CE27D7540C2B5FE8@CPExchange1.cpgreeley.com> <7883eeaf0812290910t14f7046en1e229c28a4768169@mail.gmail.com> Message-ID: <495914EA.40509@zero11.com> I think that most of the anger was directed at the wanna-be reporters/journalists that visit this list. Todd Vierling wrote: > On Mon, Dec 29, 2008 at 11:33 AM, Murphy, Jay, DOH > wrote: > >> You know, it gets pretty thick through here, when all you people slam on >> someone, to justify pent up angst or whatever the cause may be. I >> worked for Level 3 as a NOC engr, and they follow standards as other >> companies do, and for that matter a standard that I AM SURE all of you >> follow in some form, degree, or another within the employ you are with, >> so shut up already won't you. Give me a 10-minute break already. Half of >> the crap that you guys serve up is crap, just that, CRAP! Get to talking >> real 'net stuff, not filler, fodder, just facts man. Oh yeah the other >> thing, quit your whining. >> > > > > From Jay.Murphy at state.nm.us Mon Dec 29 12:25:47 2008 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Mon, 29 Dec 2008 11:25:47 -0700 Subject: Level 3 issues In-Reply-To: <495914EA.40509@zero11.com> References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> <4957F30E.8030701@ieee.org> <01759D50DC387C45A018FE1817CE27D7540C2B5FE8@CPExchange1.cpgreeley.com> <7883eeaf0812290910t14f7046en1e229c28a4768169@mail.gmail.com> <495914EA.40509@zero11.com> Message-ID: Duly meditated upon. Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 "We move the information that moves your world." -----Original Message----- From: marco [mailto:marco at zero11.com] Sent: Monday, December 29, 2008 11:20 AM To: nanog at nanog.org Subject: Re: Level 3 issues I think that most of the anger was directed at the wanna-be reporters/journalists that visit this list. Todd Vierling wrote: > On Mon, Dec 29, 2008 at 11:33 AM, Murphy, Jay, DOH > wrote: > >> You know, it gets pretty thick through here, when all you people slam >> on someone, to justify pent up angst or whatever the cause may be. I >> worked for Level 3 as a NOC engr, and they follow standards as other >> companies do, and for that matter a standard that I AM SURE all of >> you follow in some form, degree, or another within the employ you are >> with, so shut up already won't you. Give me a 10-minute break >> already. Half of the crap that you guys serve up is crap, just that, >> CRAP! Get to talking real 'net stuff, not filler, fodder, just facts >> man. Oh yeah the other thing, quit your whining. >> > > > > ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From ge at linuxbox.org Mon Dec 29 16:03:18 2008 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 29 Dec 2008 16:03:18 -0600 (CST) Subject: reliable IOS exploitation Message-ID: FX has given a comprehensive talk about IOS exploitation (including even TCL scripts operators leave behind when they moved jobs to retain access). He has shown effective and ineffective ways of detecting compromise in IOS. Then, he has shown how reliable exploitation of IOS routers works. His talk will probably be downloadable from the CCC (25C3) web site by tomorrow. Gadi. From Dennis.Springer at chartercom.com Mon Dec 29 16:07:28 2008 From: Dennis.Springer at chartercom.com (Springer, Dennis D) Date: Mon, 29 Dec 2008 16:07:28 -0600 Subject: unsubscribe In-Reply-To: References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> <4957F30E.8030701@ieee.org> <01759D50DC387C45A018FE1817CE27D7540C2B5FE8@CPExchange1.cpgreeley.com> <7883eeaf0812290910t14f7046en1e229c28a4768169@mail.gmail.com><495914EA.40509@zero11.com> Message-ID: <0D219B2E27CF864A81012C86386C29A20E205610@KSTLMEXM02.CORP.CHARTERCOM.COM> Dennis Springer Network Engineer III Charter Communications 12405 Powerscourt Dr. 2nd floor St. Louis, MO 63131 Phone: (314) 288-3425 Cell: (314) 607-9824 -----Original Message----- From: Murphy, Jay, DOH [mailto:Jay.Murphy at state.nm.us] Sent: Monday, December 29, 2008 12:26 PM To: marco; nanog at nanog.org Subject: RE: Level 3 issues Duly meditated upon. Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 "We move the information that moves your world." -----Original Message----- From: marco [mailto:marco at zero11.com] Sent: Monday, December 29, 2008 11:20 AM To: nanog at nanog.org Subject: Re: Level 3 issues I think that most of the anger was directed at the wanna-be reporters/journalists that visit this list. Todd Vierling wrote: > On Mon, Dec 29, 2008 at 11:33 AM, Murphy, Jay, DOH > wrote: > >> You know, it gets pretty thick through here, when all you people slam >> on someone, to justify pent up angst or whatever the cause may be. I >> worked for Level 3 as a NOC engr, and they follow standards as other >> companies do, and for that matter a standard that I AM SURE all of >> you follow in some form, degree, or another within the employ you are >> with, so shut up already won't you. Give me a 10-minute break >> already. Half of the crap that you guys serve up is crap, just that, >> CRAP! Get to talking real 'net stuff, not filler, fodder, just facts >> man. Oh yeah the other thing, quit your whining. >> > > > > ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. From Jay.Murphy at state.nm.us Mon Dec 29 16:31:23 2008 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Mon, 29 Dec 2008 15:31:23 -0700 Subject: unsubscribe In-Reply-To: <0D219B2E27CF864A81012C86386C29A20E205610@KSTLMEXM02.CORP.CHARTERCOM.COM> References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> <4957F30E.8030701@ieee.org> <01759D50DC387C45A018FE1817CE27D7540C2B5FE8@CPExchange1.cpgreeley.com> <7883eeaf0812290910t14f7046en1e229c28a4768169@mail.gmail.com><495914EA.40509@zero11.com> <0D219B2E27CF864A81012C86386C29A20E205610@KSTLMEXM02.CORP.CHARTERCOM.COM> Message-ID: Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: Springer, Dennis D [mailto:Dennis.Springer at chartercom.com] Sent: Monday, December 29, 2008 3:07 PM To: nanog at nanog.org Subject: unsubscribe Dennis Springer Network Engineer III Charter Communications 12405 Powerscourt Dr. 2nd floor St. Louis, MO 63131 Phone: (314) 288-3425 Cell: (314) 607-9824 -----Original Message----- From: Murphy, Jay, DOH [mailto:Jay.Murphy at state.nm.us] Sent: Monday, December 29, 2008 12:26 PM To: marco; nanog at nanog.org Subject: RE: Level 3 issues Duly meditated upon. Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 "We move the information that moves your world." -----Original Message----- From: marco [mailto:marco at zero11.com] Sent: Monday, December 29, 2008 11:20 AM To: nanog at nanog.org Subject: Re: Level 3 issues I think that most of the anger was directed at the wanna-be reporters/journalists that visit this list. Todd Vierling wrote: > On Mon, Dec 29, 2008 at 11:33 AM, Murphy, Jay, DOH > wrote: > >> You know, it gets pretty thick through here, when all you people slam >> on someone, to justify pent up angst or whatever the cause may be. I >> worked for Level 3 as a NOC engr, and they follow standards as other >> companies do, and for that matter a standard that I AM SURE all of >> you follow in some form, degree, or another within the employ you are >> with, so shut up already won't you. Give me a 10-minute break >> already. Half of the crap that you guys serve up is crap, just that, >> CRAP! Get to talking real 'net stuff, not filler, fodder, just facts >> man. Oh yeah the other thing, quit your whining. >> > > > > ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ From jthomas at crucialservers.net Mon Dec 29 16:40:31 2008 From: jthomas at crucialservers.net (James Thomas) Date: Mon, 29 Dec 2008 17:40:31 -0500 Subject: unsubscribe In-Reply-To: References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> <4957F30E.8030701@ieee.org> <01759D50DC387C45A018FE1817CE27D7540C2B5FE8@CPExchange1.cpgreeley.com> <7883eeaf0812290910t14f7046en1e229c28a4768169@mail.gmail.com><495914EA.40509@zero11.com> <0D219B2E27CF864A81012C86386C29A20E205610@KSTLMEXM02.CORP.CHARTERCOM.COM> Message-ID: <007301c96a06$749a3120$5dce9360$@net> nanog-request at merit.edu?body=unsubscribe To Unsubscribe. James Thomas -----Original Message----- From: Murphy, Jay, DOH [mailto:Jay.Murphy at state.nm.us] Sent: Monday, December 29, 2008 5:31 PM To: Springer, Dennis D; nanog at nanog.org Subject: RE: unsubscribe Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: Springer, Dennis D [mailto:Dennis.Springer at chartercom.com] Sent: Monday, December 29, 2008 3:07 PM To: nanog at nanog.org Subject: unsubscribe Dennis Springer Network Engineer III Charter Communications 12405 Powerscourt Dr. 2nd floor St. Louis, MO 63131 Phone: (314) 288-3425 Cell: (314) 607-9824 -----Original Message----- From: Murphy, Jay, DOH [mailto:Jay.Murphy at state.nm.us] Sent: Monday, December 29, 2008 12:26 PM To: marco; nanog at nanog.org Subject: RE: Level 3 issues Duly meditated upon. Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 "We move the information that moves your world." -----Original Message----- From: marco [mailto:marco at zero11.com] Sent: Monday, December 29, 2008 11:20 AM To: nanog at nanog.org Subject: Re: Level 3 issues I think that most of the anger was directed at the wanna-be reporters/journalists that visit this list. Todd Vierling wrote: > On Mon, Dec 29, 2008 at 11:33 AM, Murphy, Jay, DOH > wrote: > >> You know, it gets pretty thick through here, when all you people slam >> on someone, to justify pent up angst or whatever the cause may be. I >> worked for Level 3 as a NOC engr, and they follow standards as other >> companies do, and for that matter a standard that I AM SURE all of >> you follow in some form, degree, or another within the employ you are >> with, so shut up already won't you. Give me a 10-minute break >> already. Half of the crap that you guys serve up is crap, just that, >> CRAP! Get to talking real 'net stuff, not filler, fodder, just facts >> man. Oh yeah the other thing, quit your whining. >> > > > > ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ From mpetach at netflight.com Mon Dec 29 16:42:17 2008 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 29 Dec 2008 14:42:17 -0800 Subject: Level 3 issues In-Reply-To: <495914EA.40509@zero11.com> References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> <4957F30E.8030701@ieee.org> <01759D50DC387C45A018FE1817CE27D7540C2B5FE8@CPExchange1.cpgreeley.com> <7883eeaf0812290910t14f7046en1e229c28a4768169@mail.gmail.com> <495914EA.40509@zero11.com> Message-ID: <63ac96a50812291442u257814fcp49895c676c349421@mail.gmail.com> On 12/29/08, marco wrote: > I think that most of the anger was directed at the wanna-be > reporters/journalists that visit this list. Yes. A nice set of examples of why that anger exists can be found here: http://news.search.yahoo.com/news/search?p=petach+kablooie :( Matt > Todd Vierling wrote: > > On Mon, Dec 29, 2008 at 11:33 AM, Murphy, Jay, DOH > > wrote: > > > >> You know, it gets pretty thick through here, when all you people slam on > >> someone, to justify pent up angst or whatever the cause may be. I > >> worked for Level 3 as a NOC engr, and they follow standards as other > >> companies do, and for that matter a standard that I AM SURE all of you > >> follow in some form, degree, or another within the employ you are with, > >> so shut up already won't you. Give me a 10-minute break already. Half of > >> the crap that you guys serve up is crap, just that, CRAP! Get to talking > >> real 'net stuff, not filler, fodder, just facts man. Oh yeah the other > >> thing, quit your whining. > >> > > > > > > > > > > > From Jay.Murphy at state.nm.us Mon Dec 29 16:43:49 2008 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Mon, 29 Dec 2008 15:43:49 -0700 Subject: unsubscribe In-Reply-To: <007301c96a06$749a3120$5dce9360$@net> References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> <4957F30E.8030701@ieee.org> <01759D50DC387C45A018FE1817CE27D7540C2B5FE8@CPExchange1.cpgreeley.com> <7883eeaf0812290910t14f7046en1e229c28a4768169@mail.gmail.com><495914EA.40509@zero11.com> <0D219B2E27CF864A81012C86386C29A20E205610@KSTLMEXM02.CORP.CHARTERCOM.COM> <007301c96a06$749a3120$5dce9360$@net> Message-ID: Pardons, several keys were depressed by mechanical miscalculation. Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: James Thomas [mailto:jthomas at crucialservers.net] Sent: Monday, December 29, 2008 3:41 PM To: Murphy, Jay, DOH; 'Springer, Dennis D'; nanog at nanog.org Subject: RE: unsubscribe nanog-request at merit.edu?body=unsubscribe To Unsubscribe. James Thomas -----Original Message----- From: Murphy, Jay, DOH [mailto:Jay.Murphy at state.nm.us] Sent: Monday, December 29, 2008 5:31 PM To: Springer, Dennis D; nanog at nanog.org Subject: RE: unsubscribe Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." -----Original Message----- From: Springer, Dennis D [mailto:Dennis.Springer at chartercom.com] Sent: Monday, December 29, 2008 3:07 PM To: nanog at nanog.org Subject: unsubscribe Dennis Springer Network Engineer III Charter Communications 12405 Powerscourt Dr. 2nd floor St. Louis, MO 63131 Phone: (314) 288-3425 Cell: (314) 607-9824 -----Original Message----- From: Murphy, Jay, DOH [mailto:Jay.Murphy at state.nm.us] Sent: Monday, December 29, 2008 12:26 PM To: marco; nanog at nanog.org Subject: RE: Level 3 issues Duly meditated upon. Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 "We move the information that moves your world." -----Original Message----- From: marco [mailto:marco at zero11.com] Sent: Monday, December 29, 2008 11:20 AM To: nanog at nanog.org Subject: Re: Level 3 issues I think that most of the anger was directed at the wanna-be reporters/journalists that visit this list. Todd Vierling wrote: > On Mon, Dec 29, 2008 at 11:33 AM, Murphy, Jay, DOH > wrote: > >> You know, it gets pretty thick through here, when all you people slam >> on someone, to justify pent up angst or whatever the cause may be. I >> worked for Level 3 as a NOC engr, and they follow standards as other >> companies do, and for that matter a standard that I AM SURE all of >> you follow in some form, degree, or another within the employ you are >> with, so shut up already won't you. Give me a 10-minute break >> already. Half of the crap that you guys serve up is crap, just that, >> CRAP! Get to talking real 'net stuff, not filler, fodder, just facts >> man. Oh yeah the other thing, quit your whining. >> > > > > ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From mike.lyon at gmail.com Mon Dec 29 16:51:52 2008 From: mike.lyon at gmail.com (Mike Lyon) Date: Mon, 29 Dec 2008 14:51:52 -0800 Subject: Tata / AS6453.net peering admin? Message-ID: <1b5c1c150812291451p233529f3ra256c137df3355f@mail.gmail.com> Please hit me up offlist. I've been having issues with your peering with China Netcom and your NOC is unresponsive. Thanks, Mike From gem at rellim.com Mon Dec 29 17:09:01 2008 From: gem at rellim.com (Gary E. Miller) Date: Mon, 29 Dec 2008 15:09:01 -0800 (PST) Subject: Level 3 issues In-Reply-To: <63ac96a50812291442u257814fcp49895c676c349421@mail.gmail.com> References: <901e4420812281035x78045a1h751e0957e306902a@mail.gmail.com> <697885931.1103541230489609310.JavaMail.root@mail.dtgmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE5@CPExchange1.cpgreeley.com> <1a410e090812281053h6ab8b195ufd9d0715cca7cea0@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D7540C2B5FE6@CPExchange1.cpgreeley.com> <4957F30E.8030701@ieee.org> <01759D50DC387C45A018FE1817CE27D7540C2B5FE8@CPExchange1.cpgreeley.com> <7883eeaf0812290910t14f7046en1e229c28a4768169@mail.gmail.com> <495914EA.40509@zero11.com> <63ac96a50812291442u257814fcp49895c676c349421@mail.gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yo Matt! On Mon, 29 Dec 2008, Matthew Petach wrote: > Yes. A nice set of examples of why that anger exists > can be found here: > http://news.search.yahoo.com/news/search?p=petach+kablooie Well... I sorta liked that story. I did not think you came off badly in it either. RGDS GARY - --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFJWViQBmnRqz71OvMRAr0uAJ9fwOgXpktikAnkzZfdYLpJqsGmCgCfX/H7 MBBrbspBEOWMmTcgDX7LK9M= =7bbY -----END PGP SIGNATURE----- From glen.kent at gmail.com Mon Dec 29 17:53:50 2008 From: glen.kent at gmail.com (Glen Kent) Date: Tue, 30 Dec 2008 05:23:50 +0530 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: References: Message-ID: <92c950310812291553t69380487h42bc21d4131297a8@mail.gmail.com> There is no fundamental difference between ISIS and OSPF; it's all in details and style. You might want to look at: http://www.nada.kth.se/kurser/kth/2D1490/06/hemuppgifter/bhatia-manral-diff-isis-ospf-01.txt.html Glen. On Sat, Dec 27, 2008 at 8:17 AM, devang patel wrote: > Hello, > > I do have some confusion about which one is better for IPv6 in Service > Provider networks as far as IP routing and MPLS application is concern! > > 1. Which protocol should i use to support the IPv6 in network: ISIS or > OSPFv3? > As ISIS has multi-topology feature that can give us capability to run > IPv4 network separate from IPv6 right! and same thing with OSPF: OSPFv2 will > be used for IPv4 routing and OSPFv3 will be used for IPv6 routing! again Its > look like resource utilization for both the protocol will be same as they > are going to use separate database for storing the routing or topology > information. ISIS still has advantage over OSPF as it does use the TLV > structure which can help in expanding network to support the new feature! > > 2. MPLS is not distributing label for IPv6 protocol so again there will not > be any IGP best path calcuated for any MPLS related application for IPv6! > > 3. what if i have already running OSPFv2 for IPv4 in the network then should > i think for migrating to ISIS? > if yes then what are the advantages that I can look at for migrating my > network to IS-IS? > > > > regards > Devang Patel > From sf at lists.esoteric.ca Tue Dec 30 00:57:59 2008 From: sf at lists.esoteric.ca (Stephen Fulton) Date: Tue, 30 Dec 2008 01:57:59 -0500 Subject: E-Bay / Paypal engineer eyeballs required. Message-ID: <4959C677.8060501@lists.esoteric.ca> Apologies to the list for the post, but: Could an engineer from E-Bay/Paypal contact me off-list, as we're having some difficulty reaching your network. Our ARIN assigned space (66.135.96.0/19) is awfully close to your own, and I suspect a typo. We have no issues reaching the edge of your space via multiple carriers. -- Stephen Fulton From jmkeller at houseofzen.org Tue Dec 30 10:30:56 2008 From: jmkeller at houseofzen.org (James Michael Keller) Date: Tue, 30 Dec 2008 11:30:56 -0500 Subject: What to do when your ISP off-shores tech support In-Reply-To: References: Message-ID: <495A4CC0.8080903@houseofzen.org> Matthew Black wrote: > I've had difficulties reaching anyone with a brain > at my DSL provider Verizon California. > > I can reliably ping the first hop from my home to > the CO with a 25ms delay. But if I ping any other > location, packets get dropped or significantly > delayed. To me, this sounds like Verizon has an > internal routing problem rather than a problem > with my phone line. Note that it rained recently > in our area and the cable vault in front of my > is usually covered with stagnant water because > the gutters don't drain it away. > > I have tried to explain this to tech support but > they refuse to go off script, even the supervisors. > They keep insisting on sending a tech to my home > when I suggest this should be escalated to their > network operations team. > > Anyhow, if I can reliably ping the first hop > from my home, would that eliminate my telephone > connection as part of the problem? Just a sanity > check on my part. Thanks. > > matthew black > california state university, long beach > Are you seeing drops or slow response times for the Verizon hops but not for the last hop destination? If so, remember that most of the larger ISPs will be rate limiting non-admin (ie from their support network ranges) traffic directed to the enterprise equipment. This means they will either ignore or delay responding to ICMP requests directed to their own IP addresses vs forwarding traffic. If your seeing about the same for the destination and for the intermediate hops then it's more likely an issue on the Verizon network. -- James Michael Keller From roque at lacnic.net Tue Dec 30 13:14:13 2008 From: roque at lacnic.net (Roque Gagliano) Date: Tue, 30 Dec 2008 17:14:13 -0200 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: <200812281300.34387.mtinka@globaltransit.net> References: <200812271833.10233.mtinka@globaltransit.net> <49562D29.8030003@psg.com> <200812281300.34387.mtinka@globaltransit.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Dec 28, 2008, at 3:00 AM, Mark Tinka wrote: > On Saturday 27 December 2008 09:27:05 pm Randy Bush wrote: > >> as one who has been burned when topologies are not >> congruent, i gotta ask. if i do not anticipate v4 and v6 >> having different topologies, and all my devices are >> dual-capable, would you still recommend mt for other than >> future-proofing? > > In practice, we realized that enabling IS-ISv6 on interfaces > already running IS-ISv4 was problematic without MT pre- > configured. > at least in my case, I did turned ISISv6 in one WAN interface where the router on the other side (a Cisco) did not have the "ipv6 unicast routing" general command on and the isis adjacency went down completely. So, yes that was an issue. But if you enabled IPv6 in both ends first and then one interface at the time, it worked. I used MT to avoid IPv6 black holes during the configuration period, but as some boxes did not implemented it, I needed to use the "transition" option where IPv6 adjacencies are carried in both native and the MT-IPv6. Fortunately the two vendors that were lacking of MT support are up-to-date, however not in time as the migration ended and MT was removed and I left the company. Roque. - - - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAklabZkACgkQnk+WSgHpbO49PACg2Rx0yaH4owU2GA5koORD+pra kjgAoMgoXYDVD2ayWhn56fkt0urcyyAx =1tWb - - - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAklacwUACgkQnk+WSgHpbO4TUgCfVpGEMMIdS8y0RrtNQh9rh1Ne fQcAoIOBUc2O4em8NwqwR2UJDDm1Z7Mh =YAeJ -----END PGP SIGNATURE----- From info at arin.net Tue Dec 30 15:35:22 2008 From: info at arin.net (Member Services) Date: Tue, 30 Dec 2008 16:35:22 -0500 Subject: ARIN receives 2 new /8 blocks Message-ID: <495A941A.9040102@arin.net> ARIN received the IPv4 address blocks 108.0.0.0/8 and 184.0.0.0/8 from the IANA on Dec. 22, 2008. We will begin making allocations of /20 and shorter prefixes from these blocks in the near future in accordance with ARIN's minimum allocation policy. Network operators may wish to adjust any filters in place accordingly. For informational purposes, a list of ARIN's currently administered IP address blocks can be found at: http://www.arin.net/reference/ip_blocks.html Regards, Leslie Nobile Director, Registration Services American Registry for Internet Numbers (ARIN) From simon.allard at team.orcon.net.nz Tue Dec 30 15:41:14 2008 From: simon.allard at team.orcon.net.nz (Simon Allard) Date: Wed, 31 Dec 2008 10:41:14 +1300 Subject: Youtube contact Message-ID: Hi, Can someone from Youtube/Google please contact me off list, I have a strange routing issue at the youtube->cogent border. Usual contact methods have failed me. Thanks Regards Simon From nathan at stonekitty.net Tue Dec 30 16:01:51 2008 From: nathan at stonekitty.net (Nathan) Date: Tue, 30 Dec 2008 14:01:51 -0800 Subject: Youtube contact In-Reply-To: References: Message-ID: <5624b0d70812301401w2af7895fuc6b79830629cb011@mail.gmail.com> done. On Tue, Dec 30, 2008 at 1:41 PM, Simon Allard wrote: > Hi, > > Can someone from Youtube/Google please contact me off list, I have a strange routing issue at the youtube->cogent border. Usual contact methods have failed me. > > Thanks > > Regards > Simon > > > -- Nathan Hickson KI6RWZ aim/y!: nullrouten efnet: N2k From naveen at calpop.com Tue Dec 30 18:08:32 2008 From: naveen at calpop.com (Naveen Nathan) Date: Wed, 31 Dec 2008 00:08:32 +0000 Subject: Failover solution using BGP Message-ID: <20081231000832.GB6841@armakuni.lastninja.net> Hi, I would appreciate insight and experience for the following situation. I have a client that would like to announce a /18 & /19 over BGP in Sacramento and LA, us being the second location in LA. Our location will be a failover location incase Sacramento goes down. They want failover for extreme cases when they're completly down in Sacramento. They have strict requirements so that traffic to their blocks should exclusively go to Sacramento or LA. This seems difficult to automate and they are aware of this. They will contact their provider to stop announcing the blocks and subsequently contact us to announce their routes. I am wondering is there a better way to approaching the situation without resorting to announcing the routes when the client calls us and tells us to failover. This seems to be the inherent problem aswell because the customer wants this to be a manual process. -- Naveen Nathan To understand the human mind, understand self-deception. - Anon From cely at internap.com Tue Dec 30 18:13:49 2008 From: cely at internap.com (Chris Ely) Date: Tue, 30 Dec 2008 16:13:49 -0800 (PST) Subject: Failover solution using BGP In-Reply-To: <20081231000832.GB6841@armakuni.lastninja.net> References: <20081231000832.GB6841@armakuni.lastninja.net> Message-ID: Conditional advertisements might be what you're looking for: http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a0080094309.shtml Regards, Chris Ely On Wed, 31 Dec 2008, Naveen Nathan wrote: > Hi, > > I would appreciate insight and experience for the following situation. > > I have a client that would like to announce a /18 & /19 over BGP in > Sacramento and LA, us being the second location in LA. Our location > will be a failover location incase Sacramento goes down. > > They want failover for extreme cases when they're completly down in > Sacramento. They have strict requirements so that traffic to their blocks > should exclusively go to Sacramento or LA. > > This seems difficult to automate and they are aware of this. They will > contact their provider to stop announcing the blocks and subsequently > contact us to announce their routes. > > I am wondering is there a better way to approaching the situation > without resorting to announcing the routes when the client calls us > and tells us to failover. This seems to be the inherent problem aswell > because the customer wants this to be a manual process. > > -- > Naveen Nathan > > To understand the human mind, understand self-deception. - Anon > > From chandler.bassett at gmail.com Tue Dec 30 18:15:21 2008 From: chandler.bassett at gmail.com (Chandler Bassett) Date: Tue, 30 Dec 2008 19:15:21 -0500 Subject: Failover solution using BGP In-Reply-To: <20081231000832.GB6841@armakuni.lastninja.net> References: <20081231000832.GB6841@armakuni.lastninja.net> Message-ID: <267D7CFC-E71D-40FD-8A27-4526CD8FF254@gmail.com> If the infrastructure is the same in both locations, why not load balance with stateful failover? If it's not the same in both locations, what are they doing for replication and the such in the event a site does go down? - Chandler On Dec 30, 2008, at 7:08 PM, Naveen Nathan wrote: > Hi, > > I would appreciate insight and experience for the following situation. > > I have a client that would like to announce a /18 & /19 over BGP in > Sacramento and LA, us being the second location in LA. Our location > will be a failover location incase Sacramento goes down. > > They want failover for extreme cases when they're completly down in > Sacramento. They have strict requirements so that traffic to their > blocks > should exclusively go to Sacramento or LA. > > This seems difficult to automate and they are aware of this. They will > contact their provider to stop announcing the blocks and subsequently > contact us to announce their routes. > > I am wondering is there a better way to approaching the situation > without resorting to announcing the routes when the client calls us > and tells us to failover. This seems to be the inherent problem aswell > because the customer wants this to be a manual process. > > -- > Naveen Nathan > > To understand the human mind, understand self-deception. - Anon > From MBraun at firstam.com Tue Dec 30 18:19:33 2008 From: MBraun at firstam.com (Braun, Mike) Date: Tue, 30 Dec 2008 16:19:33 -0800 Subject: Failover solution using BGP In-Reply-To: <267D7CFC-E71D-40FD-8A27-4526CD8FF254@gmail.com> References: <20081231000832.GB6841@armakuni.lastninja.net> <267D7CFC-E71D-40FD-8A27-4526CD8FF254@gmail.com> Message-ID: Why not just AS prepend your secondary site if the services to the Internet are the same at both sites and tied to the same IP addresses? Mike -----Original Message----- From: Chandler Bassett [mailto:chandler.bassett at gmail.com] Sent: Tuesday, December 30, 2008 4:15 PM To: Naveen Nathan Cc: nanog at nanog.org Subject: Re: Failover solution using BGP If the infrastructure is the same in both locations, why not load balance with stateful failover? If it's not the same in both locations, what are they doing for replication and the such in the event a site does go down? - Chandler On Dec 30, 2008, at 7:08 PM, Naveen Nathan wrote: > Hi, > > I would appreciate insight and experience for the following situation. > > I have a client that would like to announce a /18 & /19 over BGP in > Sacramento and LA, us being the second location in LA. Our location > will be a failover location incase Sacramento goes down. > > They want failover for extreme cases when they're completly down in > Sacramento. They have strict requirements so that traffic to their > blocks > should exclusively go to Sacramento or LA. > > This seems difficult to automate and they are aware of this. They will > contact their provider to stop announcing the blocks and subsequently > contact us to announce their routes. > > I am wondering is there a better way to approaching the situation > without resorting to announcing the routes when the client calls us > and tells us to failover. This seems to be the inherent problem aswell > because the customer wants this to be a manual process. > > -- > Naveen Nathan > > To understand the human mind, understand self-deception. - Anon > -- THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE INTENDED SOLELY FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY CONTAIN CONFIDENTIAL, PROPRIETARY OR PRIVILEGED INFORMATION. IF YOU ARE NOT THE ADDRESSEE INDICATED IN THIS MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FILES TRANSMITTED HEREWITH. IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF IT FROM YOUR SYSTEM. From mtinka at globaltransit.net Tue Dec 30 18:21:41 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Wed, 31 Dec 2008 08:21:41 +0800 Subject: IPv6: IS-IS or OSPFv3 In-Reply-To: References: <200812281300.34387.mtinka@globaltransit.net> Message-ID: <200812310821.49273.mtinka@globaltransit.net> On Wednesday 31 December 2008 03:14:13 am Roque Gagliano wrote: > at least in my case, I did turned ISISv6 in one WAN > interface where the router on the other side (a Cisco) > did not have the "ipv6 unicast routing" general command > on and the isis adjacency went down completely. So, yes > that was an issue. One of the things I'm hoping Cisco can fix in not-too- distant future releases of IOS. > But if you enabled IPv6 in both ends > first and then one interface at the time, it worked. What we saw on our test segment was that v4 adjacencies were not torn down by merely enabling IS-ISv6 on an interface (given that JunOS enables IS-ISv6 by default when IS-IS is enabled on the router; in IOS, you have to explicitly turn IS-ISv6 on). v4 adjacencies were torn down *after* an IPv6 address was added to the interface. We witnessed this issue under both IOS and JunOS. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From david.freedman at uk.clara.net Tue Dec 30 19:08:01 2008 From: david.freedman at uk.clara.net (David Freedman) Date: Wed, 31 Dec 2008 01:08:01 -0000 Subject: IPv6: IS-IS or OSPFv3 Message-ID: >For IS-IS, highly recommend MT to avoid any nasties while >turning up v6 in a dual-stack environment. Also when doing MT on cisco, configure "no-adjacency-check" under the v6 address-family during the migrate else you will bounce your sessions. Cisco of course warn you against doing this but without it the change is bumpy. >From the cisco docs: "Disabling the adjacency-check command can adversely affect your network configuration. Enter the no adjacency-check command only when you are running IPv4 IS-IS on all your routers and you want to add IPv6 IS-IS to your network but you need to maintain all your adjacencies during the transition. When the IPv6 IS-IS configuration is complete, remove the no adjacency-check command from the configuration." source: http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-is-is.html ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net From austinw at bandcon.com Tue Dec 30 19:42:43 2008 From: austinw at bandcon.com (Austin Wilson) Date: Tue, 30 Dec 2008 17:42:43 -0800 Subject: Failover solution using BGP In-Reply-To: <20081231000832.GB6841@armakuni.lastninja.net> References: <20081231000832.GB6841@armakuni.lastninja.net> Message-ID: <67B864FDA9789F4FA1A854AFD6A1F3C80CB0BF2A01@devo.bandcon.local> If you don't have control over the other site my best advice would be to use the BGP communities your transit providers give you. If you setup your clients routes to a lower Local Perf on your transit provider's network, your transit provider will always pick the primary provider's routes first. The moment the primary site stops announcing the route your transit provider will immediately start announcing yours. This works better then AS prepend because almost all providers override the AS prepend with a higher local pref for free peers, local customers, etc. The only other issue would be, how to stop the primary network from advertising your client's routes automatically. This could be done by the client setting up BGP with the primary provider and then pulling the routes. If your client does not run BGP then it all depends on how the ips are setup on the primary side. My best advice is if they don't have BGP to tell them to set it up. Tell them to setup a private AS BGP session with their provider and just get a default route from them. This way they use just about any piece of networking equipment and they don't need their own external AS. Then they can either shutdown the port, BGP session, or pull the route (all they can do themselves) to have their provider pull the route from the internet. Use this link to find common communities: http://www.onesc.net/communities/ Otherwise, the customer could get around this whole issue by setting up some type global server load balancing. There are quite a few companies that have solutions for this. But it would take a lot more technical networking knowledge on the client side. Austin -----Original Message----- From: Naveen Nathan [mailto:naveen at calpop.com] Sent: Tuesday, December 30, 2008 5:09 PM To: nanog at nanog.org Subject: Failover solution using BGP Hi, I would appreciate insight and experience for the following situation. I have a client that would like to announce a /18 & /19 over BGP in Sacramento and LA, us being the second location in LA. Our location will be a failover location incase Sacramento goes down. They want failover for extreme cases when they're completly down in Sacramento. They have strict requirements so that traffic to their blocks should exclusively go to Sacramento or LA. This seems difficult to automate and they are aware of this. They will contact their provider to stop announcing the blocks and subsequently contact us to announce their routes. I am wondering is there a better way to approaching the situation without resorting to announcing the routes when the client calls us and tells us to failover. This seems to be the inherent problem aswell because the customer wants this to be a manual process. -- Naveen Nathan To understand the human mind, understand self-deception. - Anon From mvh at hosteurope.de Tue Dec 30 19:49:04 2008 From: mvh at hosteurope.de (Malte von dem Hagen) Date: Wed, 31 Dec 2008 02:49:04 +0100 Subject: Failover solution using BGP In-Reply-To: References: <20081231000832.GB6841@armakuni.lastninja.net> <267D7CFC-E71D-40FD-8A27-4526CD8FF254@gmail.com> Message-ID: <495ACF90.4090909@hosteurope.de> Hi, Am 31.12.2008 01:19 Uhr, Braun, Mike schrieb: > Why not just AS prepend your secondary site if the services to the > Internet are the same at both sites and tied to the same IP addresses? because that simply does not work (reliably). It would depend on AS-paths of the same length from every possible source. Simple, reliable and quite stylish is another way: Choose primary and secondary location by announcing more specifics at Sacramento, e.g. all networks as /20 subnets. As "longest match always wins", any source seeing both routes for an IP address will choose Sacramento. The only way traffic could reach LA would be a missing route to Sacramento. In any other case, Sacramento is chosen. Thus, if Sacramento (manually or automatically) stops announcing the /20s, LA's /18 and /19 will be chosen. CAVE: This is no failover solution for single services, just for whole subnets depending on the announcement at Sacramento. CAVE2: My suggestion creates inconsistent announcements for the source AS. That may or may not be a problem. Kind regards, Malte -- Malte v. dem Hagen Abteilung Technik - Network Operations Centre ----------------------------------------------------------------- Host Europe GmbH - http://www.hosteurope.de/ Welserstrasse 14 - D-51149 K?ln - Germany Telefon 0800-4 67 83 87 - Telefax 01805-66 32 33 HRB 28495 Amtsgericht Koeln - UST ID DE187370678 GF: Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulverm?ller ----------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 257 bytes Desc: OpenPGP digital signature URL: From herrin-nanog at dirtside.com Tue Dec 30 20:29:32 2008 From: herrin-nanog at dirtside.com (William Herrin) Date: Tue, 30 Dec 2008 21:29:32 -0500 Subject: Failover solution using BGP In-Reply-To: <20081231000832.GB6841@armakuni.lastninja.net> References: <20081231000832.GB6841@armakuni.lastninja.net> Message-ID: <3c3e3fca0812301829l12ddbdc7t7b8583695e381b27@mail.gmail.com> On Tue, Dec 30, 2008 at 7:08 PM, Naveen Nathan wrote: > I have a client that would like to announce a /18 & /19 over BGP in > Sacramento and LA, us being the second location in LA. Our location > will be a failover location incase Sacramento goes down. > > They want failover for extreme cases when they're completly down in > Sacramento. They have strict requirements so that traffic to their blocks > should exclusively go to Sacramento or LA. Announce from Sacramento normally. Announce from LA with an AS prepend 3 or 4 deep. GRE tunnel from LA back to Sacramento diverting the few packets which insist on going to LA back to Sacramento during normal operation. Or conditionally announce in LA based on a monitoring process which watches Sacramento and deal with the extra complexity and longer restoration time. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From naveen at calpop.com Tue Dec 30 21:59:17 2008 From: naveen at calpop.com (Naveen Nathan) Date: Wed, 31 Dec 2008 03:59:17 +0000 Subject: Failover solution using BGP In-Reply-To: <20081231000832.GB6841@armakuni.lastninja.net> References: <20081231000832.GB6841@armakuni.lastninja.net> Message-ID: <20081231035917.GA12164@armakuni.lastninja.net> Thank to everyone that took the time to respond with their ideas. To those who asked, the client didn't provide details on the application. However they were insistent that it wasn't possible to have it run in an active/active configuration, so load balancing at either the application or BGP level wasn't an option. Also they didn't want to subnet the space for the failover location, so it's all or nothing style routing. Of the several solutions presented the two that seem to be simple to implement and guarantee traffic were conditional route advertisements or using more specific routes. I was unable to find information for conditional route advertisements in JunOS, so it seems like advertising specific routes at the primary option will be the easiest option. If anyone has information on conditional routing for JunOS, I would be much appreciative if you could send this to me. Happy Holidays everyone. - Naveen From fw at deneb.enyo.de Wed Dec 31 07:25:02 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 31 Dec 2008 14:25:02 +0100 Subject: Failover solution using BGP In-Reply-To: <20081231035917.GA12164@armakuni.lastninja.net> (Naveen Nathan's message of "Wed, 31 Dec 2008 03:59:17 +0000") References: <20081231000832.GB6841@armakuni.lastninja.net> <20081231035917.GA12164@armakuni.lastninja.net> Message-ID: <87vdt0pjdd.fsf@mid.deneb.enyo.de> * Naveen Nathan: > Of the several solutions presented the two that seem to be simple to > implement and guarantee traffic were conditional route advertisements > or using more specific routes. One thing you need to consider is what happens if your AS is split. In this case, traffic will probably flow to both locations. From rdobbins at cisco.com Wed Dec 31 07:48:50 2008 From: rdobbins at cisco.com (Roland Dobbins) Date: Wed, 31 Dec 2008 21:48:50 +0800 Subject: Failover solution using BGP In-Reply-To: <20081231035917.GA12164@armakuni.lastninja.net> References: <20081231000832.GB6841@armakuni.lastninja.net> <20081231035917.GA12164@armakuni.lastninja.net> Message-ID: <46D33FAA-542F-4942-8FB8-72597F2AEF7B@cisco.com> On Dec 31, 2008, at 11:59 AM, Naveen Nathan wrote: > Also they didn't want to subnet the space for the failover > location, so it's all or nothing style routing. Have they considered doing GSLB via DNS rather than playing routing games? Seems as if it might answer better, be less complex, et. al. ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile All behavior is economic in motivation and/or consequence. From bvlmv at hotmail.com Wed Dec 31 07:59:26 2008 From: bvlmv at hotmail.com (Bryant Valencia) Date: Wed, 31 Dec 2008 08:59:26 -0500 Subject: Failover solution using BGP In-Reply-To: <20081231000832.GB6841@armakuni.lastninja.net> References: <20081231000832.GB6841@armakuni.lastninja.net> Message-ID: If an IBGP link is possible then you could automate this with the proper attributes. > Date: Wed, 31 Dec 2008 00:08:32 +0000> From: naveen at calpop.com> To: nanog at nanog.org> Subject: Failover solution using BGP> > Hi,> > I would appreciate insight and experience for the following situation.> > I have a client that would like to announce a /18 & /19 over BGP in> Sacramento and LA, us being the second location in LA. Our location> will be a failover location incase Sacramento goes down.> > They want failover for extreme cases when they're completly down in> Sacramento. They have strict requirements so that traffic to their blocks> should exclusively go to Sacramento or LA.> > This seems difficult to automate and they are aware of this. They will> contact their provider to stop announcing the blocks and subsequently> contact us to announce their routes.> > I am wondering is there a better way to approaching the situation> without resorting to announcing the routes when the client calls us> and tells us to failover. This seems to be the inherent problem aswell> because the customer wants this to be a manual process.> > -- > Naveen Nathan> > To understand the human mind, understand self-deception. - Anon> _________________________________________________________________ Send e-mail faster without improving your typing skills. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_speed_122008 From fw at deneb.enyo.de Wed Dec 31 09:36:16 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 31 Dec 2008 16:36:16 +0100 Subject: Failover solution using BGP In-Reply-To: <46D33FAA-542F-4942-8FB8-72597F2AEF7B@cisco.com> (Roland Dobbins's message of "Wed, 31 Dec 2008 21:48:50 +0800") References: <20081231000832.GB6841@armakuni.lastninja.net> <20081231035917.GA12164@armakuni.lastninja.net> <46D33FAA-542F-4942-8FB8-72597F2AEF7B@cisco.com> Message-ID: <871vvomk5r.fsf@mid.deneb.enyo.de> * Roland Dobbins: > Have they considered doing GSLB via DNS rather than playing routing > games? Seems as if it might answer better, be less complex, et. al. I suspect they want to solve the split brain problem, which would explain the strong, non-negotiable requirement of traffic flow to only one site. DNS tweaks won't help with that (and to be honest, BGP doesn't address it, either). From rdobbins at cisco.com Wed Dec 31 12:48:32 2008 From: rdobbins at cisco.com (Roland Dobbins) Date: Thu, 1 Jan 2009 02:48:32 +0800 Subject: Failover solution using BGP In-Reply-To: <871vvomk5r.fsf@mid.deneb.enyo.de> References: <20081231000832.GB6841@armakuni.lastninja.net> <20081231035917.GA12164@armakuni.lastninja.net> <46D33FAA-542F-4942-8FB8-72597F2AEF7B@cisco.com> <871vvomk5r.fsf@mid.deneb.enyo.de> Message-ID: On Dec 31, 2008, at 11:36 PM, Florian Weimer wrote: > DNS tweaks won't help with that (and to be honest, BGP doesn't > address it, either). After all, there ought to be an internal line of communication as well as the external one, and the availability probes can be set up with logic such that if one side has bidirectional comms and the other doesn't, the desired behavior (whatever that may be, dependent upon which side has full comms) can be enforced. Couple that with a stateless front-end - which could also afford active/active in that tier, even if the back-end is monolithic - and it's more nearly a complete solution, with more options, granularity, and safeguards available, than one based upon routing alone. ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile All behavior is economic in motivation and/or consequence. From djschaap+nanog at gmail.com Wed Dec 31 13:05:21 2008 From: djschaap+nanog at gmail.com (Doug Schaapveld) Date: Wed, 31 Dec 2008 13:05:21 -0600 Subject: Failover solution using BGP In-Reply-To: References: <20081231000832.GB6841@armakuni.lastninja.net> Message-ID: <2d06edaf0812311105y68c8acb3sc9bfeadded3ff03c@mail.gmail.com> On Tue, Dec 30, 2008 at 6:13 PM, Chris Ely wrote: > Conditional advertisements might be what you're looking for: > > http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a0080094309.shtml I did something just like this recently. Apologies if this is redundant, but it might be useful to some. showipbgp.com's BGP Topology 7 (at the bottom of the page) seems to match your request. http://www.showipbgp.com/ Example configs for Cisco are provided. I'm not familiar with JunOS, but conditional route advertisement seems like a reasonably simple request. Note that it would probably be the customer's routers that need to support the conditional route advertisement. hth, -Doug From toasty at dragondata.com Wed Dec 31 16:41:39 2008 From: toasty at dragondata.com (Kevin Day) Date: Wed, 31 Dec 2008 16:41:39 -0600 Subject: Leap second tonight Message-ID: Just a reminder that there's a leap second tonight. Last time I watched for what happened on 01/01/2006, there was a little bit of chaos: http://markmail.org/message/cpoj3jw5onzhhjkr?q=%22kevin+day%22+leap+second+reminder+nanog&page=1&refer=cnkxb3iv7sls5axu I've been told that some of the causes of these problems are fixed on any reasonably recent ntp distribution, but just in case, you might wanna keep an eye out if you're seeing any weirdness. The worst damage I'd heard from anyone after that event was their clock being significantly off for several hours. -- Kevin From roll at Stupi.SE Wed Dec 31 23:45:48 2008 From: roll at Stupi.SE (Peter Lothberg) Date: Wed, 31 Dec 2008 23:45:48 CET Subject: Leap second tonight In-Reply-To: Your message of Wed, 31 Dec 2008 16:41:39 -0600 Message-ID: INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : 33 (0) 1 40 51 22 26 FAX : 33 (0) 1 40 51 22 91 e-mail : services.iers at obspm.fr http://hpiers.obspm.fr/eop-pc Paris, 4 July 2008 Bulletin C 36 To authorities responsible for the measurement and distribution of time UTC TIME STEP on the 1st of January 2009 A positive leap second will be introduced at the end of December 2008. The sequence of dates of the UTC second markers will be: 2008 December 31, 23h 59m 59s 2008 December 31, 23h 59m 60s 2009 January 1, 0h 0m 0s The difference between UTC and the International Atomic Time TAI is: from 2006 January 1, 0h UTC, to 2009 January 1 0h UTC : UTC-TAI = - 33s from 2009 January 1, 0h UTC, until further notice : UTC-TAI = - 34s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC or to confirm that there will be no time step at the next possible date. Daniel GAMBIS Head Earth Orientation Center of IERS Observatoire de Paris, France From jasper at unleash.co.nz Wed Dec 31 17:27:36 2008 From: jasper at unleash.co.nz (Jasper Bryant-Greene) Date: Thu, 1 Jan 2009 12:27:36 +1300 Subject: Leap second tonight In-Reply-To: References: Message-ID: Since leap seconds apply to UTC, won't the leap second be in about 22 minutes? -jasper On 1/01/2009, at 11:41 AM, Kevin Day wrote: > > Just a reminder that there's a leap second tonight. > > Last time I watched for what happened on 01/01/2006, there was a > little bit of chaos: http://markmail.org/message/cpoj3jw5onzhhjkr?q=%22kevin+day%22+leap+second+reminder+nanog&page=1&refer=cnkxb3iv7sls5axu > > I've been told that some of the causes of these problems are fixed > on any reasonably recent ntp distribution, but just in case, you > might wanna keep an eye out if you're seeing any weirdness. The > worst damage I'd heard from anyone after that event was their clock > being significantly off for several hours. > > -- Kevin > > -- Jasper Bryant-Greene Network Engineer, Unleash ddi: +64 3 978 1222 mob: +64 21 129 9458 From msa at latt.net Wed Dec 31 17:27:40 2008 From: msa at latt.net (Majdi S. Abbas) Date: Wed, 31 Dec 2008 23:27:40 +0000 Subject: Leap second tonight In-Reply-To: References: Message-ID: <20081231232740.GC89298@mx1.latt.net> On Wed, Dec 31, 2008 at 04:41:39PM -0600, Kevin Day wrote: > I've been told that some of the causes of these problems are fixed on > any reasonably recent ntp distribution, but just in case, you might > wanna keep an eye out if you're seeing any weirdness. The worst damage > I'd heard from anyone after that event was their clock being > significantly off for several hours. One note, if you're using ntpd along with an HF receiver and the CHU reference driver, you'll either need to manually retune your receiver to 7850 kHz or update your ntpd. As of approximately one hour ago, CHU has moved from 7335 kHz, where it has been for several decades up to 7850 kHz due to increasing shortwave broadcast interference. Also note that many reference clocks, including GPS derived ones, do not handle leap seconds correctly, so it may be a while before your reference clocks stabilize. Happy New Year! --msa From oberman at es.net Wed Dec 31 17:28:16 2008 From: oberman at es.net (Kevin Oberman) Date: Wed, 31 Dec 2008 15:28:16 -0800 Subject: Leap second tonight In-Reply-To: Your message of "Wed, 31 Dec 2008 16:41:39 CST." Message-ID: <20081231232816.C3D7045020@ptavv.es.net> > From: Kevin Day > Date: Wed, 31 Dec 2008 16:41:39 -0600 > > > Just a reminder that there's a leap second tonight. > > Last time I watched for what happened on 01/01/2006, there was a > little bit of chaos: http://markmail.org/message/cpoj3jw5onzhhjkr?q=%22kevin+day%22+leap+second+reminder+nanog&page=1&refer=cnkxb3iv7sls5axu > > I've been told that some of the causes of these problems are fixed on > any reasonably recent ntp distribution, but just in case, you might > wanna keep an eye out if you're seeing any weirdness. The worst damage > I'd heard from anyone after that event was their clock being > significantly off for several hours. While I hope people are not still running NTP versions too old to handle leap seconds correctly, but that is only a small part of the problem. If the stratum 1 reference clocks don't handle leap seconds correctly, there is no way for NTP to deal with it. We use CDMA clocks and last leap second it took weeks for all of the cell sites to adjust the last one. As a result, I have set all of our clocks for manual leap second and set them to adjust tonight at midnight (UTC).I'll take a look in about 35 minutes and see how it worked. I've heard reports of various GPS clocks not dealing with the leap second correctly, as well. Fortunately, not too many need this sort of accuracy, but those of us who do need to be prepared. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From lars.hallgren at orange.fr Wed Dec 31 18:09:13 2008 From: lars.hallgren at orange.fr (Michael Hallgren) Date: Thu, 01 Jan 2009 01:09:13 +0100 Subject: Leap second tonight In-Reply-To: References: Message-ID: <1230768553.7635.3.camel@home> From wschultz at bsdboy.com Wed Dec 31 18:53:57 2008 From: wschultz at bsdboy.com (Wil Schultz) Date: Wed, 31 Dec 2008 16:53:57 -0800 Subject: Leap second tonight In-Reply-To: References: Message-ID: At which point my Solaris 10 v490's reboot in unison, lovely. Anyone else see anything interesting? -wil On Dec 31, 2008, at 4:01 PM, Peter Lothberg wrote: > bash-2.05b# date > Thu Jan 1 00:59:58 CET 2009 > bash-2.05b# date > Thu Jan 1 00:59:59 CET 2009 > bash-2.05b# date > Thu Jan 1 00:59:60 CET 2009 > bash-2.05b# date > Thu Jan 1 01:00:00 CET 2009 > bash-2.05b# date > Thu Jan 1 01:00:01 CET 2009 > bash-2.05b# > > > -P > From meekjt at gmail.com Wed Dec 31 19:11:49 2008 From: meekjt at gmail.com (Jon Meek) Date: Wed, 31 Dec 2008 20:11:49 -0500 Subject: Leap second tonight In-Reply-To: References: Message-ID: My Solaris 10 boxes are all happy (and did not reboot). I monitor NTP on a number of devices, including one router. The router was off by one second for a while, but is OK after an hour. Everything else was fine immediately. In 2005, our CDMA clock got the leap second between 15:08 and 15:38 EST creating some issues due to disagreement with the (too few) GPS clocks. Jon On Wed, Dec 31, 2008 at 7:53 PM, Wil Schultz wrote: > At which point my Solaris 10 v490's reboot in unison, lovely. > > Anyone else see anything interesting? > > -wil > From mhuff at ox.com Wed Dec 31 19:35:49 2008 From: mhuff at ox.com (Matthew Huff) Date: Wed, 31 Dec 2008 20:35:49 -0500 Subject: Leap second tonight In-Reply-To: References: Message-ID: <483E6B0272B0284BA86D7596C40D29F923CD7FEA3B@PUR-EXCH07.ox.com> It looks like clepsydra hasn't been updated: address ref clock st when poll reach delay offset disp -~192.5.41.40 .USNO. 1 194 1024 377 41.1 5.19 38.2 -~130.207.244.240 .GPS. 1 68 1024 377 23.1 11.09 1.3 ~127.127.7.1 127.127.7.1 7 53 64 377 0.0 0.00 0.0 +~198.60.22.240 .GPS. 1 436 1024 377 65.7 7.09 32.5 ~204.123.2.5 .GPS. 1 182 1024 377 80.4 1011.4 24.9 +~67.128.71.76 .CDMA. 1 178 1024 377 16.8 10.85 79.2 +~18.26.4.105 .CDMA. 1 562 1024 377 8.4 7.90 235.8 -~209.81.9.7 .GPS. 1 170 1024 177 79.9 16.96 170.8 *~209.51.161.238 .CDMA. 1 1019 1024 377 3.9 10.13 2.5 -~204.152.184.72 .GPS. 1 697 1024 377 75.0 1.81 3.2 +~18.145.0.30 .PSC. 1 1737 1024 376 10.0 8.52 297.1 Quick, someone call DEC. Seriously, clepsydra is one of the older ntp servers out there, and hasn't dealt with the leap second correctly. -----Original Message----- From: Kevin Day [mailto:toasty at dragondata.com] Sent: Wednesday, December 31, 2008 5:42 PM To: NANOG list Subject: Leap second tonight Just a reminder that there's a leap second tonight. Last time I watched for what happened on 01/01/2006, there was a little bit of chaos: http://markmail.org/message/cpoj3jw5onzhhjkr?q=%22kevin+day%22+leap+second+reminder+nanog&page=1&refer=cnkxb3iv7sls5axu I've been told that some of the causes of these problems are fixed on any reasonably recent ntp distribution, but just in case, you might wanna keep an eye out if you're seeing any weirdness. The worst damage I'd heard from anyone after that event was their clock being significantly off for several hours. -- Kevin From smb at cs.columbia.edu Wed Dec 31 23:41:20 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Thu, 1 Jan 2009 00:41:20 -0500 Subject: Leap second tonight In-Reply-To: References: Message-ID: <20090101004120.23170e9b@cs.columbia.edu> On Wed, 31 Dec 2008 16:53:57 -0800 Wil Schultz wrote: > At which point my Solaris 10 v490's reboot in unison, lovely. > Solaris? Or ZuneOS? (See http://www.nytimes.com/2009/01/01/technology/personaltech/01zune.html) --Steve Bellovin, http://www.cs.columbia.edu/~smb From ssaner at hubris.net Wed Dec 31 19:20:28 2008 From: ssaner at hubris.net (Steven Saner) Date: Wed, 31 Dec 2008 19:20:28 -0600 Subject: Leap second tonight In-Reply-To: References: Message-ID: <495C1A5C.6010600@hubris.net> Jon Meek wrote: > My Solaris 10 boxes are all happy (and did not reboot). I monitor NTP > on a number > of devices, including one router. The router was off by one second for > a while, but > is OK after an hour. Everything else was fine immediately. > > In 2005, our CDMA clock got the leap second between 15:08 and 15:38 > EST creating > some issues due to disagreement with the (too few) GPS clocks. > > Jon > > On Wed, Dec 31, 2008 at 7:53 PM, Wil Schultz wrote: >> At which point my Solaris 10 v490's reboot in unison, lovely. >> >> Anyone else see anything interesting? >> >> -wil I run a bunch of Slackware Linux boxes of varying versions. As best as I can tell, at or around 00:00 UTC all of my Slackware 12.0 boxes crashed with a kernel panic. I don't think it is ntpd because it is the same version as on 12.1 boxes (4.2.4p0) that did not crash. It may be the kernel: 2.6.21.5 Anyone else experience similar or was this coincidental and I have other issues... Steve -- -------------------------------------------------------------------------- Steven Saner Voice: 316-858-3000 Director of Network Operations Fax: 316-858-3001 Hubris Communications http://www.hubris.net