From alejandro_esquivel at costarricense.cr Sun Nov 1 01:37:48 2009 From: alejandro_esquivel at costarricense.cr (ALEJANDRO ESQUIVEL RODRIGUEZ) Date: Sun, 01 Nov 2009 00:37:48 -0600 Subject: Peering in Latin America In-Reply-To: <5b6f80200910312031h16c92985n4326e0acd566a185@mail.gmail.com> References: <5b6f80200910312031h16c92985n4326e0acd566a185@mail.gmail.com> Message-ID: Ken,, ? Please contact the following persons: ? For RACSA:? Luis Kopper (kopper at racsa.co.cr) ? For ICE:??????? Oscar Romero (oromero at ice.go.cr) Luis and Oscar understand BGP and others terms about SP. Regards!! ----- Mensaje original ----- De: Ken Gilmour Fecha: S?bado, 31 de Octubre de 2009, 9:33 pm Asunto: Peering in Latin America A: nanog at nanog.org > Hi There, > > I am looking for carriers who offer peering in Latin America > (Specifically Costa Rica). So far the only carrier in Costa Rica > who I > have been able to find that does this is ADN (American Data Networks, > www.data.cr). While they are already on my list for a quote, we need > at least one other diverse connection, so I would appreciate if anyone > else would be able to help me find other carriers who operate here? > Here's who i've contacted so far: > > RACSA - Can't get past 1st level support (they don't know what > BGP is) > ICE - Tried contacting a person who's address I was previously given > from NANOG to no avail > Global Crossing - Said they contacted an engineer who would get back > to me, mailed them 4 times since to no avail (no bounced emails > either). > Level 3 - Apparently don't operate in Latin America > AT&T - Want us to have a minimum of 3 locations in the US to > peer with first > > So far ADN are the only carrier who have actually been of any help. > Quick Googling for "BGP Peering Latin America" and "BGP Peering Costa > Rica" and several variations thereof is not yielding any fruitful > results. > > Thanks and regards, > > Ken > From randy at psg.com Sun Nov 1 02:06:31 2009 From: randy at psg.com (Randy Bush) Date: Sun, 01 Nov 2009 17:06:31 +0900 Subject: Upstream BGP community support In-Reply-To: References: Message-ID: > The answer is fairly simple. Does your business benefit by having the > ability to modify routing strategy as you see fit? hint: we live in a commons From kauer at biplane.com.au Sun Nov 1 04:11:44 2009 From: kauer at biplane.com.au (Karl Auer) Date: Sun, 01 Nov 2009 21:11:44 +1100 Subject: Upstream BGP community support In-Reply-To: References: Message-ID: <1257070304.4753.477.camel@karl> On Sun, 2009-11-01 at 17:06 +0900, Randy Bush wrote: > > The answer is fairly simple. Does your business benefit by having the > > ability to modify routing strategy as you see fit? > > hint: we live in a commons Yes. I was about to ask Tony "what if *their* business benefits by NOT giving you the ability to modify routing strategy as you see fit?" What's the answer then? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From isabeldias1 at yahoo.com Sun Nov 1 06:01:21 2009 From: isabeldias1 at yahoo.com (isabel dias) Date: Sun, 1 Nov 2009 04:01:21 -0800 (PST) Subject: Peering in Latin America In-Reply-To: <4AED0345.4010501@gmail.com> References: <5b6f80200910312031h16c92985n4326e0acd566a185@mail.gmail.com> <4AED0345.4010501@gmail.com> Message-ID: <281786.38314.qm@web52611.mail.re2.yahoo.com> How many times more anyone will be lookin to ask the same questions. IX's (peering) are there and most likely companies have presence either on the NY IX or LINX so ask them around and peer w/ them locally. Transite is a costy solution unless you want to load balance your traffic and have means of cross-charge. ----- Original Message ---- From: Dave Temkin To: Ken Gilmour Cc: nanog at nanog.org Sent: Sun, November 1, 2009 3:40:53 AM Subject: Re: Peering in Latin America Ken Gilmour wrote: > Hi There, > > I am looking for carriers who offer peering in Latin America > (Specifically Costa Rica). So far the only carrier in Costa Rica who I > have been able to find that does this is ADN (American Data Networks, > www.data.cr). While they are already on my list for a quote, we need > at least one other diverse connection, so I would appreciate if anyone > else would be able to help me find other carriers who operate here? > Here's who i've contacted so far: > > RACSA - Can't get past 1st level support (they don't know what BGP is) > ICE - Tried contacting a person who's address I was previously given > from NANOG to no avail > Global Crossing - Said they contacted an engineer who would get back > to me, mailed them 4 times since to no avail (no bounced emails > either). > Level 3 - Apparently don't operate in Latin America > AT&T - Want us to have a minimum of 3 locations in the US to peer with first > > So far ADN are the only carrier who have actually been of any help. > Quick Googling for "BGP Peering Latin America" and "BGP Peering Costa > Rica" and several variations thereof is not yielding any fruitful > results. > > Thanks and regards, > > Ken > >? To be clear; are you looking for paid transit connectivity within Costa Rica for the purposes of localizing traffic or are you looking for free or reduced cost connectivity to very specific SP's in Costa Rica? -Dave From isabeldias1 at yahoo.com Sun Nov 1 06:21:07 2009 From: isabeldias1 at yahoo.com (isabel dias) Date: Sun, 1 Nov 2009 04:21:07 -0800 (PST) Subject: Upstream BGP community support In-Reply-To: <620fd17c0910311903o2d65df1dq6ef51d985a540d02@mail.gmail.com> References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> <620fd17c0910311903o2d65df1dq6ef51d985a540d02@mail.gmail.com> Message-ID: <304425.87946.qm@web52601.mail.re2.yahoo.com> There is always a?peering policy in place?and I am?sure you have a few requirements in mind and you will be evaluating costs carefully as well as options thoroughly before making a decision on which SP to go for. I am sure technical teams are flexifle to accomodate some bespoke private peering connections and have defined transit products in place so you can always negotiate your timescales w/ them as well as your technical needs. ----- Original Message ---- From: Paul Wall To: Randy Bush Cc: nanog at nanog.org Sent: Sun, November 1, 2009 2:03:26 AM Subject: Re: Upstream BGP community support On Sat, Oct 31, 2009 at 8:25 PM, Randy Bush wrote: > while i can understand folk's wanting to signal upstream using > communities, and i know it's all the rage. ?one issue needs to be > raised. BGP communities are all the rage? I don't think this is new concept or fad. Signaling behaviors as well as informing users of types of routes have been around for awhile. For example, RFC1998 (Aug 1996) outlines some of these behaviors with modifying local preference. Even Sprint was advertising the ability to not advertise or prepend to individual peers back in 2002 (http://web.archive.org/web/20020607092619/www.sprintlink.net/policy/bgp.html). > so i ain't sayin' don't do it. ?after all, who would deny you the > ability to show off your bgp macho? How is providing better capabilities for your customers macho? People have been using these knobs 10 years ago and it worked then (just as well as it works now). Drive Slow (as there are trick-or-treaters out tonight) From isabeldias1 at yahoo.com Sun Nov 1 06:24:29 2009 From: isabeldias1 at yahoo.com (isabel dias) Date: Sun, 1 Nov 2009 04:24:29 -0800 (PST) Subject: Peering in Latin America In-Reply-To: References: <5b6f80200910312031h16c92985n4326e0acd566a185@mail.gmail.com> <4AED0345.4010501@gmail.com> <5b6f80200910312053q56598827w978157ba4bb96e45@mail.gmail.com> <5b6f80200910312103x335577bcm483ac7329c06bc9c@mail.gmail.com> <4AED0CFC.8090105@rollernet.us> <5b6f80200910312130r25fd63a2sa62aa58663cf65dc@mail.gmail.com> Message-ID: <304331.41010.qm@web52603.mail.re2.yahoo.com> peering in the IX's?a.k.a peering -> unless is a payed service =private-peering! at the exchange ----- Original Message ---- From: Mike Lyon To: Ken Gilmour Cc: "nanog at nanog.org" Sent: Sun, November 1, 2009 4:38:44 AM Subject: Re: Peering in Latin America You may want to double check your verbage when talking with providers. Transit = you pay for the bandwidth. Peering = free and is a mutual agreement between the two providers. Sounds like you want transit. I'd stop using the "peering" word as it may be confusing people, including your providers. Cheers, Mike On Oct 31, 2009, at 21:30, Ken Gilmour wrote: > 2009/10/31 Seth Mattinen : >> Ken Gilmour wrote: >>> >>> We have BGP4 networks in other locations (IPv4 and IPv6) - Costa Rica >>> being one of the places that don't have it... We would really like to >>> be able to implement it here but are finding it difficult to find SPs >>> who support Customers who advertise their own PI space. >>> >> >> It doesn't sound like you want peering - specifically AT&T's answer >> implies they think you want settlement-free peering when you just want >> to announce your routes via BGP (aka paid transit). >> >> ~Seth >> >> > > Yes - Sorry my initial approach to NANOG was not very specific! > However my approach to the SPs was very specific (and ADN understood > exactly what I wanted when I first approached them and are working on > a quote)... I specifically asked how we would go about getting a > second point-to-point link and peer with them over that link (and for > existing providers such as ICE and RACSA) how we could upgrade our > current contract to allow us to announce our own PI space... I am not > sure how I could be any more specific than that... > > Ken > From mvh at hosteurope.de Sun Nov 1 08:58:01 2009 From: mvh at hosteurope.de (Malte von dem Hagen) Date: Sun, 01 Nov 2009 15:58:01 +0100 Subject: Peering in Latin America In-Reply-To: <304331.41010.qm@web52603.mail.re2.yahoo.com> References: <5b6f80200910312031h16c92985n4326e0acd566a185@mail.gmail.com> <4AED0345.4010501@gmail.com> <5b6f80200910312053q56598827w978157ba4bb96e45@mail.gmail.com> <5b6f80200910312103x335577bcm483ac7329c06bc9c@mail.gmail.com> <4AED0CFC.8090105@rollernet.us> <5b6f80200910312130r25fd63a2sa62aa58663cf65dc@mail.gmail.com> <304331.41010.qm@web52603.mail.re2.yahoo.com> Message-ID: <4AEDA1F9.6080906@hosteurope.de> G'day, Am 01.11.2009 13:24 Uhr schrieb isabel dias: > peering in the IX's a.k.a peering -> unless is a payed service =private-peering! at the exchange despite full sentences are clearly better to understand, the term "_private_ peering" does not necessarily include payments. It just means that the interconnect is not realized via a _public_ infrastructure as an IX's network e.g., but via _discrete_ p2p links, for example. Paid services are often referred to as "transit" or sometimes even "transit light" (meaning "my network and the ones of my customers", german Telekom uses this) or explicitly "_paid_ peering" (which is a misuse of the word peering, imho, as e.g. used by Arcor/Vodafone). At least over here the nomenclature is like that ;-) Kind regards, .m -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From camunguia1 at yahoo.com Sun Nov 1 09:18:50 2009 From: camunguia1 at yahoo.com (carlos munguia) Date: Sun, 1 Nov 2009 07:18:50 -0800 (PST) Subject: Peering in Latin America Message-ID: <627884.63224.qm@web33205.mail.mud.yahoo.com> Hi I'm L2 support in El salvador CTE , we have L3 support from Costa Rica TAC Carriers . You can contact (506)2211-0487/ -22110454 TAC Carriers to get L3 support. (they are L3 Cisco Support for all central america NOC's) best regards ------------------------------------------------------ Message: 3 Date: Sat, 31 Oct 2009 21:31:34 -0600 From: Ken Gilmour Subject: Peering in Latin America To: nanog at nanog.org Message-ID: <5b6f80200910312031h16c92985n4326e0acd566a185 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 > Hi There, > >> >> I am looking for carriers who offer peering in Latin America >> (Specifically Costa Rica). So far the only carrier in Costa Rica who I >> have been able to find that does this is ADN (American Data Networks, >> www.data.cr). While they are already on my list for a quote, we need >> at least one other diverse connection, so I would appreciate if anyone >> else would be able to help me find other carriers who operate here? >> Here's who i've contacted so far: >> >> RACSA - Can't get past 1st level support (they don't know what BGP is) >> ICE - Tried contacting a person who's address I was previously given >> from NANOG to no avail >> Global Crossing - Said they contacted an engineer who would get back >> to me, mailed them 4 times since to no avail (no bounced emails >> either). >> Level 3 - Apparently don't operate in Latin America >> AT&T - Want us to have a minimum of 3 locations in the US to peer with >> first >> >> So far ADN are the only carrier who have actually been of any help. >> Quick Googling for "BGP Peering Latin America" and "BGP Peering Costa >> Rica" and several variations thereof is not yielding any fruitful >> results. >> >> Thanks and regards, >> From conradus at gmail.com Sun Nov 1 10:09:50 2009 From: conradus at gmail.com (Otmar Conradus) Date: Sun, 1 Nov 2009 12:09:50 -0400 Subject: Peering in Latin America In-Reply-To: <5b6f80200910312031h16c92985n4326e0acd566a185@mail.gmail.com> References: <5b6f80200910312031h16c92985n4326e0acd566a185@mail.gmail.com> Message-ID: Hi, Have you tried Columbus Networks? They are the owners of the ARCOS fiber cable and do have a landing point in Costa Rica. Check their website: http://www.nwncable.com/ Otmar On Sat, Oct 31, 2009 at 11:31 PM, Ken Gilmour wrote: > Hi There, > > I am looking for carriers who offer peering in Latin America > (Specifically Costa Rica). So far the only carrier in Costa Rica who I > have been able to find that does this is ADN (American Data Networks, > www.data.cr). While they are already on my list for a quote, we need > at least one other diverse connection, so I would appreciate if anyone > else would be able to help me find other carriers who operate here? > Here's who i've contacted so far: > > RACSA - Can't get past 1st level support (they don't know what BGP is) > ICE - Tried contacting a person who's address I was previously given > from NANOG to no avail > Global Crossing - Said they contacted an engineer who would get back > to me, mailed them 4 times since to no avail (no bounced emails > either). > Level 3 - Apparently don't operate in Latin America > AT&T - Want us to have a minimum of 3 locations in the US to peer with first > > So far ADN are the only carrier who have actually been of any help. > Quick Googling for "BGP Peering Latin America" and "BGP Peering Costa > Rica" and several variations thereof is not yielding any fruitful > results. > > Thanks and regards, > > Ken > > From jmamodio at gmail.com Sun Nov 1 11:42:46 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Sun, 1 Nov 2009 12:42:46 -0500 Subject: Peering in Latin America In-Reply-To: <5b6f80200910312130r25fd63a2sa62aa58663cf65dc@mail.gmail.com> References: <5b6f80200910312031h16c92985n4326e0acd566a185@mail.gmail.com> <4AED0345.4010501@gmail.com> <5b6f80200910312053q56598827w978157ba4bb96e45@mail.gmail.com> <5b6f80200910312103x335577bcm483ac7329c06bc9c@mail.gmail.com> <4AED0CFC.8090105@rollernet.us> <5b6f80200910312130r25fd63a2sa62aa58663cf65dc@mail.gmail.com> Message-ID: <202705b0911010942i7a3a232fn1105b49085a6d556@mail.gmail.com> You are still confusing peering and transit with ability to announce your IP prefix via BGP. It may be very useful to others willing to help, if you provide a better detail of what kind of recipe you want to cook instead of asking where you can find the individual ingredients. Regards Jorge On Sat, Oct 31, 2009 at 11:30 PM, Ken Gilmour wrote: > 2009/10/31 Seth Mattinen : >> Ken Gilmour wrote: >>> >>> We have BGP4 networks in other locations (IPv4 and IPv6) - Costa Rica >>> being one of the places that don't have it... We would really like to >>> be able to implement it here but are finding it difficult to find SPs >>> who support Customers who advertise their own PI space. >>> >> >> It doesn't sound like you want peering - specifically AT&T's answer >> implies they think you want settlement-free peering when you just want >> to announce your routes via BGP (aka paid transit). >> >> ~Seth >> >> > > Yes - Sorry my initial approach to NANOG was not very specific! > However my approach to the SPs was very specific (and ADN understood > exactly what I wanted when I first approached them and are working on > a quote)... I specifically asked how we would go about getting a > second point-to-point link and peer with them over that link (and for > existing providers such as ICE and RACSA) how we could upgrade our > current contract to allow us to announce our own PI space... I am not > sure how I could be any more specific than that... > > Ken > > From Valdis.Kletnieks at vt.edu Sun Nov 1 11:59:19 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 01 Nov 2009 12:59:19 -0500 Subject: Upstream BGP community support In-Reply-To: Your message of "Sat, 31 Oct 2009 19:33:52 CDT." <20091101003352.GB81416@blackrose.org> References: <20091031220938.GE51443@gerbil.cluepon.net> <20091031232738.GF51443@gerbil.cluepon.net> <20091031233531.GA81416@blackrose.org> <20091031234903.GG51443@gerbil.cluepon.net> <20091101003352.GB81416@blackrose.org> Message-ID: <11919.1257098359@turing-police.cc.vt.edu> On Sat, 31 Oct 2009 19:33:52 CDT, Dorian Kim said: > Fact is, regardless of whether you or I think it makes any sense or > not is that some peering agreements preclude disclosure of the locations > of peering, and in some extreme cases even the disclosure of the > existance of said peering. As Louis Mamakos pointed out back in 1992 or so, it's hard to conceal the existence of said peering: http://www-cs-students.stanford.edu/~hansell/humor/wormholes (Unfortunately, this is the only copy online I was able to find, and it's missing the e-mail headers. The one I had has gone astray. Gene Spafford used to have a copy online for a class, but it too appears to have evaporated. Anybody got a pointer to the original? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jeffrey.lyon at blacklotus.net Sun Nov 1 12:18:20 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sun, 1 Nov 2009 14:18:20 -0400 Subject: Peering in Latin America In-Reply-To: <627884.63224.qm@web33205.mail.mud.yahoo.com> References: <627884.63224.qm@web33205.mail.mud.yahoo.com> Message-ID: <16720fe00911011018ua0a5e44oac24437ece22619e@mail.gmail.com> If you're not particular to a certain country you can try Terremark Bogota (Colombia). Their U.S. sales can put you in touch. Best regards, Jeff On Sun, Nov 1, 2009 at 11:18 AM, carlos munguia wrote: > > > > > > > Hi > > I'm L2 support in El salvador CTE , we have L3 support from Costa Rica ?TAC Carriers ?. > You can contact (506)2211-0487/ -22110454 ?TAC Carriers ?to get L3 support. (they are L3 Cisco Support for all central america NOC's) > > best regards > > > ------------------------------------------------------ > Message: 3 > Date: Sat, 31 Oct 2009 21:31:34 -0600 > From: Ken Gilmour > Subject: Peering in Latin America > To: nanog at nanog.org > Message-ID: > ? ?<5b6f80200910312031h16c92985n4326e0acd566a185 at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > >> Hi There, >> >>> >>> I am looking for carriers who offer peering in Latin America >>> (Specifically Costa Rica). So far the only carrier in Costa Rica who I >>> have been able to find that does this is ADN (American Data Networks, >>> www.data.cr). While they are already on my list for a quote, we need >>> at least one other diverse > ?connection, so I would appreciate if anyone >>> else would be able to help me find other carriers who operate here? >>> Here's who i've contacted so far: >>> >>> RACSA - Can't get past 1st level support (they don't know what BGP is) >>> ICE - Tried contacting a person who's address I was previously given >>> from NANOG to no avail >>> Global Crossing - Said they contacted an engineer who would get back >>> to me, mailed them 4 times since to no avail (no bounced emails >>> either). >>> Level 3 - Apparently don't operate in Latin America >>> AT&T - Want us to have a minimum of 3 locations in the US to peer with >>> first >>> >>> So far ADN are the only carrier who have actually been of any help. >>> Quick Googling for "BGP Peering Latin America" and "BGP Peering Costa >>> Rica" and several variations thereof is not yielding > ?any fruitful >>> results. >>> >>> Thanks and regards, >>> > > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From isabeldias1 at yahoo.com Sun Nov 1 12:48:50 2009 From: isabeldias1 at yahoo.com (isabel dias) Date: Sun, 1 Nov 2009 10:48:50 -0800 (PST) Subject: Peering in Latin America In-Reply-To: <4AEDA1F9.6080906@hosteurope.de> References: <5b6f80200910312031h16c92985n4326e0acd566a185@mail.gmail.com> <4AED0345.4010501@gmail.com> <5b6f80200910312053q56598827w978157ba4bb96e45@mail.gmail.com> <5b6f80200910312103x335577bcm483ac7329c06bc9c@mail.gmail.com> <4AED0CFC.8090105@rollernet.us> <5b6f80200910312130r25fd63a2sa62aa58663cf65dc@mail.gmail.com> <304331.41010.qm@web52603.mail.re2.yahoo.com> <4AEDA1F9.6080906@hosteurope.de> Message-ID: <253534.28187.qm@web52602.mail.re2.yahoo.com> Just depends of the policy based billing /billing models in place.?If "billing" is seen as a service?the common denominator is the charge the port otherwise a variety of other elements. ----- Original Message ---- From: Malte von dem Hagen To: isabel dias Cc: Mike Lyon ; Ken Gilmour ; "nanog at nanog.org" Sent: Sun, November 1, 2009 2:58:01 PM Subject: Re: Peering in Latin America G'day, Am 01.11.2009 13:24 Uhr schrieb isabel dias: > peering in the IX's a.k.a peering -> unless is a payed service =private-peering! at the exchange despite full sentences are clearly better to understand, the term "_private_ peering" does not necessarily include payments. It just means that the interconnect is not realized via a _public_ infrastructure as an IX's network e.g., but via _discrete_ p2p links, for example. Paid services are often referred to as "transit" or sometimes even "transit light" (meaning "my network and the ones of my customers", german Telekom uses this) or explicitly "_paid_ peering" (which is a misuse of the word peering, imho, as e.g. used by Arcor/Vodafone). At least over here the nomenclature is like that ;-) Kind regards, .m From michael at linuxmagic.com Sun Nov 1 18:09:12 2009 From: michael at linuxmagic.com (Michael Peddemors) Date: Sun, 1 Nov 2009 17:09:12 -0700 Subject: Peering in Latin America In-Reply-To: <5b6f80200910312031h16c92985n4326e0acd566a185@mail.gmail.com> References: <5b6f80200910312031h16c92985n4326e0acd566a185@mail.gmail.com> Message-ID: <200911011609.12589.michael@linuxmagic.com> Isn't skylink offering peering? On October 31, 2009, Ken Gilmour wrote: > Hi There, > > I am looking for carriers who offer peering in Latin America > (Specifically Costa Rica). So far the only carrier in Costa Rica who I > have been able to find that does this is ADN (American Data Networks, > www.data.cr). While they are already on my list for a quote, we need > at least one other diverse connection, so I would appreciate if anyone > else would be able to help me find other carriers who operate here? > Here's who i've contacted so far: > > RACSA - Can't get past 1st level support (they don't know what BGP is) > ICE - Tried contacting a person who's address I was previously given > from NANOG to no avail > Global Crossing - Said they contacted an engineer who would get back > to me, mailed them 4 times since to no avail (no bounced emails > either). > Level 3 - Apparently don't operate in Latin America > AT&T - Want us to have a minimum of 3 locations in the US to peer with > first > > So far ADN are the only carrier who have actually been of any help. > Quick Googling for "BGP Peering Latin America" and "BGP Peering Costa > Rica" and several variations thereof is not yielding any fruitful > results. > > Thanks and regards, > > Ken > -- -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors - President/CEO - LinuxMagic Products, Services, Support and Development Visit us at http://www.linuxmagic.com ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-589-0037 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From steve at ibctech.ca Sun Nov 1 19:09:40 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Sun, 01 Nov 2009 20:09:40 -0500 Subject: Upstream BGP community support In-Reply-To: References: Message-ID: <4AEE3154.707@ibctech.ca> Andy B. wrote: > Hi, > > Quick question: Would you buy transit from someone who does not > support BGP communities? Without reading any more of your post, or any of the replies: - because leadership has a better bandwidth deal - cuz even though shit in one hand is heavier than hope in the other, you can't convince anyone What sucks: - having to deal with transit from someone who performs no filtering whatsoever - dealing with transit who DOESN'T RESPOND TO REQUESTS FOR BGP PEERING - dealing with transits who don't know what v6 is, or won't respond to requests (at all), even though the network who is purchasing their transport has better v6 redundancy than v4. I am AS14270. BGP with me... its been two years... you've got to have an engineer who can set up a session by now, no? Steve From tvarriale at comcast.net Sun Nov 1 19:24:53 2009 From: tvarriale at comcast.net (Tony Varriale) Date: Sun, 1 Nov 2009 19:24:53 -0600 Subject: Upstream BGP community support References: <1257070304.4753.477.camel@karl> Message-ID: If you read the original post, the poster implied he would benefit from communities. If you would like to discuss who,what, when,why and the theoretical, please start your own thread. tv ----- Original Message ----- From: "Karl Auer" To: Sent: Sunday, November 01, 2009 4:11 AM Subject: Re: Upstream BGP community support From ras at e-gerbil.net Sun Nov 1 20:07:35 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Sun, 1 Nov 2009 20:07:35 -0600 Subject: Upstream BGP community support In-Reply-To: <4AEE3154.707@ibctech.ca> References: <4AEE3154.707@ibctech.ca> Message-ID: <20091102020735.GM51443@gerbil.cluepon.net> On Sun, Nov 01, 2009 at 08:09:40PM -0500, Steve Bertrand wrote: > I am AS14270. BGP with me... its been two years... you've got to have an > engineer who can set up a session by now, no? Sounds like someone needs to send you a copy of "They Just Don't Want To Peer With You". :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From steve at ibctech.ca Sun Nov 1 20:18:56 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Sun, 01 Nov 2009 21:18:56 -0500 Subject: Upstream BGP community support In-Reply-To: <20091102020735.GM51443@gerbil.cluepon.net> References: <4AEE3154.707@ibctech.ca> <20091102020735.GM51443@gerbil.cluepon.net> Message-ID: <4AEE4190.4030408@ibctech.ca> Richard A Steenbergen wrote: > On Sun, Nov 01, 2009 at 08:09:40PM -0500, Steve Bertrand wrote: >> I am AS14270. BGP with me... its been two years... you've got to have an >> engineer who can set up a session by now, no? > > Sounds like someone needs to send you a copy of "They Just Don't Want To > Peer With You". :) Well, send it over... I'd like to see a copy of "Here's why" ...first. Steve From steve at ibctech.ca Sun Nov 1 20:30:59 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Sun, 01 Nov 2009 21:30:59 -0500 Subject: Upstream BGP community support In-Reply-To: <20091102020735.GM51443@gerbil.cluepon.net> References: <4AEE3154.707@ibctech.ca> <20091102020735.GM51443@gerbil.cluepon.net> Message-ID: <4AEE4463.5040804@ibctech.ca> Richard A Steenbergen wrote: > On Sun, Nov 01, 2009 at 08:09:40PM -0500, Steve Bertrand wrote: >> I am AS14270. BGP with me... its been two years... you've got to have an >> engineer who can set up a session by now, no? > > Sounds like someone needs to send you a copy of "They Just Don't Want To > Peer With You". :) fwiw, - I have a spotless BGP record v6-wise. - even though I am a small provider, I have ops from large providers who will vouch for me - we have s/rtbh everywhere - we ensure that my network does not spam (and if it does, I collapse things quickly) - even though I'm small, I'll entertain legitimate complaints from known ops immediately, and fix them - I have an *extremely* tight iBGP practice happening. Although I'm not a CCIE, I know what I'm doing. To be honest, I think that I could help my upstream. Meh. Here's to no redundancy. Come on guys, without names, feel the clue bat, and finally get back to me. Steve From steve at ibctech.ca Sun Nov 1 20:43:21 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Sun, 01 Nov 2009 21:43:21 -0500 Subject: Upstream BGP community support In-Reply-To: <20091102020735.GM51443@gerbil.cluepon.net> References: <4AEE3154.707@ibctech.ca> <20091102020735.GM51443@gerbil.cluepon.net> Message-ID: <4AEE4749.1030808@ibctech.ca> Richard A Steenbergen wrote: > On Sun, Nov 01, 2009 at 08:09:40PM -0500, Steve Bertrand wrote: >> I am AS14270. BGP with me... its been two years... you've got to have an >> engineer who can set up a session by now, no? > > Sounds like someone needs to send you a copy of "They Just Don't Want To > Peer With You". :) ...and directly to your statement: send the book along. I'm not looking for a 'peer'. This is a situation that my PROVIDER won't set up a BGP SESSION with me, and they continue to STATICALLY ROUTE my ARIN ALLOCATED block to me. They advertise it from their AS. Their AS advertises known bad space to me (which I've complained about). Their AS, In my humble opinion, is completely unreliable and non-trustworthy. My ARIN block is advertised by them, and I HATE it. They will not respond to me when I ask them to allow me to advertise my own space to them. Of course, having them 'listen' for my space, it would also allow me to advertise to other 'providers' which would allow for redundancy.... Note...I have a /21. It's not like I'm advertising a /24, nor am I trying to do something that isn't in the best interest of my community. Steve From joelja at bogus.com Sun Nov 1 21:00:02 2009 From: joelja at bogus.com (joel jaeggli) Date: Sun, 01 Nov 2009 19:00:02 -0800 Subject: Upstream BGP community support In-Reply-To: <4AEE4749.1030808@ibctech.ca> References: <4AEE3154.707@ibctech.ca> <20091102020735.GM51443@gerbil.cluepon.net> <4AEE4749.1030808@ibctech.ca> Message-ID: <4AEE4B32.3080705@bogus.com> Steve Bertrand wrote: > Richard A Steenbergen wrote: >> On Sun, Nov 01, 2009 at 08:09:40PM -0500, Steve Bertrand wrote: >>> I am AS14270. BGP with me... its been two years... you've got to have an >>> engineer who can set up a session by now, no? >> Sounds like someone needs to send you a copy of "They Just Don't Want To >> Peer With You". :) > > ...and directly to your statement: > > send the book along. I'm not looking for a 'peer'. > > This is a situation that my PROVIDER won't set up a BGP SESSION with me, > and they continue to STATICALLY ROUTE my ARIN ALLOCATED block to me. Perhaps it's time to find a new isp, something called adsl4u.ca doesn't sounds like a wholesale transit provider. > They advertise it from their AS. Their AS advertises known bad space to > me (which I've complained about). Their AS, In my humble opinion, is > completely unreliable and non-trustworthy. My ARIN block is advertised > by them, and I HATE it. They will not respond to me when I ask them to > allow me to advertise my own space to them. > > Of course, having them 'listen' for my space, it would also allow me to > advertise to other 'providers' which would allow for redundancy.... > > Note...I have a /21. It's not like I'm advertising a /24, nor am I > trying to do something that isn't in the best interest of my community. > > Steve > > > From steve at ibctech.ca Sun Nov 1 21:12:53 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Sun, 01 Nov 2009 22:12:53 -0500 Subject: Upstream BGP community support In-Reply-To: <4AEE4B32.3080705@bogus.com> References: <4AEE3154.707@ibctech.ca> <20091102020735.GM51443@gerbil.cluepon.net> <4AEE4749.1030808@ibctech.ca> <4AEE4B32.3080705@bogus.com> Message-ID: <4AEE4E35.1070101@ibctech.ca> joel jaeggli wrote: > Steve Bertrand wrote: >> Richard A Steenbergen wrote: >>> On Sun, Nov 01, 2009 at 08:09:40PM -0500, Steve Bertrand wrote: >>>> I am AS14270. BGP with me... its been two years... you've got to have an >>>> engineer who can set up a session by now, no? >>> Sounds like someone needs to send you a copy of "They Just Don't Want To >>> Peer With You". :) >> ...and directly to your statement: >> >> send the book along. I'm not looking for a 'peer'. >> >> This is a situation that my PROVIDER won't set up a BGP SESSION with me, >> and they continue to STATICALLY ROUTE my ARIN ALLOCATED block to me. > > Perhaps it's time to find a new isp, something called adsl4u.ca doesn't > sounds like a wholesale transit provider. Who do you recommend? I give my situation to people, and they run... Steve From martin at theicelandguy.com Sun Nov 1 21:59:10 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Sun, 1 Nov 2009 22:59:10 -0500 Subject: Upstream BGP community support In-Reply-To: <4AEE4749.1030808@ibctech.ca> References: <4AEE3154.707@ibctech.ca> <20091102020735.GM51443@gerbil.cluepon.net> <4AEE4749.1030808@ibctech.ca> Message-ID: On Sun, Nov 1, 2009 at 9:43 PM, Steve Bertrand wrote: > Richard A Steenbergen wrote: > > On Sun, Nov 01, 2009 at 08:09:40PM -0500, Steve Bertrand wrote: > >> I am AS14270. BGP with me... its been two years... you've got to have an > >> engineer who can set up a session by now, no? > > > > Sounds like someone needs to send you a copy of "They Just Don't Want To > > Peer With You". :) > > ...and directly to your statement: > > send the book along. I'm not looking for a 'peer'. > > This is a situation that my PROVIDER won't set up a BGP SESSION with me, > and they continue to STATICALLY ROUTE my ARIN ALLOCATED block to me. > > They advertise it from their AS. Their AS advertises known bad space to > me (which I've complained about). Their AS, In my humble opinion, is > completely unreliable and non-trustworthy. My ARIN block is advertised > by them, and I HATE it. They will not respond to me when I ask them to > allow me to advertise my own space to them. > > Of course, having them 'listen' for my space, it would also allow me to > advertise to other 'providers' which would allow for redundancy.... > > Note...I have a /21. It's not like I'm advertising a /24, nor am I > trying to do something that isn't in the best interest of my community. > > Steve > What's the block? -M< -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From steve at ibctech.ca Sun Nov 1 22:01:28 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Sun, 01 Nov 2009 23:01:28 -0500 Subject: Small guys with BGP issues Message-ID: <4AEE5998.6060009@ibctech.ca> Seems to me that some people have issues when a thread is taken over. capiche... However, it also seems to me that there are people here who are intelligent engineers who are afraid to speak, due to the size of the company they work for. On behalf of the 'small guys', it sucks when you big(ger) guys: - don't listen to us - practice good behaviour (bcp38) and don't preach it - speak proudly of decent support, but don't respond to people who aren't staffed by a tier(x) - act as though you know something, but won't get out of the textbook mentality - again, this isn't a test for ccie, just because were working in smaller *sp's doesn't mean that we know less than you - we work hard. We have smaller networks. I bet we defend our border egress to you than you defend toward us - if all small guys like me are the same, then the 'big boys' should be motivated to move forward Lets take it off topic and off-thread... This is a big-boy list. Out of the small guys on this big boy list, lets have a hands-up for who is doing the right thing (v6 & network defence & protecting their connected networks )... Steve From mpetach at netflight.com Sun Nov 1 22:17:49 2009 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 1 Nov 2009 21:17:49 -0700 Subject: Upstream BGP community support In-Reply-To: <63ac96a50911012016w28fcd998g46c16be1a11901bd@mail.gmail.com> References: <4AEE3154.707@ibctech.ca> <63ac96a50911012016w28fcd998g46c16be1a11901bd@mail.gmail.com> Message-ID: <63ac96a50911012017y2853671gc3571b1d1c59877@mail.gmail.com> On Sun, Nov 1, 2009 at 6:09 PM, Steve Bertrand wrote: ... > I am AS14270. BGP with me... I tried, but I couldn't find you in http://peeringdb.org/ > its been two years... you've got to have an > engineer who can set up a session by now, no? > > Steve You might consider just taking matters into your own hands, and getting a connection to an exchange point, adding an entry into peeringdb, and start doing BGP with other folks; announce your /21 directly to people, and it's likely your upstream will suddenly wake up and smell the coffee when they realize you've actually become truly multihomed in spite of them. Nothing shows clue factor quite as much as, well, practical demonstrations--and turning up sessions with other networks at an exchange point is a really good way to let folks see the level at which you're ready to play. Best of luck! Matt From steve at ibctech.ca Sun Nov 1 22:18:13 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Sun, 01 Nov 2009 23:18:13 -0500 Subject: Upstream BGP community support In-Reply-To: References: <4AEE3154.707@ibctech.ca> <20091102020735.GM51443@gerbil.cluepon.net> <4AEE4749.1030808@ibctech.ca> Message-ID: <4AEE5D85.1040104@ibctech.ca> Martin Hannigan wrote: > > > On Sun, Nov 1, 2009 at 9:43 PM, Steve Bertrand > wrote: > > Richard A Steenbergen wrote: > > On Sun, Nov 01, 2009 at 08:09:40PM -0500, Steve Bertrand wrote: > >> I am AS14270. BGP with me... its been two years... you've got to > have an > >> engineer who can set up a session by now, no? > > > > Sounds like someone needs to send you a copy of "They Just Don't > Want To > > Peer With You". :) > > ...and directly to your statement: > > send the book along. I'm not looking for a 'peer'. > > This is a situation that my PROVIDER won't set up a BGP SESSION with me, > and they continue to STATICALLY ROUTE my ARIN ALLOCATED block to me. > > They advertise it from their AS. Their AS advertises known bad space to > me (which I've complained about). Their AS, In my humble opinion, is > completely unreliable and non-trustworthy. My ARIN block is advertised > by them, and I HATE it. They will not respond to me when I ask them to > allow me to advertise my own space to them. > > Of course, having them 'listen' for my space, it would also allow me to > advertise to other 'providers' which would allow for redundancy.... > > Note...I have a /21. It's not like I'm advertising a /24, nor am I > trying to do something that isn't in the best interest of my community. > > Steve > > > > What's the block? Martin, I learnt early on that NANOG is not suitable to stage a reliable 'notification'. I was merely remarking (perhaps out of frustration) on the thread. Steve From steve at ibctech.ca Sun Nov 1 22:40:55 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Sun, 01 Nov 2009 23:40:55 -0500 Subject: Small guys with BGP issues In-Reply-To: <4AEE5998.6060009@ibctech.ca> References: <4AEE5998.6060009@ibctech.ca> Message-ID: <4AEE62D7.3040202@ibctech.ca> Steve Bertrand wrote: > Seems to me that some people have issues when a thread is taken over. > capiche... > > However, it also seems to me that there are people here who are > intelligent engineers who are afraid to speak, due to the size of the > company they work for. > > On behalf of the 'small guys', it sucks when you big(ger) guys: > > - don't listen to us > - practice good behaviour (bcp38) and don't preach it > - speak proudly of decent support, but don't respond to people who > aren't staffed by a tier(x) > - act as though you know something, but won't get out of the textbook > mentality > - again, this isn't a test for ccie, just because were working in > smaller *sp's doesn't mean that we know less than you > - we work hard. We have smaller networks. I bet we defend our border > egress to you than you defend toward us > - if all small guys like me are the same, then the 'big boys' should be > motivated to move forward > > Lets take it off topic and off-thread... > > This is a big-boy list. Out of the small guys on this big boy list, lets > have a hands-up for who is doing the right thing (v6 & network defence & > protecting their connected networks )... Holy shiat, I can't even deal with the off-list feedback! Thank you! Politically, unfortunately, I'm not that type. I can't do much there. I wish that I could make decisions with the company purse, but I can't... On the other hand, I wish I could direct operations. I know what needs to be done, and I know how to command people to get there. I *think* I know how to direct an entire company (given its geo-location) to success given the area it's in. Nonetheless, I am where I am, and I like it. I am responsible for what comes into my network, and what leaves it. I have written an ISP management system, and ensure/troubleshoot montly revenue streams. I love my job. I love being an ISP. Unfortunately, my ISP doesn't love me the same way. ( I can understand the business aspect, but at least show that you are technically inclined!) Steve From patrick at ianai.net Sun Nov 1 22:47:25 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 1 Nov 2009 23:47:25 -0500 Subject: Small guys with BGP issues In-Reply-To: <4AEE5998.6060009@ibctech.ca> References: <4AEE5998.6060009@ibctech.ca> Message-ID: <19B95C86-540B-4B26-99BD-E9B233828ABF@ianai.net> > - practice good behaviour (bcp38) and don't preach it Did you mean preach but don't practice it? While I appreciate everyone who "preaches" it, I am not going to complain in the slightest at any "big guy" who practices BCP38. Just the opposite, I'm going to praise them whether they preach it or not. And this is not the big boy list. This is for all Operators in North America, and many who are not, regardless of size. (Well, I guess we'll exclude the guy who buys are cable/DSL link and "provides" to his mother & father with a LinkSys.) -- TTFN, patrick On Nov 1, 2009, at 11:01 PM, Steve Bertrand wrote: > Seems to me that some people have issues when a thread is taken over. > capiche... > > However, it also seems to me that there are people here who are > intelligent engineers who are afraid to speak, due to the size of the > company they work for. > > On behalf of the 'small guys', it sucks when you big(ger) guys: > > - don't listen to us > - practice good behaviour (bcp38) and don't preach it > - speak proudly of decent support, but don't respond to people who > aren't staffed by a tier(x) > - act as though you know something, but won't get out of the textbook > mentality > - again, this isn't a test for ccie, just because were working in > smaller *sp's doesn't mean that we know less than you > - we work hard. We have smaller networks. I bet we defend our border > egress to you than you defend toward us > - if all small guys like me are the same, then the 'big boys' should > be > motivated to move forward > > Lets take it off topic and off-thread... > > This is a big-boy list. Out of the small guys on this big boy list, > lets > have a hands-up for who is doing the right thing (v6 & network > defence & > protecting their connected networks )... > > Steve > From steve at ibctech.ca Sun Nov 1 22:54:07 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Sun, 01 Nov 2009 23:54:07 -0500 Subject: Small guys with BGP issues In-Reply-To: <19B95C86-540B-4B26-99BD-E9B233828ABF@ianai.net> References: <4AEE5998.6060009@ibctech.ca> <19B95C86-540B-4B26-99BD-E9B233828ABF@ianai.net> Message-ID: <4AEE65EF.3040607@ibctech.ca> Patrick W. Gilmore wrote: >> - practice good behaviour (bcp38) and don't preach it > > Did you mean preach but don't practice it? While I appreciate everyone > who "preaches" it, I am not going to complain in the slightest at any > "big guy" who practices BCP38. Just the opposite, I'm going to praise > them whether they preach it or not. I'm not a political person. Take it for what it is worth. I personally know people who do both: - practice but not preach - preach but don't practice ... however you take my point, I don't care. I just wanted it to be known that the 'guys' who do practice it should 'God willing' come out and preach it. > And this is not the big boy list. This is for all Operators in North > America, and many who are not, regardless of size. (Well, I guess we'll > exclude the guy who buys are cable/DSL link and "provides" to his mother > & father with a LinkSys.) eh, -stevieb has much respect for all those who read this list, and when he posts, feels that the big guys are looking down upon him... hopefully with approval. Steve From ras at e-gerbil.net Sun Nov 1 23:07:34 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Sun, 1 Nov 2009 23:07:34 -0600 Subject: Small guys with BGP issues In-Reply-To: <4AEE65EF.3040607@ibctech.ca> References: <4AEE5998.6060009@ibctech.ca> <19B95C86-540B-4B26-99BD-E9B233828ABF@ianai.net> <4AEE65EF.3040607@ibctech.ca> Message-ID: <20091102050734.GN51443@gerbil.cluepon.net> On Sun, Nov 01, 2009 at 11:54:07PM -0500, Steve Bertrand wrote: > I'm not a political person. Take it for what it is worth. > > I personally know people who do both: > > - practice but not preach > - preach but don't practice > > ... however you take my point, I don't care. > > I just wanted it to be known that the 'guys' who do practice it should > 'God willing' come out and preach it. > > > And this is not the big boy list. This is for all Operators in North > > America, and many who are not, regardless of size. (Well, I guess we'll > > exclude the guy who buys are cable/DSL link and "provides" to his mother > > & father with a LinkSys.) > > eh, -stevieb has much respect for all those who read this list, and when > he posts, feels that the big guys are looking down upon him... hopefully > with approval. Ok so, without getting into debates over being political, practicing vs preaching, BCP38, or big guys vs little guys, can you please explain in clear english what in the name of holy hell you're talking about? What is the issue here, that your DSL provider won't speak BGP with you no matter how many times you've asked, so you're complaining to NANOG about it because you don't have the ability or authority to change providers? Please correct me if I'm reading this wrong, but the emails so far haven't been very clear and this isn't making a lot of sense. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From patrick at ianai.net Sun Nov 1 23:26:57 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 2 Nov 2009 00:26:57 -0500 Subject: Upstream BGP community support In-Reply-To: <1257070304.4753.477.camel@karl> References: <1257070304.4753.477.camel@karl> Message-ID: <6AF4762B-AEAF-44E3-86A8-0B1458C501DC@ianai.net> On Nov 1, 2009, at 5:11 AM, Karl Auer wrote: > On Sun, 2009-11-01 at 17:06 +0900, Randy Bush wrote: >>> The answer is fairly simple. Does your business benefit by having >>> the >>> ability to modify routing strategy as you see fit? >> >> hint: we live in a commons > > Yes. I was about to ask Tony "what if *their* business benefits by NOT > giving you the ability to modify routing strategy as you see fit?" > > What's the answer then? To answer your question, obviously each network should do whatever is in their best interest. But isn't it in a transit provider's best interest to make their customers happy? :) However, I'm pretty sure that's not what Randy meant. Randy frequently (and correctly) points out that the Internet is a shared resource. What you do can affect others. BGP sucks, but it's the only thing we have. So try not to break it. OTOH: The Internet is not a science project. I'm not even going to say "any more", since no one should be confused about that today. Transit providers are almost always for-profit companies. These two basic facts create an interesting dynamic. Everyone wants to do what is best for themselves to make more money, but what one network does affects other networks. Finding a happy medium is hard, mmmmm-KAY. I personally believe transit providers should support communities. I don't think the added complexity is too dangers, and I think it will help add to the profit of providers. Others may disagree. But as someone (either Richard or Paul, sometimes I have trouble telling them apart) pointed out, it's been happening for a long time. "Past performance is no guarantee of future profit", but it does give one at least a little confidence that supporting community tags will not collapse the Internet tomorrow. End of day, I'll just fall back on what I always say: Your Network, Your Decision. But try to remember that Your Network is connected to everyone else's network. -- TTFN, patrick From steve at ibctech.ca Sun Nov 1 23:42:51 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Mon, 02 Nov 2009 00:42:51 -0500 Subject: Small guys with BGP issues In-Reply-To: <20091102050734.GN51443@gerbil.cluepon.net> References: <4AEE5998.6060009@ibctech.ca> <19B95C86-540B-4B26-99BD-E9B233828ABF@ianai.net> <4AEE65EF.3040607@ibctech.ca> <20091102050734.GN51443@gerbil.cluepon.net> Message-ID: <4AEE715B.8020801@ibctech.ca> Richard A Steenbergen wrote: > On Sun, Nov 01, 2009 at 11:54:07PM -0500, Steve Bertrand wrote: >> I'm not a political person. Take it for what it is worth. >> >> I personally know people who do both: >> >> - practice but not preach >> - preach but don't practice >> >> ... however you take my point, I don't care. >> >> I just wanted it to be known that the 'guys' who do practice it should >> 'God willing' come out and preach it. >> >>> And this is not the big boy list. This is for all Operators in North >>> America, and many who are not, regardless of size. (Well, I guess we'll >>> exclude the guy who buys are cable/DSL link and "provides" to his mother >>> & father with a LinkSys.) >> eh, -stevieb has much respect for all those who read this list, and when >> he posts, feels that the big guys are looking down upon him... hopefully >> with approval. > > Ok so, without getting into debates over being political, practicing vs > preaching, BCP38, or big guys vs little guys, can you please explain in > clear english what in the name of holy hell you're talking about? > > What is the issue here, that your DSL provider won't speak BGP with you > no matter how many times you've asked, so you're complaining to NANOG Theoretically, I'm not complaining, I'm venting. This isn't just my DSL provider, its a business class connection provider who also happens to provide my (hrm.. our) primary Internet connection. Are you going to teach me something with a clue bat, or are you going to beat me to death with the specifics that each prong of a fork carries? > Please correct me if I'm reading this wrong, but the emails > so far haven't been very clear and this isn't making a lot of sense. My apologies if I haven't been clear. What would you like me to say? If I can't 'complain' here, where do I go? I think that I've acted tactfully and responsibly. What didn't make sense? Enlighten me. Although I did come here with concerns and questions, I do have a clue bat of my own to swing in defence... Steve From steve at ibctech.ca Sun Nov 1 23:58:27 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Mon, 02 Nov 2009 00:58:27 -0500 Subject: Upstream BGP community support In-Reply-To: References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> Message-ID: <4AEE7503.7080100@ibctech.ca> jim deleskie wrote: > Agree'd :) > > On Sat, Oct 31, 2009 at 9:34 PM, Randy Bush wrote: >>> Here is the problem as I see it. Sure some % fo the people using BGP >>> are bright nuff to use some upstreams communities, but sadly many are >>> not. So this ends up breaking one or more networks, who in turn twist >>> more dials causing other changes.. rinse, wash and repeat. But like >>> Randy said who am I to stop anyone from playing... just means those of >>> us with clue will be able to continue to earn a pay check for a very >>> long time still :) >> i would rather earn it by designing things, not by cleaning up messes >> made by kiddies needing to show off. For those who try their best, given your comment, what in the fsck is one to do? What practices should be followed? Is this about not pushing knobs, or is this about people with big dicks? What really should we do? I mean those with 2691's still in practice. What do we do? We watch for guidance from here. It seems as though people are making a mochary of communities. How many steps am I really behind? Steve From ras at e-gerbil.net Mon Nov 2 00:00:59 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Mon, 2 Nov 2009 00:00:59 -0600 Subject: Small guys with BGP issues In-Reply-To: <4AEE715B.8020801@ibctech.ca> References: <4AEE5998.6060009@ibctech.ca> <19B95C86-540B-4B26-99BD-E9B233828ABF@ianai.net> <4AEE65EF.3040607@ibctech.ca> <20091102050734.GN51443@gerbil.cluepon.net> <4AEE715B.8020801@ibctech.ca> Message-ID: <20091102060059.GO51443@gerbil.cluepon.net> On Mon, Nov 02, 2009 at 12:42:51AM -0500, Steve Bertrand wrote: > This isn't just my DSL provider, its a business class connection > provider who also happens to provide my (hrm.. our) primary Internet > connection. > > Are you going to teach me something with a clue bat, or are you going > to beat me to death with the specifics that each prong of a fork > carries? Sure, I'll give it a brief shot... Some Internet connections are simply not designed to support customer BGP. When someone says "business class service" over cable or DSL, typically what they're talking about is "we'll route your calls to a slightly higher class call center", and "we'll provide you with 5 e-mail addresses/IPs and 50MB of hosting for your website instead of just the usual 1 email and 1 dynamic IP". The DSL gear may very well not be able to speak BGP to a customer at all. Each provider gets to decide what service they do and don't want to sell, and your provider has clearly decided they don't want to sell you BGP. From the providers' point of view, I'm sure this makes perfect sense. I'd love to get Comcast to speak BGP to my cable modem, but I have absolutely no delusions that they will ever do so. There is more than likely nothing you're going to be able to do about it, and the more you complain about it like this the more likely they are to move you into the "this guy is a nut and we don't want your business at all" category. If you don't like the service you're getting, vote with your money and buy from someone else. This is quite simply not a NANOG issue, but in the interests of being helpful the best advice I can give you is this: "Your request is unreasonable, and you should adjust your expectations that you'll ever get it from the service you are purchasing". Sorry if that's not the answer you want. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From steve at ibctech.ca Mon Nov 2 00:16:24 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Mon, 02 Nov 2009 01:16:24 -0500 Subject: Small guys with BGP issues In-Reply-To: <20091102060059.GO51443@gerbil.cluepon.net> References: <4AEE5998.6060009@ibctech.ca> <19B95C86-540B-4B26-99BD-E9B233828ABF@ianai.net> <4AEE65EF.3040607@ibctech.ca> <20091102050734.GN51443@gerbil.cluepon.net> <4AEE715B.8020801@ibctech.ca> <20091102060059.GO51443@gerbil.cluepon.net> Message-ID: <4AEE7938.3040500@ibctech.ca> Richard A Steenbergen wrote: > On Mon, Nov 02, 2009 at 12:42:51AM -0500, Steve Bertrand wrote: >> This isn't just my DSL provider, its a business class connection >> provider who also happens to provide my (hrm.. our) primary Internet >> connection. >> >> Are you going to teach me something with a clue bat, or are you going >> to beat me to death with the specifics that each prong of a fork >> carries? > > Sure, I'll give it a brief shot... Some Internet connections are simply > not designed to support customer BGP. When someone says "business class > service" over cable or DSL, typically what they're talking about is > "we'll route your calls to a slightly higher class call center", and > "we'll provide you with 5 e-mail addresses/IPs and 50MB of hosting for > your website instead of just the usual 1 email and 1 dynamic IP". > > The DSL gear may very well not be able to speak BGP to a customer at > all. Each provider gets to decide what service they do and don't want to > sell, and your provider has clearly decided they don't want to sell you > BGP. From the providers' point of view, I'm sure this makes perfect > sense. I'd love to get Comcast to speak BGP to my cable modem, but I > have absolutely no delusions that they will ever do so. There is more > than likely nothing you're going to be able to do about it, and the more > you complain about it like this the more likely they are to move you > into the "this guy is a nut and we don't want your business at all" > category. Richard, I appreciate your concern. I would have expected however that you might have understood that I wasn't asking about some resi-type connection. Yes, we are small. I would love to be in a position to say that our 100Mb connection qualifies... Regardless... > If you don't like the service you're getting, vote with your money and > buy from someone else. This is quite simply not a NANOG issue, but in > the interests of being helpful the best advice I can give you is this: > > "Your request is unreasonable, and you should adjust your expectations > that you'll ever get it from the service you are purchasing". Tell me, what can you offer me? Here are my immediate purchasing qualifications: - 100Mbps - space in Torix - optic, from Toronto, Ontario to Cobourg, Ontario (55 miles) - gear at both ends We pay ~$2500 for the fibre and the bandwidth. Get me a deal. I am not the money man. I don't even want to deal with money. I can't vote with money, as it's not mine. Believe me, if I could vote with money, I'd be 100% HE. I'm venting. I'm allowed to vent here. I think I'm qualified to do so. Even though I can't speak with $, there are those who know my determination to keep a clean network, and they may be willing to help me in the future. Steve From adrian at creative.net.au Mon Nov 2 00:16:58 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Mon, 2 Nov 2009 14:16:58 +0800 Subject: Small guys with BGP issues In-Reply-To: <20091102060059.GO51443@gerbil.cluepon.net> References: <4AEE5998.6060009@ibctech.ca> <19B95C86-540B-4B26-99BD-E9B233828ABF@ianai.net> <4AEE65EF.3040607@ibctech.ca> <20091102050734.GN51443@gerbil.cluepon.net> <4AEE715B.8020801@ibctech.ca> <20091102060059.GO51443@gerbil.cluepon.net> Message-ID: <20091102061658.GB16011@skywalker.creative.net.au> On Mon, Nov 02, 2009, Richard A Steenbergen wrote: > If you don't like the service you're getting, vote with your money and > buy from someone else. This is quite simply not a NANOG issue, but in > the interests of being helpful the best advice I can give you is this: > > "Your request is unreasonable, and you should adjust your expectations > that you'll ever get it from the service you are purchasing". > > Sorry if that's not the answer you want. :) Or you could look at alternatives with your provider, ie: "Ok, so we can't speak BGP over that particular link. May I colocate some router with you at extra cost and connect to you via -that-, so I may then speak BGP to you over that and then tunnel my data back to me over your DSL network?" That way you don't require your ISP to speak BGP over a DSL link and all of the headaches they may not be prepared for, and you get control over your own network. 2c, Adrian From steve at ibctech.ca Mon Nov 2 00:22:50 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Mon, 02 Nov 2009 01:22:50 -0500 Subject: Small guys with BGP issues In-Reply-To: <20091102061658.GB16011@skywalker.creative.net.au> References: <4AEE5998.6060009@ibctech.ca> <19B95C86-540B-4B26-99BD-E9B233828ABF@ianai.net> <4AEE65EF.3040607@ibctech.ca> <20091102050734.GN51443@gerbil.cluepon.net> <4AEE715B.8020801@ibctech.ca> <20091102060059.GO51443@gerbil.cluepon.net> <20091102061658.GB16011@skywalker.creative.net.au> Message-ID: <4AEE7ABA.7040808@ibctech.ca> Adrian Chadd wrote: > On Mon, Nov 02, 2009, Richard A Steenbergen wrote: > >> If you don't like the service you're getting, vote with your money and >> buy from someone else. This is quite simply not a NANOG issue, but in >> the interests of being helpful the best advice I can give you is this: >> >> "Your request is unreasonable, and you should adjust your expectations >> that you'll ever get it from the service you are purchasing". >> >> Sorry if that's not the answer you want. :) > > Or you could look at alternatives with your provider, ie: > > "Ok, so we can't speak BGP over that particular link. May I colocate some > router with you at extra cost and connect to you via -that-, so I may then > speak BGP to you over that and then tunnel my data back to me over your > DSL network?" > > That way you don't require your ISP to speak BGP over a DSL link and all > of the headaches they may not be prepared for, and you get control over > your own network. heh, Adrian, unfortunately, it's political, out of my grasp. Thankfully, these threads should be enough to either get things moving forward, or get me fired. Either way, progress was made. I'm sick of sitting still. I want to do more. Steve From ras at e-gerbil.net Mon Nov 2 00:44:49 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Mon, 2 Nov 2009 00:44:49 -0600 Subject: Small guys with BGP issues In-Reply-To: <4AEE7938.3040500@ibctech.ca> References: <4AEE5998.6060009@ibctech.ca> <19B95C86-540B-4B26-99BD-E9B233828ABF@ianai.net> <4AEE65EF.3040607@ibctech.ca> <20091102050734.GN51443@gerbil.cluepon.net> <4AEE715B.8020801@ibctech.ca> <20091102060059.GO51443@gerbil.cluepon.net> <4AEE7938.3040500@ibctech.ca> Message-ID: <20091102064449.GP51443@gerbil.cluepon.net> On Mon, Nov 02, 2009 at 01:16:24AM -0500, Steve Bertrand wrote: > Tell me, what can you offer me? Here are my immediate purchasing > qualifications: > > - 100Mbps > - space in Torix > - optic, from Toronto, Ontario to Cobourg, Ontario (55 miles) > - gear at both ends > > We pay ~$2500 for the fibre and the bandwidth. Get me a deal. I am not > the money man. I don't even want to deal with money. I can't vote with > money, as it's not mine. Believe me, if I could vote with money, I'd be > 100% HE. You said business class DSL before, now you're saying 100Mbps. There are many dozens of providers who will speak BGP with you in 151 Front, you should have absolutely no trouble finding one to buy from at attractive prices. Your best bet is to unbundle the backhaul from the transit, that way you have flexibility to buy bandwidth from who you would like without being tied to the specific network providing the backhaul. But you said "gear on both ends", which implies that you have something in Toronto already? At any rate this is completely and totally off topic for NANOG, but if you say the words "I'd like to buy 100Mbps of service with BGP in Toronto" I'm sure you'll be swarmed with offers. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From pauldotwall at gmail.com Mon Nov 2 00:50:25 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Mon, 2 Nov 2009 01:50:25 -0500 Subject: Small guys with BGP issues In-Reply-To: <4AEE7938.3040500@ibctech.ca> References: <4AEE5998.6060009@ibctech.ca> <19B95C86-540B-4B26-99BD-E9B233828ABF@ianai.net> <4AEE65EF.3040607@ibctech.ca> <20091102050734.GN51443@gerbil.cluepon.net> <4AEE715B.8020801@ibctech.ca> <20091102060059.GO51443@gerbil.cluepon.net> <4AEE7938.3040500@ibctech.ca> Message-ID: <620fd17c0911012250q29c1241du2efed820a1675d31@mail.gmail.com> On Mon, Nov 2, 2009 at 1:16 AM, Steve Bertrand wrote: > - space in Torix TorIX is not a place, its actually two switches that form an Internet exchange. Perhaps you meant 151 Front Street? Do you have your own suite? Whose suite are you in? > I'm venting. I'm allowed to vent here. I think I'm qualified to do so. Yes, according to www.ibctech.ca, you advertise that you are "Sage" level IPv6 qualified individual from Hurricane Electric. If you only had mentioned that first, no one would have replied to you with such elementary questions. That aside, I think you should have started your thread with explaining the problem you are trying to solve, instead of ranting about big providers and the ills they cause you. If you are in "torix space" why aren't you peering at TorIX (I don't see your ASN on the list)? Out of curiosity, have you contacted anyone off the TorIX participants list to see if they would be willing to sell IP transit and peer BGP with you? If you want a better venting location, try IRC. Drive Slow (because Cobourg has slow speed limits, especially near the water) From randy at psg.com Mon Nov 2 04:19:32 2009 From: randy at psg.com (Randy Bush) Date: Mon, 02 Nov 2009 05:19:32 -0500 Subject: Upstream BGP community support In-Reply-To: <4AEE7503.7080100@ibctech.ca> References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> <4AEE7503.7080100@ibctech.ca> Message-ID: >>> i would rather earn it by designing things, not by cleaning up messes >>> made by kiddies needing to show off. > > For those who try their best, given your comment, what in the fsck is > one to do? [ i prefer to speak in the first person, not tell you what you should do. ] i try to use as few tricks, knobs, and clever things as possible and still get my job done. i try to be extremely conscious of, and minimal, when what i am doing effects or is visible to my neighbors and/or the global net. i try to complicate the internals of my network as little as possible, after all, complexity == opex and i value my time, it is a non-renewable resource. i prefer to be seen as an old and lazy minimalist, not a clever person. clever was a pejorative where/when i was brought up. randy From ras at e-gerbil.net Mon Nov 2 04:56:11 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Mon, 2 Nov 2009 04:56:11 -0600 Subject: Upstream BGP community support In-Reply-To: References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> <4AEE7503.7080100@ibctech.ca> Message-ID: <20091102105610.GQ51443@gerbil.cluepon.net> On Mon, Nov 02, 2009 at 05:19:32AM -0500, Randy Bush wrote: > i try to use as few tricks, knobs, and clever things as possible and > still get my job done. i try to be extremely conscious of, and minimal, > when what i am doing effects or is visible to my neighbors and/or the > global net. > > i try to complicate the internals of my network as little as possible, > after all, complexity == opex and i value my time, it is a non-renewable > resource. > > i prefer to be seen as an old and lazy minimalist, not a clever person. > clever was a pejorative where/when i was brought up. Translation: You damn kids! Get off my lawn! But seriously now, the reason we have these squishy things taking up space between our ears in the first place is so we can come up with new ideas and better ways to solve our problems. Obviously you can take it too far, I'm sure we've all seen examples of absurdly over-complicated designs which existed only for the edification of someone's ego, but I have never seen a intelligent and well thought out BGP community system do anything other than make everyone's life easier. I don't know who these people are who you claim are busy breaking things with communities, but I've never seen them. Being clever is a good thing when it helps you find new ways to do more with less, and those who can't innovate in this industry are dooming themselves to obsolescence. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From globichen at gmail.com Mon Nov 2 05:16:08 2009 From: globichen at gmail.com (Andy B.) Date: Mon, 2 Nov 2009 12:16:08 +0100 Subject: Upstream BGP community support In-Reply-To: <20091102105610.GQ51443@gerbil.cluepon.net> References: <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> <4AEE7503.7080100@ibctech.ca> <20091102105610.GQ51443@gerbil.cluepon.net> Message-ID: On Mon, Nov 2, 2009 at 11:56 AM, Richard A Steenbergen wrote: > But seriously now, the reason we have these squishy things taking up > space between our ears in the first place is so we can come up with new > ideas and better ways to solve our problems. Obviously you can take it > too far, I'm sure we've all seen examples of absurdly over-complicated > designs which existed only for the edification of someone's ego, but I > have never seen a intelligent and well thought out BGP community system > do anything other than make everyone's life easier. I don't know who > these people are who you claim are busy breaking things with > communities, but I've never seen them. Being clever is a good thing when > it helps you find new ways to do more with less, and those who can't > innovate in this industry are dooming themselves to obsolescence. That being said, how can we (me, my company, nanog, ...) possibly do to convince someone like HE, who wants to be a global player, to support BGP communities? I'm not that good at baking cakes, but HE seems to be doing pretty well at that. I know that some engineers from HE are in this list; maybe they can give us some insight as to why they believe communities are worthless. Andy From randy at psg.com Mon Nov 2 05:46:59 2009 From: randy at psg.com (Randy Bush) Date: Mon, 02 Nov 2009 06:46:59 -0500 Subject: Upstream BGP community support In-Reply-To: <20091102105610.GQ51443@gerbil.cluepon.net> References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> <4AEE7503.7080100@ibctech.ca> <20091102105610.GQ51443@gerbil.cluepon.net> Message-ID: <4AEEC6B3.10707@psg.com> Richard A Steenbergen wrote: > On Mon, Nov 02, 2009 at 05:19:32AM -0500, Randy Bush wrote: >> i try to use as few tricks, knobs, and clever things as possible and >> still get my job done. i try to be extremely conscious of, and minimal, >> when what i am doing effects or is visible to my neighbors and/or the >> global net. >> >> i try to complicate the internals of my network as little as possible, >> after all, complexity == opex and i value my time, it is a non-renewable >> resource. >> >> i prefer to be seen as an old and lazy minimalist, not a clever person. >> clever was a pejorative where/when i was brought up. > > Translation: > > You damn kids! Get off my lawn! bullshit > But seriously now, the reason we have these squishy things taking up > space between our ears in the first place is so we can come up with new > ideas and better ways to solve our problems. and they need not be cute, clever, or complex. unless we did not get enough strokes as a kid. randy From mitigator at gmail.com Mon Nov 2 06:37:03 2009 From: mitigator at gmail.com (mitigator at gmail.com) Date: Mon, 2 Nov 2009 12:37:03 +0000 Subject: Small guys with BGP issues Message-ID: <1479441097-1257165414-cardhu_decombobulator_blackberry.rim.net-1375456056-@bda469.bisx.prod.on.blackberry> Friends don't let friends drink and reply-all. I'm just sayin. -j ------Original Message------ From: Richard A Steenbergen To: Steve Bertrand Cc: NANOG list Subject: Re: Small guys with BGP issues Sent: Nov 1, 2009 11:07 PM On Sun, Nov 01, 2009 at 11:54:07PM -0500, Steve Bertrand wrote: > I'm not a political person. Take it for what it is worth. > > I personally know people who do both: > > - practice but not preach > - preach but don't practice > > ... however you take my point, I don't care. > > I just wanted it to be known that the 'guys' who do practice it should > 'God willing' come out and preach it. > > > And this is not the big boy list. This is for all Operators in North > > America, and many who are not, regardless of size. (Well, I guess we'll > > exclude the guy who buys are cable/DSL link and "provides" to his mother > > & father with a LinkSys.) > > eh, -stevieb has much respect for all those who read this list, and when > he posts, feels that the big guys are looking down upon him... hopefully > with approval. Ok so, without getting into debates over being political, practicing vs preaching, BCP38, or big guys vs little guys, can you please explain in clear english what in the name of holy hell you're talking about? What is the issue here, that your DSL provider won't speak BGP with you no matter how many times you've asked, so you're complaining to NANOG about it because you don't have the ability or authority to change providers? Please correct me if I'm reading this wrong, but the emails so far haven't been very clear and this isn't making a lot of sense. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From randy at psg.com Mon Nov 2 07:36:31 2009 From: randy at psg.com (Randy Bush) Date: Mon, 02 Nov 2009 08:36:31 -0500 Subject: Upstream BGP community support In-Reply-To: <11919.1257098359@turing-police.cc.vt.edu> References: <20091031220938.GE51443@gerbil.cluepon.net> <20091031232738.GF51443@gerbil.cluepon.net> <20091031233531.GA81416@blackrose.org> <20091031234903.GG51443@gerbil.cluepon.net> <20091101003352.GB81416@blackrose.org> <11919.1257098359@turing-police.cc.vt.edu> Message-ID: > As Louis Mamakos pointed out back in 1992 or so, it's hard to conceal the > existence of said peering: g2 is raising the cost of gaining info. you can not prevent it absolutely. randy From patrick at ianai.net Mon Nov 2 08:26:37 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 2 Nov 2009 09:26:37 -0500 Subject: Upstream BGP community support In-Reply-To: <4AEEC6B3.10707@psg.com> References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> <4AEE7503.7080100@ibctech.ca> <20091102105610.GQ51443@gerbil.cluepon.net> <4AEEC6B3.10707@psg.com> Message-ID: <3E74E0BC-634A-4FBE-BDAC-6C1F7BB026FB@ianai.net> On Nov 2, 2009, at 6:46 AM, Randy Bush wrote: >> But seriously now, the reason we have these squishy things taking up >> space between our ears in the first place is so we can come up with >> new >> ideas and better ways to solve our problems. > > and they need not be cute, clever, or complex. unless we did not get > enough strokes as a kid. I think you two are speaking ever so slightly past each other. Specifically, you are using the term 'clever' in different ways. Also, Randy, complexity is not always bad. More transistors on a chip can absolutely make it more complex, but it can be useful if you know where to put them and how they interact. Complexity is not the enemy. Poorly understood complexity, complexity for the sake of complexity, complexity with no goal, these are bad. Saying complexity itself is bad is just as silly as adding complexity for no gain. You want to lower opex. A fine goal. Richard claims implementing a community-signaling product on his network lowers his opex. You say breaking things in ways that hurt your neighbors is bad. Richard has years of running his network in this way without harming his neighbors. Etc., etc. It sounds to me like you two agree. So why don't you shake hands and go back to your corners? Unless you'd rather talk past each other and argue semantics in front of 10K+ of your not-so-closest friends? -- TTFN, patrick From mpetach at netflight.com Mon Nov 2 10:38:05 2009 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 2 Nov 2009 09:38:05 -0700 Subject: Upstream BGP community support In-Reply-To: References: <20091031220938.GE51443@gerbil.cluepon.net> <20091031232738.GF51443@gerbil.cluepon.net> <20091031233531.GA81416@blackrose.org> <20091031234903.GG51443@gerbil.cluepon.net> <20091101003352.GB81416@blackrose.org> <11919.1257098359@turing-police.cc.vt.edu> Message-ID: <63ac96a50911020838s1302b445h9897d1f1f4acb2e7@mail.gmail.com> On Mon, Nov 2, 2009 at 6:36 AM, Randy Bush wrote: >> As Louis Mamakos pointed out back in 1992 or so, it's hard to conceal the >> existence of said peering: > > g2 is raising the cost of gaining info. ?you can not prevent it > absolutely. No kidding--the traffic backlog on it this morning was horrible; must have cost at least twice as much gas as normal![1] (it actually took a bit of digging for me to find a working definition of "G2" that made sense in this context; is this a commonly used term that I've just managed to remain ignorant of, or is it really as archaic and esoteric as the lack of definitions in search engines would seem to indicate? Is there a commonly-referred-to network glossary where people go to look up random acronyms and terms like this, or does everybody just do their own digging when terms are tossed out like this with no definition associated with it?) > randy Thanks! Matt [1]http://en.wikipedia.org/wiki/County_Route_G2_%28California%29 From joelja at bogus.com Mon Nov 2 11:28:19 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 02 Nov 2009 09:28:19 -0800 Subject: some discussion on one vendor's (juniper) silicon... Message-ID: <4AEF16B3.404@bogus.com> The juniper pr event at the nyse actually contained some not unreasonable information on their new silicon. starts about 25 minutes in (silly registration required)... http://www.thenewnetworkishere.com/simulcast.html From joelja at bogus.com Mon Nov 2 13:33:49 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 02 Nov 2009 11:33:49 -0800 Subject: Upstream BGP community support In-Reply-To: References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> Message-ID: <4AEF341D.7050009@bogus.com> So this questions we have approached from time to time. Is there some worth to be had in finding some consensus (assuming such a thing is possible) on a subset of the features that people use communities for that could be standardized? particularly in the context of source based remote triggered blackholing this seemed a like a worthwhile effort. A standardized set means it can be cooked into documentation, training, and potentially even products. it doesn't mean that everyone will enable it, but if they do it would be nice to agree on some basi grounds rules. it should also be understood that many if not most localized community signaling uses would remain localized in terms of their documentation and use. joel jim deleskie wrote: > Here is the problem as I see it. Sure some % fo the people using BGP > are bright nuff to use some upstreams communities, but sadly many are > not. So this ends up breaking one or more networks, who in turn twist > more dials causing other changes.. rinse, wash and repeat. But like > Randy said who am I to stop anyone from playing... just means those of > us with clue will be able to continue to earn a pay check for a very > long time still :) > > -jim > > On Sat, Oct 31, 2009 at 9:25 PM, Randy Bush wrote: >> while i can understand folk's wanting to signal upstream using >> communities, and i know it's all the rage. one issue needs to be >> raised. >> >> bgp is a brilliant information hiding protocol. policy is horribly >> opaque. complexity abounds. and it has unfun consequences, e.g. see >> tim on wedgies etc. >> >> and this just adds to the complexity and opacity. >> >> so i ain't sayin' don't do it. after all, who would deny you the >> ability to show off your bgp macho? >> >> just try to minimize its use to only when you *really* need it. >> >> randy >> >> > From jbates at brightok.net Mon Nov 2 13:38:00 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 02 Nov 2009 13:38:00 -0600 Subject: Upstream BGP community support In-Reply-To: <4AEF341D.7050009@bogus.com> References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> <4AEF341D.7050009@bogus.com> Message-ID: <4AEF3518.7050006@brightok.net> Joel Jaeggli wrote: > > A standardized set means it can be cooked into documentation, training, > and potentially even products. > Communities (except the standardized well known ones) are extremely diverse. For those that support even more granular traffic engineering by limiting which of their peers your routes might be transiting, I believe there are 2 distinct methods of using communities. The nature of communities, and the different levels of support and traffic engineering capabilities makes it difficult for it to be standardized. It would take even longer for anyone to adopt such a standard due to the sheer volume of routers and customers who would have to adapt from long term established policies. Jack Bates From joelja at bogus.com Mon Nov 2 13:57:30 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 02 Nov 2009 11:57:30 -0800 Subject: Upstream BGP community support In-Reply-To: <4AEF3518.7050006@brightok.net> References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> <4AEF341D.7050009@bogus.com> <4AEF3518.7050006@brightok.net> Message-ID: <4AEF39AA.7010602@bogus.com> Jack Bates wrote: > Joel Jaeggli wrote: >> >> A standardized set means it can be cooked into documentation, training, >> and potentially even products. >> > > Communities (except the standardized well known ones) are extremely > diverse. For those that support even more granular traffic engineering > by limiting which of their peers your routes might be transiting, I > believe there are 2 distinct methods of using communities. > > The nature of communities, and the different levels of support and > traffic engineering capabilities makes it difficult for it to be > standardized. It would take even longer for anyone to adopt such a > standard due to the sheer volume of routers and customers who would have > to adapt from long term established policies. You're not going to get any argument from me about the diversity of implmentations or the needs arising out of network specific optimization. That said, our previous conclusion was also that we couldn't reasonably do this for a subset of them so I don't have to go very far to be convinced. That said standardization would likely make some features more accessible and therefore more likely to be used, I don't think traffic engineering is something I particularly want to encourage to excess but RTBH is a know that more people need access to quite frankly. joel > > Jack Bates > From jbates at brightok.net Mon Nov 2 14:02:58 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 02 Nov 2009 14:02:58 -0600 Subject: Upstream BGP community support In-Reply-To: <4AEF39AA.7010602@bogus.com> References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> <4AEF341D.7050009@bogus.com> <4AEF3518.7050006@brightok.net> <4AEF39AA.7010602@bogus.com> Message-ID: <4AEF3AF2.7040402@brightok.net> Joel Jaeggli wrote: > more accessible and therefore more likely to be used, I don't think > traffic engineering is something I particularly want to encourage to > excess but RTBH is a know that more people need access to quite frankly. I think creating a standard or at least a template might push more people to adopt communities support and to use them. There are definitely times it is useful to redirect traffic 2 ASN's away through a longer route. In some cases (like my small self, I try to adopt policies that allow communities to me to also be rewritten to the corresponding peers communities to alter things as far as 3 ASN's away from my customer. Jack From ras at e-gerbil.net Mon Nov 2 14:13:38 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Mon, 2 Nov 2009 14:13:38 -0600 Subject: Upstream BGP community support In-Reply-To: <4AEF3518.7050006@brightok.net> References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> <4AEF341D.7050009@bogus.com> <4AEF3518.7050006@brightok.net> Message-ID: <20091102201338.GZ51443@gerbil.cluepon.net> On Mon, Nov 02, 2009 at 01:38:00PM -0600, Jack Bates wrote: > Communities (except the standardized well known ones) are extremely > diverse. For those that support even more granular traffic engineering > by limiting which of their peers your routes might be transiting, I > believe there are 2 distinct methods of using communities. Even the standardized ones aren't guaranteed to be useful. For example RFC3765 defines a NOPEER community, i.e. a standardized way to say "do not export this route to peers" (in the settlement free bilateral sense of the word). But there is no possible way for the router to know what is or isn't a peer, so it's up to the operator to implement the matching for this supposedly "standard" community. But guess what, most people don't, and those that do implement the functionality end up writing their own network specific version anyways (either because they want to keep it secret, or because they need to implement far more powerful version anyways). If we want to turn this into a discussion on useful things to do with communities (to try and recover some value from this otherwise brain rotting thread), how about this one. We as network operators are currently facing a problem with BGP communities, and that problem is called 32 bit ASNs. Quite simply, 32 bit ASNs don't fit into the existing 16:16 scheme. There are new 64 bit communities (extended communities) out there, but they aren't a 1:1 mapping of the way communities work today. Rather than simply double the size and break it up into 32:32, the designers reserved the top 16 bits for "type" and "subtype" attributes, leaving you only 48 bits to work with. Clearly the only suitable mapping for support of 32-bit ASNs on the Internet is 32:16, leaving us with exactly the same range of "data" values that we have today. So why do I bring this up? Because of those top 16 bits for type and subtype. Two of the type fields that are newly introduced in extended communities are "target" and "origin", which specifically mean "this tag is trying to tell $ASN something", vs "this $ASN is trying to tell you something". This actually has the benefit of addressing one of the most common problems with communities today, namespace collision between folks trying to both send instructions and receive data within the same ASN:xxxxx tag. Since we're all going to need to start updating our routing policies to support 32 bit ASNs soon anyways (unless you want to tell people getting them that they aren't allowed to use communities :P), now is a good time to start thinking about taking advantage of these new features to resolve age-old problems in your new community design. Another feature I think would be beneficial for router vendors to consider implementing is a way to "map" between regular and extended communities. For example, I might be able to apply a policy at the edge of my network which "imports" regular communities from my neighbor, and turns them into origin: tags of extended communities. I might then be able to update my internal network to work on extended communities, and translate them back again to regular for backwards compatibility at the edge. Also, now is a good time to find out if your router vendor ACTUALLY supports extended communities in all of their features (for example, regexp support), or if they only exist for l3vpn support and are not actually prepared to use them to work with 32-bit ASNs. Hint: Some vendors still fall into this category last I looked. Apologies if this post contained too much "clever" and made Randy's head explode. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From Brian.Dickson at concertia.com Mon Nov 2 14:44:19 2009 From: Brian.Dickson at concertia.com (Brian Dickson) Date: Mon, 2 Nov 2009 16:44:19 -0400 Subject: Upstream BGP community support In-Reply-To: <4AEF3AF2.7040402@brightok.net> References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> <4AEF341D.7050009@bogus.com> <4AEF3518.7050006@brightok.net> <4AEF39AA.7010602@bogus.com> <4AEF3AF2.7040402@brightok.net> Message-ID: <21D41A38B8859B4A97B1AE2313922B8A812FB7FB24@concertiabl02.concertia.com> (Apologies for top-replying, but hey, it makes it easier to ignore stuff you've already read.) I think the main things to consider in identifying what things "belong" in a standardized community are: - is it something that is really global, and not local, in behaviour and scope? - is it something that is mostly a signalling-of-intent "flag", and not a modification of path-selection? --> (because) It should not require universal adoption to be useful - if it is ignored by A, and passed to B, will it still be useful/semantically correct? - is it something that will either be applied by the originator to all instances of a given prefix (i.e. sending X to neighbour A and neighbour B, with community M); - or something that will be applied by the originator to some instances of a given prefix (i.e. sending X to A with N, and X to B without N) - is the intent being signalled easily understood, ideally in an absolute sense? The two things I can think of, which would benefit from such a community, and where nearly-universal adoption would be of significant benefit, are: (1) Blackhole this prefix, and; (2) Use this prefix as a last resort only. (Please add to this list if you think of any other cases meeting the above criteria). Comments on particular proposed-standard-community cases follows... I bring up (2) because it is otherwise *very* difficult to signal (or achieve), and often leads to potential wedgies. The existing mechanisms to achieve (2) are often indistinguishable from Traffic Engineering - but this is very much not TE. TE is "reduce load on this instance". (2) is "Don't use this for traffic unless you have no paths not marked with this community". TE will typically be observed with small numbers of AS-prepending. (2) will be observed with large numbers of AS-prepending. And, my guess would be, 80% of the prepending would not be needed if (2) were standardized and in use. It might even reduce significantly the observed instances of wedgies and/or persistent oscillations in the wild. Brian -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: November-02-09 4:03 PM To: Joel Jaeggli Cc: nanog at nanog.org Subject: Re: Upstream BGP community support Joel Jaeggli wrote: > more accessible and therefore more likely to be used, I don't think > traffic engineering is something I particularly want to encourage to > excess but RTBH is a know that more people need access to quite frankly. I think creating a standard or at least a template might push more people to adopt communities support and to use them. There are definitely times it is useful to redirect traffic 2 ASN's away through a longer route. In some cases (like my small self, I try to adopt policies that allow communities to me to also be rewritten to the corresponding peers communities to alter things as far as 3 ASN's away from my customer. Jack From mark.urbach at pnpt.com Mon Nov 2 15:56:56 2009 From: mark.urbach at pnpt.com (Mark Urbach) Date: Mon, 2 Nov 2009 15:56:56 -0600 Subject: Speed Testing and Throughput testing Message-ID: Anyone have a good solution to get "accurate" speed results when testing at 10/100/1000 Ethernet speeds? Do you have a server/software that customer can test too? Thanks, Mark Urbach PinPoint Communications, Inc. 100 N. 12th St Suite 500 Lincoln, NE 68508 402-438-6211 ext 1923 Office 402-660-7982 Cell mark.urbach at pnpt.com [cid:image003.jpg at 01CA5BD5.1A5CEE20] -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 1972 bytes Desc: image003.jpg URL: From jack at crepinc.com Mon Nov 2 16:51:32 2009 From: jack at crepinc.com (Jack Carrozzo) Date: Mon, 2 Nov 2009 17:51:32 -0500 Subject: Speed Testing and Throughput testing In-Reply-To: References: Message-ID: <2ad0f9f60911021451m528d7822x5defb1583ae258e6@mail.gmail.com> iperf is fairly standard and supports some handy features - http://en.wikipedia.org/wiki/Iperf -Jack Carrozzo On Mon, Nov 2, 2009 at 4:56 PM, Mark Urbach wrote: > Anyone have a good solution to get "accurate" speed results when testing at 10/100/1000 Ethernet speeds? > > Do you have a server/software that customer can test too? > > > > Thanks, > Mark Urbach > PinPoint Communications, Inc. > 100 N. 12th St ?Suite 500 > Lincoln, NE 68508 > 402-438-6211 ?ext 1923 ?Office > 402-660-7982 ?Cell > mark.urbach at pnpt.com > [cid:image003.jpg at 01CA5BD5.1A5CEE20] > > From nanog at daork.net Mon Nov 2 16:54:21 2009 From: nanog at daork.net (Nathan Ward) Date: Tue, 3 Nov 2009 11:54:21 +1300 Subject: Speed Testing and Throughput testing In-Reply-To: References: Message-ID: <598DF164-D082-4DBA-8FBE-E6E10330A35B@daork.net> On 3/11/2009, at 10:56 AM, Mark Urbach wrote: > Anyone have a good solution to get "accurate" speed results when > testing at 10/100/1000 Ethernet speeds? If you want accuracy, you want to buy a packet generator/router tester unit. I just built a tool for a customer (a last-mile network provider) that runs a series of iperf tests over several days, and generates a report. iperf works well enough, but it seems to be much better when driven by humans, vs. driven by scripts. I'm not aware of any free tools that do just ethernet frames. > Do you have a server/software that customer can test too? Not sure what you're after here - do you want to host your own speedtest.net-like service so your customers can self-test their access links? Does this mean much, or should they be testing against a server outside your network? Also, if you host your own service and you're talking about 10/100/1000mbit connections, you might want to put something in place that prevents several people testing at once. -- Nathan Ward From azher at hep.caltech.edu Mon Nov 2 17:09:09 2009 From: azher at hep.caltech.edu (Azher Mughal) Date: Mon, 02 Nov 2009 15:09:09 -0800 Subject: Speed Testing and Throughput testing In-Reply-To: <598DF164-D082-4DBA-8FBE-E6E10330A35B@daork.net> References: <598DF164-D082-4DBA-8FBE-E6E10330A35B@daork.net> Message-ID: <4AEF6695.7040804@hep.caltech.edu> perfsonar livecd offers npad service that remote hosts can connect and see the performance and results. http://www.internet2.edu/performance/toolkit/index.html TcpOptimizer helps tunning the tcp/ip for windows systems. http://www.speedguide.net/downloads.php nuttcp is good to generate packets/sec. -Azher Nathan Ward wrote: > On 3/11/2009, at 10:56 AM, Mark Urbach wrote: > >> Anyone have a good solution to get "accurate" speed results when >> testing at 10/100/1000 Ethernet speeds? > > If you want accuracy, you want to buy a packet generator/router tester > unit. > > I just built a tool for a customer (a last-mile network provider) that > runs a series of iperf tests over several days, and generates a report. > iperf works well enough, but it seems to be much better when driven by > humans, vs. driven by scripts. > > I'm not aware of any free tools that do just ethernet frames. > >> Do you have a server/software that customer can test too? > > Not sure what you're after here - do you want to host your own > speedtest.net-like service so your customers can self-test their > access links? Does this mean much, or should they be testing against a > server outside your network?Also, if you host your own service and > you're talking about 10/100/1000mbit connections, you might want to > put something in place that prevents several people testing at once. > > -- > Nathan Ward > > -Azher From meekjt at gmail.com Mon Nov 2 17:22:19 2009 From: meekjt at gmail.com (Jon Meek) Date: Mon, 2 Nov 2009 18:22:19 -0500 Subject: Speed Testing and Throughput testing In-Reply-To: References: Message-ID: I use iperf with packet capture on both sides, then analyze the packet capture for per-second throughput and re-transmits. I usually do 10 TCP streams for 30 seconds. Note that on GigE with significant RTTs (5-15 ms) some TCP tuning is needed to deal with the bandwidth delay product. It is also possible that Ethernet drivers will have an effect. Local testing of the pair of test machines should be done if you can't get to about 980 Mbps on a Gig link (keeping in mind the comment about TCP tuning as latency increases). Jon On Mon, Nov 2, 2009 at 4:56 PM, Mark Urbach wrote: > Anyone have a good solution to get "accurate" speed results when testing at 10/100/1000 Ethernet speeds? > > Do you have a server/software that customer can test too? > > > > Thanks, > Mark Urbach > PinPoint Communications, Inc. > 100 N. 12th St ?Suite 500 > Lincoln, NE 68508 > 402-438-6211 ?ext 1923 ?Office > 402-660-7982 ?Cell > mark.urbach at pnpt.com > [cid:image003.jpg at 01CA5BD5.1A5CEE20] > > From andreas at naund.org Mon Nov 2 17:27:59 2009 From: andreas at naund.org (Andreas Ott) Date: Mon, 2 Nov 2009 15:27:59 -0800 Subject: Speed Testing and Throughput testing In-Reply-To: ; from mark.urbach@pnpt.com on Mon, Nov 02, 2009 at 03:56:56PM -0600 References: Message-ID: <20091102152759.U2769@naund.org> Hello, On Mon, Nov 02, 2009 at 03:56:56PM -0600, Mark Urbach wrote: > Anyone have a good solution to get "accurate" speed results when > testing at 10/100/1000 Ethernet speeds? iperf. Check http://www.nanog.org/meetings/nanog43/abstracts.php?pt=MjkmbmFub2c0Mw==&nm=nanog43 and http://www.merit.edu/mail.archives/nanog/2009-03/threads.html#00388 > Do you have a server/software that customer can test too? You can set up your own iperf server on your net, or install the server side parts of the browser based software from 'speedtest.net' http://speedtest.net/mini.php Note: IMHO that one has issues selecting the correct test based on the perceived RTT and will deliver misleading results sometime. -andreas -- Andreas Ott K6OTT andreas at naund.org From tvhawaii at shaka.com Mon Nov 2 17:30:18 2009 From: tvhawaii at shaka.com (Michael Painter) Date: Mon, 2 Nov 2009 13:30:18 -1000 Subject: Speed Testing and Throughput testing References: <598DF164-D082-4DBA-8FBE-E6E10330A35B@daork.net> Message-ID: <36078C360A8B43E5BD6D8A64AD56D81E@DELL16> Nathan Ward wrote: > On 3/11/2009, at 10:56 AM, Mark Urbach wrote: > >> Anyone have a good solution to get "accurate" speed results when >> testing at 10/100/1000 Ethernet speeds? An NDT server?... such as: http://ndt.anl.gov:7123/ From ras at e-gerbil.net Mon Nov 2 18:02:04 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Mon, 2 Nov 2009 18:02:04 -0600 Subject: Speed Testing and Throughput testing In-Reply-To: <36078C360A8B43E5BD6D8A64AD56D81E@DELL16> References: <598DF164-D082-4DBA-8FBE-E6E10330A35B@daork.net> <36078C360A8B43E5BD6D8A64AD56D81E@DELL16> Message-ID: <20091103000204.GB51443@gerbil.cluepon.net> On Mon, Nov 02, 2009 at 01:30:18PM -1000, Michael Painter wrote: > Nathan Ward wrote: > >On 3/11/2009, at 10:56 AM, Mark Urbach wrote: > > > >>Anyone have a good solution to get "accurate" speed results when > >>testing at 10/100/1000 Ethernet speeds? > > An NDT server?... such as: > http://ndt.anl.gov:7123/ I just tested that server, and couldn't get any results which were even vaguely close to accurate. Of course it probably didn't help that the only routes I could find to the test server were either Chicago - Palo Alto - Chicago or Chicago - Ashburn - Chicago, but this doesn't seem like it would ever be useful for testing gigabit anything. For end user testing, I've actually seen reasonable results from speedtest.net. http://www.speedtest.net/result/610596179.png for example, better than ndt.anl.gov at any rate. :P For quick and dirty high speed Internet testing up to a gigabit, this is my favorite standby (it often helps to eliminate your local disk from the equation by writing the downloaded file to /dev/null too): > fetch -o /dev/null http://cachefly.cachefly.net/100mb.test /dev/null 100% of 100 MB 102 MBps But the best (and conveniently enough the most commonly used) tool for in-depth high speed testing was already mentioned, iperf. Another useful tool if you're trying to troubleshoot tcp issues is http://www.tcptrace.org/. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From beckman at angryox.com Mon Nov 2 18:39:14 2009 From: beckman at angryox.com (Peter Beckman) Date: Mon, 2 Nov 2009 19:39:14 -0500 Subject: Level3 90+% Packet Loss in New York Message-ID: Anyone know anything? Has happened twice today, right now, and between 12:22pm and 12:49pm (at least same symptoms as this issue) Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 208.72.185.177 0.0% 785 0.3 0.3 0.2 20.4 1.1 2. 208.72.184.245 0.0% 785 0.6 0.4 0.2 78.7 2.9 3. ge-6-7.car3.NewYork1.Level3.net 0.0% 785 0.6 11.7 0.4 316.3 37.7 4. vlan69.csw1.NewYork1.Level3.net 96.4% 784 8.2 5.4 0.6 13.5 4.2 5. ae-64-64.ebr4.NewYork1.Level3.net 97.1% 784 3.6 11.1 1.7 25.2 6.4 6. ae-6-6.ebr2.NewYork2.Level3.net 95.5% 784 9.0 5.5 1.0 13.7 4.1 7. ae-2-2.ebr1.Chicago1.Level3.net 94.9% 784 39.1 31.2 22.0 41.6 6.5 8. ae-1-53.edge3.Chicago3.Level3.net 96.3% 784 33.4 29.9 21.6 83.6 12.8 9. BANDCON.edge3.Chicago3.Level3.net 95.7% 784 26.8 32.4 22.3 150.1 23.2 10. po2.core3.chi01.steadfast.net 96.3% 784 33.0 30.1 22.2 93.0 13.0 11. ip76.216-86-150.static.steadfast.net 96.3% 777 33.5 28.4 22.6 35.4 4.5 --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From morrowc.lists at gmail.com Mon Nov 2 20:00:00 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 2 Nov 2009 21:00:00 -0500 Subject: Speed Testing and Throughput testing In-Reply-To: References: Message-ID: <75cb24520911021800v3c5c2065rc190b7b9e9381906@mail.gmail.com> On Mon, Nov 2, 2009 at 4:56 PM, Mark Urbach wrote: > Anyone have a good solution to get "accurate" speed results when testing at 10/100/1000 Ethernet speeds? > > Do you have a server/software that customer can test too? One wonders how netnod does this... I believe they put in some servers specifically so their local users could verify that bw bought was bw received... Maybe someone from netnod even wrote up their methods/procedures/process/utilities/tools? :) (Maybe one would even give a talk about it at an upcoming meeting?) -Chris From joly at punkcast.com Mon Nov 2 20:37:47 2009 From: joly at punkcast.com (Joly MacFie) Date: Mon, 2 Nov 2009 21:37:47 -0500 Subject: Level3 90+% Packet Loss in New York In-Reply-To: References: Message-ID: <313b48d0911021837j6976f17ag63a6d998754d3c1d@mail.gmail.com> Only thing I know is that as I was walking home, I saw a Level 3 van with an open manhole cover outside the front of the Tribeca Grand (a block from 32 Ave of A).. On Mon, Nov 2, 2009 at 7:39 PM, Peter Beckman wrote: > Anyone know anything? ?Has happened twice today, right now, and between > 12:22pm and 12:49pm (at least same symptoms as this issue) > > > -- --------------------------------------------------------------- Joly MacFie 917 442 8665 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com --------------------------------------------------------------- From benoit.vannier at apog.net Tue Nov 3 04:01:53 2009 From: benoit.vannier at apog.net (Benoit VANNIER) Date: Tue, 3 Nov 2009 11:01:53 +0100 Subject: Speed Testing and Throughput testing In-Reply-To: References: Message-ID: <41D9DD0F7396FC4CBAC6760948AE02AC011A63EADE@angelina> Hello, Iperf is pretty good at this ... It s free Ben -----Message d'origine----- De?: Mark Urbach [mailto:mark.urbach at pnpt.com] Envoy??: lundi 2 novembre 2009 22:57 ??: nanog at nanog.org Objet?: Speed Testing and Throughput testing Anyone have a good solution to get "accurate" speed results when testing at 10/100/1000 Ethernet speeds? Do you have a server/software that customer can test too? Thanks, Mark Urbach PinPoint Communications, Inc. 100 N. 12th St Suite 500 Lincoln, NE 68508 402-438-6211 ext 1923 Office 402-660-7982 Cell mark.urbach at pnpt.com [cid:image003.jpg at 01CA5BD5.1A5CEE20] From jason at biel-tech.com Tue Nov 3 06:05:24 2009 From: jason at biel-tech.com (Jason Biel) Date: Tue, 3 Nov 2009 06:05:24 -0600 Subject: Speed Testing and Throughput testing In-Reply-To: <41D9DD0F7396FC4CBAC6760948AE02AC011A63EADE@angelina> References: <41D9DD0F7396FC4CBAC6760948AE02AC011A63EADE@angelina> Message-ID: Please take note with using iperf that you'll want to make sure the appropriate TCP Window Size has been negotiated. We recently did some testing with systems that had decided to pick less than optimal window sizes and in turn had to manually set the size within iperf options. Jason On Tue, Nov 3, 2009 at 4:01 AM, Benoit VANNIER wrote: > Hello, > > Iperf is pretty good at this ... It s free > > > Ben > > > -----Message d'origine----- > De : Mark Urbach [mailto:mark.urbach at pnpt.com] > Envoy? : lundi 2 novembre 2009 22:57 > ? : nanog at nanog.org > Objet : Speed Testing and Throughput testing > > Anyone have a good solution to get "accurate" speed results when testing at > 10/100/1000 Ethernet speeds? > > Do you have a server/software that customer can test too? > > > > Thanks, > Mark Urbach > PinPoint Communications, Inc. > 100 N. 12th St Suite 500 > Lincoln, NE 68508 > 402-438-6211 ext 1923 Office > 402-660-7982 Cell > mark.urbach at pnpt.com > [cid:image003.jpg at 01CA5BD5.1A5CEE20] > > > -- Jason Biel From bclark at spectraaccess.com Tue Nov 3 06:18:28 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Tue, 03 Nov 2009 07:18:28 -0500 Subject: Speed Testing and Throughput testing In-Reply-To: References: <41D9DD0F7396FC4CBAC6760948AE02AC011A63EADE@angelina> Message-ID: <4AF01F94.6020303@spectraaccess.com> True, we usually find Linux based machines work better running IPerf then Windows (at least out of the box) because of the TCP window size....well Windows XP at least, don't know about Vista or 7. Jason Biel wrote: Please take note with using iperf that you'll want to make sure the appropriate TCP Window Size has been negotiated. We recently did some testing with systems that had decided to pick less than optimal window sizes and in turn had to manually set the size within iperf options. Jason On Tue, Nov 3, 2009 at 4:01 AM, Benoit VANNIER [1]wrote : Hello, Iperf is pretty good at this ... It s free Ben -----Message d'origine----- De : Mark Urbach [[2]mailto:mark.urbach at pnpt.com] Envoy? : lundi 2 novembre 2009 22:57 ? : [3]nanog at nanog.org Objet : Speed Testing and Throughput testing Anyone have a good solution to get "accurate" speed results when testing at 10/100/1000 Ethernet speeds? Do you have a server/software that customer can test too? Thanks, Mark Urbach PinPoint Communications, Inc. 100 N. 12th St Suite 500 Lincoln, NE 68508 402-438-6211 ext 1923 Office 402-660-7982 Cell [4]mark.urbach at pnpt.com [[5]cid:image003.jpg at 01CA5BD5.1A5CEE20] References 1. mailto:benoit.vannier at apog.net 2. mailto:mark.urbach at pnpt.com 3. mailto:nanog at nanog.org 4. mailto:mark.urbach at pnpt.com 5. cid:image003.jpg at 01CA5BD5.1A5CEE20 From wmaton at ryouko.imsb.nrc.ca Tue Nov 3 06:19:51 2009 From: wmaton at ryouko.imsb.nrc.ca (William F. Maton Sotomayor) Date: Tue, 3 Nov 2009 07:19:51 -0500 (EST) Subject: Speed Testing and Throughput testing In-Reply-To: References: <41D9DD0F7396FC4CBAC6760948AE02AC011A63EADE@angelina> Message-ID: On Tue, 3 Nov 2009, Jason Biel wrote: > Please take note with using iperf that you'll want to make sure the > appropriate TCP Window Size has been negotiated. We recently did some > testing with systems that had decided to pick less than optimal window sizes > and in turn had to manually set the size within iperf options. Indeed this is true. Also, if you use one of the Internet2 network test web100-enabled servers, you can try testing through a web browser. There's both NPAD and NDT on distributed on different nodes, although each has its own slightly different tests. It's also not a bad set of tools for support people wanting to troubleshoot bandwidth problems caused by duplex misconfigs. > > Jason > > On Tue, Nov 3, 2009 at 4:01 AM, Benoit VANNIER wrote: > >> Hello, >> >> Iperf is pretty good at this ... It s free >> >> >> Ben >> >> >> -----Message d'origine----- >> De : Mark Urbach [mailto:mark.urbach at pnpt.com] >> Envoy? : lundi 2 novembre 2009 22:57 >> ? : nanog at nanog.org >> Objet : Speed Testing and Throughput testing >> >> Anyone have a good solution to get "accurate" speed results when testing at >> 10/100/1000 Ethernet speeds? >> >> Do you have a server/software that customer can test too? >> >> >> >> Thanks, >> Mark Urbach >> PinPoint Communications, Inc. >> 100 N. 12th St Suite 500 >> Lincoln, NE 68508 >> 402-438-6211 ext 1923 Office >> 402-660-7982 Cell >> mark.urbach at pnpt.com >> [cid:image003.jpg at 01CA5BD5.1A5CEE20] >> >> >> > > > -- > Jason Biel > wfms From jason at biel-tech.com Tue Nov 3 06:49:05 2009 From: jason at biel-tech.com (Jason Biel) Date: Tue, 3 Nov 2009 06:49:05 -0600 Subject: Speed Testing and Throughput testing In-Reply-To: <4AF01F94.6020303@spectraaccess.com> References: <41D9DD0F7396FC4CBAC6760948AE02AC011A63EADE@angelina> <4AF01F94.6020303@spectraaccess.com> Message-ID: Linux always worked best for us as well, was easy running a livecd with laptops. We found that two windows XP machines, same identical hardware and OS load yielded different registry settings (or lack thereof) for TCP Window setting. Jason On Tue, Nov 3, 2009 at 6:18 AM, Bret Clark wrote: > True, we usually find Linux based machines work better running IPerf > then Windows (at least out of the box) because of the TCP window > size....well Windows XP at least, don't know about Vista or 7. > Jason Biel wrote: > > Please take note with using iperf that you'll want to make sure the > appropriate TCP Window Size has been negotiated. We recently did some > testing with systems that had decided to pick less than optimal window > sizes > and in turn had to manually set the size within iperf options. > > Jason > > On Tue, Nov 3, 2009 at 4:01 AM, Benoit VANNIER [1] >wrote > : > > > Hello, > > Iperf is pretty good at this ... It s free > > > Ben > > > -----Message d'origine----- > De : Mark Urbach [[2]mailto:mark.urbach at pnpt.com] > Envoy? : lundi 2 novembre 2009 22:57 > ? : [3]nanog at nanog.org > Objet : Speed Testing and Throughput testing > > Anyone have a good solution to get "accurate" speed results when testing at > 10/100/1000 Ethernet speeds? > > Do you have a server/software that customer can test too? > > > > Thanks, > Mark Urbach > PinPoint Communications, Inc. > 100 N. 12th St Suite 500 > Lincoln, NE 68508 > 402-438-6211 ext 1923 Office > 402-660-7982 Cell > [4]mark.urbach at pnpt.com > [[5]cid:image003.jpg at 01CA5BD5.1A5CEE20] > > References > > 1. mailto:benoit.vannier at apog.net > 2. mailto:mark.urbach at pnpt.com > 3. mailto:nanog at nanog.org > 4. mailto:mark.urbach at pnpt.com > 5. cid:image003.jpg at 01CA5BD5.1A5CEE20 > -- Jason Biel From lists at memetic.org Tue Nov 3 08:06:06 2009 From: lists at memetic.org (Adam Armstrong) Date: Tue, 03 Nov 2009 14:06:06 +0000 Subject: Small guys with BGP issues In-Reply-To: <4AEE7938.3040500@ibctech.ca> References: <4AEE5998.6060009@ibctech.ca> <19B95C86-540B-4B26-99BD-E9B233828ABF@ianai.net> <4AEE65EF.3040607@ibctech.ca> <20091102050734.GN51443@gerbil.cluepon.net> <4AEE715B.8020801@ibctech.ca> <20091102060059.GO51443@gerbil.cluepon.net> <4AEE7938.3040500@ibctech.ca> Message-ID: <4AF038CE.9000204@memetic.org> Steve Bertrand wrote: > I'm venting. I'm allowed to vent here. I think I'm qualified to do so Sorry, this is not facebook. You're not allowed to randomly splurt inane and unexplaned rants and complaints. At the very least it makes you look stupid to your peers, and at worst it will harm your future employement prospects with anyone on the list. Think before you email. adam. From jmaimon at ttec.com Tue Nov 3 08:45:26 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Tue, 03 Nov 2009 09:45:26 -0500 Subject: Upstream BGP community support In-Reply-To: <4AEF341D.7050009@bogus.com> References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> <4AEF341D.7050009@bogus.com> Message-ID: <4AF04206.3050602@ttec.com> Joel Jaeggli wrote: > So this questions we have approached from time to time. Is there some > worth to be had in finding some consensus (assuming such a thing is > possible) on a subset of the features that people use communities for > that could be standardized? particularly in the context of source based > remote triggered blackholing this seemed a like a worthwhile effort. > > A standardized set means it can be cooked into documentation, training, > and potentially even products. > > it doesn't mean that everyone will enable it, but if they do it would be > nice to agree on some basi grounds rules. it should also be understood > that many if not most localized community signaling uses would remain > localized in terms of their documentation and use. > > joel > It might be a holy grail to have it completely automatable, but it would seriously help just to have a couple standard ways to do things published, product support could follow that. I dont know if communities is really the best thing to keep overloading this way. Whats wrong with dedicating a new attribute for automating policy? From jmaimon at ttec.com Tue Nov 3 08:46:45 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Tue, 03 Nov 2009 09:46:45 -0500 Subject: Small guys with BGP issues In-Reply-To: <20091102050734.GN51443@gerbil.cluepon.net> References: <4AEE5998.6060009@ibctech.ca> <19B95C86-540B-4B26-99BD-E9B233828ABF@ianai.net> <4AEE65EF.3040607@ibctech.ca> <20091102050734.GN51443@gerbil.cluepon.net> Message-ID: <4AF04255.3010107@ttec.com> Richard A Steenbergen wrote: > On Sun, Nov 01, 2009 at 11:54:07PM -0500, Steve Bertrand wrote: >> I'm not a political person. Take it for what it is worth. > What is the issue here, that your DSL provider won't speak BGP with you > no matter how many times you've asked, so you're complaining to NANOG > about it because you don't have the ability or authority to change > providers? Please correct me if I'm reading this wrong, but the emails > so far haven't been very clear and this isn't making a lot of sense. > Any small ISP's that I may have the privilege to be involved with should have no issues running BGP with a DSL customer if thats what was needed to properly achieve their objectives. I would even do it over a GRE tunnel. BGP is a tool, not a measuring stick. Of course that would have more to do with insistence and effort to bring the overall network to the state where it is practical and non dangerous, some hodge-podges just are not conducive. You can attach a DSL line to any piece of complex gear, it just takes using a bridge. I have attached them to the full range of cisco "small" gear (among others), from 1600 - 7200. They all have ethernet ports and pppoe dialers. They can come up to speeds of 15/1. You can terminate multiples. You can use them in conjunction with faster lines. This kind of flexibility is exactly why small ISP's exist. Bring on the inflexibility! It is lifeblood for the small players and that is what competition is all about. We can always learn something of value from each other. I completely respect that those who work with larger networks as a matter of course have talents and skills other may not have been able to develop and hone and I believe the reverse is true as well. I have seen a welcoming and fairly level playing ground at NANOG, both at meetings and on this list. I suspect most consider whining and responding smackdowns to be distasteful and I would appreciate encouraging anyone with the temptation to do so to please reconsider and spare everyone. Save your draft, drink your coffee and re-read it before sending. Joe From joelja at bogus.com Tue Nov 3 09:14:12 2009 From: joelja at bogus.com (joel jaeggli) Date: Tue, 03 Nov 2009 07:14:12 -0800 Subject: Upstream BGP community support In-Reply-To: <4AF04206.3050602@ttec.com> References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> <4AEF341D.7050009@bogus.com> <4AF04206.3050602@ttec.com> Message-ID: <4AF048C4.7000300@bogus.com> Joe Maimon wrote: > > I dont know if communities is really the best thing to keep overloading > this way. Whats wrong with dedicating a new attribute for automating > policy? Well there's always flowspec, as an example... From mike-nanog at tiedyenetworks.com Tue Nov 3 10:11:15 2009 From: mike-nanog at tiedyenetworks.com (Mike) Date: Tue, 03 Nov 2009 08:11:15 -0800 Subject: small site multi-homing (related to: Small guys with BGP issues) In-Reply-To: <4AF04255.3010107@ttec.com> References: <4AEE5998.6060009@ibctech.ca> <19B95C86-540B-4B26-99BD-E9B233828ABF@ianai.net> <4AEE65EF.3040607@ibctech.ca> <20091102050734.GN51443@gerbil.cluepon.net> <4AF04255.3010107@ttec.com> Message-ID: <4AF05623.2090007@tiedyenetworks.com> Small-site multi-homing is one of the great inequities of the Internet and one that can, and should, be solved. I envision an Internet of the future where anyone with any mixture of any type of network connections can achieve, automatically, provider independence and inbound/outbound load sharing across disparate links. Gone is the built in hostage situation of having to either use your provider assigned IP's (>%99 of internet connected sites today), or the quantum leap of being an AS with PI space (and the associated technical baggage to configure and manage that beast). End users should have the power to dictate their own routing policies and not suffer thru 'damping', 'urpf', or other policies imposed on how or when their packets come and go. So if you want to use 2 dsl lines and a CDMA modem, or a satellite and a fiber, or 27 dial up modems and a T1, you should be able to do that and the network should work with you to deliver your packets no matter where 'you' connect or how. What it's gonna take is new routing paradigms and new thinking about the role of providers and users and a lowering of the barriers between these two for more cooperation in the overall structure of the network. Just like classfull addressing giving way to cidr, I belive hierarchal routing will give way to truely dynamic routing where all participants have equal capabilities over their own domain with no one (or group) of 'providers' having any more or less influence on global reachability for any 'users' who choose to go their own way, and I expect that to be an easy (or even default) choice in the future. You may say I'm a dreamer, but I'm not the only one. I hope some day you'll join us, and the world will live as one. >> What is the issue here, that your DSL provider won't speak BGP with you >> no matter how many times you've asked, so you're complaining to NANOG >> about it because you don't have the ability or authority to change >> providers? Please correct me if I'm reading this wrong, but the emails >> so far haven't been very clear and this isn't making a lot of sense. >> From michael at linuxmagic.com Tue Nov 3 10:32:10 2009 From: michael at linuxmagic.com (Michael Peddemors) Date: Tue, 3 Nov 2009 08:32:10 -0800 Subject: New Class C's just lit on on AT&T, Email Marketing Message-ID: <200911030832.10155.michael@linuxmagic.com> A new block under AT&T, listed as being owned by: The Karcher Group Inc. ATTIS-9951800 (NET-99-51-80-0-1) 99.51.80.0 - 99.51.81.255 Just started an email marketing campaign to addresses stripped from the web.. We wouldn't run out of IP's if this didn't keep happening.. So called CAN-SPAM compliant of course.. Return-Path: <618882010 at return.signtabulararrayoffice.com> Delivered-To: support at linuxmagic.com Received: (qmail 25942 invoked from network); 3 Nov 2009 05:26:41 -0000 Received: from unknown (HELO mail23.collegeloanassociates.com) (99.51.80.247) by thundercracker.cityemail.com with SMTP; Mon, 02 Nov 2009 21:26:41 -0800 DKIM-Signature: v=1; a=rsa-sha1; d=signtabulararrayoffice.com; s=default; c=simple/simple; q=dns/txt; i=@signtabulararrayoffice.com; t=1257225979; h=From; bh=dua1L4dgTnW3vCenQjnlynXJ0yk=; b=jxhpH/zBQxVZ5O4+8Yd2Va5Dj3v6Soasndd6moffduE1XIfNz7UzYntYdA6AwGZ1 qLBFmNjyNyTKjdeCc9vDa/ApxFy6LrsPMpsRjbyOjh8Io3951KpzLOPD3BwcYYsf; DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws; s=default; d=signtabulararrayoffice.com; h=Received:Date:From:To:Message-id:Mime-Version:Subject:X-Ver:X- CampaignDetail:X-Edata1:X-Log:Errors-To:List-Unsubscribe:Content-Type; b=PhZXM6t8AayFvb3UDWPYbhL98WpXfcC/g95pqhVM2gNwjRd6hnTO+w1PB2z2Xv8/ 5L7acKRTMWdCNZ8Ql1doxzrZ0QYt5u4bd48rbyQiUmMU69ToMXnvFw5mKxLtX5H+ Received: from 316-99.51.80.247 (316-99.51.80.247-s [192.168.1.75]) by signtabulararrayoffice.com for support at linuxmagic.com; Tue, 03 Nov 2009 00:26:19 -0500 Date: Tue, 03 Nov 2009 00:26:19 -0500 From: NaughtyDating Alerts Return-Path: <618882010 at return.initiativesnetwork.com> Delivered-To: support at linuxmagic.com Received: (qmail 28563 invoked from network); 3 Nov 2009 05:32:47 -0000 Received: from unknown (HELO mail16.bankanswer.net) (99.51.80.144) by thundercracker.cityemail.com with SMTP; Mon, 02 Nov 2009 21:32:47 -0800 DKIM-Signature: v=1; a=rsa-sha1; d=initiativesnetwork.com; s=default; c=simple/simple; q=dns/txt; i=@initiativesnetwork.com; t=1257226339; h=From; bh=ZAz5horGN06rHfgsLW4iBy5nKtY=; b=1sfpRla+5g4KyKZbji1fiTueDe9pLJKojoqbjic6icN+CehR20mDLLxhi1m58Jjh 4IO10Esc9T1+nDvh3D68nw0bePfCkBKYO6yOThLpGBb95ewtzZ7oFoq3agpS6tYM; DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws; s=default; d=initiativesnetwork.com; h=Received:Date:From:To:Message-id:Mime-Version:Subject:X-Ver:X- CampaignDetail:X-Edata1:X-Log:Errors-To:List-Unsubscribe:Content-Type; b=VTbPf7DV+qu9jWHRmmpB4U8p9Ug4DMdqkz3c1KcCXPw4uyq23JKkBr/fkWJDnyAz hI+zrGFDem3jt+ReJO7X9IK0nZsB0q7f2gZ2YyZyEP53+LnCScdpcpTWB7CnZXUM Received: from 315-99.51.80.144 (315-99.51.80.144-s [192.168.1.78]) by initiativesnetwork.com for support at linuxmagic.com; Tue, 03 Nov 2009 00:32:10 -0500 Date: Tue, 03 Nov 2009 00:32:10 -0500 From: CoverQuotes -- -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors - President/CEO - LinuxMagic Products, Services, Support and Development Visit us at http://www.linuxmagic.com ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-589-0037 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From jlewis at lewis.org Tue Nov 3 10:49:21 2009 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 3 Nov 2009 11:49:21 -0500 (EST) Subject: New Class C's just lit on on AT&T, Email Marketing In-Reply-To: <200911030832.10155.michael@linuxmagic.com> References: <200911030832.10155.michael@linuxmagic.com> Message-ID: On Tue, 3 Nov 2009, Michael Peddemors wrote: > A new block under AT&T, listed as being owned by: > > The Karcher Group Inc. ATTIS-9951800 (NET-99-51-80-0-1) 99.51.80.0 - > 99.51.81.255 > > Just started an email marketing campaign to addresses stripped from the web.. > > We wouldn't run out of IP's if this didn't keep happening.. I don't see how this relates to IPv4-runout. The allocation (to AT&T) isn't all that new...and when they cancel this spammer, the space will undoubtedly be assigned to another customer. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From rubensk at gmail.com Tue Nov 3 10:52:53 2009 From: rubensk at gmail.com (Rubens Kuhl) Date: Tue, 3 Nov 2009 14:52:53 -0200 Subject: New Class C's just lit on on AT&T, Email Marketing In-Reply-To: References: <200911030832.10155.michael@linuxmagic.com> Message-ID: <6bb5f5b10911030852v488d7a47mdf430153c476fd3c@mail.gmail.com> >> Just started an email marketing campaign to addresses stripped from the >> web.. >> >> We wouldn't run out of IP's if this didn't keep happening.. > > I don't see how this relates to IPv4-runout. ?The allocation (to AT&T) isn't > all that new...and when they cancel this spammer, the space will undoubtedly > be assigned to another customer. And the new customer will suffer from blocklists until he asks AT&T for a new space, which will most likely be granted, consuming the previous spammer allocation for ever. Rubens From michael at linuxmagic.com Tue Nov 3 10:54:32 2009 From: michael at linuxmagic.com (Michael Peddemors) Date: Tue, 3 Nov 2009 08:54:32 -0800 Subject: New Class C's just lit on on AT&T, Email Marketing In-Reply-To: <14b99b330911030843y41b0538dm325698330c130487@mail.gmail.com> References: <200911030832.10155.michael@linuxmagic.com> <14b99b330911030843y41b0538dm325698330c130487@mail.gmail.com> Message-ID: <200911030854.32734.michael@linuxmagic.com> It was mentioned that this might be offtopic for this list, however I did want to get a feel for the attitudes of network operators, in light of the recent discussions regarding the Russian Operators.. and blocking routing et al.. At what point does it become an issue to the point where operators demand that others are responsible for the activiities coming from their networks? Wanted to start a thread on this issue.. It was mentioned that not routing operators who are puported to be owned/operated/supported by criminal activities, in conjunction with the Russian IP's, and the controversy on the Hurricane Electric actions.. I think this is on topic.. However, if others think it isn't I will not post to this subject here further... I do know that there is a lot of chatter on this list, so I fully understand if it needs to be kept for strictly technical problems, rather than discussions. -- Michael -- On November 3, 2009, you wrote: > Hi, > > This really is not on topic for NANOG at all (unless you want to hear > people whine about calling it a 'class c' instead of the /23 it is, > etc etc) but it probably *is* on topic for the mailop list. I would > suggest setting followups to this message accordingly with nanog not > included. > > On Tue, Nov 3, 2009 at 11:32 AM, Michael Peddemors > > wrote: > > A new block under AT&T, listed as being owned by: > > > > The Karcher Group Inc. ATTIS-9951800 (NET-99-51-80-0-1) 99.51.80.0 - > > 99.51.81.255 > > > > Just started an email marketing campaign to addresses stripped from the > > web.. > > > > We wouldn't run out of IP's if this didn't keep happening.. > > > > So called CAN-SPAM compliant of course.. > > -- -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors - President/CEO - LinuxMagic Products, Services, Support and Development Visit us at http://www.linuxmagic.com ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-589-0037 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From braaen at zcorum.com Tue Nov 3 11:28:06 2009 From: braaen at zcorum.com (Brian Raaen) Date: Tue, 3 Nov 2009 12:28:06 -0500 Subject: small site multi-homing (related to: Small guys with BGP issues) In-Reply-To: <4AF05623.2090007@tiedyenetworks.com> References: <4AEE5998.6060009@ibctech.ca> <4AF04255.3010107@ttec.com> <4AF05623.2090007@tiedyenetworks.com> Message-ID: <200911031228.07126.braaen@zcorum.com> While the idea of seamless routing sounds great, so does world peace... I don't think I will see either in my lifetime. There are some technical hurdles you will have to solve first. 1st how do I solve security (preventing spoofing and other evil deeds done by rouge networks). 2nd how can my system scale and achieve stability. 3rd how will my routes work and converge (unstable routes don't work really well). 4th My system will need to work and scale on a much larger environment than a lab. 5th How do I test and verify your system. 6th Politics/Layer 8 (think peering wars) 7th How do I propose for routers be able to store (2^128 + 2^32) * x routes in their routing table, and possibly utilize current hardware (the whole world isn't going to do a flag day forklift upgrade) 8th How am I going to get anyone to invest money and R&D into my system. If you have any good idea's we'd love to hear them. I am open to such a system, but do not think it can realistically happen anytime soon. -- ---------------------- Brian Raaen Network Engineer braaen at zcorum.com On Tuesday 03 November 2009, Mike wrote: > > Small-site multi-homing is one of the great inequities of the > Internet and one that can, and should, be solved. I envision an Internet > of the future where anyone with any mixture of any type of network > connections can achieve, automatically, provider independence and > inbound/outbound load sharing across disparate links. Gone is the built > in hostage situation of having to either use your provider assigned IP's > (>%99 of internet connected sites today), or the quantum leap of being > an AS with PI space (and the associated technical baggage to configure > and manage that beast). End users should have the power to dictate > their own routing policies and not suffer thru 'damping', 'urpf', or > other policies imposed on how or when their packets come and go. So if > you want to use 2 dsl lines and a CDMA modem, or a satellite and a > fiber, or 27 dial up modems and a T1, you should be able to do that and > the network should work with you to deliver your packets no matter where > 'you' connect or how. > > What it's gonna take is new routing paradigms and new thinking about > the role of providers and users and a lowering of the barriers between > these two for more cooperation in the overall structure of the network. > Just like classfull addressing giving way to cidr, I belive hierarchal > routing will give way to truely dynamic routing where all participants > have equal capabilities over their own domain with no one (or group) of > 'providers' having any more or less influence on global reachability for > any 'users' who choose to go their own way, and I expect that to be an > easy (or even default) choice in the future. > > You may say I'm a dreamer, but I'm not the only one. I hope some day > you'll join us, and the world will live as one. > > > > >> What is the issue here, that your DSL provider won't speak BGP with you > >> no matter how many times you've asked, so you're complaining to NANOG > >> about it because you don't have the ability or authority to change > >> providers? Please correct me if I'm reading this wrong, but the emails > >> so far haven't been very clear and this isn't making a lot of sense. > >> > > > From morrowc.lists at gmail.com Tue Nov 3 11:34:37 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 3 Nov 2009 12:34:37 -0500 Subject: New Class C's just lit on on AT&T, Email Marketing In-Reply-To: <200911030854.32734.michael@linuxmagic.com> References: <200911030832.10155.michael@linuxmagic.com> <14b99b330911030843y41b0538dm325698330c130487@mail.gmail.com> <200911030854.32734.michael@linuxmagic.com> Message-ID: <75cb24520911030934t76fbe38o14e9386847eb3859@mail.gmail.com> On Tue, Nov 3, 2009 at 11:54 AM, Michael Peddemors wrote: > It was mentioned that this might be offtopic for this list, however I did want > to get a feel for the attitudes of network operators, in light of the recent > discussions regarding the Russian Operators.. and blocking routing et al.. > > At what point does it become an issue to the point where operators demand that > others are responsible for the activiities coming from their networks? I think this is fairly much off topic, but.. I'd say this: 1) did you send in proper complaints to att/Sbc for the activity you allege comes from this ip block? 2) did you get back an auto-ack? 3) did this activity start prior to today? (looking at the headers in the original post) If so, then I'm sure ATT will do the right thing in the next little while... they can't turn off (for a variety of reasons) a customer that seems may have been 'ok' for 7 months time (judging by the reg-date for the block in question) with only a single complaint/event. Complaining about this on nanog-l certainly won't get any of your concerns about this SBCIS customer addressed though. -Chris (note I don't see in my personal spamtraps content from this address range) From Valdis.Kletnieks at vt.edu Tue Nov 3 11:42:07 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 03 Nov 2009 12:42:07 -0500 Subject: small site multi-homing (related to: Small guys with BGP issues) In-Reply-To: Your message of "Tue, 03 Nov 2009 08:11:15 PST." <4AF05623.2090007@tiedyenetworks.com> References: <4AEE5998.6060009@ibctech.ca> <19B95C86-540B-4B26-99BD-E9B233828ABF@ianai.net> <4AEE65EF.3040607@ibctech.ca> <20091102050734.GN51443@gerbil.cluepon.net> <4AF04255.3010107@ttec.com> <4AF05623.2090007@tiedyenetworks.com> Message-ID: <5414.1257270127@turing-police.cc.vt.edu> On Tue, 03 Nov 2009 08:11:15 PST, Mike said: > > Small-site multi-homing is one of the great inequities of the > Internet and one that can, and should, be solved. I envision an Internet > of the future where anyone with any mixture of any type of network > connections can achieve, automatically, provider independence and > inbound/outbound load sharing across disparate links. 400 million Joe Sixpacks and their counterparts around the globe, all wanting to run BGPto multihome the /29 in their basement. Be careful what you ask for, you may get it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jay at west.net Tue Nov 3 11:54:27 2009 From: jay at west.net (Jay Hennigan) Date: Tue, 03 Nov 2009 09:54:27 -0800 Subject: New Class C's just lit on on AT&T, spamming In-Reply-To: References: <200911030832.10155.michael@linuxmagic.com> Message-ID: <4AF06E53.106@west.net> Jon Lewis wrote: > On Tue, 3 Nov 2009, Michael Peddemors wrote: > >> A new block under AT&T, listed as being owned by: >> >> The Karcher Group Inc. ATTIS-9951800 (NET-99-51-80-0-1) 99.51.80.0 - >> 99.51.81.255 >> >> Just started an email marketing campaign to addresses stripped from >> the web.. There's a far more succinct term for "email marketing campaign"... >> We wouldn't run out of IP's if this didn't keep happening.. > > I don't see how this relates to IPv4-runout. The allocation (to AT&T) > isn't all that new...and when they cancel this spammer, the space will > undoubtedly be assigned to another customer. And that other customer will find that it's poisoned space and will need to look for another subnet. -- 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 cluestore at gmail.com Tue Nov 3 12:01:42 2009 From: cluestore at gmail.com (Clue Store) Date: Tue, 3 Nov 2009 12:01:42 -0600 Subject: small site multi-homing (related to: Small guys with BGP issues) In-Reply-To: <4AF05623.2090007@tiedyenetworks.com> References: <4AEE5998.6060009@ibctech.ca> <19B95C86-540B-4B26-99BD-E9B233828ABF@ianai.net> <4AEE65EF.3040607@ibctech.ca> <20091102050734.GN51443@gerbil.cluepon.net> <4AF04255.3010107@ttec.com> <4AF05623.2090007@tiedyenetworks.com> Message-ID: <580af3b90911031001q53836fcfma81f03e18553cf0@mail.gmail.com> Well you and the rest of these so called "dreamers" can help with the purchase of my new routers that don't exist yet to support you wanting to multi-home a /29 and have the rest of the Internet world hold all of these said /29's in their tables. Most folks who get a /29's don't care how they get to and from the internet, they just want to always be able to get there. TE at that granular of a level is not needed. So in other words, you and the rest of the world of these dreamers can keep dreaming, because I doubt any sensible ISP would accept and pass along anyone announcing /29's .... and then there's V6, which I won't even get started on. Most ISP's are having a hard time holding 300k ipv4 routes as of today, and you want to de-aggregate even farther?? Clue On Tue, Nov 3, 2009 at 10:11 AM, Mike wrote: > > Small-site multi-homing is one of the great inequities of the Internet > and one that can, and should, be solved. I envision an Internet of the > future where anyone with any mixture of any type of network connections can > achieve, automatically, provider independence and inbound/outbound load > sharing across disparate links. Gone is the built in hostage situation of > having to either use your provider assigned IP's (>%99 of internet connected > sites today), or the quantum leap of being an AS with PI space (and the > associated technical baggage to configure and manage that beast). End users > should have the power to dictate their own routing policies and not suffer > thru 'damping', 'urpf', or other policies imposed on how or when their > packets come and go. So if you want to use 2 dsl lines and a CDMA modem, or > a satellite and a fiber, or 27 dial up modems and a T1, you should be able > to do that and the network should work with you to deliver your packets no > matter where 'you' connect or how. > > What it's gonna take is new routing paradigms and new thinking about the > role of providers and users and a lowering of the barriers between these two > for more cooperation in the overall structure of the network. Just like > classfull addressing giving way to cidr, I belive hierarchal routing will > give way to truely dynamic routing where all participants have equal > capabilities over their own domain with no one (or group) of 'providers' > having any more or less influence on global reachability for any 'users' who > choose to go their own way, and I expect that to be an easy (or even > default) choice in the future. > > You may say I'm a dreamer, but I'm not the only one. I hope some day > you'll join us, and the world will live as one. > > > > What is the issue here, that your DSL provider won't speak BGP with you >>> no matter how many times you've asked, so you're complaining to NANOG >>> about it because you don't have the ability or authority to change >>> providers? Please correct me if I'm reading this wrong, but the emails >>> so far haven't been very clear and this isn't making a lot of sense. >>> >>> > > From jlewis at lewis.org Tue Nov 3 12:03:02 2009 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 3 Nov 2009 13:03:02 -0500 (EST) Subject: New Class C's just lit on on AT&T, spamming In-Reply-To: <4AF06E53.106@west.net> References: <200911030832.10155.michael@linuxmagic.com> <4AF06E53.106@west.net> Message-ID: On Tue, 3 Nov 2009, Jay Hennigan wrote: >> I don't see how this relates to IPv4-runout. The allocation (to AT&T) >> isn't all that new...and when they cancel this spammer, the space will >> undoubtedly be assigned to another customer. > > And that other customer will find that it's poisoned space and will need to > look for another subnet. I don't buy that once IP space has been used by a spammer it's ruined forever. Only if abuse complaints are ignored for a considerable time are the IPs likely to end up widely privately blacklisted. Even then, I don't believe "space is widely blacklisted, please give us more" is a valid justification for going to ARIN for more IPs. We've terminated spammer customers...and reused their assignments. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From joelja at bogus.com Tue Nov 3 12:05:09 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 03 Nov 2009 10:05:09 -0800 Subject: small site multi-homing (related to: Small guys with BGP issues) In-Reply-To: <5414.1257270127@turing-police.cc.vt.edu> References: <4AEE5998.6060009@ibctech.ca> <19B95C86-540B-4B26-99BD-E9B233828ABF@ianai.net> <4AEE65EF.3040607@ibctech.ca> <20091102050734.GN51443@gerbil.cluepon.net> <4AF04255.3010107@ttec.com> <4AF05623.2090007@tiedyenetworks.com> <5414.1257270127@turing-police.cc.vt.edu> Message-ID: <4AF070D5.1070306@bogus.com> Valdis.Kletnieks at vt.edu wrote: > On Tue, 03 Nov 2009 08:11:15 PST, Mike said: >> Small-site multi-homing is one of the great inequities of the >> Internet and one that can, and should, be solved. I envision an Internet >> of the future where anyone with any mixture of any type of network >> connections can achieve, automatically, provider independence and >> inbound/outbound load sharing across disparate links. Hey there's always LISP, they even have code... http://www.ietf.org/dyn/wg/charter/lisp-charter.html The largest inequity of all is that cost delta to you when advertise one more prefix (minor) vs the collective cost to the whole internet of carrying it. The fact is that a combination of technical conventions, business considerations, and social pressures retard the growth in the routing table to a rate which while not all that desirable from some perspectives is manageable. It continues to be the case that the barrier to entry is relatively low as the existance proof of new entrants routinely shows. There is in fact nothing other than a little money, time, and a business need between you and multihoming. The fact that it may not be as cheap or convenient as some might like is not the product of discrimination... > 400 million Joe Sixpacks and their counterparts around the globe, all wanting > to run BGPto multihome the /29 in their basement. > > Be careful what you ask for, you may get it. From davei at otd.com Tue Nov 3 12:21:40 2009 From: davei at otd.com (Dave Israel) Date: Tue, 03 Nov 2009 13:21:40 -0500 Subject: small site multi-homing (related to: Small guys with BGP issues) In-Reply-To: <580af3b90911031001q53836fcfma81f03e18553cf0@mail.gmail.com> References: <4AEE5998.6060009@ibctech.ca> <19B95C86-540B-4B26-99BD-E9B233828ABF@ianai.net> <4AEE65EF.3040607@ibctech.ca> <20091102050734.GN51443@gerbil.cluepon.net> <4AF04255.3010107@ttec.com> <4AF05623.2090007@tiedyenetworks.com> <580af3b90911031001q53836fcfma81f03e18553cf0@mail.gmail.com> Message-ID: <4AF074B4.5020603@otd.com> Clue Store wrote: > Well you and the rest of these so called "dreamers" can help with the > purchase of my new routers that don't exist yet to support you wanting to > multi-home a /29 and have the rest of the Internet world hold all of these > said /29's in their tables. Most folks who get a /29's don't care how they > get to and from the internet, they just want to always be able to get there. > TE at that granular of a level is not needed. So in other words, you and the > rest of the world of these dreamers can keep dreaming, because I doubt any > sensible ISP would accept and pass along anyone announcing /29's .... and > then there's V6, which I won't even get started on. Most ISP's are having a > hard time holding 300k ipv4 routes as of today, and you want to de-aggregate > even farther?? > It's clear that you have some impatience with deaggregation, and with cause. However, there are a few flaws in your position. The first is that you contradicted yourself. If most folks who get a /29 don't care how they get to and from the Internet, then there won't be a flood of new /29s. It is the minority who do care how they get to and from the Internet who will be adding routes. Currently, they are doing so by getting more address space than they need assigned, so as to have a block large enough to be heard. If 500 companies are currently announcing /24s to be heard, but could be moved to /29s, then you still have 500 route announcements. You just have a lot less waste. The second is that you said "BGP." Mike didn't say BGP. He said he was dreaming of the future. That future coudl easily include a lightweight multihoming protocol, something that informs interested parties of presence on multiple networks, or allows for extremely fast reconvergence, so that a second route need only join the routing table when needed. And he's right; if I want to change my name to Joe, grab a sixpack, build a rack in my kitchen, and pay two providers for service, it isn't unreasonable to want an infrastructure that supports my configuration. We shouldn't dismiss a dreamer's dream because it is hard, or we can't do it right now with what we have. The desire to do what is not currently possible is the source of innovation, and we shouldn't shoot down innovation because it sounds hard and we don't like it. -Dave From dave.nanog at alfordmedia.com Tue Nov 3 12:33:14 2009 From: dave.nanog at alfordmedia.com (Dave Pooser) Date: Tue, 03 Nov 2009 12:33:14 -0600 Subject: small site multi-homing (related to: Small guys with BGP issues) In-Reply-To: <4AF074B4.5020603@otd.com> Message-ID: > If 500 companies are currently > announcing /24s to be heard, but could be moved to /29s, then you still > have 500 route announcements. You just have a lot less waste. That's my situation here. I've got a /24 with fewer than 10 public IPs active, because I need those 10 hosts to be reachable even after Bubba and his backhoe finish tearing up the road in front of my office. -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com From tico-nanog at raapid.net Tue Nov 3 12:50:06 2009 From: tico-nanog at raapid.net (Tico) Date: Tue, 03 Nov 2009 10:50:06 -0800 Subject: HE.net, Fremont-2 outage? Message-ID: <4AF07B5E.1020504@raapid.net> Hey guys, I can't get through to Hurricane Electric, and they seem to be having an outage at their Fremont-2 facility again (as of 17:30 UTC or thereabouts) -- ticket system is unanswered, phones go to voicemail, all equipment is unreachable. Does anyone here have a presence at 48233 Warm Springs Blvd, that can provide any information about this? I got hit by the ATS failure last month, so I guess it's possible that that equipment may have flaked again. -t From cluestore at gmail.com Tue Nov 3 13:09:49 2009 From: cluestore at gmail.com (Clue Store) Date: Tue, 3 Nov 2009 13:09:49 -0600 Subject: small site multi-homing (related to: Small guys with BGP issues) In-Reply-To: <4AF074B4.5020603@otd.com> References: <4AEE5998.6060009@ibctech.ca> <19B95C86-540B-4B26-99BD-E9B233828ABF@ianai.net> <4AEE65EF.3040607@ibctech.ca> <20091102050734.GN51443@gerbil.cluepon.net> <4AF04255.3010107@ttec.com> <4AF05623.2090007@tiedyenetworks.com> <580af3b90911031001q53836fcfma81f03e18553cf0@mail.gmail.com> <4AF074B4.5020603@otd.com> Message-ID: <580af3b90911031109g5557d5femdf2343ff2c5b2e25@mail.gmail.com> I think you're missing my point and did not read my post completely. First off, BGP was never mentioned in my post. By the time these 'dreamers' want to announce a /29 to multiple providers and have everyone accept them with this new light weight protocol you speak about, there will hopefully be no /29's (as in v4 host sub-nets) as I dream that IPv4 will be a forgotten protocol by the time BGP is replaced by this magical protocol that does not exist in any form as today. If I accept a /29 for the minority and pass that prefix along to the next provider, I have to accept it for the majority and pass them along to the next provider. And these 500 company's you speak about, the other blocks given back to would be hashed back out which WOULD still increase prefixes in the global table as they want to advertise their /29's. I agree that it would save v4 space right now for those who wouldn't announce the remainder /29's, but you're thinking short term as we all know that v4 space has out-welcomed it's stay (thank you NAT). Yes, it will run paraellel for 3, 5, maybe 7 years until enough folks get a clue and make the switch to v6, but in the end, v4 will go away. Having all that said, I am not knocking the 'dreamers' out there one bit. I encourage new ideas to help solve issues that we've discussed in this very thread. But at this point, there's more dreaming than solutions and revenue. And de-aggreation is one of the biggest problems with global routing today. Add v6 and the possibility of /48's being permitted into the global table, and most folks with a router from any vendor today couldn't support a full global table. I'll stop my rant at that, but again, im not knocking the dreamers. I'm just having to deal with more problems that don't have valid solutions today. Clue On Tue, Nov 3, 2009 at 12:21 PM, Dave Israel wrote: > > Clue Store wrote: > > Well you and the rest of these so called "dreamers" can help with the > > purchase of my new routers that don't exist yet to support you wanting to > > multi-home a /29 and have the rest of the Internet world hold all of > these > > said /29's in their tables. Most folks who get a /29's don't care how > they > > get to and from the internet, they just want to always be able to get > there. > > TE at that granular of a level is not needed. So in other words, you and > the > > rest of the world of these dreamers can keep dreaming, because I doubt > any > > sensible ISP would accept and pass along anyone announcing /29's .... and > > then there's V6, which I won't even get started on. Most ISP's are having > a > > hard time holding 300k ipv4 routes as of today, and you want to > de-aggregate > > even farther?? > > > > It's clear that you have some impatience with deaggregation, and with > cause. However, there are a few flaws in your position. The first is > that you contradicted yourself. If most folks who get a /29 don't care > how they get to and from the Internet, then there won't be a flood of > new /29s. It is the minority who do care how they get to and from the > Internet who will be adding routes. Currently, they are doing so by > getting more address space than they need assigned, so as to have a > block large enough to be heard. If 500 companies are currently > announcing /24s to be heard, but could be moved to /29s, then you still > have 500 route announcements. You just have a lot less waste. > > The second is that you said "BGP." Mike didn't say BGP. He said he was > dreaming of the future. That future coudl easily include a lightweight > multihoming protocol, something that informs interested parties of > presence on multiple networks, or allows for extremely fast > reconvergence, so that a second route need only join the routing table > when needed. And he's right; if I want to change my name to Joe, grab a > sixpack, build a rack in my kitchen, and pay two providers for service, > it isn't unreasonable to want an infrastructure that supports my > configuration. > > We shouldn't dismiss a dreamer's dream because it is hard, or we can't > do it right now with what we have. The desire to do what is not > currently possible is the source of innovation, and we shouldn't shoot > down innovation because it sounds hard and we don't like it. > > -Dave > > > From stef-list at memberwebs.com Tue Nov 3 13:13:12 2009 From: stef-list at memberwebs.com (Stef Walter) Date: Tue, 03 Nov 2009 13:13:12 -0600 Subject: HE.net, Fremont-2 outage? In-Reply-To: <4AF07B5E.1020504@raapid.net> References: <4AF07B5E.1020504@raapid.net> Message-ID: <4AF080C8.5010108@memberwebs.com> Tico wrote: > Hey guys, > > I can't get through to Hurricane Electric, and they seem to be having an > outage at their Fremont-2 facility again (as of 17:30 UTC or > thereabouts) -- > ticket system is unanswered, phones go to voicemail, all equipment is > unreachable. Yes, there was a power outage. Confirmed with Hurricane Electric. All our equipment was offline for 5 minutes or so. Discussed over on outages at outages.org. This is the second such data center wide power outage in 2 months. I'm unimpressed with their lack of transparency on these issues. It seems not even their own employees know the causes or their remedial actions. The impression you get is that it's a pretty wild and crazy over at Hurricane Electric without real disaster recovery plans or procedures. Cheers, Stef From henry at AegisInfoSys.com Tue Nov 3 13:23:46 2009 From: henry at AegisInfoSys.com (Henry Yen) Date: Tue, 3 Nov 2009 14:23:46 -0500 Subject: New Class C's just lit on on AT&T, Email Marketing In-Reply-To: <75cb24520911030934t76fbe38o14e9386847eb3859@mail.gmail.com>; from Christopher Morrow on Tue, Nov 03, 2009 at 12:34:37PM -0500 References: <200911030832.10155.michael@linuxmagic.com> <14b99b330911030843y41b0538dm325698330c130487@mail.gmail.com> <200911030854.32734.michael@linuxmagic.com> <75cb24520911030934t76fbe38o14e9386847eb3859@mail.gmail.com> Message-ID: <20091103142346.K31930@AegisInfoSys.com> On Tue, Nov 03, 2009 at 12:34:37PM -0500, Christopher Morrow wrote: > 3) did this activity start prior to today? (looking at the headers in > the original post) e-mail spam from 99.51.80.0/23 starting 04/15/2009, and from 99.51.84.0/24 starting 09/21/2009. -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York From nenolod at systeminplace.net Tue Nov 3 13:28:01 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Tue, 3 Nov 2009 19:28:01 +0000 Subject: HE.net, Fremont-2 outage? Message-ID: <1074431535-1257276457-cardhu_decombobulator_blackberry.rim.net-581302542-@bda145.bisx.prod.on.blackberry> Yeah. They had yet another power outage. The fourth in 16 months. Luckily we have already begun plans to leave their facility. William ------Original Message------ From: Tico To: nanog at nanog.org Subject: HE.net, Fremont-2 outage? Sent: Nov 3, 2009 1:50 PM Hey guys, I can't get through to Hurricane Electric, and they seem to be having an outage at their Fremont-2 facility again (as of 17:30 UTC or thereabouts) -- ticket system is unanswered, phones go to voicemail, all equipment is unreachable. Does anyone here have a presence at 48233 Warm Springs Blvd, that can provide any information about this? I got hit by the ATS failure last month, so I guess it's possible that that equipment may have flaked again. -t -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-866-519-6149 From davei at otd.com Tue Nov 3 13:30:43 2009 From: davei at otd.com (Dave Israel) Date: Tue, 03 Nov 2009 14:30:43 -0500 Subject: small site multi-homing (related to: Small guys with BGP issues) In-Reply-To: <580af3b90911031109g5557d5femdf2343ff2c5b2e25@mail.gmail.com> References: <4AEE5998.6060009@ibctech.ca> <19B95C86-540B-4B26-99BD-E9B233828ABF@ianai.net> <4AEE65EF.3040607@ibctech.ca> <20091102050734.GN51443@gerbil.cluepon.net> <4AF04255.3010107@ttec.com> <4AF05623.2090007@tiedyenetworks.com> <580af3b90911031001q53836fcfma81f03e18553cf0@mail.gmail.com> <4AF074B4.5020603@otd.com> <580af3b90911031109g5557d5femdf2343ff2c5b2e25@mail.gmail.com> Message-ID: <4AF084E3.8080202@otd.com> Clue Store wrote: > I think you're missing my point and did not read my post completely. > > First off, BGP was never mentioned in my post. Oops, you are correct. Somebody else said "BGP." You spoke of the existing table, and so I had BGP in my mind, and I muddled the two together. Mea culpa. > If I accept a /29 for the minority and pass that prefix along to the > next provider, I have to accept it for the majority and pass them > along to the next provider. And these 500 company's you speak about, > the other blocks given back to would be > hashed back out which WOULD still increase prefixes in the global > table as they want to advertise their /29's. I agree that it would > save v4 space right now for those who wouldn't announce the remainder > /29's, but you're thinking short term as we all know that v4 space has > out-welcomed it's stay (thank you NAT). Yes, it will run paraellel for > 3, 5, maybe 7 years until enough folks get a clue and make the switch > to v6, but in the end, v4 will go away. That assumes that there isn't a solution that requires constant presence in the global table, instead of a tell-me-about-this-prefix-when-I-need-it-and-not-before method. I admit that there hasn't been a good solution to the problem yet, but that doesn't mean there isn't one. I'm not sure it has been seriously researched in recent years. > Having all that said, I am not knocking the 'dreamers' out there one > bit. I encourage new ideas to help solve issues that we've discussed > in this very thread. But at this point, there's more dreaming than > solutions and revenue. And de-aggreation is one of the biggest > problems with global routing today. Add v6 and the possibility of > /48's being permitted into the global table, and most folks with a > router from any vendor today couldn't support a full global table. No, but providers having to upgrade software or hardware to support the needs of the network in 3, 5, or 7 years isn't anything new, and neither is router vendors coming up with incremental software or hardware upgrades to make boxes do what they can't do now. -Dave From aaron at coinet.com Tue Nov 3 14:10:43 2009 From: aaron at coinet.com (Aaron L. Meehan) Date: Tue, 3 Nov 2009 12:10:43 -0800 Subject: New Class C's just lit on on AT&T, Email Marketing In-Reply-To: <200911030832.10155.michael@linuxmagic.com> References: <200911030832.10155.michael@linuxmagic.com> Message-ID: <20091103201043.GL9711@earth.coinet.com> I don't think AT&T cares, since I complained about a massive snowshoe spamming campaign a couple of months ago--no action taken it seems--and they have netblocks all over the place there. A bunch of customers were calling me since their junk was being scored low by spamassassin and ending up in inboxes. Blah! I've seen spam from each one of their blocks at at&t. 99.155.208-209 99.51.80-81 99.170.198-199 99.16.32-39 On Tue, Nov 03, 2009 at 08:32:10AM -0800, Michael Peddemors wrote: > A new block under AT&T, listed as being owned by: > > The Karcher Group Inc. ATTIS-9951800 (NET-99-51-80-0-1) 99.51.80.0 - > 99.51.81.255 > > Just started an email marketing campaign to addresses stripped from the web.. > > We wouldn't run out of IP's if this didn't keep happening.. From pbosworth at gmail.com Tue Nov 3 14:18:24 2009 From: pbosworth at gmail.com (Paul Bosworth) Date: Tue, 3 Nov 2009 14:18:24 -0600 Subject: New Class C's just lit on on AT&T, Email Marketing In-Reply-To: <25b132e90911031217u44a8715dr4b70c5a4477a34e5@mail.gmail.com> References: <200911030832.10155.michael@linuxmagic.com> <25b132e90911031217u44a8715dr4b70c5a4477a34e5@mail.gmail.com> Message-ID: <25b132e90911031218y3b4454b2ve510227e318e696b@mail.gmail.com> Just filter it and move on- business as usual. If we barked up every tree we'd never get any real work done. On Nov 3, 2009 11:33 AM, "Michael Peddemors" wrote: A new block under AT&T, listed as being owned by: The Karcher Group Inc. ATTIS-9951800 (NET-99-51-80-0-1) 99.51.80.0 - 99.51.81.255 Just started an email marketing campaign to addresses stripped from the web.. We wouldn't run out of IP's if this didn't keep happening.. So called CAN-SPAM compliant of course.. Return-Path: <618882010 at return.signtabulararrayoffice.com> Delivered-To: support at linuxmagic.com Received: (qmail 25942 invoked from network); 3 Nov 2009 05:26:41 -0000 Received: from unknown (HELO mail23.collegeloanassociates.com) (99.51.80.247) by thundercracker.cityemail.com with SMTP; Mon, 02 Nov 2009 21:26:41 -0800 DKIM-Signature: v=1; a=rsa-sha1; d=signtabulararrayoffice.com; s=default; c=simple/simple; q=dns/txt; i=@signtabulararrayoffice.com; t=1257225979; h=From; bh=dua1L4dgTnW3vCenQjnlynXJ0yk=; b=jxhpH/zBQxVZ5O4+8Yd2Va5Dj3v6Soasndd6moffduE1XIfNz7UzYntYdA6AwGZ1 qLBFmNjyNyTKjdeCc9vDa/ApxFy6LrsPMpsRjbyOjh8Io3951KpzLOPD3BwcYYsf; DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws; s=default; d=signtabulararrayoffice.com; h=Received:Date:From:To:Message-id:Mime-Version:Subject:X-Ver:X- CampaignDetail:X-Edata1:X-Log:Errors-To:List-Unsubscribe:Content-Type; b=PhZXM6t8AayFvb3UDWPYbhL98WpXfcC/g95pqhVM2gNwjRd6hnTO+w1PB2z2Xv8/ 5L7acKRTMWdCNZ8Ql1doxzrZ0QYt5u4bd48rbyQiUmMU69ToMXnvFw5mKxLtX5H+ Received: from 316-99.51.80.247 (316-99.51.80.247-s [192.168.1.75]) by signtabulararrayoffice.com for support at linuxmagic.com; Tue, 03 Nov 2009 00:26:19 -0500 Date: Tue, 03 Nov 2009 00:26:19 -0500 From: NaughtyDating Alerts Return-Path: <618882010 at return.initiativesnetwork.com> Delivered-To: support at linuxmagic.com Received: (qmail 28563 invoked from network); 3 Nov 2009 05:32:47 -0000 Received: from unknown (HELO mail16.bankanswer.net) (99.51.80.144) by thundercracker.cityemail.com with SMTP; Mon, 02 Nov 2009 21:32:47 -0800 DKIM-Signature: v=1; a=rsa-sha1; d=initiativesnetwork.com; s=default; c=simple/simple; q=dns/txt; i=@initiativesnetwork.com; t=1257226339; h=From; bh=ZAz5horGN06rHfgsLW4iBy5nKtY=; b=1sfpRla+5g4KyKZbji1fiTueDe9pLJKojoqbjic6icN+CehR20mDLLxhi1m58Jjh 4IO10Esc9T1+nDvh3D68nw0bePfCkBKYO6yOThLpGBb95ewtzZ7oFoq3agpS6tYM; DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws; s=default; d=initiativesnetwork.com; h=Received:Date:From:To:Message-id:Mime-Version:Subject:X-Ver:X- CampaignDetail:X-Edata1:X-Log:Errors-To:List-Unsubscribe:Content-Type; b=VTbPf7DV+qu9jWHRmmpB4U8p9Ug4DMdqkz3c1KcCXPw4uyq23JKkBr/fkWJDnyAz hI+zrGFDem3jt+ReJO7X9IK0nZsB0q7f2gZ2YyZyEP53+LnCScdpcpTWB7CnZXUM Received: from 315-99.51.80.144 (315-99.51.80.144-s [192.168.1.78]) by initiativesnetwork.com for support at linuxmagic.com; Tue, 03 Nov 2009 00:32:10 -0500 Date: Tue, 03 Nov 2009 00:32:10 -0500 From: CoverQuotes -- -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors - President/CEO - LinuxMagic Products, Services, Support and Development Visit us at http://www.linuxmagic.com ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-589-0037 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From rbonica at juniper.net Tue Nov 3 14:21:36 2009 From: rbonica at juniper.net (Ron Bonica) Date: Tue, 3 Nov 2009 15:21:36 -0500 Subject: ISP port blocking practice In-Reply-To: <4AE0DF32.1040903@justinshore.com> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <4AE0DF32.1040903@justinshore.com> Message-ID: <4AF090D0.7050103@juniper.net> Folks, I would love to see the IETF OPSEC WG publish a Best Common Practices document on ISP Port filtering. The document would capture information similar to that offered by Justin. Would anybody on this list be willing to author an Internet Draft? Ron (co-director IETF O&M Area) Justin Shore wrote: > Zhiyun Qian wrote: >> Hi all, >> >> What is the common practice for enforcing port blocking policy (or what >> is the common practice for you and your ISP)? More specifically, when >> ISPs try to block certain outgoing port (port 25 for instance), they >> could do two rules: >> 1). For any outgoing traffic, if the destination port is 25, then drop >> the packets. >> 2). For any incoming traffic, if the source port is 25, then drop the >> packets. > > I block on both generally. I block inbound and outbound for residential > customers in dynamic pools. I block inbound only for residential with > statically-assigned IPs. That way a customer can request (and pay for) > a static IP and be able to get around out outbound SMTP block. Few > companies use the MSP port (tcp/587). I'm not sure why more don't make > the effort but most don't. To make up for that we allow static > residential customers to evade that filter with a static IP. We still > block inbound though. We also allow them to use our SMTP servers and > SmartHosts if they want with no requirements on source domains (like > some providers require, essentially requiring the customer to advertise > for you). The inbound block isn't really all that useful as you elude > to. However I use it more often than not to look for people scanning > out ranges for open relays. I use that data for feed my RTBH trigger > router and drop the spammer's traffic on the floor (or the poor, > unfortunate owner of the compromised PC that's been 0wned. > > We block several other things too. Netbios traffic gets dropped both > ways. MS-SQL traffic gets dropped both ways (a few users have > complained about this but very few stick to their guns when you point > out that their traffic is traversing the web completely unencrypted). I > block default and common proxy ports such as 3128, 7212, and 6588 in > both directions. Squid is too easy to misconfigure (done it myself). > GhostSurf and WinGate have both been abusable as open proxies in various > releases. I also block 8000, 8080 and 8081 towards the customers. > These are some of our most commonly scanned ports (usually all 3 at once > plus some or all of the 80xx ones). I've encountered many compromised > residential CPEs that the users either enabled themselves or were > enabled by default. I don't block those 3 ports on outbound flows > though; too many false positives. > > And finally we also block several different types of ICMPs. First off > we block ICMP fragments. Then we permit echo, echo-reply, > packet-too-big, and time-exceeded. The rest get explicitly dropped. > IPv6 will change this list dramatically. I haven't had time to research > ICMPv6 thoroughly enough to say any more than that. > > Basically I just pick out some of the really bad ports and block them. > This gives me a wealth of data with which to null-route compromised PCs > scanning my networks. > >> Also, is it common that the rules are based on tcp flags (e.g. SYN, >> SYN-ACK)? One would think block SYN packet is good enough. > > I don't get that deep into it. Forged packets of types other than SYN > can still reek havoc on existing flows. I think it's better to block > all and move on. > > Justin > > > . > From john-nanog at johnpeach.com Tue Nov 3 14:29:54 2009 From: john-nanog at johnpeach.com (John Peach) Date: Tue, 03 Nov 2009 15:29:54 -0500 Subject: New Class C's just lit on on AT&T, Email Marketing In-Reply-To: <20091103201043.GL9711@earth.coinet.com> References: <200911030832.10155.michael@linuxmagic.com> <20091103201043.GL9711@earth.coinet.com> Message-ID: <20091103152954.1fef1d6e@jpeach-desktop.1425mad.mountsinai.org> On Tue, 3 Nov 2009 12:10:43 -0800 "Aaron L. Meehan" wrote: > I don't think AT&T cares, since I complained about a massive snowshoe > spamming campaign a couple of months ago--no action taken it > seems--and they have netblocks all over the place there. A bunch of > customers were calling me since their junk was being scored low by > spamassassin and ending up in inboxes. Blah! I've seen spam from > each one of their blocks at at&t. > > 99.155.208-209 > 99.51.80-81 > 99.170.198-199 > 99.16.32-39 > > 99.16.32.0/21 REJECT 99.51.80.0/23 REJECT 99.155.208.0/23 REJECT 99.170.198.0/23 REJECT will do nicely, thank-you. -- John From rbonica at juniper.net Tue Nov 3 14:44:41 2009 From: rbonica at juniper.net (Ron Bonica) Date: Tue, 3 Nov 2009 15:44:41 -0500 Subject: ip options In-Reply-To: <1256756748.2228.9.camel@nld06907> References: <1256756748.2228.9.camel@nld06907> Message-ID: <4AF09639.1050802@juniper.net> Folks, I would love to see the IETF OPSEC WG publish a document on the pros and cons of filtering optioned packets. Would anybody on this list be willing to author an Internet Draft? Ron (co-director IETF O&M Area) Luca Tosolini wrote: > Experts, > out of the well-known values for ip options: > > X at r4# set ip-options ? > Possible completions: > Range of values > [ Open a set of values > any Any IP option > loose-source-route Loose source route > route-record Route record > router-alert Router alert > security Security > stream-id Stream ID > strict-source-route Strict source route > timestamp Timestamp > > I can only think of: > - RSVP using router-alert > - ICMP using route-record, timestamp > > But I can not think of any other use of any other IP option. > Considering the security hazard that they imply, I am therefore thinking > to drop them. > > Is any other ip options used by: ospf, isis, bgp, ldp, igmp, pim, bfd? > Thanks, > Luca. > > > From nanog at webazilla.com Tue Nov 3 16:35:43 2009 From: nanog at webazilla.com (Konstantin Bezruchenko) Date: Wed, 04 Nov 2009 00:35:43 +0200 Subject: In Building Dark Fiber inside Infomart Dallas Message-ID: <4AF0B03F.9040902@webazilla.com> Hi all, Just wondering if someone here can offer in building dark fiber (cross connects) inside Infomart (1950 Stemmons Freeway, Dallas, TX). We are trying to get from Equinix to Switch and Data. Please reply offlist. Thanks! -Konstantin From mike.lyon at gmail.com Tue Nov 3 16:38:20 2009 From: mike.lyon at gmail.com (Mike Lyon) Date: Tue, 3 Nov 2009 14:38:20 -0800 Subject: In Building Dark Fiber inside Infomart Dallas In-Reply-To: <4AF0B03F.9040902@webazilla.com> References: <4AF0B03F.9040902@webazilla.com> Message-ID: <1b5c1c150911031438x64298230oa680880f8f76de3c@mail.gmail.com> Aren't they the same company now? On Tue, Nov 3, 2009 at 2:35 PM, Konstantin Bezruchenko wrote: > Hi all, > > Just wondering if someone here can offer in building dark fiber (cross > connects) inside Infomart (1950 Stemmons Freeway, Dallas, TX). We are trying > to get from Equinix to Switch and Data. > > Please reply offlist. Thanks! > > -Konstantin > > > From tme at americafree.tv Tue Nov 3 16:46:28 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 3 Nov 2009 17:46:28 -0500 Subject: In Building Dark Fiber inside Infomart Dallas In-Reply-To: <1b5c1c150911031438x64298230oa680880f8f76de3c@mail.gmail.com> References: <4AF0B03F.9040902@webazilla.com> <1b5c1c150911031438x64298230oa680880f8f76de3c@mail.gmail.com> Message-ID: Certainly not yet. On Nov 3, 2009, at 5:38 PM, Mike Lyon wrote: > Aren't they the same company now? > > On Tue, Nov 3, 2009 at 2:35 PM, Konstantin Bezruchenko > wrote: > >> Hi all, >> >> Just wondering if someone here can offer in building dark fiber >> (cross >> connects) inside Infomart (1950 Stemmons Freeway, Dallas, TX). We >> are trying >> to get from Equinix to Switch and Data. >> >> Please reply offlist. Thanks! >> >> -Konstantin >> >> >> > From pcorrao at voxeo.com Tue Nov 3 17:41:38 2009 From: pcorrao at voxeo.com (Paul Corrao) Date: Tue, 3 Nov 2009 18:41:38 -0500 Subject: In Building Dark Fiber inside Infomart Dallas In-Reply-To: References: <4AF0B03F.9040902@webazilla.com> <1b5c1c150911031438x64298230oa680880f8f76de3c@mail.gmail.com> Message-ID: <2C711481-7C50-4AEA-8E59-73413A61FDEE@voxeo.com> The parties are targeting completion of the transaction in the first quarter of 2010. The transaction will be subject to customary closing conditions, including the approval of Switch and Data?s stockholders and regulatory approvals. On Nov 3, 2009, at 5:46 PM, Marshall Eubanks wrote: > Certainly not yet. > > On Nov 3, 2009, at 5:38 PM, Mike Lyon wrote: > >> Aren't they the same company now? >> >> On Tue, Nov 3, 2009 at 2:35 PM, Konstantin Bezruchenko >> wrote: >> >>> Hi all, >>> >>> Just wondering if someone here can offer in building dark fiber >>> (cross >>> connects) inside Infomart (1950 Stemmons Freeway, Dallas, TX). We >>> are trying >>> to get from Equinix to Switch and Data. >>> >>> Please reply offlist. Thanks! >>> >>> -Konstantin >>> >>> >>> >> > > From marka at isc.org Tue Nov 3 18:02:33 2009 From: marka at isc.org (Mark Andrews) Date: Wed, 04 Nov 2009 11:02:33 +1100 Subject: small site multi-homing (related to: Small guys with BGP issues) In-Reply-To: Your message of "Tue, 03 Nov 2009 12:42:07 CDT." <5414.1257270127@turing-police.cc.vt.edu> References: <4AEE5998.6060009@ibctech.ca> <19B95C86-540B-4B26-99BD-E9B233828ABF@ianai.net> <4AEE65EF.3040607@ibctech.ca> <20091102050734.GN51443@gerbil.cluepon.net> <4AF04255.3010107@ttec.com> <4AF05623.2090007@tiedyenetworks.com> <5414.1257270127@turing-police.cc.vt.edu> Message-ID: <200911040002.nA402X2k081264@drugs.dv.isc.org> In message <5414.1257270127 at turing-police.cc.vt.edu>, Valdis.Kletnieks at vt.edu w rites: > On Tue, 03 Nov 2009 08:11:15 PST, Mike said: > > > > Small-site multi-homing is one of the great inequities of the > > Internet and one that can, and should, be solved. I envision an Internet > > of the future where anyone with any mixture of any type of network > > connections can achieve, automatically, provider independence and > > inbound/outbound load sharing across disparate links. > > 400 million Joe Sixpacks and their counterparts around the globe, all wanting > to run BGPto multihome the /29 in their basement. > > Be careful what you ask for, you may get it. With a protocol to distribute which prefixes (with weighting) are viable, a end node could just select a appropritate source address out of several provider assigned ones and use source address routing to find a appropropiate exit path which doesn't break BCP 38. This is as good as the NAT solutions for small-site multi-homing today. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jeffrey.lyon at blacklotus.net Tue Nov 3 19:04:31 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 3 Nov 2009 20:04:31 -0500 Subject: HE.net, Fremont-2 outage? In-Reply-To: <1074431535-1257276457-cardhu_decombobulator_blackberry.rim.net-581302542-@bda145.bisx.prod.on.blackberry> References: <1074431535-1257276457-cardhu_decombobulator_blackberry.rim.net-581302542-@bda145.bisx.prod.on.blackberry> Message-ID: <16720fe00911031704y3b660606hc520cffaf8980780@mail.gmail.com> FWIW: http://www.he.net/releases/release18.html Jeff On Tue, Nov 3, 2009 at 2:28 PM, William Pitcock wrote: > Yeah. ?They had yet another power outage. ?The fourth in 16 months. > > Luckily we have already begun plans to leave their facility. > > William > ------Original Message------ > From: Tico > To: nanog at nanog.org > Subject: HE.net, Fremont-2 outage? > Sent: Nov 3, 2009 1:50 PM > > Hey guys, > > I can't get through to Hurricane Electric, and they seem to be having an > outage at their Fremont-2 facility again (as of 17:30 UTC or thereabouts) -- > ticket system is unanswered, phones go to voicemail, all equipment is > unreachable. > > Does anyone here have a presence at 48233 Warm Springs Blvd, that can > provide any information about this? I got hit by the ATS failure last > month, so I guess it's possible that that equipment may have flaked again. > > -t > > > > -- > William Pitcock > SystemInPlace - Simple Hosting Solutions > 1-866-519-6149 > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From Charles.Jouglard at cox.com Tue Nov 3 19:18:06 2009 From: Charles.Jouglard at cox.com (Charles.Jouglard at cox.com) Date: Tue, 3 Nov 2009 20:18:06 -0500 Subject: T-Mobile ? In-Reply-To: <16720fe00911031704y3b660606hc520cffaf8980780@mail.gmail.com> References: <1074431535-1257276457-cardhu_decombobulator_blackberry.rim.net-581302542-@bda145.bisx.prod.on.blackberry> <16720fe00911031704y3b660606hc520cffaf8980780@mail.gmail.com> Message-ID: Anyone hear of any issues on the T-Mobile network? Seems as if we cannot reach anyone with a T-Mobile cell phone. Dialing out works sporadically, but calls drop frequently. Thanks, Charles From bc-list at beztech.net Tue Nov 3 19:19:23 2009 From: bc-list at beztech.net (Ben Carleton) Date: Tue, 3 Nov 2009 20:19:23 -0500 Subject: T-Mobile ? In-Reply-To: References: <1074431535-1257276457-cardhu_decombobulator_blackberry.rim.net-581302542-@bda145.bisx.prod.on.blackberry> <16720fe00911031704y3b660606hc520cffaf8980780@mail.gmail.com> Message-ID: <9E73E81F-0735-4234-A4CA-F8C44C1E56DC@beztech.net> We are also seeing this in the Metro NY market. Ben On Nov 3, 2009, at 8:18 PM, wrote: > Anyone hear of any issues on the T-Mobile network? Seems as if we > cannot reach anyone with a T-Mobile cell phone. Dialing out works > sporadically, but calls drop frequently. > > Thanks, > Charles From patrick at ianai.net Tue Nov 3 19:20:32 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 3 Nov 2009 20:20:32 -0500 Subject: T-Mobile ? In-Reply-To: References: <1074431535-1257276457-cardhu_decombobulator_blackberry.rim.net-581302542-@bda145.bisx.prod.on.blackberry> <16720fe00911031704y3b660606hc520cffaf8980780@mail.gmail.com> Message-ID: <6011F9BF-4533-4876-9341-39FE58FAF78B@ianai.net> On Nov 3, 2009, at 8:18 PM, wrote: > Anyone hear of any issues on the T-Mobile network? Seems as if we > cannot reach anyone with a T-Mobile cell phone. Dialing out works > sporadically, but calls drop frequently. T-Mobile has admitted the outage. Apparently T-Mobile phones cannot receive calls or texts, even from other T-Mobile phones: But the good news is that they apparently added a 'feature' when you go to pay your bill: -- TTFN, patrick From jeffrey.lyon at blacklotus.net Tue Nov 3 19:20:50 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 3 Nov 2009 20:20:50 -0500 Subject: T-Mobile ? In-Reply-To: References: <1074431535-1257276457-cardhu_decombobulator_blackberry.rim.net-581302542-@bda145.bisx.prod.on.blackberry> <16720fe00911031704y3b660606hc520cffaf8980780@mail.gmail.com> Message-ID: <16720fe00911031720i5e3105eej6590259fd400bd28@mail.gmail.com> We're using T-Mobile here, no issues reported. I have staff at sites in Virginia, California, and Arizona. Jeff On Tue, Nov 3, 2009 at 8:18 PM, wrote: > Anyone hear of any issues on the T-Mobile network? ?Seems as if we cannot reach anyone with a T-Mobile cell phone. ?Dialing out works sporadically, but calls drop frequently. > > Thanks, > Charles > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From pbosworth at gmail.com Tue Nov 3 19:22:11 2009 From: pbosworth at gmail.com (Paul Bosworth) Date: Tue, 3 Nov 2009 19:22:11 -0600 Subject: T-Mobile ? In-Reply-To: References: <1074431535-1257276457-cardhu_decombobulator_blackberry.rim.net-581302542-@bda145.bisx.prod.on.blackberry> <16720fe00911031704y3b660606hc520cffaf8980780@mail.gmail.com> Message-ID: <25b132e90911031722u6ff9e4ebn1cae97587bb30c89@mail.gmail.com> This was brought up on the outages list. T-Mobile is currently experiencing large scale outbound voice and data outages across the nation right now. No current ETA, estimates are several hours. Paul B. On Tue, Nov 3, 2009 at 7:18 PM, wrote: > Anyone hear of any issues on the T-Mobile network? Seems as if we cannot > reach anyone with a T-Mobile cell phone. Dialing out works sporadically, > but calls drop frequently. > > Thanks, > Charles > -- Paul H Bosworth CCNP, CCIP, CCDP, CCDA, CCNA, CCNA Security From moonwick at lasthome.net Tue Nov 3 19:23:38 2009 From: moonwick at lasthome.net (Jonathan Bishop) Date: Tue, 3 Nov 2009 19:23:38 -0600 Subject: T-Mobile ? In-Reply-To: <9E73E81F-0735-4234-A4CA-F8C44C1E56DC@beztech.net> References: <1074431535-1257276457-cardhu_decombobulator_blackberry.rim.net-581302542-@bda145.bisx.prod.on.blackberry> <16720fe00911031704y3b660606hc520cffaf8980780@mail.gmail.com> <9E73E81F-0735-4234-A4CA-F8C44C1E56DC@beztech.net> Message-ID: <64913669-DBEF-4D0D-9750-3390E621E848@lasthome.net> Voice service works in the Austin market but SMS is down. This thread suggests something major died: http://www.howardforums.com/showthread.php?t=1585834 On Nov 3, 2009, at 7:19 PM, Ben Carleton wrote: > We are also seeing this in the Metro NY market. > > > Ben > > On Nov 3, 2009, at 8:18 PM, wrote: > >> Anyone hear of any issues on the T-Mobile network? Seems as if we >> cannot reach anyone with a T-Mobile cell phone. Dialing out works >> sporadically, but calls drop frequently. >> >> Thanks, >> Charles > > -- Jonathan Bishop -- moonwick at lasthome.net http://lasthome.net/~moonwick/ "Embrace the company of those that seek the truth, and run from those who have found it." -- V?clav Havel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2454 bytes Desc: not available URL: From mike_schuler at me.com Tue Nov 3 19:23:38 2009 From: mike_schuler at me.com (Michael Schuler) Date: Tue, 03 Nov 2009 19:23:38 -0600 Subject: T-Mobile ? In-Reply-To: <9E73E81F-0735-4234-A4CA-F8C44C1E56DC@beztech.net> References: <1074431535-1257276457-cardhu_decombobulator_blackberry.rim.net-581302542-@bda145.bisx.prod.on.blackberry> <16720fe00911031704y3b660606hc520cffaf8980780@mail.gmail.com> <9E73E81F-0735-4234-A4CA-F8C44C1E56DC@beztech.net> Message-ID: <7B9C6418-1E4A-4942-955B-AD874539A07E@me.com> Illinois is experiencing the outtage as well looks to be all of the U.S. -- Is ait an mac an sol. Life is strange (such is life). On Nov 3, 2009, at 7:19 PM, Ben Carleton wrote: > We are also seeing this in the Metro NY market. > > > Ben > > On Nov 3, 2009, at 8:18 PM, wrote: > >> Anyone hear of any issues on the T-Mobile network? Seems as if we >> cannot reach anyone with a T-Mobile cell phone. Dialing out works >> sporadically, but calls drop frequently. >> >> Thanks, >> Charles > > From Charles.Jouglard at cox.com Tue Nov 3 19:23:55 2009 From: Charles.Jouglard at cox.com (Charles.Jouglard at cox.com) Date: Tue, 3 Nov 2009 20:23:55 -0500 Subject: T-Mobile ? In-Reply-To: <25b132e90911031722u6ff9e4ebn1cae97587bb30c89@mail.gmail.com> References: <1074431535-1257276457-cardhu_decombobulator_blackberry.rim.net-581302542-@bda145.bisx.prod.on.blackberry> <16720fe00911031704y3b660606hc520cffaf8980780@mail.gmail.com> <25b132e90911031722u6ff9e4ebn1cae97587bb30c89@mail.gmail.com> Message-ID: Thanks. Experiencing the inability to reach several personnel. Thanks, Charles -----Original Message----- From: Paul Bosworth [mailto:pbosworth at gmail.com] Sent: Tuesday, November 03, 2009 7:22 PM To: Jouglard, Charles (CCI-Louisiana) Cc: nanog at nanog.org Subject: Re: T-Mobile ? This was brought up on the outages list. T-Mobile is currently experiencing large scale outbound voice and data outages across the nation right now. No current ETA, estimates are several hours. Paul B. On Tue, Nov 3, 2009 at 7:18 PM, wrote: Anyone hear of any issues on the T-Mobile network? Seems as if we cannot reach anyone with a T-Mobile cell phone. Dialing out works sporadically, but calls drop frequently. Thanks, Charles -- Paul H Bosworth CCNP, CCIP, CCDP, CCDA, CCNA, CCNA Security From sean-list at head-net.com Tue Nov 3 19:25:51 2009 From: sean-list at head-net.com (Sean Head) Date: Tue, 03 Nov 2009 17:25:51 -0800 Subject: T-Mobile ? In-Reply-To: References: <1074431535-1257276457-cardhu_decombobulator_blackberry.rim.net-581302542-@bda145.bisx.prod.on.blackberry> <16720fe00911031704y3b660606hc520cffaf8980780@mail.gmail.com> Message-ID: <4AF0D81F.3080704@head-net.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2009.11.03 17:18:06, Charles.Jouglard at cox.com wrote: > Anyone hear of any issues on the T-Mobile network? Seems as if we cannot reach anyone with a T-Mobile cell phone. Dialing out works sporadically, but calls drop frequently. > > Thanks, > Charles There's been a little chatter about it over on outages. (outages.org) Next time can you start a new message instead of replying to something, then removing the body/subject. Most modern mail clients use message references that allow threaded conversations to happen. And how there's a t-mobile conversation happening under a thread about a he.net failure... - -sean -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJK8NgeAAoJEPWrDhFvhqzdDbIH/Aq5DIjmxmPr4nQc7eRmZqYB L/4+o45+mOKC2odzVUcI5cHmDQwSHqdRB/mxBTEkRM91n077lJIKO+4pdQp5h6Jp VhfICySusHd/05caZh0vVLGs7EZaMlBxQx/Gzs8/8310ipSZlVYXMYLuuDRLBXAO Vfygn6zWRRvdIl8KtMTY6T1nKtrg1+IWeWKlrvP2m6taOsJdkkf7gZ++PuauTPDk qerBMStG2zIIAaWlkuQnMjwBGLqqewDoyKMcDqJL2aavNd9eQSOs+Nb/+v0H+VE2 85Fn+KBsktlUlHhmrkEAC9kmMilpECDiq/PtLoy2/bf9hG5pqzHmrCS0HiymoXA= =qDlI -----END PGP SIGNATURE----- From chaim.rieger at gmail.com Tue Nov 3 19:26:49 2009 From: chaim.rieger at gmail.com (chaim.rieger at gmail.com) Date: Wed, 4 Nov 2009 01:26:49 +0000 Subject: T-Mobile ? Message-ID: <1808858782-1257298017-cardhu_decombobulator_blackberry.rim.net-163546753-@bda630.bisx.prod.on.blackberry> Global outage ------Original Message------ From: Charles.Jouglard at cox.com To: nanog at nanog.org Subject: T-Mobile ? Sent: Nov 3, 2009 17:18 Anyone hear of any issues on the T-Mobile network? Seems as if we cannot reach anyone with a T-Mobile cell phone. Dialing out works sporadically, but calls drop frequently. Thanks, Charles Sent via BlackBerry from T-Mobile From chaim.rieger at gmail.com Tue Nov 3 19:31:33 2009 From: chaim.rieger at gmail.com (chaim.rieger at gmail.com) Date: Wed, 4 Nov 2009 01:31:33 +0000 Subject: T-Mobile ? Message-ID: <537025597-1257298300-cardhu_decombobulator_blackberry.rim.net-224128006-@bda630.bisx.prod.on.blackberry> According to what I got from t-mobile It out and in but only between t-mobile devices, phone, sms, and data. Data to the rest, as well as cell and sms to the rest still work Sent via BlackBerry from T-Mobile From carywiedemann at gmail.com Tue Nov 3 19:34:50 2009 From: carywiedemann at gmail.com (Cary Wiedemann) Date: Tue, 3 Nov 2009 20:34:50 -0500 Subject: T-Mobile ? In-Reply-To: <16720fe00911031720i5e3105eej6590259fd400bd28@mail.gmail.com> References: <1074431535-1257276457-cardhu_decombobulator_blackberry.rim.net-581302542-@bda145.bisx.prod.on.blackberry> <16720fe00911031704y3b660606hc520cffaf8980780@mail.gmail.com> <16720fe00911031720i5e3105eej6590259fd400bd28@mail.gmail.com> Message-ID: Hard down in Fairfax, VA here. Inbound calls are met with a fast busy (no path) signal. Outbound calls fail. Inbound/outbound SMS text has not worked since at least 6:00PM EST. Surprisingly the IP network seems to still be up. BlackBerry specific functions such as BlackBerry email (BIS) and BBM still work. Web browsing still works. Seems their UMA (GSM over TCP/IP) servers are down too. Pretty bad. - Cary On Tue, Nov 3, 2009 at 8:20 PM, Jeffrey Lyon wrote: > We're using T-Mobile here, no issues reported. I have staff at sites > in Virginia, California, and Arizona. > > Jeff > > On Tue, Nov 3, 2009 at 8:18 PM, wrote: > > Anyone hear of any issues on the T-Mobile network? Seems as if we cannot > reach anyone with a T-Mobile cell phone. Dialing out works sporadically, > but calls drop frequently. > > > > Thanks, > > Charles > > > > > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications of The IRC Company, Inc. > > Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - > 21 to find out how to "protect your booty." > > From jeffrey.lyon at blacklotus.net Tue Nov 3 19:35:45 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 3 Nov 2009 20:35:45 -0500 Subject: T-Mobile ? In-Reply-To: <6011F9BF-4533-4876-9341-39FE58FAF78B@ianai.net> References: <1074431535-1257276457-cardhu_decombobulator_blackberry.rim.net-581302542-@bda145.bisx.prod.on.blackberry> <16720fe00911031704y3b660606hc520cffaf8980780@mail.gmail.com> <6011F9BF-4533-4876-9341-39FE58FAF78B@ianai.net> Message-ID: <16720fe00911031735mfcc2c9ao13ee277629a68749@mail.gmail.com> Thank you for posting this. I have a G1 and have randomly seen this exact picture pop up on my screen without explanation. I had previously assured myself I was going crazy since I was never able to reproduce the glitch in front of anyone. Jeff > But the good news is that they apparently added a 'feature' when you go to > pay your bill: > > > > > -- > TTFN, > patrick > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From stearns at dhyw.com Tue Nov 3 19:36:12 2009 From: stearns at dhyw.com (David Stearns) Date: Tue, 3 Nov 2009 18:36:12 -0700 Subject: T-Mobile ? In-Reply-To: <7B9C6418-1E4A-4942-955B-AD874539A07E@me.com> References: <1074431535-1257276457-cardhu_decombobulator_blackberry.rim.net-581302542-@bda145.bisx.prod.on.blackberry> <16720fe00911031704y3b660606hc520cffaf8980780@mail.gmail.com> <9E73E81F-0735-4234-A4CA-F8C44C1E56DC@beztech.net> <7B9C6418-1E4A-4942-955B-AD874539A07E@me.com> Message-ID: <3d6c57170911031736m7dd65015x5b7b480d5f0a192b@mail.gmail.com> I also noticed an outage here in Colorado, however the service appears to be back for us now, at least incoming and outgoing calls, plus data is available. -DS On Tue, Nov 3, 2009 at 18:23, Michael Schuler wrote: > Illinois is experiencing the outtage as well looks to be all of the U.S. > > -- > Is ait an mac an sol. > Life is strange (such is life). > > > On Nov 3, 2009, at 7:19 PM, Ben Carleton wrote: > > We are also seeing this in the Metro NY market. >> >> >> Ben >> >> On Nov 3, 2009, at 8:18 PM, wrote: >> >> Anyone hear of any issues on the T-Mobile network? Seems as if we cannot >>> reach anyone with a T-Mobile cell phone. Dialing out works sporadically, >>> but calls drop frequently. >>> >>> Thanks, >>> Charles >>> >> >> >> > From sethm at rollernet.us Tue Nov 3 19:37:12 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 03 Nov 2009 17:37:12 -0800 Subject: T-Mobile ? In-Reply-To: <6011F9BF-4533-4876-9341-39FE58FAF78B@ianai.net> References: <1074431535-1257276457-cardhu_decombobulator_blackberry.rim.net-581302542-@bda145.bisx.prod.on.blackberry> <16720fe00911031704y3b660606hc520cffaf8980780@mail.gmail.com> <6011F9BF-4533-4876-9341-39FE58FAF78B@ianai.net> Message-ID: <4AF0DAC8.8080206@rollernet.us> Patrick W. Gilmore wrote: > On Nov 3, 2009, at 8:18 PM, wrote: > >> Anyone hear of any issues on the T-Mobile network? Seems as if we >> cannot reach anyone with a T-Mobile cell phone. Dialing out works >> sporadically, but calls drop frequently. > > T-Mobile has admitted the outage. Apparently T-Mobile phones cannot > receive calls or texts, even from other T-Mobile phones: > > > Twitter is over capacity. Too many tweets! Please wait a moment and try again. @ 5:37 PST From mike at m5computersecurity.com Tue Nov 3 19:41:59 2009 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Tue, 03 Nov 2009 17:41:59 -0800 Subject: HE.net, Fremont-2 outage? In-Reply-To: <16720fe00911031704y3b660606hc520cffaf8980780@mail.gmail.com> References: <1074431535-1257276457-cardhu_decombobulator_blackberry.rim.net-581302542-@bda145.bisx.prod.on.blackberry> <16720fe00911031704y3b660606hc520cffaf8980780@mail.gmail.com> Message-ID: <1257298919.17875.503.camel@mike-desktop> That release is from 10/31/01. On Tue, 2009-11-03 at 20:04 -0500, Jeffrey Lyon wrote: > FWIW: http://www.he.net/releases/release18.html > > Jeff > > On Tue, Nov 3, 2009 at 2:28 PM, William Pitcock > wrote: > > Yeah. They had yet another power outage. The fourth in 16 months. > > > > Luckily we have already begun plans to leave their facility. > > > > William > > ------Original Message------ > > From: Tico > > To: nanog at nanog.org > > Subject: HE.net, Fremont-2 outage? > > Sent: Nov 3, 2009 1:50 PM > > > > Hey guys, > > > > I can't get through to Hurricane Electric, and they seem to be having an > > outage at their Fremont-2 facility again (as of 17:30 UTC or thereabouts) -- > > ticket system is unanswered, phones go to voicemail, all equipment is > > unreachable. > > > > Does anyone here have a presence at 48233 Warm Springs Blvd, that can > > provide any information about this? I got hit by the ATS failure last > > month, so I guess it's possible that that equipment may have flaked again. > > > > -t > > > > > > > > -- > > William Pitcock > > SystemInPlace - Simple Hosting Solutions > > 1-866-519-6149 > > > > > > > -- ************************************************************ 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 rodrick.brown at gmail.com Tue Nov 3 19:41:45 2009 From: rodrick.brown at gmail.com (rodrick brown) Date: Tue, 3 Nov 2009 20:41:45 -0500 Subject: T-Mobile ? In-Reply-To: <7B9C6418-1E4A-4942-955B-AD874539A07E@me.com> References: <1074431535-1257276457-cardhu_decombobulator_blackberry.rim.net-581302542-@bda145.bisx.prod.on.blackberry> <16720fe00911031704y3b660606hc520cffaf8980780@mail.gmail.com> <9E73E81F-0735-4234-A4CA-F8C44C1E56DC@beztech.net> <7B9C6418-1E4A-4942-955B-AD874539A07E@me.com> Message-ID: <942FF5D7-EB6E-47CA-A2FA-D0FBBE16CE7E@gmail.com> This problem also seems to be affecting tmo users in NYC. I'm unable to reach any tmo user from Att network Sent from my iPhone 3GS. On Nov 3, 2009, at 8:23 PM, Michael Schuler wrote: > Illinois is experiencing the outtage as well looks to be all of the > U.S. > > -- > Is ait an mac an sol. > Life is strange (such is life). > > On Nov 3, 2009, at 7:19 PM, Ben Carleton wrote: > >> We are also seeing this in the Metro NY market. >> >> >> Ben >> >> On Nov 3, 2009, at 8:18 PM, wrote: >> >>> Anyone hear of any issues on the T-Mobile network? Seems as if we >>> cannot reach anyone with a T-Mobile cell phone. Dialing out works >>> sporadically, but calls drop frequently. >>> >>> Thanks, >>> Charles >> >> > From jared at puck.nether.net Tue Nov 3 19:43:11 2009 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 3 Nov 2009 20:43:11 -0500 Subject: T-Mobile ? In-Reply-To: <1808858782-1257298017-cardhu_decombobulator_blackberry.rim.net-163546753-@bda630.bisx.prod.on.blackberry> References: <1808858782-1257298017-cardhu_decombobulator_blackberry.rim.net-163546753-@bda630.bisx.prod.on.blackberry> Message-ID: Has anyone here with WPS/GETS tested calling T-Mobile users? I'm curious to know results. - Jared From lyndon at orthanc.ca Tue Nov 3 19:49:25 2009 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE6BBM/VE7TFX)) Date: Tue, 3 Nov 2009 18:49:25 -0700 Subject: HE.net, Fremont-2 outage? In-Reply-To: <16720fe00911031704y3b660606hc520cffaf8980780@mail.gmail.com> Message-ID: > FWIW: http://www.he.net/releases/release18.html How long can they go on those 3000 gallons under their current load? From mark at edgewire.sg Tue Nov 3 19:51:30 2009 From: mark at edgewire.sg (mark [at] edgewire) Date: Wed, 4 Nov 2009 09:51:30 +0800 Subject: ISP port blocking practice In-Reply-To: <4AF090D0.7050103@juniper.net> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <4AE0DF32.1040903@justinshore.com> <4AF090D0.7050103@juniper.net> Message-ID: <0D08C3AA-3DF6-499B-92B7-35C0576C0125@edgewire.sg> Hi all, Just out of curiosity for those whom may manage Hotel Wifi networks (I know I know, not really ISP level but since we're on the topic of port blocking). Does anyone actually make an effort to be blocking port 443? I've had that experience at a few Hotels in Philippines and I can't think of a valid reason as to why those ports would be dropping traffic. Would like to hear from anyone whom has had this experience. Best regards, Mark On 04-Nov-2009, at 4:21 AM, Ron Bonica wrote: > Folks, > > I would love to see the IETF OPSEC WG publish a Best Common Practices > document on ISP Port filtering. The document would capture information > similar to that offered by Justin. > > Would anybody on this list be willing to author an Internet Draft? > > Ron > (co-director IETF O&M Area) > > Justin Shore wrote: >> Zhiyun Qian wrote: >>> Hi all, >>> >>> What is the common practice for enforcing port blocking policy (or >>> what >>> is the common practice for you and your ISP)? More specifically, >>> when >>> ISPs try to block certain outgoing port (port 25 for instance), they >>> could do two rules: >>> 1). For any outgoing traffic, if the destination port is 25, then >>> drop >>> the packets. >>> 2). For any incoming traffic, if the source port is 25, then drop >>> the >>> packets. >> >> I block on both generally. I block inbound and outbound for >> residential >> customers in dynamic pools. I block inbound only for residential >> with >> statically-assigned IPs. That way a customer can request (and pay >> for) >> a static IP and be able to get around out outbound SMTP block. Few >> companies use the MSP port (tcp/587). I'm not sure why more don't >> make >> the effort but most don't. To make up for that we allow static >> residential customers to evade that filter with a static IP. We >> still >> block inbound though. We also allow them to use our SMTP servers and >> SmartHosts if they want with no requirements on source domains (like >> some providers require, essentially requiring the customer to >> advertise >> for you). The inbound block isn't really all that useful as you >> elude >> to. However I use it more often than not to look for people scanning >> out ranges for open relays. I use that data for feed my RTBH trigger >> router and drop the spammer's traffic on the floor (or the poor, >> unfortunate owner of the compromised PC that's been 0wned. >> >> We block several other things too. Netbios traffic gets dropped both >> ways. MS-SQL traffic gets dropped both ways (a few users have >> complained about this but very few stick to their guns when you point >> out that their traffic is traversing the web completely >> unencrypted). I >> block default and common proxy ports such as 3128, 7212, and 6588 in >> both directions. Squid is too easy to misconfigure (done it myself). >> GhostSurf and WinGate have both been abusable as open proxies in >> various >> releases. I also block 8000, 8080 and 8081 towards the customers. >> These are some of our most commonly scanned ports (usually all 3 at >> once >> plus some or all of the 80xx ones). I've encountered many >> compromised >> residential CPEs that the users either enabled themselves or were >> enabled by default. I don't block those 3 ports on outbound flows >> though; too many false positives. >> >> And finally we also block several different types of ICMPs. First >> off >> we block ICMP fragments. Then we permit echo, echo-reply, >> packet-too-big, and time-exceeded. The rest get explicitly dropped. >> IPv6 will change this list dramatically. I haven't had time to >> research >> ICMPv6 thoroughly enough to say any more than that. >> >> Basically I just pick out some of the really bad ports and block >> them. >> This gives me a wealth of data with which to null-route compromised >> PCs >> scanning my networks. >> >>> Also, is it common that the rules are based on tcp flags (e.g. SYN, >>> SYN-ACK)? One would think block SYN packet is good enough. >> >> I don't get that deep into it. Forged packets of types other than >> SYN >> can still reek havoc on existing flows. I think it's better to block >> all and move on. >> >> Justin >> >> >> . >> > From davidattaei at gmail.com Tue Nov 3 20:12:11 2009 From: davidattaei at gmail.com (davidattaei at gmail.com) Date: Wed, 4 Nov 2009 02:12:11 +0000 Subject: T-Mobile ? Message-ID: <1807446688-1257300703-cardhu_decombobulator_blackberry.rim.net-228807593-@bda026.bisx.prod.on.blackberry> Outtage is here in Orlando, FL as well. Impossible to send or receive texts. All voice calls are possible with non-TMobile users. Anything in-network is hit or miss. Cannot reach any TMobile users in Boston. ------Original Message------ From: rodrick brown To: Michael Schuler Cc: nanog at nanog.org Cc: Charles.Jouglard at cox.com Sent: Nov 3, 2009 20:41 Subject: Re: T-Mobile ? This problem also seems to be affecting tmo users in NYC. I'm unable to reach any tmo user from Att network Sent from my iPhone 3GS. On Nov 3, 2009, at 8:23 PM, Michael Schuler wrote: > Illinois is experiencing the outtage as well looks to be all of the > U.S. > > -- > Is ait an mac an sol. > Life is strange (such is life). > > On Nov 3, 2009, at 7:19 PM, Ben Carleton wrote: > >> We are also seeing this in the Metro NY market. >> >> >> Ben >> >> On Nov 3, 2009, at 8:18 PM, wrote: >> >>> Anyone hear of any issues on the T-Mobile network? Seems as if we >>> cannot reach anyone with a T-Mobile cell phone. Dialing out works >>> sporadically, but calls drop frequently. >>> >>> Thanks, >>> Charles >> >> > Sent via BlackBerry from T-Mobile From jared at puck.nether.net Tue Nov 3 20:13:35 2009 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 3 Nov 2009 21:13:35 -0500 Subject: ISP port blocking practice In-Reply-To: <0D08C3AA-3DF6-499B-92B7-35C0576C0125@edgewire.sg> References: <0A08271D-49B9-4382-9F54-1A0BB6A3F2B2@umich.edu> <4AE0DF32.1040903@justinshore.com> <4AF090D0.7050103@juniper.net> <0D08C3AA-3DF6-499B-92B7-35C0576C0125@edgewire.sg> Message-ID: <535B904F-F12E-462A-A899-E16921406B70@puck.nether.net> On Nov 3, 2009, at 8:51 PM, mark [at] edgewire wrote: > Hi all, > > Just out of curiosity for those whom may manage Hotel Wifi networks > (I know I know, not really ISP level but since we're on the topic of > port blocking). Does anyone actually make an effort to be blocking > port 443? I've had that experience at a few Hotels in Philippines > and I can't think of a valid reason as to why those ports would be > dropping traffic. Would like to hear from anyone whom has had this > experience. I've found that some public (eg: Hospital) networks have very draconian security policies on their guest wireless. The University of Michigan hospitals block IMAP over SSL (tcp/993), SMTP-Submit (tcp/ 587) and all the vpn software I had at my disposal. This blocking is becoming more common to force people to HTTP/HTTPS ONLY based systems. They make utilizing these networks from a mobile device hard, and quickly forget your mac authentication quickly and are overall poorly run (no feedback loop to get things unblocked that are legit). I have found that I am having to vpn-out more often from these 'guest' networks to obtain "real" internet access. I recommend running a few gateways (eg: pptp, ipsec, openvpn) to get around these issues. (I have found some well run hotel networks that intercept tcp/3128 and send it to a local squid cache). - Jared From max.clark at gmail.com Tue Nov 3 21:15:18 2009 From: max.clark at gmail.com (Max Clark) Date: Tue, 3 Nov 2009 19:15:18 -0800 Subject: HE.net, Fremont-2 outage? In-Reply-To: References: <16720fe00911031704y3b660606hc520cffaf8980780@mail.gmail.com> Message-ID: <2fa1e1780911031915p3e182a6bq9025fef3ef8e854b@mail.gmail.com> http://www.dieselserviceandsupply.com/Diesel_Fuel_Consumption.aspx On Tue, Nov 3, 2009 at 5:49 PM, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote: >> FWIW: http://www.he.net/releases/release18.html > > How long can they go on those 3000 gallons under their current > load? > > > From marcus.sachs at verizon.com Tue Nov 3 21:29:38 2009 From: marcus.sachs at verizon.com (Sachs, Marcus Hans (Marc)) Date: Tue, 3 Nov 2009 22:29:38 -0500 Subject: T-Mobile ? In-Reply-To: References: <1808858782-1257298017-cardhu_decombobulator_blackberry.rim.net-163546753-@bda630.bisx.prod.on.blackberry> Message-ID: <81D582C724CA1046A279A7EE1299638B02420C4A@FHDP1LUMXCV24.us.one.verizon.com> Great question Jared! But I think for WPS to work you have to dial FROM a T-Mobile device rather than TO the device. But of course if the system is kaput WPS will be too. Based on what's happening at Twitter will we need TPS (Twitter Priority Service) some day in the near future? Marc -----Original Message----- From: Jared Mauch [mailto:jared at puck.nether.net] Sent: Tuesday, November 03, 2009 8:43 PM To: chaim.rieger at gmail.com Cc: Charles.Jouglard at cox.com; nanog at nanog.org Subject: Re: T-Mobile ? Has anyone here with WPS/GETS tested calling T-Mobile users? I'm curious to know results. - Jared From stef-list at memberwebs.com Tue Nov 3 21:33:41 2009 From: stef-list at memberwebs.com (Stef Walter) Date: Tue, 03 Nov 2009 21:33:41 -0600 Subject: HE.net, Fremont-2 outage? In-Reply-To: <16720fe00911031704y3b660606hc520cffaf8980780@mail.gmail.com> References: <1074431535-1257276457-cardhu_decombobulator_blackberry.rim.net-581302542-@bda145.bisx.prod.on.blackberry> <16720fe00911031704y3b660606hc520cffaf8980780@mail.gmail.com> Message-ID: <4AF0F615.9010202@memberwebs.com> Jeffrey Lyon wrote: > FWIW: http://www.he.net/releases/release18.html No date on that 'press release' but the way back machine helps put it somewhere in 2002. A lot of good this "Alameda" sized generator has done recently... http://web.archive.org/web/*/http://www.he.net/releases/release18.html Cheers, Stef From joelja at bogus.com Tue Nov 3 21:41:26 2009 From: joelja at bogus.com (joel jaeggli) Date: Tue, 03 Nov 2009 19:41:26 -0800 Subject: ip options In-Reply-To: <4AF09639.1050802@juniper.net> References: <1256756748.2228.9.camel@nld06907> <4AF09639.1050802@juniper.net> Message-ID: <4AF0F7E6.7040809@bogus.com> How about unused and/or private/local diffserve code points? Ron Bonica wrote: > Folks, > > I would love to see the IETF OPSEC WG publish a document on the pros and > cons of filtering optioned packets. > > Would anybody on this list be willing to author an Internet Draft? > > Ron > (co-director IETF O&M Area) > > Luca Tosolini wrote: >> Experts, >> out of the well-known values for ip options: >> >> X at r4# set ip-options ? >> Possible completions: >> Range of values >> [ Open a set of values >> any Any IP option >> loose-source-route Loose source route >> route-record Route record >> router-alert Router alert >> security Security >> stream-id Stream ID >> strict-source-route Strict source route >> timestamp Timestamp >> >> I can only think of: >> - RSVP using router-alert >> - ICMP using route-record, timestamp >> >> But I can not think of any other use of any other IP option. >> Considering the security hazard that they imply, I am therefore thinking >> to drop them. >> >> Is any other ip options used by: ospf, isis, bgp, ldp, igmp, pim, bfd? >> Thanks, >> Luca. >> >> >> > From jgreco at ns.sol.net Tue Nov 3 22:03:06 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 3 Nov 2009 22:03:06 -0600 (CST) Subject: HE.net, Fremont-2 outage? In-Reply-To: <4AF0F615.9010202@memberwebs.com> from "Stef Walter" at Nov 03, 2009 09:33:41 PM Message-ID: <200911040403.nA4436RS041824@aurora.sol.net> > Jeffrey Lyon wrote: > > FWIW: http://www.he.net/releases/release18.html > > No date on that 'press release' but the way back machine helps put it > somewhere in 2002. A lot of good this "Alameda" sized generator has done > recently... > > http://web.archive.org/web/*/http://www.he.net/releases/release18.html 2MW isn't super huge or anything. I would expect that, given the size I have been led to believe HE is, they've got a lot more than that now. My memory is that Alameda isn't huge, but it isn't small either. I'm not sure .. ah, here http://www.reuters.com/article/pressRelease/idUS179594+03-Apr-2009+BW20090403 peak 70MW I'm not sure what the basis for the claim is that a 2MW generator is "large enough to power the entire city of Alameda" ... 2MW gensets are common enough in this business and it's possible to burn through 2MW in a few hundred racks. It isn't *that* much power. A more conventional comparison might be to something like a hospital; one of our local hospitals installed a 1.25MW generator which, IIRC, powers all critical circuits. http://hhenergyservices.com/electrical/photos.php?category_id=2845&subcategory_id=5027&id=196&number=7 Sometimes it is easier to picture things that way. ... 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 tico-nanog at raapid.net Wed Nov 4 01:09:48 2009 From: tico-nanog at raapid.net (Tico) Date: Wed, 04 Nov 2009 07:09:48 +0000 Subject: HE.net, Fremont-2 outage? In-Reply-To: <200911040403.nA4436RS041824@aurora.sol.net> References: <200911040403.nA4436RS041824@aurora.sol.net> Message-ID: <4AF128BC.3060704@raapid.net> Joe Greco wrote: >> Jeffrey Lyon wrote: >> >>> FWIW: http://www.he.net/releases/release18.html >>> >> No date on that 'press release' but the way back machine helps put it >> somewhere in 2002. A lot of good this "Alameda" sized generator has done >> recently... >> >> http://web.archive.org/web/*/http://www.he.net/releases/release18.html >> > > 2MW isn't super huge or anything. I would expect that, given the size > I have been led to believe HE is, they've got a lot more than that now. > > My memory is that Alameda isn't huge, but it isn't small either. I'm > not sure .. ah, here > > http://www.reuters.com/article/pressRelease/idUS179594+03-Apr-2009+BW20090403 > > peak 70MW > > I'm not sure what the basis for the claim is that a 2MW generator is > "large enough to power the entire city of Alameda" ... 2MW gensets are > common enough in this business and it's possible to burn through 2MW in > a few hundred racks. It isn't *that* much power. > > A more conventional comparison might be to something like a hospital; one > of our local hospitals installed a 1.25MW generator which, IIRC, powers > all critical circuits. > > http://hhenergyservices.com/electrical/photos.php?category_id=2845&subcategory_id=5027&id=196&number=7 > > Sometimes it is easier to picture things that way. > Regardless of generator sizing issues or disparities, if the ATS fails, then no amount of grid or generator power will keep the cabinets juiced up. Since this is the second time in recent history that this building has experienced a short power outage caused by ATS flakiness, perhaps keeping a small UPS in the cabinet isn't such a bad idea? Even if the distribution switches/routers lose power, at least the servers wouldn't have to go through fscks and DB integrity checks due to unplanned power loss, and the recovery time would be significantly faster. Hell, for a 5 minute power outage, some of my services were down for 20 minutes. I'll happily take a 75% reduction in downtime for the cost of a UPS , though clearly redundancy across more reliable datacenters is a better solution. > ... JG > From msa at latt.net Wed Nov 4 01:17:37 2009 From: msa at latt.net (Majdi S. Abbas) Date: Wed, 4 Nov 2009 00:17:37 -0700 Subject: HE.net, Fremont-2 outage? In-Reply-To: <4AF128BC.3060704@raapid.net> References: <200911040403.nA4436RS041824@aurora.sol.net> <4AF128BC.3060704@raapid.net> Message-ID: <20091104071737.GC76391@puck.nether.net> On Wed, Nov 04, 2009 at 07:09:48AM +0000, Tico wrote: > Since this is the second time in recent history that this building > has experienced a short power outage caused by ATS flakiness, > perhaps keeping a small UPS in the cabinet isn't such a bad idea? It sounds like a great idea....until one of those small UPSes smokes out, triggering the fire suppression (or at least preaction), possibly also causing the power to be cut to the floor. The customer with the small UPS that smoked out generally does not like receiving the bill for everyone else's equipment cleaning, too. --msa From scott at doc.net.au Wed Nov 4 01:22:08 2009 From: scott at doc.net.au (Scott Howard) Date: Tue, 3 Nov 2009 23:22:08 -0800 Subject: HE.net, Fremont-2 outage? In-Reply-To: <4AF128BC.3060704@raapid.net> References: <200911040403.nA4436RS041824@aurora.sol.net> <4AF128BC.3060704@raapid.net> Message-ID: On Tue, Nov 3, 2009 at 11:09 PM, Tico wrote: > Since this is the second time in recent history that this building has > experienced a short power outage caused by ATS flakiness, perhaps keeping a > small UPS in the cabinet isn't such a bad idea? Even if Although this time it was "short", the outage 5 weeks ago was about 90 minutes. Scott From jgreco at ns.sol.net Wed Nov 4 01:23:48 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 4 Nov 2009 01:23:48 -0600 (CST) Subject: HE.net, Fremont-2 outage? In-Reply-To: <4AF128BC.3060704@raapid.net> from "Tico" at Nov 04, 2009 07:09:48 AM Message-ID: <200911040723.nA47NmMc052469@aurora.sol.net> > Regardless of generator sizing issues or disparities, if the ATS fails, > then no amount of grid or generator power will keep the cabinets juiced up. Sure. Having no direct knowledge of the HE DC in question, I was merely commenting on the issue I replied to. > Since this is the second time in recent history that this building has > experienced a short power outage caused by ATS flakiness, Has this been verified? > perhaps > keeping a small UPS in the cabinet isn't such a bad idea? Even if the > distribution switches/routers lose power, at least the servers wouldn't > have to go through fscks and DB integrity checks due to unplanned power > loss, and the recovery time would be significantly faster. Small UPS's have their own set of ugly failure modes. For example, we find that the APC Smart-UPS 1400's have a tendency to cook their batteries; if you don't have monitoring of some sort, you may not find out that your batteries are cooked until the UPS decides it is hopeless and shuts itself off. In the meantime, the lingering sulfur smell may panic someone... or cause a falsing of the fire system... Colos frequently forbid the use of small UPS's for a variety of reasons. > Hell, for a 5 minute power outage, some of my services were down for 20 > minutes. I'll happily take a 75% reduction in downtime for the cost of a UPS > , though clearly redundancy across more reliable datacenters is a better > solution. So is redundancy across power systems within the colo, but only for well- designed colos. Stories omitted. ... 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 dpeterson at sixapart.com Wed Nov 4 01:36:41 2009 From: dpeterson at sixapart.com (David B. Peterson) Date: Tue, 3 Nov 2009 23:36:41 -0800 Subject: HE.net, Fremont-2 outage? In-Reply-To: <200911040723.nA47NmMc052469@aurora.sol.net> References: <200911040723.nA47NmMc052469@aurora.sol.net> Message-ID: <67A886C5-CECD-49F7-B230-53344BC94EF6@sixapart.com> > Colos frequently forbid the use of small UPS's for a variety of > reasons. In my experience they always need to be connected to the EPO switch, which poses it's own risks. Plus try to find a UPS with that feature for reasonable prices. Which leads me to this question: What questions do you ask any potential colocation provider to determine if they are built out to your needs? -Dave From jgreco at ns.sol.net Wed Nov 4 02:36:09 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 4 Nov 2009 02:36:09 -0600 (CST) Subject: HE.net, Fremont-2 outage? In-Reply-To: <67A886C5-CECD-49F7-B230-53344BC94EF6@sixapart.com> from "David B. Peterson" at Nov 03, 2009 11:36:41 PM Message-ID: <200911040836.nA48a936069188@aurora.sol.net> > > Colos frequently forbid the use of small UPS's for a variety of > > reasons. > > In my experience they always need to be connected to the EPO switch, > which poses it's own risks. Plus try to find a UPS with that feature > for reasonable prices. APC says it's available on the SUA2200RM2U and SUA3000RM2U, and lists it as optional for the APC SUA1500RM2U. I would consider all of these to be reasonably priced. > Which leads me to this question: What questions do you ask any > potential colocation provider to determine if they are built out to > your needs? See if they'll guarantee diverse power as part of the contract. :-) It's disappointing to find a colo that feeds you your primary and redundant power off the same UPS. ... 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 isabeldias1 at yahoo.com Wed Nov 4 08:54:43 2009 From: isabeldias1 at yahoo.com (isabel dias) Date: Wed, 4 Nov 2009 06:54:43 -0800 (PST) Subject: ip options In-Reply-To: <4AF0F7E6.7040809@bogus.com> References: <1256756748.2228.9.camel@nld06907> <4AF09639.1050802@juniper.net> <4AF0F7E6.7040809@bogus.com> Message-ID: <907901.22460.qm@web52608.mail.re2.yahoo.com> :-) ----- Original Message ---- From: joel jaeggli To: Ron Bonica Cc: nanog Sent: Wed, November 4, 2009 3:41:26 AM Subject: Re: ip options How about unused and/or private/local diffserve code points? Ron Bonica wrote: > Folks, > > I would love to see the IETF OPSEC WG publish a document on the pros and > cons of filtering optioned packets. > > Would anybody on this list be willing to author an Internet Draft? > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Ron >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (co-director IETF O&M Area) > > Luca Tosolini wrote: >> Experts, >> out of the well-known values for ip options: >> >> X at r4# set ip-options ? >> Possible completions: >>? ? ? ? ? ? ? ? Range of values >>? [? ? ? ? ? ? ? ? ? ? Open a set of values >>? any? ? ? ? ? ? ? ? ? Any IP option >>? loose-source-route? Loose source route >>? route-record? ? ? ? Route record >>? router-alert? ? ? ? Router alert >>? security? ? ? ? ? ? Security >>? stream-id? ? ? ? ? ? Stream ID >>? strict-source-route? Strict source route >>? timestamp? ? ? ? ? ? Timestamp >> >> I can only think of: >> - RSVP using router-alert >> - ICMP using route-record, timestamp >> >> But I can not think of any other use of any other IP option. >> Considering the security hazard that they imply, I am therefore thinking >> to drop them. >> >> Is any other ip options used by: ospf, isis, bgp, ldp, igmp, pim, bfd? >> Thanks, >> Luca. >> >> >> > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From dan.syn.ack at gmail.com Wed Nov 4 10:00:34 2009 From: dan.syn.ack at gmail.com (dan syn) Date: Wed, 4 Nov 2009 10:00:34 -0600 Subject: HE.net, Fremont-2 outage? In-Reply-To: <4AF128BC.3060704@raapid.net> References: <200911040403.nA4436RS041824@aurora.sol.net> <4AF128BC.3060704@raapid.net> Message-ID: On Wed, Nov 4, 2009 at 7:09 AM, Tico wrote: > >> Sometimes it is easier to picture things that way. >> >> > > Regardless of generator sizing issues or disparities, if the ATS fails, > then no amount of grid or generator power will keep the cabinets juiced up. > > Since this is the second time in recent history that this building has > experienced a short power outage caused by ATS flakiness, perhaps keeping a > small UPS in the cabinet isn't such a bad idea? Even if the distribution > switches/routers lose power, at least the servers wouldn't have to go > through fscks and DB integrity checks due to unplanned power loss, and the > recovery time would be significantly faster. > > Hell, for a 5 minute power outage, some of my services were down for 20 > minutes. I'll happily take a 75% reduction in downtime for the cost of a UPS > , though clearly redundancy across more reliable datacenters is a better > solution. > > Maybe some of us [[soon-to-be-]ex-]customers of Hurricane can bake them a cake and beg for UPSes. Or reliable power. Or for someone to actually answer the voicemails much less phone calls within even a few hours of an outage. Or for there to be at the very least a status page notifying customers that they are, in fact, screwed, and for how long, and that it's useless to continue trying to get through at such time. Who's with me? From michael.holstein at csuohio.edu Wed Nov 4 10:19:55 2009 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Wed, 04 Nov 2009 11:19:55 -0500 Subject: HE.net, Fremont-2 outage? In-Reply-To: References: Message-ID: <4AF1A9AB.7060202@csuohio.edu> >> FWIW: http://www.he.net/releases/release18.html >> > > Well, they say it's a Cat unit, so probably one like this : http://www.cat.com/cda/components/securedFile/displaySecuredFileServletJSP?x=7&fileId=1081064 > How long can they go on those 3000 gallons under their current > load? > > That engine is rated to consume 70.9g/hr at 50% .. so using a conservative estimate, I'd say about 42 hours. Cheers, Michael Holstein Cleveland State University > > From mpetach at netflight.com Wed Nov 4 11:56:02 2009 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 4 Nov 2009 09:56:02 -0800 Subject: HE.net, Fremont-2 outage? In-Reply-To: <4AF1A9AB.7060202@csuohio.edu> References: <4AF1A9AB.7060202@csuohio.edu> Message-ID: <63ac96a50911040956l4b88763awc55ceecb9044e8b4@mail.gmail.com> On Wed, Nov 4, 2009 at 8:19 AM, Michael Holstein wrote: >>> FWIW: http://www.he.net/releases/release18.html >>> > Well, they say it's a Cat unit, so probably one like this : > http://www.cat.com/cda/components/securedFile/displaySecuredFileServletJSP?x=7&fileId=1081064 > >> How long can they go on those 3000 gallons under their current >> load? >> > That engine is rated to consume 70.9g/hr at 50% .. so using a conservative > estimate, I'd say about 42 hours. Wouldn't the conservative estimate be 21 hours? (3000 gallons, 142 gal/hr at 100% load); you'd get more hours out by guessing at what fraction of full load the generator is running, but anything longer than 21 hours is fudge-factor guesstimate based, and not to be counted on. > Cheers, > > Michael Holstein > Cleveland State University Matt From drew.weaver at thenap.com Wed Nov 4 12:01:56 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Wed, 4 Nov 2009 13:01:56 -0500 Subject: Anyone having complaints about connectivity from people in asia? Message-ID: Packet loss, latency, etc? We have 6 connections and there doesn't seem to be any real theme between source/dest IPs except everyone complaining appears to be in Asia (pakistan, etc). -Drew From jgreco at ns.sol.net Wed Nov 4 12:26:15 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 4 Nov 2009 12:26:15 -0600 (CST) Subject: HE.net, Fremont-2 outage? In-Reply-To: <63ac96a50911040956l4b88763awc55ceecb9044e8b4@mail.gmail.com> from "Matthew Petach" at Nov 04, 2009 09:56:02 AM Message-ID: <200911041826.nA4IQGeT020376@aurora.sol.net> > On Wed, Nov 4, 2009 at 8:19 AM, Michael Holstein > wrote: > >>> FWIW: http://www.he.net/releases/release18.html > >>> > > Well, they say it's a Cat unit, so probably one like this : > > http://www.cat.com/cda/components/securedFile/displaySecuredFileServletJSP?x=7&fileId=1081064 > > > >> How long can they go on those 3000 gallons under their current > >> load? > >> > > That engine is rated to consume 70.9g/hr at 50% .. so using a conservative > > estimate, I'd say about 42 hours. > > Wouldn't the conservative estimate be 21 hours? (3000 gallons, 142 > gal/hr at 100% load); > you'd get more hours out by guessing at what fraction of full load the > generator is > running, but anything longer than 21 hours is fudge-factor guesstimate > based, and not > to be counted on. The mildly conservative estimate is 21 hours minus the guaranteed turnaround time for your fuel vendor to show up, minus some more fudge factor to allow for someone to actually hook up and actually refuel, etc. The paranoid conservative estimate is more complex; you have to assume you call the primary vendor, they don't show, and then you have to call your backup(s). If you have a three hour guarantee in the contract, you have to remember that this can still represent some scrambling by your vendor, and if you're lights out, it's quite possible that others are as well, and hospitals and city hall might rate as more urgent. It's also possible that the truck'll have a flat, mechanical problems, or try to rush through the railroad crossing about to be rendered unpassable by a slow-moving freight train. It'll probably take you an additional hour to panic and call your backup supplier; now you are a bunch of hours shorter on capacity than you thought. Of course, a lot of this is simply how you look at the problem. If we're talking runtime-until-dry, yeah, 21 hours. If we're talking a practical number of how long can you go until it's proper for some panic to set in and calls to get made, it's more like half that. ;-) With power: N+1 is usually better than N Best to assume full load when doing math Things will go wrong, predict common failures The best plans are still prone to failure Safety margins can save your rear etc ... 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 sethm at rollernet.us Wed Nov 4 12:39:57 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 04 Nov 2009 10:39:57 -0800 Subject: HE.net, Fremont-2 outage? In-Reply-To: <200911041826.nA4IQGeT020376@aurora.sol.net> References: <200911041826.nA4IQGeT020376@aurora.sol.net> Message-ID: <4AF1CA7D.1010105@rollernet.us> Joe Greco wrote: > > With power: > > N+1 is usually better than N > Best to assume full load when doing math > Things will go wrong, predict common failures > The best plans are still prone to failure > Safety margins can save your rear > etc > I find that electrical panelboards, busways, transfer switches, etc. are often put in the category of things that don't need maintenance or routine inspections. Big deal if you can start your fancy generator once a month (I prefer on-load weekly) but the in between stuff is in disrepair or full of mice. Even a simple dusty transfer switch could arc weld itself to once side of the contacts. ~Seth From scott at doc.net.au Wed Nov 4 12:41:39 2009 From: scott at doc.net.au (Scott Howard) Date: Wed, 4 Nov 2009 10:41:39 -0800 Subject: HE.net, Fremont-2 outage? In-Reply-To: <4AF07B5E.1020504@raapid.net> References: <4AF07B5E.1020504@raapid.net> Message-ID: Has anyone managed to get a root cause from HE yet regarding what happened? I'm still waiting for them to get back to me over 24 hours later... Scott On Tue, Nov 3, 2009 at 10:50 AM, Tico wrote: > I can't get through to Hurricane Electric, and they seem to be having an > outage at their Fremont-2 facility again (as of 17:30 UTC or thereabouts) -- > ticket system is unanswered, phones go to voicemail, all equipment is > unreachable. > > Does anyone here have a presence at 48233 Warm Springs Blvd, that can > provide any information about this? I got hit by the ATS failure last month, > so I guess it's possible that that equipment may have flaked again. > > -t > > From alex at corp.nac.net Wed Nov 4 12:44:11 2009 From: alex at corp.nac.net (Alex Rubenstein) Date: Wed, 4 Nov 2009 13:44:11 -0500 Subject: HE.net, Fremont-2 outage? In-Reply-To: References: <200911040403.nA4436RS041824@aurora.sol.net> <4AF128BC.3060704@raapid.net> Message-ID: > > Regardless of generator sizing issues or disparities, if the ATS fails, > > then no amount of grid or generator power will keep the cabinets juiced up. That is patently false. Assume N+1 UPS, with each UPS module having its own ATS fed from a utility and emergency bus. Then you can even individually maintain each UPS module and ATS. Bonus and score. And if it's a really good place, you have two of the above (2(n+1)) and each of your power cords goes to one each. "Question everything, assume nothing, discuss all, and resolve quickly." -- Alex Rubenstein, AR97, K2AHR, alex at nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- From mpetach at netflight.com Wed Nov 4 12:44:48 2009 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 4 Nov 2009 10:44:48 -0800 Subject: Anyone having complaints about connectivity from people in asia? In-Reply-To: References: Message-ID: <63ac96a50911041044q34191378t1a020633a0b71804@mail.gmail.com> On Wed, Nov 4, 2009 at 10:01 AM, Drew Weaver wrote: > Packet loss, latency, etc? > > We have 6 connections and there doesn't seem to be any real theme between source/dest IPs except everyone complaining appears to be in Asia (pakistan, etc). > > -Drew There's always someone somewhere complaining about packet loss and latency; this *is* the Internet we're talking about, after all. it's usually not the source/dest IPs that matter, as much as the ones in the middle. do traceroutes, and look for points of commonality; observe which ASNs show up in common along the different paths, see if there's locations in common across the different traceroutes (do they all go through a common city that might have a localized issue like an earthquake, tsunami, flood, etc.). Matt From jgreco at ns.sol.net Wed Nov 4 12:54:49 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 4 Nov 2009 12:54:49 -0600 (CST) Subject: HE.net, Fremont-2 outage? In-Reply-To: <4AF1CA7D.1010105@rollernet.us> from "Seth Mattinen" at Nov 04, 2009 10:39:57 AM Message-ID: <200911041854.nA4Isnbv021842@aurora.sol.net> > Joe Greco wrote: > > > > With power: > > > > N+1 is usually better than N > > Best to assume full load when doing math > > Things will go wrong, predict common failures > > The best plans are still prone to failure > > Safety margins can save your rear > > etc > > I find that electrical panelboards, busways, transfer switches, etc. are > often put in the category of things that don't need maintenance or > routine inspections. Big deal if you can start your fancy generator once > a month (I prefer on-load weekly) but the in between stuff is in > disrepair or full of mice. Even a simple dusty transfer switch could arc > weld itself to once side of the contacts. Yup. Related: "100% availability" is a marketing person's dream; it sounds good in theory but is unattainable in practice, and is a reliable sign of non-100%-reliability. The most common way to gain "100% availability" is to avoid testing under load. This surely protects the equipment against a whole slew of failures in the less-used portions of your power systems, but also protects you from detecting them outside your Hour(s) Of Greatest Need. And even for those who follow best practices... You can inspect and maintain things until you're blue in the face. One day a contractor will drop a wrench into a PDU or UPS or whatever and spectacular things will happen. Or a battery develops a strange fault. You do live load testing, you'll lose now and then. It's best to simply assume no single circuit is 100% reliable. You should be able to get two circuits from separate power systems and the combination of the two should really closely approximate 100%, but even there... it isn't. ... 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 alex at corp.nac.net Wed Nov 4 13:06:03 2009 From: alex at corp.nac.net (Alex Rubenstein) Date: Wed, 4 Nov 2009 14:06:03 -0500 Subject: HE.net, Fremont-2 outage? In-Reply-To: <200911041854.nA4Isnbv021842@aurora.sol.net> References: <4AF1CA7D.1010105@rollernet.us> from "Seth Mattinen" at Nov 04, 2009 10:39:57 AM <200911041854.nA4Isnbv021842@aurora.sol.net> Message-ID: > Yup. Related: "100% availability" is a marketing person's dream; it > sounds good in theory but is unattainable in practice, and is a > reliable sign of non-100%-reliability. You are confusing two different things. Availability != Reliability. For instance, an airplane is designed to be 100% reliable, but much less available. To keep a 747 from not crashing (100% reliability) it needs significant downtime (not 100% available). > And even for those who follow best practices... You can inspect and > maintain things until you're blue in the face. One day a contractor > will drop a wrench into a PDU or UPS or whatever and spectacular things > will happen. That's were policies, procedures and methods come in (read: SAS70) > Or a battery develops a strange fault. Get more than one string, one more than one UPS, with monitoring. Batteries are NOT the Achilles heel everyone wants to make you believe they are. "Question everything, assume nothing, discuss all, and resolve quickly." -- Alex Rubenstein, AR97, K2AHR, alex at nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- From mksmith at adhost.com Wed Nov 4 12:21:37 2009 From: mksmith at adhost.com (Michael K. Smith) Date: Wed, 04 Nov 2009 11:21:37 -0700 Subject: HE.net, Fremont-2 outage? In-Reply-To: Message-ID: On 11/4/09 11:44 AM, "Alex Rubenstein" wrote: >>> Regardless of generator sizing issues or disparities, if the ATS fails, >>> then no amount of grid or generator power will keep the cabinets juiced up. > > That is patently false. > At it's root it's true - if an ATS fails the power between the source and destination will be interrupted. > Assume N+1 UPS, with each UPS module having its own ATS fed from a utility and > emergency bus. Then you can even individually maintain each UPS module and > ATS. Bonus and score. > > And if it's a really good place, you have two of the above (2(n+1)) and each > of your power cords goes to one each. > Which doesn't address the failure of one piece of equipment. Of course, if you're dual chorded from your server through fully redundant switch gear to multiple, diverse vaults then a single ATS failure shouldn't affect you. Regards, Mike From stef-list at memberwebs.com Wed Nov 4 13:23:25 2009 From: stef-list at memberwebs.com (Stef Walter) Date: Wed, 04 Nov 2009 13:23:25 -0600 Subject: HE.net, Fremont-2 outage? In-Reply-To: References: <4AF07B5E.1020504@raapid.net> Message-ID: <4AF1D4AD.3060909@memberwebs.com> Scott Howard wrote: > Has anyone managed to get a root cause from HE yet regarding what happened? > > I'm still waiting for them to get back to me over 24 hours later... Good luck. I'm still waiting for them to get back to me about the outage six weeks ago. I called and emailed all sorts of folks there, got the run around for a week at least. Eventually got promises of "so and so should let you know shortly" but that never occurred. Cheers, Stef From sethm at rollernet.us Wed Nov 4 14:28:41 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 04 Nov 2009 12:28:41 -0800 Subject: HE.net, Fremont-2 outage? In-Reply-To: <200911041854.nA4Isnbv021842@aurora.sol.net> References: <200911041854.nA4Isnbv021842@aurora.sol.net> Message-ID: <4AF1E3F9.1050406@rollernet.us> Joe Greco wrote: > > Yup. Related: "100% availability" is a marketing person's dream; it > sounds good in theory but is unattainable in practice, and is a reliable > sign of non-100%-reliability. > > The most common way to gain "100% availability" is to avoid testing > under load. This surely protects the equipment against a whole slew of > failures in the less-used portions of your power systems, but also > protects you from detecting them outside your Hour(s) Of Greatest Need. Not testing under load is silly, IMHO. Does it work? Maybe. If it does something strange during testing it's attended, expected, and utility is available to fall back on. Starting your generator only means it'll turn over and idle, not that it'll provide power under load all the way to the racks. Some people may prefer a colo that never risks it and therefore never does more than idle the genset to claim 100% uptime. Others may prefer one that won't promise 100% everything but does load tests. I'd rather have a test go wrong while utility is available rather than a failed backup with no utility hoping the power comes back before the UPS dies or the room cooks itself. Both extremes are available to choose from if you do your research before picking a colo. > And even for those who follow best practices... You can inspect and > maintain things until you're blue in the face. One day a contractor > will drop a wrench into a PDU or UPS or whatever and spectacular things > will happen. Or a battery develops a strange fault. > > You do live load testing, you'll lose now and then. It's best to simply > assume no single circuit is 100% reliable. You should be able to get > two circuits from separate power systems and the combination of the two > should really closely approximate 100%, but even there... it isn't. > Separate power systems are overrated, especially if the fire department ends up being involved for some reason. (Re: the infamous gas leak story.) And of course with increased complexity comes increased risk of failure and longer downtime to diagnose and repair. There is no perfect balance. ~Seth From jgreco at ns.sol.net Wed Nov 4 15:14:39 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 4 Nov 2009 15:14:39 -0600 (CST) Subject: HE.net, Fremont-2 outage? In-Reply-To: from "Alex Rubenstein" at Nov 04, 2009 02:06:03 PM Message-ID: <200911042114.nA4LEd4M026870@aurora.sol.net> > > Yup. Related: "100% availability" is a marketing person's dream; it > > sounds good in theory but is unattainable in practice, and is a > > reliable sign of non-100%-reliability. > > You are confusing two different things. No, I'm not. They're interrelated. That doesn't mean that they are the same thing, but to talk about them in terms of their relationship or their effect on service is perfectly fair. > > And even for those who follow best practices... You can inspect and > > maintain things until you're blue in the face. One day a contractor > > will drop a wrench into a PDU or UPS or whatever and spectacular things > > will happen. > > That's were policies, procedures and methods come in (read: SAS70) Policies, procedures, and methods are nice. Unfortunately, it is not too uncommon for all of the above to be bent or broken for a whole slew of reasons. What about a problem that hasn't been planned for? It only takes one time ... one mistake ... of just the right kind. > > Or a battery develops a strange fault. > > Get more than one string, one more than one UPS, with monitoring. > Batteries are NOT the Achilles heel everyone wants to make you > believe they are. I know you have a rather higher faith in batteries than some of us, but practical experience suggests that batteries are merely a mostly- reliable technology. ... 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 raphael.carrier at gmail.com Wed Nov 4 16:08:17 2009 From: raphael.carrier at gmail.com (Raphael Carrier) Date: Wed, 4 Nov 2009 17:08:17 -0500 Subject: HE.net, Fremont-2 outage? In-Reply-To: <200911042114.nA4LEd4M026870@aurora.sol.net> References: <200911042114.nA4LEd4M026870@aurora.sol.net> Message-ID: > I know you have a rather higher faith in batteries than some of us, > but practical experience suggests that batteries are merely a mostly- > reliable technology. > Agreed batteries are unreliable, an alternative to battery based UPS are flywheel energy storage devices, they come either as an integrated solution with the diesel generator (i think cat offers such a package) or as a standalone UPS (see: www.pentadyne.com/uploads/18/File/Pentadyne-VSS-Brochure.pdf) another vendor is Active Power (which i think partners with cat) They seem to be MUCH more reliable than batteries from what i read HE probably acquired one of those solutions -Raphael Carrier From scott at doc.net.au Wed Nov 4 16:20:16 2009 From: scott at doc.net.au (Scott Howard) Date: Wed, 4 Nov 2009 14:20:16 -0800 Subject: HE.net, Fremont-2 outage? In-Reply-To: References: <200911042114.nA4LEd4M026870@aurora.sol.net> Message-ID: On Wed, Nov 4, 2009 at 2:08 PM, Raphael Carrier wrote: > Agreed batteries are unreliable, an alternative to battery based UPS > are flywheel energy storage devices, they come either as an integrated > solution with the diesel generator (i think cat offers such a package) > Yup, just ask 365 Main how reliable they are - http://365main.com/status_update.html I'm not saying that battery-based UPS's are better, but no matter what type of system you look at you're going to find failures. Scott From owen at delong.com Wed Nov 4 16:18:04 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 4 Nov 2009 14:18:04 -0800 Subject: HE.net, Fremont-2 outage? In-Reply-To: References: <200911042114.nA4LEd4M026870@aurora.sol.net> Message-ID: <97E072B0-8E7B-4A40-A63C-E7D7926CCCA2@delong.com> On Nov 4, 2009, at 2:08 PM, Raphael Carrier wrote: >> I know you have a rather higher faith in batteries than some of us, >> but practical experience suggests that batteries are merely a mostly- >> reliable technology. >> > > Agreed batteries are unreliable, an alternative to battery based UPS > are flywheel energy storage devices, they come either as an integrated > solution with the diesel generator (i think cat offers such a package) > or as a standalone UPS (see: > www.pentadyne.com/uploads/18/File/Pentadyne-VSS-Brochure.pdf) > Apparently you do not remember 365 Main... Batteries are reliable. Flywheels are reliable. Both require proper maintenance and proper procedures to handle corner cases (like the multiple-outage corner-case that took out 365 main). Both have their issues. In my experience working at and with a variety of datacenters, I have to day that I have had generally better luck with batteries than flywheels, but, the key difference that suggests flywheels could actually be better technology is this: About 50% of battery failures traced back to human factors. 100% of the flywheel failures I experienced were human factors related. Owen Speaking as an individual, not representing any affiliation. From mhelmest at uvic.ca Wed Nov 4 16:49:42 2009 From: mhelmest at uvic.ca (Michael Helmeste) Date: Wed, 4 Nov 2009 14:49:42 -0800 Subject: Speed Testing and Throughput testing In-Reply-To: References: Message-ID: <20091104144942.6dd9b0cd.mhelmest@uvic.ca> We had a problem where our (mostly research network connected, international) users were getting generally low HTTP transfer speeds, even though the path was often gigabit. The classic high bandwidth/high latency problem. Initially I tried using iperf/ndt and friends but found that iperf required too much user knowledge and interaction, and NDT was sometimes inaccurate at diagnosing problems -- it seemed to be overly fond of saying there was a duplex mismatch or congestion. Iperf in TCP mode either requires manually seeking the number of streams to try and find optimum throughput, or doing window size tweaks. I also found that packet captures were useful for discovering problems in the path; you can load it up in wireshark or tcptrace and get a sequence no. vs time graph, look for packetloss, or other good things like that. Anyways I didn't find much out there in terms of automating this type of thing (simple throughput tests with packet capture) so I just ended up making my own. It does a dump of 10 sec. of test traffic, uses a somewhat dumb algorithm to seek up the number of TCP streams, and gets an AS path from a BGP route server and displays it to the user. The caveat is that it only tests your download speed, not upload, since that was primarily what I was interested in. You can give it a try at: http://caranthir.dao.nrc.ca/netperf-www/ (login nanog/nanog). User guide here: http://www.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/netperf/testdetail.shtml I might end up packaging and releasing the code if there is interest. On Mon, 2 Nov 2009 15:56:56 -0600 Mark Urbach wrote: > Anyone have a good solution to get "accurate" speed results when testing at 10/100/1000 Ethernet speeds? > > Do you have a server/software that customer can test too? > > > > Thanks, > Mark Urbach > PinPoint Communications, Inc. > 100 N. 12th St Suite 500 > Lincoln, NE 68508 > 402-438-6211 ext 1923 Office > 402-660-7982 Cell > mark.urbach at pnpt.com > [cid:image003.jpg at 01CA5BD5.1A5CEE20] > > From bking at inline.com Wed Nov 4 16:56:32 2009 From: bking at inline.com (Bryan King) Date: Wed, 4 Nov 2009 16:56:32 -0600 Subject: HE.net, Fremont-2 outage? In-Reply-To: <97E072B0-8E7B-4A40-A63C-E7D7926CCCA2@delong.com> References: <200911042114.nA4LEd4M026870@aurora.sol.net> <97E072B0-8E7B-4A40-A63C-E7D7926CCCA2@delong.com> Message-ID: <2E2217480B29844BA5E3B4A4BEACE51D24C1A75D@TCNMAIL1> Sry for the top post... As more facilities are built/retrofitted with an eye toward overall efficiency using CCHP, we will start seeing more facilities (like Syracuse U's new datacenter) use systems like the Capstone turbines for primary power/secure power/CCHP. The main grid will become the backup. Not saying this approach replaces the need for batteries or some other storage device such as a flywheel system.. "This Year InGuard has Stopped 159,953,000 Spam E-Mails and 573,000 Viruses... Do you have http://www.inline.com/SolutionsbyTechnology/InternetDataCenter/InGuard/tabid/129/Default.aspx?" InLine> bryan king | Internet Department Director InLine> Solutions Through Technology 600 Lakeshore Pkwy Birmingham AL, 35209 205-278-8139 [p] 205-314-7729[f] bking at inline.com www.InLine.com All Quotes from InLine are only valid for 30 days. This message and any attached files may contain confidential information and are intended solely for the message recipient. If you are not the message recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. From: Owen DeLong [mailto:owen at delong.com] Sent: Wednesday, November 04, 2009 4:18 PM To: Raphael Carrier Cc: nanog at nanog.org; Joe Greco Subject: Re: HE.net, Fremont-2 outage? On Nov 4, 2009, at 2:08 PM, Raphael Carrier wrote: >> I know you have a rather higher faith in batteries than some of us, >> but practical experience suggests that batteries are merely a mostly- >> reliable technology. >> > > Agreed batteries are unreliable, an alternative to battery based UPS > are flywheel energy storage devices, they come either as an integrated > solution with the diesel generator (i think cat offers such a package) > or as a standalone UPS (see: > www.pentadyne.com/uploads/18/File/Pentadyne-VSS-Brochure.pdf) > Apparently you do not remember 365 Main... Batteries are reliable. Flywheels are reliable. Both require proper maintenance and proper procedures to handle corner cases (like the multiple-outage corner-case that took out 365 main). Both have their issues. In my experience working at and with a variety of datacenters, I have to day that I have had generally better luck with batteries than flywheels, but, the key difference that suggests flywheels could actually be better technology is this: About 50% of battery failures traced back to human factors. 100% of the flywheel failures I experienced were human factors related. Owen Speaking as an individual, not representing any affiliation. From jgreco at ns.sol.net Wed Nov 4 16:56:19 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 4 Nov 2009 16:56:19 -0600 (CST) Subject: HE.net, Fremont-2 outage? In-Reply-To: from "Scott Howard" at Nov 04, 2009 02:20:16 PM Message-ID: <200911042256.nA4MuJ1X031635@aurora.sol.net> > On Wed, Nov 4, 2009 at 2:08 PM, Raphael Carrier > wrote: > > > Agreed batteries are unreliable, an alternative to battery based UPS > > are flywheel energy storage devices, they come either as an integrated > > solution with the diesel generator (i think cat offers such a package) > > Yup, just ask 365 Main how reliable they are - > http://365main.com/status_update.html > > I'm not saying that battery-based UPS's are better, but no matter what type > of system you look at you're going to find failures. I would point out that my cursory review of the document linked above leaves a very positive impression. I don't know the actual details well enough to know if there is any reason to doubt the document... I would, however, tend to trust a vendor who disclosed events in this manner. Even the best systems can fail. How a failure is handled is in many ways the more important factor; being transparent about it is good for confidence. Best to plan for the occasional issue. ... 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 scott at doc.net.au Wed Nov 4 18:31:28 2009 From: scott at doc.net.au (Scott Howard) Date: Wed, 4 Nov 2009 16:31:28 -0800 Subject: HE.net, Fremont-2 outage? In-Reply-To: <200911042256.nA4MuJ1X031635@aurora.sol.net> References: <200911042256.nA4MuJ1X031635@aurora.sol.net> Message-ID: On Wed, Nov 4, 2009 at 2:56 PM, Joe Greco wrote: > > Yup, just ask 365 Main how reliable they are - > > http://365main.com/status_update.html > > I would point out that my cursory review of the document linked above > leaves a very positive impression. I don't know the actual details well > enough to know if there is any reason to doubt the document... > > I would, however, tend to trust a vendor who disclosed events in this > manner. Even the best systems can fail. How a failure is handled is > in many ways the more important factor; being transparent about it is > good for confidence. > Absolutely! 365 Main handled this outage very well, both at the time, but more importantly with the followup as you can see from the URL above, which as you can see was made (very!) public by them at the time, and not covered in "confidential/customer only/etc" warnings. Those that have (finally) received the notification from HE about yesterdays outage will notice the stark difference between the way they've handled it and the way 365 Main handled things... Scott. From nevin at enginehosting.com Wed Nov 4 20:38:13 2009 From: nevin at enginehosting.com (nevin at enginehosting.com) Date: Wed, 4 Nov 2009 20:38:13 -0600 (CST) Subject: =?UTF-8?Q?Re:=20HE.net,=20Fremont-2=20outage=3F?= In-Reply-To: <200911040403.nA4436RS041824@aurora.sol.net> References: <200911040403.nA4436RS041824@aurora.sol.net> Message-ID: <1257388693.973329082@192.168.1.71> On Tuesday, November 3, 2009 10:03pm, "Joe Greco" said: >> Jeffrey Lyon wrote: >> > FWIW: http://www.he.net/releases/release18.html >> >> No date on that 'press release' but the way back machine helps put it >> somewhere in 2002. A lot of good this "Alameda" sized generator has done >> recently... >> >> http://web.archive.org/web/*/http://www.he.net/releases/release18.html > > 2MW isn't super huge or anything. I would expect that, given the size > I have been led to believe HE is, they've got a lot more than that now. > > My memory is that Alameda isn't huge, but it isn't small either. I'm > not sure .. ah, here The 2002 press release is talking about the Fremont 1 facility not the newer Fremont 2 facility. Fremont 1 has a fixed power availability to each cabinet of just a single 15A circuit. You can not modify or change that, and if you need more power your option is to add another cabinet. You are not allowed to route power cords between cabinets so you are forever running a single circuit and 80% of your 15A circuit max. The data center was built in a different time. -- Nevin Lyne -- Founder / Director of Technology -- EngineHosting.com From stef-list at memberwebs.com Wed Nov 4 20:51:44 2009 From: stef-list at memberwebs.com (Stef Walter) Date: Wed, 04 Nov 2009 20:51:44 -0600 Subject: HE.net, Fremont-2 outage? In-Reply-To: <1257388693.973329082@192.168.1.71> References: <200911040403.nA4436RS041824@aurora.sol.net> <1257388693.973329082@192.168.1.71> Message-ID: <4AF23DC0.6050104@memberwebs.com> nevin at enginehosting.com wrote: > The 2002 press release is talking about the Fremont 1 facility not > the newer Fremont 2 facility. Fremont 1 has a fixed power > availability to each cabinet of just a single 15A circuit. You can > not modify or change that, and if you need more power your option is > to add another cabinet. You are not allowed to route power cords > between cabinets so you are forever running a single circuit and 80% > of your 15A circuit max. The data center was built in a different > time. The same is true of racks in most of the suites in the more recent Freemont 2 facility. Cheers, Stef From nevin at enginehosting.com Wed Nov 4 20:53:18 2009 From: nevin at enginehosting.com (nevin at enginehosting.com) Date: Wed, 4 Nov 2009 20:53:18 -0600 (CST) Subject: =?UTF-8?Q?Re:=20HE.net,=20Fremont-2=20outage=3F?= In-Reply-To: References: <200911040403.nA4436RS041824@aurora.sol.net> <4AF128BC.3060704@raapid.net> Message-ID: <1257389598.832719817@192.168.1.71> On Wednesday, November 4, 2009 10:00am, "dan syn" said: > Maybe some of us [[soon-to-be-]ex-]customers of Hurricane can bake them a > cake and beg for UPSes. > Or reliable power. > Or for someone to actually answer the voicemails much less phone calls > within even a few hours of an outage. > Or for there to be at the very least a status page notifying customers that > they are, in fact, screwed, and for how long, and that it's useless to > continue trying to get through at such time. > > Who's with me? Yeah, after years of dealing with them all I can say is Best of luck. While we still have some legacy systems in Fremont #1 we moved 98% of our operations out to other data centers back in 2005 because of the same lack of communications even about scheduled events (which to this day I don't believe are posted anywhere). We were rapidly expanding at the time, and given the brush off, so we moved. That was the only way to get good, timely, and details information about things taking place. Flash forward almost 5 years and it seems their flagship Fremont #2 which was just being announced when we started moving, is still the same song, different year... -- Nevin Lyne -- Founder / Director of Technology -- EngineHosting.com From Valdis.Kletnieks at vt.edu Wed Nov 4 20:57:33 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 04 Nov 2009 21:57:33 -0500 Subject: HE.net, Fremont-2 outage? In-Reply-To: Your message of "Wed, 04 Nov 2009 12:26:15 CST." <200911041826.nA4IQGeT020376@aurora.sol.net> References: <200911041826.nA4IQGeT020376@aurora.sol.net> Message-ID: <6980.1257389853@turing-police.cc.vt.edu> On Wed, 04 Nov 2009 12:26:15 CST, Joe Greco said: > With power: > > N+1 is usually better than N > Best to assume full load when doing math > Things will go wrong, predict common failures And uncommon ones. :) So as part of a major compute-cluster install, we upgraded our UPS and diesel generator one weekend, and breathed a collective sigh of relief that we were now safe from power outages and mostly dodged a bullet. We *did* have some scary moments when we discovered that (a) of the 400 or so disks on our Sun E10K, about 10 didn't spin up again and (b) several of the boot disks on said box weren't mirrored. Fortunately, none of the 10 fails were on a non-mirrored disk. By Tuesday, all the non-mirrored boot disks were in fact mirrored. That Friday, a bozo contractor relocating a doorway managed to set off the Halon. Only lost two disks on the E10K. Guess which two? ;) And a month later, we discovered that the nice shiny new automatic cutover switch was wired in backwards, necessitating another power outage to re-wire it correctly. So much for safe from power outages... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From scott at doc.net.au Wed Nov 4 21:50:19 2009 From: scott at doc.net.au (Scott Howard) Date: Wed, 4 Nov 2009 19:50:19 -0800 Subject: HE.net, Fremont-2 outage? In-Reply-To: <1257388693.973329082@192.168.1.71> References: <200911040403.nA4436RS041824@aurora.sol.net> <1257388693.973329082@192.168.1.71> Message-ID: On Wed, Nov 4, 2009 at 6:38 PM, wrote: > The 2002 press release is talking about the Fremont 1 facility not the > newer Fremont 2 facility. Fremont 1 has a fixed power availability to each > cabinet of just a single 15A circuit. You can not modify or change that, > and if you need more power your option is to add another cabinet. You are > not allowed to route power cords between cabinets so you are forever running > a single circuit and 80% of your 15A circuit max. The data center was built > in a different time. > A different time, but obviously not that much different... Fremont 2 is still limited to either a single 15A or a single 20A circuit per rack. They are rebuilding one of the Fremont 2 wings and turning it into a single area rather than the existing suites, so it'll be interesting to see if things are done differently there. Scott From maillist at webjogger.net Wed Nov 4 22:03:21 2009 From: maillist at webjogger.net (Adam Greene) Date: Wed, 04 Nov 2009 23:03:21 -0500 Subject: SIP trunk silliness after peering change Message-ID: <4AF24E89.6090205@webjogger.net> Hi, Does this make any sense? We (ASN 11579) peer to (2) WBS routers (ASN 19080). We lost our link to the primary WBS router. After that, calls coming in over our Bandwidth.com SIP trunks were fine in one direction only. Callers could hear us, but we couldn't hear them. After 45 minutes, things righted themselves. Later on the primary WBS link came back up and went down again 5 minutes later (not WBS's fault, we brought up and took down the BGP session). Again we experienced the one-direction-only problem with Bandwidth.com, but this time it lasted 2.50 hours. Again things eventually righted themselves without our intervention. Traces from us to Bandwidth.com were fine during the outage. We were unable to get a trace from Bandwidth.com to us during the outage. Maybe the only way to figure out what is going on is to get that return path trace during an outage. Has anyone else experienced issues of this nature (extended outage of voice in one direction only) specifically with Bandwidth.com SIP trunks as a result of simply changing one's peering with one's upstream provider? Thanks, Adam From horms at verge.net.au Wed Nov 4 22:54:14 2009 From: horms at verge.net.au (Simon Horman) Date: Thu, 5 Nov 2009 15:54:14 +1100 Subject: Speed Testing and Throughput testing In-Reply-To: References: <41D9DD0F7396FC4CBAC6760948AE02AC011A63EADE@angelina> <4AF01F94.6020303@spectraaccess.com> Message-ID: <20091105045413.GA3828@verge.net.au> On Tue, Nov 03, 2009 at 06:49:05AM -0600, Jason Biel wrote: > Linux always worked best for us as well, was easy running a livecd with > laptops. We found that two windows XP machines, same identical hardware and > OS load yielded different registry settings (or lack thereof) for TCP Window > setting. I would have thought that (netperf's) UDP tests were more appropriate than TCP for testing link speed. Am I missing the point? From mathews at hawaii.edu Wed Nov 4 23:32:02 2009 From: mathews at hawaii.edu (Robert Mathews (OSIA)) Date: Thu, 05 Nov 2009 00:32:02 -0500 Subject: HE.net, Fremont-2 outage? In-Reply-To: References: <4AF1CA7D.1010105@rollernet.us> "2009 10:39:57 AM" <200911041854.nA4Isnbv021842@aurora.sol.net> Message-ID: <4AF26352.8000104@hawaii.edu> Alex Rubenstein wrote: >> Yup. Related: "100% availability" is a marketing person's dream; it >> sounds good in theory but is unattainable in practice, and is a >> reliable sign of non-100%-reliability. > > You are confusing two different things. > > Availability != Reliability. Pardon the interruption... In the aforementioned statement, there appears an intense/flagrant - compartmentalization/separation of terms without sufficient explanation. Note that in being available, 'a' criteria to ensure reliability is met. If one has the desire to delve into some of the nuanced operational perspective, see: http://ow.ly/zmQg (pdf) or http://ow.ly/zmTB (web friendly). The article is also available through the IEEE Portal at http://ow.ly/zn3a (if one of the other links appear to be unavailable, anytime). > For instance, an airplane is designed to be 100% reliable, but much less available. To keep a 747 from not crashing (100% reliability) it needs significant downtime (not 100% available). This explanation, aside from being unsatisfactory, is misleading. Operating times and maintenance times are very much separate quantities. >> And even for those who follow best practices... You can inspect and >> maintain things until you're blue in the face. One day a contractor >> will drop a wrench into a PDU or UPS or whatever and spectacular things >> will happen. > > That's were policies, procedures and methods come in (read: SAS70) For the operationally minded -- on one hand, there is an assumption here that 'accidents' are not preventable; on the other hand, there is at least an assumption being made here that SAS 70 is the curative for 'accidents.' To be brief, accounting for human behavior as an underlying contributor to accidents can be a backbreaking and immensely messy endeavor. In this respect, SAS 70 can only be assistive. All the best, Robert Mathews. -- From ml at axmo12.de Thu Nov 5 04:30:24 2009 From: ml at axmo12.de (ml at axmo12.de) Date: Thu, 05 Nov 2009 11:30:24 +0100 Subject: Speed Testing and Throughput testing In-Reply-To: <20091104144942.6dd9b0cd.mhelmest@uvic.ca> References: <20091104144942.6dd9b0cd.mhelmest@uvic.ca> Message-ID: <20091105113024.18524peuz4cajx8g@webmail.df.eu> Hi Michael, Zitat von Michael Helmeste : > [...] > You can give it a try at: http://caranthir.dao.nrc.ca/netperf-www/ > (login nanog/nanog). User guide here: > http://www.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/netperf/testdetail.shtml > > I might end up packaging and releasing the code if there is interest. If you have time it would be great if you could do that. - I'm very interested in it! Kind Regards, Axel From jgreco at ns.sol.net Thu Nov 5 07:49:47 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 5 Nov 2009 07:49:47 -0600 (CST) Subject: HE.net, Fremont-2 outage? In-Reply-To: <4AF26352.8000104@hawaii.edu> from "Robert Mathews (OSIA)" at Nov 05, 2009 12:32:02 AM Message-ID: <200911051349.nA5DnljR007422@aurora.sol.net> > Alex Rubenstein wrote: > >> Yup. Related: "100% availability" is a marketing person's dream; it > >> sounds good in theory but is unattainable in practice, and is a > >> reliable sign of non-100%-reliability. > > > > You are confusing two different things. > > > > Availability != Reliability. > > Pardon the interruption... > > In the aforementioned statement, there appears an intense/flagrant - > compartmentalization/separation of terms without sufficient > explanation. Correct. It's even a bit more interesting than that; there's an implication that marketing people will not really know the difference, having heard repeatedly about "high availability", may proceed to use "availability" as a buzzword... I guess I was a bit more oblique than intended. > Note that in being available, 'a' criteria to ensure > reliability is met. If one has the desire to delve into some of the > nuanced operational perspective, see: http://ow.ly/zmQg (pdf) or > http://ow.ly/zmTB (web friendly). The article is also available > through the IEEE Portal at http://ow.ly/zn3a (if one of the other links > appear to be unavailable, anytime). I doubt marketing people will care. :-) > > For instance, an airplane is designed to be 100% reliable, but much less available. To keep a 747 from not crashing (100% reliability) it needs significant downtime (not 100% available). > > This explanation, aside from being unsatisfactory, is misleading. > Operating times and maintenance times are very much separate quantities. And airplanes aren't 100% reliable regardless... For a power system as a whole, though, one could see 100% availability as a prereq for 100% reliability. Of course, you more closely approach 100% through redundancies... oops, should we introduce another term to debate? :-) > >> And even for those who follow best practices... You can inspect and > >> maintain things until you're blue in the face. One day a contractor > >> will drop a wrench into a PDU or UPS or whatever and spectacular things > >> will happen. > > > > That's were policies, procedures and methods come in (read: SAS70) > > For the operationally minded -- on one hand, there is an assumption here > that 'accidents' are not preventable; You cannot eliminate accidents. Accidents represent things which are by definition unforeseen and unplanned. Accidents may be reducible through the use of good planning and practices. On one hand, one can foresee a risk in resting a wrench near some energized busbars while needing one's hands to do something else; you can define good practices that forbid this sort of thing. Even that may not completely eliminate the practice; there are plenty of examples of companies having good policies that are disregarded by employees in the field. On the other hand, when Bruno is moving a construction excavator around next door, suffers a heart attack, and floors the controls such that the excavator rams your building and the boom arm penetrates your wall and shoves a guy face-first into the busbars, well, obviously we're talking extremely unlikely (I hope it's obvious I'm even trying to be a bit ridiculous), but that's an Accident. And they happen. > on the other hand, there is at > least an assumption being made here that SAS 70 is the curative for > 'accidents.' To be brief, accounting for human behavior as an > underlying contributor to accidents can be a backbreaking and immensely > messy endeavor. In this respect, SAS 70 can only be assistive. Correct. We can only hope to reduce accidents. My original point was simply that I prefer people who recognize 100% as a desirable-but-unobtainable goal. ... 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 jason at biel-tech.com Thu Nov 5 08:07:49 2009 From: jason at biel-tech.com (Jason Biel) Date: Thu, 5 Nov 2009 08:07:49 -0600 Subject: Speed Testing and Throughput testing In-Reply-To: <20091105045413.GA3828@verge.net.au> References: <41D9DD0F7396FC4CBAC6760948AE02AC011A63EADE@angelina> <4AF01F94.6020303@spectraaccess.com> <20091105045413.GA3828@verge.net.au> Message-ID: We actually used both tests to finally narrow down the TCP window size issue. We first used the UDP test to make sure the link was good. Jason On Wed, Nov 4, 2009 at 10:54 PM, Simon Horman wrote: > On Tue, Nov 03, 2009 at 06:49:05AM -0600, Jason Biel wrote: > > Linux always worked best for us as well, was easy running a livecd with > > laptops. We found that two windows XP machines, same identical hardware > and > > OS load yielded different registry settings (or lack thereof) for TCP > Window > > setting. > > I would have thought that (netperf's) UDP tests were more appropriate > than TCP for testing link speed. Am I missing the point? > > -- Jason Biel From owen at delong.com Thu Nov 5 08:20:25 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Nov 2009 06:20:25 -0800 Subject: Human Factors and Accident reduction/mitigation In-Reply-To: <200911051349.nA5DnljR007422@aurora.sol.net> References: <200911051349.nA5DnljR007422@aurora.sol.net> Message-ID: <550BABDF-1A67-414D-8676-A875F16A93BF@delong.com> Regarding Reliability and Availability: 1. Reliability and Availability are related, but not identical. 2. Systemic availability is, generally, the result of the combination of component reliability, component redundancy, policies, procedures, and discipline. 3. Policies, procedures, and discipline help to reduce and/or mitigate accidents. In terms of accidents and human factors: 1. Accidents cannot be eliminated, but, with proper procedures, policies, and disciplines, most can be eliminated or prevented. 2. Most accidents which cannot be eliminated can be mitigated, but, doing so often comes at a cost which exceeds the product of benefit and likelihood. We could learn a lot about this from Aviation. Nowhere in human history has more research, care, training, and discipline been applied to accident prevention, mitigation, and analysis as in aviation. A few examples: NTSB investigations of EVERY US aircraft accident and published findings. NASA Aviation Safety Reporting System When NTSB finds a design flaw in an aircraft at fault for an accident there is a process by which that error gets translated into an Airworthiness Directive forcing aircraft owners to have the flaw corrected to continue operating the aircraft. When NTSB finds a training discrepancy, procedural problem, etc., there is a process by which those discrepancies are addressed.through training, retraining, etc. For example, after a couple of accidents related to microbursts, NTSB and FAA determined that all pilots should undergo training on windshear and windshear avoidance, including microburts. etc. (There are many more examples) Owen From jason at i6ix.com Thu Nov 5 08:26:29 2009 From: jason at i6ix.com (Jason Bertoch) Date: Thu, 05 Nov 2009 09:26:29 -0500 Subject: Speed Testing and Throughput testing In-Reply-To: <20091105113024.18524peuz4cajx8g@webmail.df.eu> References: <20091104144942.6dd9b0cd.mhelmest@uvic.ca> <20091105113024.18524peuz4cajx8g@webmail.df.eu> Message-ID: <4AF2E095.30808@i6ix.com> ml at axmo12.de wrote: > Hi Michael, > > Zitat von Michael Helmeste : >> [...] >> You can give it a try at: http://caranthir.dao.nrc.ca/netperf-www/ >> (login nanog/nanog). User guide here: >> http://www.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/netperf/testdetail.shtml >> >> I might end up packaging and releasing the code if there is interest. > > If you have time it would be great if you could do that. - I'm very > interested in it! +1 From leland at taranta.discpro.org Thu Nov 5 10:24:16 2009 From: leland at taranta.discpro.org (Leland Vandervort) Date: Thu, 05 Nov 2009 17:24:16 +0100 Subject: AT&T flapped in Washington? Message-ID: <1257438256.22434.21.camel@leland-gandi> Hi all, Anyone have any information on the 20 minute (or so) flap that appears to have occured in Washington between AT&T and the rest of the world? We saw a complete outage of connectivity to several APIs at a few parnters who happen to all be behind AT&T. Although in BGP the routes were still being advertised across this peering from AT&T to the world, traffic just died at the washington peering with AT&T irrespective of which path we took. (3 different transits here). Just curious. Thanks, Leland From sterbeats at gmail.com Thu Nov 5 11:21:12 2009 From: sterbeats at gmail.com (Ali S) Date: Thu, 5 Nov 2009 09:21:12 -0800 Subject: AT&T flapped in Washington? In-Reply-To: References: <1257438256.22434.21.camel@leland-gandi> Message-ID: Washington state or DC ? sent via droid... On Nov 5, 2009 8:25 AM, "Leland Vandervort" wrote: Hi all, Anyone have any information on the 20 minute (or so) flap that appears to have occured in Washington between AT&T and the rest of the world? We saw a complete outage of connectivity to several APIs at a few parnters who happen to all be behind AT&T. Although in BGP the routes were still being advertised across this peering from AT&T to the world, traffic just died at the washington peering with AT&T irrespective of which path we took. (3 different transits here). Just curious. Thanks, Leland From leland at taranta.discpro.org Thu Nov 5 11:26:30 2009 From: leland at taranta.discpro.org (Leland Vandervort) Date: Thu, 05 Nov 2009 18:26:30 +0100 Subject: AT&T flapped in Washington? In-Reply-To: References: <1257438256.22434.21.camel@leland-gandi> Message-ID: <1257441990.22434.42.camel@leland-gandi> DC it seems.. specifically #13 in the partial trace: 11 cr2.n54ny.ip.att.net (12.122.130.102) 87.720 ms 85.642 ms 87.083 ms 12 cr2.wswdc.ip.att.net (12.122.3.38) 85.815 ms 89.022 ms 89.031 ms 13 12.122.134.153 (12.122.134.153) 88.434 ms 85.743 ms 85.440 ms and #13 in this one: 9 xe-0-1-0.er1.dca2.us.above.net (64.125.27.25) 103.117 ms 103.171 ms 103.140 ms 10 xe-1-1-0.er1.iad10.above.net (64.125.26.238) 81.522 ms 81.509 ms 81.570 ms 11 192.205.36.125 (192.205.36.125) 82.556 ms 82.594 ms 82.570 ms 12 cr1.wswdc.ip.att.net (12.122.82.222) 85.047 ms cr2.wswdc.ip.att.net (12.122.84.46) 84.959 ms 84.784 ms 13 12.122.134.1 (12.122.134.1) 84.224 ms 84.719 ms 12.122.135.1 (12.122.135.1) 84.745 ms On Thu, 2009-11-05 at 09:21 -0800, Ali S wrote: > Washington state or DC ? > > sent via droid... > > > On Nov 5, 2009 8:25 AM, "Leland Vandervort" > > wrote: > > > > Hi all, > > > > Anyone have any information on the 20 minute (or so) flap that > > appears > > to have occured in Washington between AT&T and the rest of the > > world? > > > > We saw a complete outage of connectivity to several APIs at a few > > parnters who happen to all be behind AT&T. Although in BGP the > > routes > > were still being advertised across this peering from AT&T to the > > world, > > traffic just died at the washington peering with AT&T irrespective > > of > > which path we took. (3 different transits here). > > > > Just curious. > > > > > > Thanks, > > > > Leland > > > > > > > From mark.urbach at pnpt.com Thu Nov 5 12:02:43 2009 From: mark.urbach at pnpt.com (Mark Urbach) Date: Thu, 5 Nov 2009 12:02:43 -0600 Subject: Email filtering and protection Help In-Reply-To: References: Message-ID: <007801ca5e42$2c7d6bb0$85784310$@urbach@pnpt.com> Today we use Postini for inbound email protection. Today we use Symantec's SMTP Gateway (running on Solaris) for outgoing email filtering. (helps stop bad stuff from our customers sending email to the Internet) This SMTP Gateway software is "End of Life" Does anyone have recommendations for other products/software to filter our outgoing email, from our customers going to the internet. Thanks, Mark Urbach PinPoint Communications, Inc. 100 N. 12th St Suite 500 Lincoln, NE 68508 402-438-6211 ext 1923 Office 402-660-7982 Cell mark.urbach at pnpt.com From sfouant at shortestpathfirst.com Thu Nov 5 12:06:47 2009 From: sfouant at shortestpathfirst.com (Stefan Fouant) Date: Thu, 5 Nov 2009 13:06:47 -0500 Subject: Pros and Cons of Cloud Computing in dealing with DDoS Message-ID: <002101ca5e42$bddeace0$399c06a0$@com> I'm working on an article on the Pros and Cons of Cloud Computing as an effective strategy for dealing with DDoS. I'd like to open this up for debate and get some perspectives from folks on the list. In a recent article in ITWire titled "DDoS, the biggest threat to Cloud Computing", Roland Dobbins states that "DDoS attacks are one of the most under-rated and ill-guarded against security threats to corporate IT, and in particular the biggest threat facing cloud computing." To a certain extent, I agree with Roland, however, I also believe this perspective is inconsistent with the view that the elasticity of cloud computing and ability to scale resources on demand is a good way of dealing with the problem. The counterpoint to this is that I can also envision the cloud computing model causing a shift from that of a DDoS to what some are calling EDoS (Economic Denial of Sustainability). In an EDoS, the elasticity of the cloud and surplus of available resources might be used in such a way that large botnets generating seemingly legitimate "targeted" requests for service causing the victim to cloudburst in order to keep pace with the scale of the requests. Even though the victim can sustain business operations, the cost of doing so may be so exorbitantly expensive that to do so threatens economic sustainability. Roland also states "The cloud providers emerging as leaders don't tend to talk much about their resiliency to DDoS attacks". Which brings about another point - are there any cloud providers taking a proactive look at dealing with this problem and deploying effective countermeasures for dealing with this in their environments? What motivation would cloud providers have to deploy DDoS mitigation services and/or services which can distinguish between legitimate resource consumption vs. targeted resource consumption, especially if their revenues are driven from service availability and potential expansion of resource utilization? Stefan Fouant GPG Key ID: 0xB5E3803D From regnauld at nsrc.org Thu Nov 5 12:08:24 2009 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 5 Nov 2009 19:08:24 +0100 Subject: Email filtering and protection Help In-Reply-To: <007801ca5e42$2c7d6bb0$85784310$@urbach@pnpt.com> References: <007801ca5e42$2c7d6bb0$85784310$@urbach@pnpt.com> Message-ID: <20091105180820.GM10158@macbook.catpipe.net> Mark Urbach (mark.urbach) writes: > Today we use Postini for inbound email protection. > Today we use Symantec's SMTP Gateway (running on Solaris) for outgoing email > filtering. (helps stop bad stuff from our customers sending email to the > Internet) This SMTP Gateway software is "End of Life" > > Does anyone have recommendations for other products/software to filter our > outgoing email, from our customers going to the internet. Are we talking virus protection ? You might want to look at something like amavisd-new or clamav in SMTP proxy mode. http://www.ijs.si/software/amavisd/ http://www.clamav.net/ Amavisd-new together with clamav and SpamAssassin will block a big chunk aof spam and viruses. Some vendors like Barracuda and IronPort do this as well, if you're willing to pay. Cheers, Phil From jeffrey.lyon at blacklotus.net Thu Nov 5 12:20:17 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 5 Nov 2009 13:20:17 -0500 Subject: Pros and Cons of Cloud Computing in dealing with DDoS In-Reply-To: <002101ca5e42$bddeace0$399c06a0$@com> References: <002101ca5e42$bddeace0$399c06a0$@com> Message-ID: <16720fe00911051020m4327d713jfa0e1b4043adc23f@mail.gmail.com> DDoS is a threat to the cloud just as DDoS is a threat to any other service when you fail to implement protection. Our company recently put out a DDoS mitigated cloud product specifically for high risk clients. Best regards, Jeff On Thu, Nov 5, 2009 at 1:06 PM, Stefan Fouant wrote: > I'm working on an article on the Pros and Cons of Cloud Computing as an > effective strategy for dealing with DDoS. ?I'd like to open this up for > debate and get some perspectives from folks on the list. > > > > In a recent article in ITWire titled "DDoS, the biggest threat to Cloud > Computing", Roland Dobbins states that "DDoS attacks are one of the most > under-rated and ill-guarded against security threats to corporate IT, and in > particular the biggest threat facing cloud computing." ?To a certain extent, > I agree with Roland, however, I also believe this perspective is > inconsistent with the view that the elasticity of cloud computing and > ability to scale resources on demand is a good way of dealing with the > problem. ?The counterpoint to this is that I can also envision the cloud > computing model causing a shift from that of a DDoS to what some are calling > EDoS (Economic Denial of Sustainability). ?In an EDoS, the elasticity of the > cloud and surplus of available resources might be used in such a way that > large botnets generating seemingly legitimate "targeted" requests for > service causing the victim to cloudburst in order to keep pace with the > scale of the requests. ?Even though the victim can sustain business > operations, the cost of doing so may be so exorbitantly expensive that to do > so threatens economic sustainability. > > > > Roland also states "The cloud providers emerging as leaders don't tend to > talk much about their resiliency to DDoS attacks". ?Which brings about > another point - are there any cloud providers taking a proactive look at > dealing with this problem and deploying effective countermeasures for > dealing with this in their environments? ?What motivation would cloud > providers have to deploy DDoS mitigation services and/or services which can > distinguish between legitimate resource consumption vs. targeted resource > consumption, especially if their revenues are driven from service > availability and potential expansion of resource utilization? > > > > Stefan Fouant > > GPG Key ID: 0xB5E3803D > > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From sethm at rollernet.us Thu Nov 5 12:27:47 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 05 Nov 2009 10:27:47 -0800 Subject: Pros and Cons of Cloud Computing in dealing with DDoS In-Reply-To: <16720fe00911051020m4327d713jfa0e1b4043adc23f@mail.gmail.com> References: <002101ca5e42$bddeace0$399c06a0$@com> <16720fe00911051020m4327d713jfa0e1b4043adc23f@mail.gmail.com> Message-ID: <4AF31923.1000505@rollernet.us> Jeffrey Lyon wrote: > DDoS is a threat to the cloud just as DDoS is a threat to any other > service when you fail to implement protection. Our company recently > put out a DDoS mitigated cloud product specifically for high risk > clients. > How about the cloud as a DDoS source? ~Seth From jasongurtz at npumail.com Thu Nov 5 12:55:38 2009 From: jasongurtz at npumail.com (Jason Gurtz) Date: Thu, 5 Nov 2009 13:55:38 -0500 Subject: Email filtering and protection Help In-Reply-To: <007801ca5e42$2c7d6bb0$85784310$@urbach@pnpt.com> References: <007801ca5e42$2c7d6bb0$85784310$@urbach@pnpt.com> Message-ID: > Does anyone have recommendations for other products/software to filter > our outgoing email, from our customers going to the internet. For Roll-your-own it's hard to beat a combo of MIMEDefang/SA/Clam (MD is a milter, so sendmail or postfix needed). The MIMEDefang developer also started a company which sells CanIT Pro, an appliance version of the above with additional features/web interface/support Ironport (reassuringly expensive) has worked great here at work. ~JasonG -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3088 bytes Desc: not available URL: From fergdawgster at gmail.com Thu Nov 5 13:04:00 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 5 Nov 2009 11:04:00 -0800 Subject: Pros and Cons of Cloud Computing in dealing with DDoS In-Reply-To: <4AF31923.1000505@rollernet.us> References: <002101ca5e42$bddeace0$399c06a0$@com> <16720fe00911051020m4327d713jfa0e1b4043adc23f@mail.gmail.com> <4AF31923.1000505@rollernet.us> Message-ID: <6cd462c00911051104h4a2ee37bk44e4ecdfe36d1690@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Nov 5, 2009 at 10:27 AM, Seth Mattinen wrote: > Jeffrey Lyon wrote: >> DDoS is a threat to the cloud just as DDoS is a threat to any other >> service when you fail to implement protection. Our company recently >> put out a DDoS mitigated cloud product specifically for high risk >> clients. >> > > How about the cloud as a DDoS source? > It's called a botnet. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFK8yGZq1pz9mNUZTMRAsipAJ0ZuFMPjGDhK8RjZD8yerlNJZ4sLQCeLrbp vDQqPsasoKduDA2m+rj2h1Q= =PLip -----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 jgreco at ns.sol.net Thu Nov 5 13:07:23 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 5 Nov 2009 13:07:23 -0600 (CST) Subject: Pros and Cons of Cloud Computing in dealing with DDoS In-Reply-To: <6cd462c00911051104h4a2ee37bk44e4ecdfe36d1690@mail.gmail.com> from "Paul Ferguson" at Nov 05, 2009 11:04:00 AM Message-ID: <200911051907.nA5J7NFA020437@aurora.sol.net> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thu, Nov 5, 2009 at 10:27 AM, Seth Mattinen wrote: > > > Jeffrey Lyon wrote: > >> DDoS is a threat to the cloud just as DDoS is a threat to any other > >> service when you fail to implement protection. Our company recently > >> put out a DDoS mitigated cloud product specifically for high risk > >> clients. > >> > > > > How about the cloud as a DDoS source? > > > > It's called a botnet. Everything's called a botnet. How about 'clotnet'? :-) ... 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 sfouant at shortestpathfirst.com Thu Nov 5 13:11:35 2009 From: sfouant at shortestpathfirst.com (Stefan Fouant) Date: Thu, 5 Nov 2009 14:11:35 -0500 Subject: Pros and Cons of Cloud Computing in dealing with DDoS In-Reply-To: <16720fe00911051020m4327d713jfa0e1b4043adc23f@mail.gmail.com> References: <002101ca5e42$bddeace0$399c06a0$@com> <16720fe00911051020m4327d713jfa0e1b4043adc23f@mail.gmail.com> Message-ID: <003101ca5e4b$cbe74550$63b5cff0$@com> > -----Original Message----- > From: jeffrey.lyon at gmail.com [mailto:jeffrey.lyon at gmail.com] On Behalf > Of Jeffrey Lyon > Sent: Thursday, November 05, 2009 1:20 PM > To: Stefan Fouant > Cc: NANOG list > Subject: Re: Pros and Cons of Cloud Computing in dealing with DDoS > > DDoS is a threat to the cloud just as DDoS is a threat to any other > service when you fail to implement protection. Our company recently > put out a DDoS mitigated cloud product specifically for high risk > clients. > > Best regards, Jeff Obviously the cloud is no different than any other infrastructure insofar as implementing protection mechanisms. Ample bandwidth (typically more so than in the enterprise) should make it easier to absorb larger amounts of the bad stuff. What I'm really wondering is what steps cloud providers are taking to be able to differentiate between the legitimate vs. targeted resource consumption, what are their motivations if the main thing driving revenue is expansion of resource utilization, or do most cloud providers simply think this is a non-issue if they can just overengineer compute, storage, and network resources such that they can sustain even the heaviest loads, legitimate or not. I'd also like to get perspectives from some of the heavy hitters (ahem... Danny, Roland, etc.) and understand why they think DDoS is the single biggest threat to the cloud computing model, again this is counter to a lot of evidence which points to the corollary - think DNS Root Servers and you'll have an idea what I'm talking about... BTW - the BlackLotus offering using RioRey is pretty cool (those are good boxes and I've used them before for specific point applications), but I'm really trying to discuss the relevance to cloud based services, not hosted services (I don't generally group them into the same category). Stefan Fouant GPG Key ID: 0xB5E3803D From ghicks at hicks-net.net Thu Nov 5 13:31:11 2009 From: ghicks at hicks-net.net (Gregory Hicks) Date: Thu, 5 Nov 2009 11:31:11 -0800 (PST) Subject: Email filtering and protection Help Message-ID: <200911051931.nA5JVBt0024531@metis.hicks-net.net> > From: Mark Urbach > To: > Subject: Email filtering and protection Help > Date: Thu, 5 Nov 2009 12:02:43 -0600 > > Today we use Postini for inbound email protection. > Today we use Symantec's SMTP Gateway (running on Solaris) for outgoing email > filtering. (helps stop bad stuff from our customers sending email to the > Internet) This SMTP Gateway software is "End of Life" > > Does anyone have recommendations for other products/software to filter our > outgoing email, from our customers going to the internet. Postini also does outgoing email filtering. Just requires setup. Regards, Gregory Hicks > > > Thanks, > Mark Urbach > PinPoint Communications, Inc. > 100 N. 12th St Suite 500 > Lincoln, NE 68508 > 402-438-6211 ext 1923 Office > 402-660-7982 Cell > mark.urbach at pnpt.com > --------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer | Direct: 408.569.7928 People sleep peaceably in their beds at night only because rough men stand ready to do violence on their behalf -- George Orwell The price of freedom is eternal vigilance. -- Thomas Jefferson "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton From dave at stayonline.com Thu Nov 5 13:42:44 2009 From: dave at stayonline.com (Dave Larter) Date: Thu, 5 Nov 2009 14:42:44 -0500 Subject: Email filtering and protection Help In-Reply-To: <200911051931.nA5JVBt0024531@metis.hicks-net.net> References: <200911051931.nA5JVBt0024531@metis.hicks-net.net> Message-ID: <8B79B73777E7D544A24BEB8FC50D35DB798B44@MERCURY.socrdu.com> I (we) use SBG, if you like the Symantec stuff it is much better than the SMS SMTP product. -----Original Message----- From: Gregory Hicks [mailto:ghicks at hicks-net.net] Sent: Thursday, November 05, 2009 2:31 PM To: nanog at nanog.org; mark.urbach at pnpt.com Subject: Re: Email filtering and protection Help > From: Mark Urbach > To: > Subject: Email filtering and protection Help > Date: Thu, 5 Nov 2009 12:02:43 -0600 > > Today we use Postini for inbound email protection. > Today we use Symantec's SMTP Gateway (running on Solaris) for outgoing email > filtering. (helps stop bad stuff from our customers sending email to the > Internet) This SMTP Gateway software is "End of Life" > > Does anyone have recommendations for other products/software to filter our > outgoing email, from our customers going to the internet. Postini also does outgoing email filtering. Just requires setup. Regards, Gregory Hicks > > > Thanks, > Mark Urbach > PinPoint Communications, Inc. > 100 N. 12th St Suite 500 > Lincoln, NE 68508 > 402-438-6211 ext 1923 Office > 402-660-7982 Cell > mark.urbach at pnpt.com > --------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer | Direct: 408.569.7928 People sleep peaceably in their beds at night only because rough men stand ready to do violence on their behalf -- George Orwell The price of freedom is eternal vigilance. -- Thomas Jefferson "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton From johnl at iecc.com Thu Nov 5 14:56:31 2009 From: johnl at iecc.com (John Levine) Date: 5 Nov 2009 20:56:31 -0000 Subject: Email filtering and protection Help In-Reply-To: <200911051931.nA5JVBt0024531@metis.hicks-net.net> Message-ID: <20091105205631.58938.qmail@simone.iecc.com> >Postini also does outgoing email filtering. Just requires setup. Based on the amount of spam their customers send me, it doesn't work very well. R's, John From rdobbins at arbor.net Thu Nov 5 15:35:20 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 6 Nov 2009 04:35:20 +0700 Subject: Pros and Cons of Cloud Computing in dealing with DDoS In-Reply-To: <003101ca5e4b$cbe74550$63b5cff0$@com> References: <002101ca5e42$bddeace0$399c06a0$@com> <16720fe00911051020m4327d713jfa0e1b4043adc23f@mail.gmail.com> <003101ca5e4b$cbe74550$63b5cff0$@com> Message-ID: <55F6AEA5-1FCB-425D-AB1E-9F541C5D44F3@arbor.net> On Nov 6, 2009, at 2:11 AM, Stefan Fouant wrote: > Obviously the cloud is no different than any other infrastructure > insofar as > implementing protection mechanisms. Ample bandwidth (typically more > so than > in the enterprise) should make it easier to absorb larger amounts of > the bad > stuff. Actually, no - the miscreants are always going to have more bandwidth at their disposal, plus they utilize attack vectors which provide a great deal of amplification (including at layer-7) which make bandwidth largely irrelevant. > why they think DDoS is the single biggest threat to the cloud > computing model, Availability is the one thing which *must* be guaranteed at all costs in order for the cloud model to work, and by definition, most cloud infrastructure isn't going to be within the span of control of the end- customer. Look at all the apps/services we all use and depend upon every day - Webmail, IM, various Web 2.0ish AJAXy things, Skype, SIP, et al. When these things are DDoSed either deliberately or inadvertently, directly or indirectly (i.e., zorching authoritative DNS a la Baofeng), lots and lots of folks end up getting hosed. Now, expand this to your back-end line-of-business apps, your IP PBXes, your customer databases, your ERP software, your CAM/CAM system, your basic file/print services, and the picture becomes much clearer. The movement towards 'cloud' - starting with things like VPS and VPDC and SaaS for specific applications - largely consists of end-customer organizations jettisoning their internal data centers/WAN links/ops staff and subscribing to these apps/services on a recurring basis, with said apps/services either residing within a public-facing IDC or in a multitenanted IDC made available to the end-customer via an MPLS NGN. It entails shutting down locally-/internally-owned-and-operated DCs and moving into > again this is counter to a lot of evidence which points to the > corollary Which evidence is that? [You meant 'contrary', yes?] > - think DNS Root Servers and you'll have an idea what I'm talking > about... There's a heck of a lot of engineering which has gone into protecting the roots - I'm sure you'll recall the high-visibility DDoS attacks which affected multiple roots in the past. The root operators learned from that experience and took proactive measures to ensure that they can continue to maintain availability in the face of constant onslaughts. The bottom line is that it's easy to achieve perfect confidentiality and integrity if availability is lacking, heh. All three legs of the classical information security triad are of import, but it's always been my view that availability is the first among equals, which translates into the need for robust, scalable architecture and the willingness to devote time and resources to the operational security art. Paul's comment about botnets being 'cloud' services is dead-on; and of course, miscreants using stolen credit-cards to purchase IaaS for spamming/phishing purposes has already been seen in the wild, just as they do so with their nonsense domains for botnet C&C. IaaS abused to launch DDoS won't be far behind. ----------------------------------------------------------------------- Roland Dobbins // Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 From smeuse at mara.org Thu Nov 5 16:26:42 2009 From: smeuse at mara.org (Steve Meuse) Date: Thu, 5 Nov 2009 17:26:42 -0500 Subject: Upstream BGP community support In-Reply-To: References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> <4AEE7503.7080100@ibctech.ca> Message-ID: <20091105222642.GB31308@mara.org> Randy Bush expunged (randy at psg.com): > i try to complicate the internals of my network as little as possible, > after all, complexity == opex and i value my time, it is a non-renewable > resource. I'm guessing you don't have the same financial constraints that others on this list have. When you have "lots of traffic(tm)" to move around, and some paths are more 'spensive than others, you often don't have a choise but to muck with communities, or so I've heard.... -Steve From smeuse at mara.org Thu Nov 5 16:33:07 2009 From: smeuse at mara.org (Steve Meuse) Date: Thu, 5 Nov 2009 17:33:07 -0500 Subject: Upstream BGP community support In-Reply-To: <4AEF3AF2.7040402@brightok.net> References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> <4AEF341D.7050009@bogus.com> <4AEF3518.7050006@brightok.net> <4AEF39AA.7010602@bogus.com> <4AEF3AF2.7040402@brightok.net> Message-ID: <20091105223307.GC31308@mara.org> Jack Bates expunged (jbates at brightok.net): > I think creating a standard or at least a template might push more > people to adopt communities support and to use them. I put this up there with trynig to define inter-provider QoS. You are never going to get two business to agree to the same model.....and after all, community support is basically a business tool. I know from experience that some providers deliberately constrain their community support for business purposes, this goes back 10+ years..... -Steve From bking at inline.com Thu Nov 5 16:40:09 2009 From: bking at inline.com (Bryan King) Date: Thu, 05 Nov 2009 16:40:09 -0600 Subject: Congress may require ISPs to block fraud sites H.R.3817 Message-ID: <4AF35449.8030700@inline.com> Did I miss a thread on this? Has anyone looked at this yet? http://m.news.com/2166-12_3-10390779-38.html Section 508 of H.R.3817: SEC. 508. PENALTY FOR MISREPRESENTATION OF SIPC MEMBERSHIP OR PROTECTION. Section 14 of the Securities Investor Protection Act of 1970 (15 U.S.C. 78jjj) is amended by adding at the end the following new subsection: `(d) Misrepresentation of SIPC Membership or Protection- `(1) IN GENERAL- Any person who falsely represents by any means (including, without limitation, through the Internet or any other medium of mass communication), with actual knowledge of the falsity of the representation and with an intent to deceive or cause injury to another, that such person, or another person, is a member of SIPC or that any person or account is protected or is eligible for protection under this Act or by SIPC, shall be liable for any damages caused thereby and shall be fined not more than $250,000 or imprisoned for not more than five years. `(2) INTERNET SERVICE PROVIDERS- Any Internet service provider that, on or through a system or network controlled or operated by the Internet service provider, transmits, routes, provides connections for, or stores any material containing any misrepresentation of the kind prohibited in paragraph (1) shall be liable for any damages caused thereby, including damages suffered by SIPC, if the Internet service provider-- `(A) has actual knowledge that the material contains a misrepresentation of the kind prohibited in paragraph (1), or `(B) in the absence of actual knowledge, is aware of facts or circumstances from which it is apparent that the material contains a misrepresentation of the kind prohibited in paragraph (1), and upon obtaining such knowledge or awareness, fails to act expeditiously to remove, or disable access to, the material. `(3) INJUNCTIONS- Any court having jurisdiction of a civil action arising under this Act may grant temporary injunctions and final injunctions on such terms as the court deems reasonable to prevent or restrain any violation of paragraph (1) or (2). Any such injunction may be served anywhere in the United States on the person enjoined, shall be operative throughout the United States, and shall be enforceable, by proceedings in contempt or otherwise, by any United States court having jurisdiction over that person. The clerk of the court granting the injunction shall, when requested by any other court in which enforcement of the injunction is sought, transmit promptly to the other court a certified copy of all papers in the case on file in such clerk's office.'. From jbates at brightok.net Thu Nov 5 16:52:53 2009 From: jbates at brightok.net (Jack Bates) Date: Thu, 05 Nov 2009 16:52:53 -0600 Subject: Upstream BGP community support In-Reply-To: <20091105223307.GC31308@mara.org> References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> <4AEF341D.7050009@bogus.com> <4AEF3518.7050006@brightok.net> <4AEF39AA.7010602@bogus.com> <4AEF3AF2.7040402@brightok.net> <20091105223307.GC31308@mara.org> Message-ID: <4AF35745.5080204@brightok.net> Steve Meuse wrote: > I put this up there with trynig to define inter-provider QoS. You are never going to get two business to agree to the same model.....and after all, community support is basically a business tool. I know from experience that some providers deliberately constrain their community support for business purposes, this goes back 10+ years..... > While I agree, I was thinking more along the lines of easy tools to provide the clueless with ways to do nifty things. Jack From Valdis.Kletnieks at vt.edu Thu Nov 5 16:56:46 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 05 Nov 2009 17:56:46 -0500 Subject: Congress may require ISPs to block fraud sites H.R.3817 In-Reply-To: Your message of "Thu, 05 Nov 2009 16:40:09 CST." <4AF35449.8030700@inline.com> References: <4AF35449.8030700@inline.com> Message-ID: <23895.1257461806@turing-police.cc.vt.edu> On Thu, 05 Nov 2009 16:40:09 CST, Bryan King said: > Did I miss a thread on this? Has anyone looked at this yet? > `(2) INTERNET SERVICE PROVIDERS- Any Internet service provider that, on > or through a system or network controlled or operated by the Internet > service provider, transmits, routes, provides connections for, or stores > any material containing any misrepresentation of the kind prohibited in > paragraph (1) shall be liable for any damages caused thereby, including > damages suffered by SIPC, if the Internet service provider-- "routes" sounds the most dangerous part there. Does this mean that if we have a BGP peering session with somebody, we need to filter it? Fortunately, there's the conditions: > `(A) has actual knowledge that the material contains a misrepresentation > of the kind prohibited in paragraph (1), or > `(B) in the absence of actual knowledge, is aware of facts or > circumstances from which it is apparent that the material contains a > misrepresentation of the kind prohibited in paragraph (1), and > upon obtaining such knowledge or awareness, fails to act expeditiously > to remove, or disable access to, the material. So the big players that just provide bandwidth to the smaller players are mostly off the hook - AS701 has no reason to be aware that some website in Tortuga is in violation (which raises an intresting point - what if the site *is* offshore?) And the immediate usptreams will fail to obtain knowledge or awareness of their customer's actions, the same way they always have. Move along, nothing to see.. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dr at cluenet.de Thu Nov 5 17:04:18 2009 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 6 Nov 2009 00:04:18 +0100 Subject: Upstream BGP community support In-Reply-To: <20091102201338.GZ51443@gerbil.cluepon.net> References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> <4AEF341D.7050009@bogus.com> <4AEF3518.7050006@brightok.net> <20091102201338.GZ51443@gerbil.cluepon.net> Message-ID: <20091105230418.GA12914@srv03.cluenet.de> On Mon, Nov 02, 2009 at 02:13:38PM -0600, Richard A Steenbergen wrote: > Rather than simply double the size and break it > up into 32:32, the designers reserved the top 16 bits for "type" and > "subtype" attributes, leaving you only 48 bits to work with. Clearly the > only suitable mapping for support of 32-bit ASNs on the Internet is > 32:16, leaving us with exactly the same range of "data" values that we > have today. ... which breaks schemes such as 65123:45678 where 45678 is the neighboring AS to apply the action defined by 65123 to. Seen those multiple times. Of course using anything else then your own ASN in the "AS part" of TE communities is certainly debatable. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From robert at tellurian.com Thu Nov 5 17:14:01 2009 From: robert at tellurian.com (Robert Boyle) Date: Thu, 05 Nov 2009 18:14:01 -0500 Subject: Human Factors and Accident reduction/mitigation In-Reply-To: <550BABDF-1A67-414D-8676-A875F16A93BF@delong.com> References: <200911051349.nA5DnljR007422@aurora.sol.net> <550BABDF-1A67-414D-8676-A875F16A93BF@delong.com> Message-ID: <1257462944_503118@mail1.tellurian.net> At 09:20 AM 11/5/2009, Owen DeLong wrote: >Regarding Reliability and Availability: > >We could learn a lot about this from Aviation. Owen, I think if we conducted a poll, a disproportionate percentage of NANOG folks are likely also pilots (compared to the general population anyway) I agree with you completely that aviation is a good model to follow if it is adapted where it makes sense. All, The real problem is same human factors we have in aviation which cause most accidents. Look at the list below and replace the word Pilot with Network Engineer or Support Tech or Programmer or whatever... and think about all the problems where something didn't work out right. It's because someone circumvented the rules, processes, and cross checks put in place to prevent the problem in the first place. Nothing can be made idiot proof because idiots are so creative. -Robert SEL/MEL Private Instrument Listed here: THE FIVE HAZARDOUS ATTITUDES 1. Anti-Authority: "Don't tell me." This attitude is found in people who do not like anyone telling them what to do. In a sense, they are saying, "No one can tell me what to do." They may be resentful of having someone tell them what to do, or may regard rules, regulations, and procedures as silly or unnecessary. However, it is always your prerogative to question authority if you feel it is in error. 2. Impulsivity: "Do it quickly." This is the attitude of people who frequently feel the need to do something, anything, immediately. They do not stop to think about what they are about to do; they do not select the best alternative, and they do the first thing that comes to mind. 3. Invulnerability: "It won't happen to me." Many people feel that accidents happen to others, but never to them. They know accidents can happen, and they know that anyone can be affected. They never really feel or believe that they will be personally involved. Pilots who think this way are more likely to take chances and increase risk. 4. Macho: "I can do it." Pilots who are always trying to prove that they are better than anyone else are thinking, "I can do it ?I'll show them." Pilots with this type of attitude will try to prove themselves by taking risks in order to impress others. While this pattern is thought to be a male characteristic, women are equally susceptible. 5. Resignation: "What's the use?" Pilots who think, "What's the use?" do not see themselves as being able to make a great deal of difference in what happens to them. When things go well, the pilot is apt to think that it is good luck. When things go badly, the pilot may feel that someone is out to get me, or attribute it to bad luck. The pilot will leave the action to others, for better or worse. Sometimes, such pilots will even go along with unreasonable requests just to be a "nice guy." Tellurian Networks - A Dell Perot Systems Company http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin From marka at isc.org Thu Nov 5 18:06:06 2009 From: marka at isc.org (Mark Andrews) Date: Fri, 06 Nov 2009 11:06:06 +1100 Subject: Congress may require ISPs to block fraud sites H.R.3817 In-Reply-To: Your message of "Thu, 05 Nov 2009 17:56:46 CDT." <23895.1257461806@turing-police.cc.vt.edu> References: <4AF35449.8030700@inline.com> <23895.1257461806@turing-police.cc.vt.edu> Message-ID: <200911060006.nA6066fO031090@drugs.dv.isc.org> In message <23895.1257461806 at turing-police.cc.vt.edu>, Valdis.Kletnieks at vt.edu writes: > --==_Exmh_1257461806_2581P > Content-Type: text/plain; charset=us-ascii > > On Thu, 05 Nov 2009 16:40:09 CST, Bryan King said: > > Did I miss a thread on this? Has anyone looked at this yet? > > > `(2) INTERNET SERVICE PROVIDERS- Any Internet service provider that, on > > or through a system or network controlled or operated by the Internet > > service provider, transmits, routes, provides connections for, or stores > > any material containing any misrepresentation of the kind prohibited in > > paragraph (1) shall be liable for any damages caused thereby, including > > damages suffered by SIPC, if the Internet service provider-- > > "routes" sounds the most dangerous part there. Does this mean that if > we have a BGP peering session with somebody, we need to filter it? > > Fortunately, there's the conditions: > > > `(A) has actual knowledge that the material contains a misrepresentation > > of the kind prohibited in paragraph (1), or > > > `(B) in the absence of actual knowledge, is aware of facts or > > circumstances from which it is apparent that the material contains a > > misrepresentation of the kind prohibited in paragraph (1), and > > > upon obtaining such knowledge or awareness, fails to act expeditiously > > to remove, or disable access to, the material. > > So the big players that just provide bandwidth to the smaller players are > mostly off the hook - AS701 has no reason to be aware that some website in > Tortuga is in violation (which raises an intresting point - what if the > site *is* offshore?) Unless it is informed. Once it is informed it has to take action. Turning the informer off, luckily, doesn't meet the requirements for "taking action" as you need to protect all of your customers or make yourself liable for prosecution. I suspect informing a closer peer that is also subject to the act would be seen as taking reasonable action as it could be reasonably assumed that they will take appropriate steps, but one would have to check that the material was removed/blocked. If you run a residential network, it appears to me that, you are now responsible for seeing that all material that is subject to the act that is reported to you by your customers is addressed. INAL. > And the immediate usptreams will fail to obtain knowledge or awareness of > their customer's actions, the same way they always have. > > Move along, nothing to see.. ;) > > --==_Exmh_1257461806_2581P > Content-Type: application/pgp-signature > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Exmh version 2.5 07/13/2001 > > iD8DBQFK81gucC3lWbTT17ARAjaeAJ9Snqyq/z7qeF/Z+ag+xluKfUQAdwCgrJ4V > LyG+0P2RJeLA9VRrzgejyiE= > =Mxbr > -----END PGP SIGNATURE----- > > --==_Exmh_1257461806_2581P-- > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From smb at cs.columbia.edu Thu Nov 5 18:24:33 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 5 Nov 2009 19:24:33 -0500 Subject: Congress may require ISPs to block fraud sites H.R.3817 In-Reply-To: <23895.1257461806@turing-police.cc.vt.edu> References: <4AF35449.8030700@inline.com> <23895.1257461806@turing-police.cc.vt.edu> Message-ID: <6EE2A54A-E255-471F-9D29-18237D19E991@cs.columbia.edu> On Nov 5, 2009, at 5:56 PM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 05 Nov 2009 16:40:09 CST, Bryan King said: >> Did I miss a thread on this? Has anyone looked at this yet? > >> `(2) INTERNET SERVICE PROVIDERS- Any Internet service provider >> that, on >> or through a system or network controlled or operated by the Internet >> service provider, transmits, routes, provides connections for, or >> stores >> any material containing any misrepresentation of the kind >> prohibited in >> paragraph (1) shall be liable for any damages caused thereby, >> including >> damages suffered by SIPC, if the Internet service provider-- > > "routes" sounds the most dangerous part there. Does this mean that if > we have a BGP peering session with somebody, we need to filter it? Also "transmits". (I'm impressed that someone in Congress knows the word "routes"....) > > Fortunately, there's the conditions: > >> `(A) has actual knowledge that the material contains a >> misrepresentation >> of the kind prohibited in paragraph (1), or > >> `(B) in the absence of actual knowledge, is aware of facts or >> circumstances from which it is apparent that the material contains a >> misrepresentation of the kind prohibited in paragraph (1), and > >> upon obtaining such knowledge or awareness, fails to act >> expeditiously >> to remove, or disable access to, the material. > > So the big players that just provide bandwidth to the smaller > players are > mostly off the hook - AS701 has no reason to be aware that some > website in > Tortuga is in violation (which raises an intresting point - what if > the > site *is* offshore?) > > And the immediate usptreams will fail to obtain knowledge or > awareness of > their customer's actions, the same way they always have. Note the word "circumstances"... > > Move along, nothing to see.. ;) Until, of course, some Assistant U.S. Attorney or some attorney in a civil lawsuit decides you were or should have been aware and takes you to court. You may win, but after spending O(\alph_0) zorkmids on lawyers defending yourself.... --Steve Bellovin, http://www.cs.columbia.edu/~smb From michael at linuxmagic.com Thu Nov 5 18:30:07 2009 From: michael at linuxmagic.com (Michael Peddemors) Date: Thu, 5 Nov 2009 16:30:07 -0800 Subject: Human Factors and Accident reduction/mitigation In-Reply-To: <1257462944_503118@mail1.tellurian.net> References: <200911051349.nA5DnljR007422@aurora.sol.net> <550BABDF-1A67-414D-8676-A875F16A93BF@delong.com> <1257462944_503118@mail1.tellurian.net> Message-ID: <200911051630.07293.michael@linuxmagic.com> On November 5, 2009, Robert Boyle wrote: > It's > because someone circumvented the rules, > processes, and cross checks put in place to > prevent the problem in the first place. Nothing > can be made idiot proof because idiots are so creative. > > -Robert > SEL/MEL Private Instrument > No, no commercial pilot every flew overweight, or in weather below minimums, or more that the max hours in a month.. never happens ;) And there was never a boss that 'pushed' them into it, for the sake of expediency or financial gain, and the phrase.. 'Big Sky, Little Plane' was nevered uttered.. logbooks never fudged and rules are always followed.. C(om)255379 -- -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors - President/CEO - LinuxMagic Products, Services, Support and Development Visit us at http://www.linuxmagic.com ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-589-0037 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From richard at bennett.com Thu Nov 5 18:44:27 2009 From: richard at bennett.com (Richard Bennett) Date: Thu, 05 Nov 2009 16:44:27 -0800 Subject: Congress may require ISPs to block fraud sites H.R.3817 In-Reply-To: <6EE2A54A-E255-471F-9D29-18237D19E991@cs.columbia.edu> References: <4AF35449.8030700@inline.com> <23895.1257461806@turing-police.cc.vt.edu> <6EE2A54A-E255-471F-9D29-18237D19E991@cs.columbia.edu> Message-ID: <4AF3716B.1040000@bennett.com> I think the idea is for the government to create an official blacklist of the offending sites, and for ISPs to consult it before routing a packet to the fraud site. The common implementation would be an ACL on the ISPs border router. The Congress doesn't yet understand the distinction between ISPs and transit providers, of course, and typically says that proposed ISP regulations (including the net neutrality regulations) apply only to consumer-facing service providers. If this measure passes, you can expect expansion of blocking mandates for rogue sites of other kinds, such as kiddie porn and DMCA scofflaws. RB Steven Bellovin wrote: > > On Nov 5, 2009, at 5:56 PM, Valdis.Kletnieks at vt.edu wrote: > >> On Thu, 05 Nov 2009 16:40:09 CST, Bryan King said: >>> Did I miss a thread on this? Has anyone looked at this yet? >> >>> `(2) INTERNET SERVICE PROVIDERS- Any Internet service provider that, on >>> or through a system or network controlled or operated by the Internet >>> service provider, transmits, routes, provides connections for, or >>> stores >>> any material containing any misrepresentation of the kind prohibited in >>> paragraph (1) shall be liable for any damages caused thereby, including >>> damages suffered by SIPC, if the Internet service provider-- >> >> "routes" sounds the most dangerous part there. Does this mean that if >> we have a BGP peering session with somebody, we need to filter it? > > Also "transmits". (I'm impressed that someone in Congress knows the > word "routes"....) >> >> Fortunately, there's the conditions: >> >>> `(A) has actual knowledge that the material contains a >>> misrepresentation >>> of the kind prohibited in paragraph (1), or >> >>> `(B) in the absence of actual knowledge, is aware of facts or >>> circumstances from which it is apparent that the material contains a >>> misrepresentation of the kind prohibited in paragraph (1), and >> >>> upon obtaining such knowledge or awareness, fails to act expeditiously >>> to remove, or disable access to, the material. >> >> So the big players that just provide bandwidth to the smaller players >> are >> mostly off the hook - AS701 has no reason to be aware that some >> website in >> Tortuga is in violation (which raises an intresting point - what if the >> site *is* offshore?) >> >> And the immediate usptreams will fail to obtain knowledge or >> awareness of >> their customer's actions, the same way they always have. > > Note the word "circumstances"... >> >> Move along, nothing to see.. ;) > > Until, of course, some Assistant U.S. Attorney or some attorney in a > civil lawsuit decides you were or should have been aware and takes you > to court. You may win, but after spending O(\alph_0) zorkmids on > lawyers defending yourself.... > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > > > > > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From sfouant at shortestpathfirst.com Thu Nov 5 18:46:40 2009 From: sfouant at shortestpathfirst.com (Stefan Fouant) Date: Thu, 5 Nov 2009 19:46:40 -0500 Subject: Pros and Cons of Cloud Computing in dealing with DDoS In-Reply-To: <55F6AEA5-1FCB-425D-AB1E-9F541C5D44F3@arbor.net> References: <002101ca5e42$bddeace0$399c06a0$@com> <16720fe00911051020m4327d713jfa0e1b4043adc23f@mail.gmail.com> <003101ca5e4b$cbe74550$63b5cff0$@com> <55F6AEA5-1FCB-425D-AB1E-9F541C5D44F3@arbor.net> Message-ID: <003801ca5e7a$9b5c9f00$d215dd00$@com> > -----Original Message----- > From: Roland Dobbins [mailto:rdobbins at arbor.net] > Sent: Thursday, November 05, 2009 4:35 PM > > On Nov 6, 2009, at 2:11 AM, Stefan Fouant wrote: > > > Obviously the cloud is no different than any other infrastructure > > insofar as > > implementing protection mechanisms. Ample bandwidth (typically more > > so than > > in the enterprise) should make it easier to absorb larger amounts of > > the bad > > stuff. > > Actually, no - the miscreants are always going to have more bandwidth > at their disposal, plus they utilize attack vectors which provide a > great deal of amplification (including at layer-7) which make > bandwidth largely irrelevant. So if I'm hearing you correctly, you're saying that no matter how much infrastructure you have to potentially absorb the problem, there is nothing you can do because the bad guys are always going to have more bandwidth at their disposal. Man, that's a pretty bad position to be in for a vendor who's fundamental premise is to sell boxes to deal with these sorts of problems. ;) I've built quite a few of these solutions now, and the designs usually entail having enough bandwidth and other resources at your disposal so as to be able to scrub the traffic with purpose-built mitigation equipment. I'd also like to point out that according to the 4th edition of Arbor's Worldwide Infrastructure Security Report, only about 1% of all attacks observed via ATLAS were in the 10+ Gbps range. So while there are certainly larger attacks exhibited in the wild, I'm pretty certain that most of the cloud providers today have at least enough bandwidth to deal with the other 99% of attacks, assuming they have the appropriate countermeasures in place to scrub the traffic. To your point however with regards to various attack vectors, I am in agreement that this doesn't provide any tangible benefit to those low-level attacks which require surgical mitigation to deal with. > > why they think DDoS is the single biggest threat to the cloud > > computing model, > > Availability is the one thing which *must* be guaranteed at all costs > in order for the cloud model to work, and by definition, most cloud > infrastructure isn't going to be within the span of control of the end- > customer. Look at all the apps/services we all use and depend upon > every day - Webmail, IM, various Web 2.0ish AJAXy things, Skype, SIP, > et al. When these things are DDoSed either deliberately or > inadvertently, directly or indirectly (i.e., zorching authoritative > DNS a la Baofeng), lots and lots of folks end up getting hosed. > > Now, expand this to your back-end line-of-business apps, your IP > PBXes, your customer databases, your ERP software, your CAM/CAM > system, your basic file/print services, and the picture becomes much > clearer. > > The movement towards 'cloud' - starting with things like VPS and VPDC > and SaaS for specific applications - largely consists of end-customer > organizations jettisoning their internal data centers/WAN links/ops > staff and subscribing to these apps/services on a recurring basis, > with said apps/services either residing within a public-facing IDC or > in a multitenanted IDC made available to the end-customer via an MPLS > NGN. It entails shutting down locally-/internally-owned-and-operated > DCs and moving into > > > again this is counter to a lot of evidence which points to the > > corollary > > Which evidence is that? [You meant 'contrary', yes?] Yep, brainfart. ;) > > - think DNS Root Servers and you'll have an idea what I'm talking > > about... > > There's a heck of a lot of engineering which has gone into protecting > the roots - I'm sure you'll recall the high-visibility DDoS attacks > which affected multiple roots in the past. The root operators learned > from that experience and took proactive measures to ensure that they > can continue to maintain availability in the face of constant > onslaughts. My point exactly - similar measures can and should be done to ensure that cloud computing models are similarly robust. > The bottom line is that it's easy to achieve perfect confidentiality > and integrity if availability is lacking, heh. All three legs of the > classical information security triad are of import, but it's always > been my view that availability is the first among equals, which > translates into the need for robust, scalable architecture and the > willingness to devote time and resources to the operational security > art. > > Paul's comment about botnets being 'cloud' services is dead-on; and of > course, miscreants using stolen credit-cards to purchase IaaS for > spamming/phishing purposes has already been seen in the wild, just as > they do so with their nonsense domains for botnet C&C. IaaS abused to > launch DDoS won't be far behind. This is really scary to think about... if we look at how Service Providers typically respond to hosts on their network behaving badly, it doesn't bode well for the Internet as a whole. Stefan Fouant GPG Key ID: 0xB5E3803D From smb at cs.columbia.edu Thu Nov 5 18:58:51 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 5 Nov 2009 19:58:51 -0500 Subject: Congress may require ISPs to block fraud sites H.R.3817 In-Reply-To: <4AF3716B.1040000@bennett.com> References: <4AF35449.8030700@inline.com> <23895.1257461806@turing-police.cc.vt.edu> <6EE2A54A-E255-471F-9D29-18237D19E991@cs.columbia.edu> <4AF3716B.1040000@bennett.com> Message-ID: On Nov 5, 2009, at 7:44 PM, Richard Bennett wrote: > I think the idea is for the government to create an official > blacklist of the offending sites, and for ISPs to consult it before > routing a packet to the fraud site. The common implementation would > be an ACL on the ISPs border router. The Congress doesn't yet > understand the distinction between ISPs and transit providers, of > course, and typically says that proposed ISP regulations (including > the net neutrality regulations) apply only to consumer-facing > service providers. > > If this measure passes, you can expect expansion of blocking > mandates for rogue sites of other kinds, such as kiddie porn and > DMCA scofflaws. > > It's worth looking at hhttp://www.cdt.org/speech/pennwebblock/ -- a Federal court struck down a law requiring web site blocking because of child pornography. --Steve Bellovin, http://www.cs.columbia.edu/~smb From owen at delong.com Thu Nov 5 19:08:29 2009 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Nov 2009 17:08:29 -0800 Subject: Human Factors and Accident reduction/mitigation In-Reply-To: <200911051630.07293.michael@linuxmagic.com> References: <200911051349.nA5DnljR007422@aurora.sol.net> <550BABDF-1A67-414D-8676-A875F16A93BF@delong.com> <1257462944_503118@mail1.tellurian.net> <200911051630.07293.michael@linuxmagic.com> Message-ID: On Nov 5, 2009, at 4:30 PM, Michael Peddemors wrote: > On November 5, 2009, Robert Boyle wrote: >> It's >> because someone circumvented the rules, >> processes, and cross checks put in place to >> prevent the problem in the first place. Nothing >> can be made idiot proof because idiots are so creative. >> >> -Robert >> SEL/MEL Private Instrument >> > > No, no commercial pilot every flew overweight, or in weather below > minimums, > or more that the max hours in a month.. never happens ;) And there > was never > a boss that 'pushed' them into it, for the sake of expediency or > financial > gain, and the phrase.. 'Big Sky, Little Plane' was nevered uttered.. > logbooks > never fudged and rules are always followed.. > > C(om)255379 > Of course, all of those things have happened. However, if we started treating networking errors more like the way we treat aviation errors, the reliability of networking would improve dramatically. OTOH, if we did that, the cost of networking would also probably gain a zero. Owen Commercial ASEL Instrument Airplane From richard at bennett.com Thu Nov 5 19:14:03 2009 From: richard at bennett.com (Richard Bennett) Date: Thu, 05 Nov 2009 17:14:03 -0800 Subject: Congress may require ISPs to block fraud sites H.R.3817 In-Reply-To: References: <4AF35449.8030700@inline.com> <23895.1257461806@turing-police.cc.vt.edu> <6EE2A54A-E255-471F-9D29-18237D19E991@cs.columbia.edu> <4AF3716B.1040000@bennett.com> Message-ID: <4AF3785B.4000508@bennett.com> IANAL, but I wouldn't set too much stock by that order - there are numerous errors of fact in the opinion, and much of it relates to the lack of due process in the maintenance of a secret blacklist. It was also a state law, not a federal one, so there was a large jurisdictional question (the Commerce Clause concern.) As people in Washington are saying around the net neutrality debate these days: "anything goes is not a serious argument." RB Steven Bellovin wrote: > > On Nov 5, 2009, at 7:44 PM, Richard Bennett wrote: > >> I think the idea is for the government to create an official >> blacklist of the offending sites, and for ISPs to consult it before >> routing a packet to the fraud site. The common implementation would >> be an ACL on the ISPs border router. The Congress doesn't yet >> understand the distinction between ISPs and transit providers, of >> course, and typically says that proposed ISP regulations (including >> the net neutrality regulations) apply only to consumer-facing service >> providers. >> >> If this measure passes, you can expect expansion of blocking mandates >> for rogue sites of other kinds, such as kiddie porn and DMCA scofflaws. >> >> > It's worth looking at hhttp://www.cdt.org/speech/pennwebblock/ -- a > Federal court struck down a law requiring web site blocking because of > child pornography. > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > > > > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From jeffrey.lyon at blacklotus.net Thu Nov 5 19:16:16 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 5 Nov 2009 20:16:16 -0500 Subject: Congress may require ISPs to block fraud sites H.R.3817 In-Reply-To: References: <4AF35449.8030700@inline.com> <23895.1257461806@turing-police.cc.vt.edu> <6EE2A54A-E255-471F-9D29-18237D19E991@cs.columbia.edu> <4AF3716B.1040000@bennett.com> Message-ID: <16720fe00911051716x10226c53o40d5466cb830a679@mail.gmail.com> Net neutrality suffers another blow. I liked Congress when they had no idea what the internet was, now they've progressed to "still have no idea but like to pretend." Jeff On Thu, Nov 5, 2009 at 7:58 PM, Steven Bellovin wrote: > > On Nov 5, 2009, at 7:44 PM, Richard Bennett wrote: > >> I think the idea is for the government to create an official blacklist of >> the offending sites, and for ISPs to consult it before routing a packet to >> the fraud site. The common implementation would be an ACL on the ISPs border >> router. The Congress doesn't yet understand the distinction between ISPs and >> transit providers, of course, and typically says that proposed ISP >> regulations (including the net neutrality regulations) apply only to >> consumer-facing service providers. >> >> If this measure passes, you can expect expansion of blocking mandates for >> rogue sites of other kinds, such as kiddie porn and DMCA scofflaws. >> >> > It's worth looking at hhttp://www.cdt.org/speech/pennwebblock/ -- a Federal > court struck down a law requiring web site blocking because of child > pornography. > > ? ? ? ? ? ? ? ?--Steve Bellovin, http://www.cs.columbia.edu/~smb > > > > > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From fergdawgster at gmail.com Thu Nov 5 19:25:31 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 5 Nov 2009 17:25:31 -0800 Subject: Pros and Cons of Cloud Computing in dealing with DDoS In-Reply-To: <003801ca5e7a$9b5c9f00$d215dd00$@com> References: <002101ca5e42$bddeace0$399c06a0$@com> <16720fe00911051020m4327d713jfa0e1b4043adc23f@mail.gmail.com> <003101ca5e4b$cbe74550$63b5cff0$@com> <55F6AEA5-1FCB-425D-AB1E-9F541C5D44F3@arbor.net> <003801ca5e7a$9b5c9f00$d215dd00$@com> Message-ID: <6cd462c00911051725w200e5480tb33e68cf377592df@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Nov 5, 2009 at 4:46 PM, Stefan Fouant wrote: >> >> Actually, no - the miscreants are always going to have more bandwidth >> at their disposal, plus they utilize attack vectors which provide a >> great deal of amplification (including at layer-7) which make >> bandwidth largely irrelevant. > > So if I'm hearing you correctly, you're saying that no matter how much > infrastructure you have to potentially absorb the problem, there is > nothing you can do because the bad guys are always going to have more > bandwidth at their disposal. Man, that's a pretty bad position to be in > for a vendor who's fundamental premise is to sell boxes to deal with > these sorts of > problems. ;) Well, the fact of the matter is that you can't put 10 lb. of [expletive] in a 5 lb. bag, so to speak. :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFK83sEq1pz9mNUZTMRAnvkAJ9XcDIi7XTE32nMtwJfwCflq6hcdgCfXmPT OkqNIuL8OH+BN6S4UxlfdSc= =kqaC -----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 sfouant at shortestpathfirst.com Thu Nov 5 19:35:17 2009 From: sfouant at shortestpathfirst.com (Stefan Fouant) Date: Thu, 5 Nov 2009 20:35:17 -0500 Subject: Pros and Cons of Cloud Computing in dealing with DDoS In-Reply-To: <6cd462c00911051725w200e5480tb33e68cf377592df@mail.gmail.com> References: <002101ca5e42$bddeace0$399c06a0$@com> <16720fe00911051020m4327d713jfa0e1b4043adc23f@mail.gmail.com> <003101ca5e4b$cbe74550$63b5cff0$@com> <55F6AEA5-1FCB-425D-AB1E-9F541C5D44F3@arbor.net> <003801ca5e7a$9b5c9f00$d215dd00$@com> <6cd462c00911051725w200e5480tb33e68cf377592df@mail.gmail.com> Message-ID: <003901ca5e81$65b9ada0$312d08e0$@com> > -----Original Message----- > From: Paul Ferguson [mailto:fergdawgster at gmail.com] > Sent: Thursday, November 05, 2009 8:26 PM > > On Thu, Nov 5, 2009 at 4:46 PM, Stefan Fouant > wrote: > > >> > >> Actually, no - the miscreants are always going to have more > bandwidth > >> at their disposal, plus they utilize attack vectors which provide a > >> great deal of amplification (including at layer-7) which make > >> bandwidth largely irrelevant. > > > > So if I'm hearing you correctly, you're saying that no matter how > much > > infrastructure you have to potentially absorb the problem, there is > > nothing you can do because the bad guys are always going to have more > > bandwidth at their disposal. Man, that's a pretty bad position to be > in > > for a vendor who's fundamental premise is to sell boxes to deal with > > these sorts of > > problems. ;) > > Well, the fact of the matter is that you can't put 10 lb. of > [expletive] > in a 5 lb. bag, so to speak. :-) Which is why vendors selling DDoS mitigation equipment will always tell you to get a 15lb. bag first. ;) Their solutions work, but only if you got a bag big enough to store a lot of crap. Stefan Fouant GPG Key ID: 0xB5E3803D From bzs at world.std.com Thu Nov 5 20:26:05 2009 From: bzs at world.std.com (Barry Shein) Date: Thu, 5 Nov 2009 21:26:05 -0500 Subject: Congress may require ISPs to block fraud sites H.R.3817 In-Reply-To: <200911060006.nA6066fO031090@drugs.dv.isc.org> References: <4AF35449.8030700@inline.com> <23895.1257461806@turing-police.cc.vt.edu> <200911060006.nA6066fO031090@drugs.dv.isc.org> Message-ID: <19187.35133.84926.826002@world.std.com> I was at an IP (as in intellectual property), um, "constituency" I think, IPC, meeting at ICANN which basically consisted of 99 lawyers and me in the room. There was a fair amount of grousing about how ISPs give them the run-around when they inform them of a violation looking for a takedown, and don't take down the site or whatever demanding (sneer sneer) paper from a court of competent jurisdiction as a dodge. I explained that they should try it from the other side, we get a fair amount of spurious stuff. I gave the example of a spouse in an ugly divorce demanding we do something or other with the web site they developed together in happier days IMMEDIATELY OR ELSE!!! (typically change the password to one only they know). How can we as ISPs possibly sort that out? Court orders are your friend, they're not that hard to get if you're legitimate. The way this reg is written it has that feel, it seems to promote the fantasy that if J. Random Voice calls me and says "a site you host, creepsrus.com, violates HR3817, YOU HAVE BEEN INFORMED!" then we have been informed and therefore culpable/liable. Well, perhaps there's enough precedent that it doesn't have to be spelled out in that text what's meant by "knowingly" and a call like that wouldn't be sufficient. At the very least I'd require a clear transfer of liability. That is, if the claim (and hence, takedown) turns out to be unsupportable then any damages etc are indemnified by the complaining ("informing") party. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From brunner at nic-naa.net Thu Nov 5 21:10:33 2009 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Thu, 05 Nov 2009 22:10:33 -0500 Subject: Congress may require ISPs to block fraud sites H.R.3817 In-Reply-To: <19187.35133.84926.826002@world.std.com> References: <4AF35449.8030700@inline.com> <23895.1257461806@turing-police.cc.vt.edu> <200911060006.nA6066fO031090@drugs.dv.isc.org> <19187.35133.84926.826002@world.std.com> Message-ID: <4AF393A9.8040207@nic-naa.net> Barry Shein wrote: > I was at an IP (as in intellectual property), um, "constituency" I > think, IPC, meeting at ICANN which basically consisted of 99 lawyers > and me in the room. > By the Montevideo ICANN meeting '01 the "Internet Service Providers Constituency" (ISPC) had dwindled down to the corporate trademarks portfolio managers for the few remaining ISPs. At the Paris ICANN meeting a year ago we corrolated the votes of the Intellectual Property, Business, and ISP Constituencies and found that there was no discernable independence amongst them, another way of sayins the IPC had captured the BC and ISPC. Of course, now we have GNSO reform, and "Stakeholder Groups" replacing the Constituencies. Bottom line. ISPs are f**ked by their own sonombulism. In a slightly different and partially overlapping policy and operational scope, the Address Supporting Organization originates no policy development of note, and has been somnolent for most of the ICANN trajectory, so BCP 38 and sBGP and so on have no real presence in the ICANN toolkit. So IP lawyers are doing pretty good in the oughts, and more time and bandwidth goes to retail cops and robbers than goes to any "critical infrastructure vulnerability", outside of ICANN's DNS mafia, post-Kaminsky. Any ISP that want's to spend some resources on operational issues, having some relevance to resource identifiers, feel free to drop me a line. I could just as well give process clue to Ops folk as ops clue to IP lawyers. > There was a fair amount of grousing about how ISPs give them the > run-around when they inform them of a violation looking for a > takedown, and don't take down the site or whatever demanding (sneer > sneer) paper from a court of competent jurisdiction as a dodge. > > I explained that they should try it from the other side, we get a fair > amount of spurious stuff. I gave the example of a spouse in an ugly > divorce demanding we do something or other with the web site they > developed together in happier days IMMEDIATELY OR ELSE!!! (typically > change the password to one only they know). > > How can we as ISPs possibly sort that out? Court orders are your > friend, they're not that hard to get if you're legitimate. > > The way this reg is written it has that feel, it seems to promote the > fantasy that if J. Random Voice calls me and says "a site you host, > creepsrus.com, violates HR3817, YOU HAVE BEEN INFORMED!" then we have > been informed and therefore culpable/liable. > > Well, perhaps there's enough precedent that it doesn't have to be > spelled out in that text what's meant by "knowingly" and a call like > that wouldn't be sufficient. > > At the very least I'd require a clear transfer of liability. > > That is, if the claim (and hence, takedown) turns out to be > unsupportable then any damages etc are indemnified by the complaining > ("informing") party. > > From rdobbins at arbor.net Thu Nov 5 21:29:15 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 6 Nov 2009 10:29:15 +0700 Subject: Pros and Cons of Cloud Computing in dealing with DDoS In-Reply-To: <003801ca5e7a$9b5c9f00$d215dd00$@com> References: <002101ca5e42$bddeace0$399c06a0$@com> <16720fe00911051020m4327d713jfa0e1b4043adc23f@mail.gmail.com> <003101ca5e4b$cbe74550$63b5cff0$@com> <55F6AEA5-1FCB-425D-AB1E-9F541C5D44F3@arbor.net> <003801ca5e7a$9b5c9f00$d215dd00$@com> Message-ID: On Nov 6, 2009, at 7:46 AM, Stefan Fouant wrote: > So if I'm hearing you correctly, you're saying that no matter how > much infrastructure you have to potentially absorb the problem, > there is nothing you can do because the bad guys are always going to > have more bandwidth at > their disposal. What I'm saying is that one can't simply rely on bandwidth capacity/ connection capacity/tps scaling/etc. on their own to always 'eat' the problem traffic; rather that there's a full spectrum of things one must do in order to be able to maintain availability in the face of attack, starting with fundamental architecture at layer-7 and moving down the model, taking special care to try and avoid design choices which lead to blocking behaviors and/or open up amplification vectors (some of these simply can't be avoided due to protocol semantics, of course). I'm also saying that threats to availability aren't something one can always assume one will be able to handle alone; engaging with the larger opsec community is key. ----------------------------------------------------------------------- Roland Dobbins // Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 From ras at e-gerbil.net Thu Nov 5 23:06:56 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Thu, 5 Nov 2009 23:06:56 -0600 Subject: Upstream BGP community support In-Reply-To: <20091105230418.GA12914@srv03.cluenet.de> References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> <4AEF341D.7050009@bogus.com> <4AEF3518.7050006@brightok.net> <20091102201338.GZ51443@gerbil.cluepon.net> <20091105230418.GA12914@srv03.cluenet.de> Message-ID: <20091106050655.GZ51443@gerbil.cluepon.net> On Fri, Nov 06, 2009 at 12:04:18AM +0100, Daniel Roesen wrote: > On Mon, Nov 02, 2009 at 02:13:38PM -0600, Richard A Steenbergen wrote: > > Rather than simply double the size and break it > > up into 32:32, the designers reserved the top 16 bits for "type" and > > "subtype" attributes, leaving you only 48 bits to work with. Clearly the > > only suitable mapping for support of 32-bit ASNs on the Internet is > > 32:16, leaving us with exactly the same range of "data" values that we > > have today. > > ... which breaks schemes such as > > 65123:45678 > > where 45678 is the neighboring AS to apply the action defined by > 65123 to. Seen those multiple times. > > Of course using anything else then your own ASN in the "AS part" of > TE communities is certainly debatable. Definitely a problem. The point of using 65123:45678 in the first place (with a private ASN field in the "AS part") is to avoid stepping on anyone else's ASN with your internal use community. Clearly we won't be able to continue implementing this pattern AND fully support 32 bit ASNs, so the type field is going to have to come to the rescue here. Fortunately there is a "transitive" bit on the extended community type that could be used to signal a behavior to your upstream network without allowing that community to leak any further, so in theory one could use something like that to do a "localtarget:45678:actiondata" tag without poluting the namespace. Uou would lose the ability to send a community to your "upstream's upstream", but that is probably of questionable legitimacy anyhow. But the way I read RFC5668 and the IANA extended community registry it doesn't look like there is an explicit definition of a non-transitive target type, and the way I read RFC4360 it doesn't look like the non-transitive value gets automatically reserved. So I guess someone will need to request 0x4002 and 0x4202 non-transitive target types for this purpose. Unless someone has a better idea of how to handle the problem stated above? -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From fweimer at bfk.de Fri Nov 6 02:18:08 2009 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 06 Nov 2009 08:18:08 +0000 Subject: Congress may require ISPs to block fraud sites H.R.3817 In-Reply-To: <16720fe00911051716x10226c53o40d5466cb830a679@mail.gmail.com> (Jeffrey Lyon's message of "Thu\, 5 Nov 2009 20\:16\:16 -0500") References: <4AF35449.8030700@inline.com> <23895.1257461806@turing-police.cc.vt.edu> <6EE2A54A-E255-471F-9D29-18237D19E991@cs.columbia.edu> <4AF3716B.1040000@bennett.com> <16720fe00911051716x10226c53o40d5466cb830a679@mail.gmail.com> Message-ID: <823a4soym7.fsf@mid.bfk.de> * Jeffrey Lyon: > Net neutrality suffers another blow. I liked Congress when they had no > idea what the internet was, now they've progressed to "still have no > idea but like to pretend." Our company is most likely not the owner of the site associated with this domain. Please do not contact us with inquiries regarding the web site content as they will likely be disregarded. If you keep playing such games, it's guaranteed that there will be some sort of backlash. -- 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 Fri Nov 6 03:52:19 2009 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 06 Nov 2009 09:52:19 +0000 Subject: Pros and Cons of Cloud Computing in dealing with DDoS In-Reply-To: <003101ca5e4b$cbe74550$63b5cff0$@com> (Stefan Fouant's message of "Thu\, 5 Nov 2009 14\:11\:35 -0500") References: <002101ca5e42$bddeace0$399c06a0$@com> <16720fe00911051020m4327d713jfa0e1b4043adc23f@mail.gmail.com> <003101ca5e4b$cbe74550$63b5cff0$@com> Message-ID: <82tyx8m14c.fsf@mid.bfk.de> * Stefan Fouant: > Obviously the cloud is no different than any other infrastructure insofar as > implementing protection mechanisms. It's different in one aspect, though: you don't know with whom you're sharing your toothbrush. To some extent, this is true for other infrastructure as well (even your dedicated Internet connectivity eventually joins shared infrastructure, which is precisely the point, of course). But virtualization makes those risks very difficult to estimate. Some companies have already suffered from this because they completely outsourced their authoritative DNS service to dedicated DNS service providers. Only very few customers of those providers were attacked, but the impact was felt across larger parts of their customer base. (The obvious thing to do is to use both external DNS and DNS on your network, so you stay up even if your external DNS goes down. I suppose a similar model could be used for many in-the-cloud services.) -- 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 Fri Nov 6 03:55:24 2009 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 06 Nov 2009 09:55:24 +0000 Subject: Pros and Cons of Cloud Computing in dealing with DDoS In-Reply-To: <003901ca5e81$65b9ada0$312d08e0$@com> (Stefan Fouant's message of "Thu\, 5 Nov 2009 20\:35\:17 -0500") References: <002101ca5e42$bddeace0$399c06a0$@com> <16720fe00911051020m4327d713jfa0e1b4043adc23f@mail.gmail.com> <003101ca5e4b$cbe74550$63b5cff0$@com> <55F6AEA5-1FCB-425D-AB1E-9F541C5D44F3@arbor.net> <003801ca5e7a$9b5c9f00$d215dd00$@com> <6cd462c00911051725w200e5480tb33e68cf377592df@mail.gmail.com> <003901ca5e81$65b9ada0$312d08e0$@com> Message-ID: <82pr7wm0z7.fsf@mid.bfk.de> * Stefan Fouant: > Which is why vendors selling DDoS mitigation equipment will always tell you > to get a 15lb. bag first. ;) Their solutions work, but only if you got a > bag big enough to store a lot of crap. Not all attacks involve saturated pipes. There used to be anti-DDoS vendors whose boxes didn't even have WAN links. Part of the problem is that operating systems come with TCP stacks and web servers which are not very robust, so it's pretty easy to create something which behaves spectacularly better under certain attacks. -- 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 lear at cisco.com Fri Nov 6 08:25:05 2009 From: lear at cisco.com (Eliot Lear) Date: Fri, 06 Nov 2009 15:25:05 +0100 Subject: Pros and Cons of Cloud Computing in dealing with DDoS In-Reply-To: <82tyx8m14c.fsf@mid.bfk.de> References: <002101ca5e42$bddeace0$399c06a0$@com> <16720fe00911051020m4327d713jfa0e1b4043adc23f@mail.gmail.com> <003101ca5e4b$cbe74550$63b5cff0$@com> <82tyx8m14c.fsf@mid.bfk.de> Message-ID: <4AF431C1.4050608@cisco.com> On 11/6/09 10:52 AM, Florian Weimer wrote: > * Stefan Fouant: > > >> Obviously the cloud is no different than any other infrastructure insofar as >> implementing protection mechanisms. >> > It's different in one aspect, though: you don't know with whom you're > sharing your toothbrush. > I love the analogy, though I feel the need to replace my toothbrush. I also think that clouds have a tendency to do usage based billing, and hence a DDOS can run your meter, which perhaps is where Stefan Fouant gets to the idea of EDOS. Eliot From dgolding at tier1research.com Fri Nov 6 08:58:35 2009 From: dgolding at tier1research.com (Dan Golding) Date: Fri, 6 Nov 2009 08:58:35 -0600 Subject: Congress may require ISPs to block fraud sites H.R.3817 In-Reply-To: <6EE2A54A-E255-471F-9D29-18237D19E991@cs.columbia.edu> References: <4AF35449.8030700@inline.com> <23895.1257461806@turing-police.cc.vt.edu> <6EE2A54A-E255-471F-9D29-18237D19E991@cs.columbia.edu> Message-ID: <5516225D-6B17-49AA-82C9-BD1492CB98D8@t1r.com> On Nov 5, 2009, at 7:24 PM, Steven Bellovin wrote: > > On Nov 5, 2009, at 5:56 PM, Valdis.Kletnieks at vt.edu wrote: > >> On Thu, 05 Nov 2009 16:40:09 CST, Bryan King said: >>> Did I miss a thread on this? Has anyone looked at this yet? >> >>> `(2) INTERNET SERVICE PROVIDERS- Any Internet service provider >>> that, on >>> or through a system or network controlled or operated by the >>> Internet >>> service provider, transmits, routes, provides connections for, or >>> stores >>> any material containing any misrepresentation of the kind >>> prohibited in >>> paragraph (1) shall be liable for any damages caused thereby, >>> including >>> damages suffered by SIPC, if the Internet service provider-- >> >> "routes" sounds the most dangerous part there. Does this mean that >> if >> we have a BGP peering session with somebody, we need to filter it? > > Also "transmits". (I'm impressed that someone in Congress knows the > word "routes"....) Don't get hung up on the wording. A DNS blackhole list will do the trick as well. I don't think border ACLs on routers will be necessary. - Daniel Golding From morrowc.lists at gmail.com Fri Nov 6 09:47:19 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 6 Nov 2009 10:47:19 -0500 Subject: Congress may require ISPs to block fraud sites H.R.3817 In-Reply-To: <23895.1257461806@turing-police.cc.vt.edu> References: <4AF35449.8030700@inline.com> <23895.1257461806@turing-police.cc.vt.edu> Message-ID: <75cb24520911060747x3556e01tbb80be8c9e0d58b3@mail.gmail.com> On Thu, Nov 5, 2009 at 5:56 PM, wrote: > On Thu, 05 Nov 2009 16:40:09 CST, Bryan King said: >> Did I miss a thread on this? Has anyone looked at this yet? > >> `(2) INTERNET SERVICE PROVIDERS- Any Internet service provider that, on >> or through a system or network controlled or operated by the Internet >> service provider, transmits, routes, provides connections for, or stores >> any material containing any misrepresentation of the kind prohibited in >> paragraph (1) shall be liable for any damages caused thereby, including >> damages suffered by SIPC, if the Internet service provider-- > > "routes" sounds the most dangerous part there. ?Does this mean that if > we have a BGP peering session with somebody, we need to filter it? > > Fortunately, there's the conditions: > >> `(A) has actual knowledge that the material contains a misrepresentation >> of the kind prohibited in paragraph (1), or > >> `(B) in the absence of actual knowledge, is aware of facts or >> circumstances from which it is apparent that the material contains a >> misrepresentation of the kind prohibited in paragraph (1), and > >> upon obtaining such knowledge or awareness, fails to act expeditiously >> to remove, or disable access to, the material. > > So the big players that just provide bandwidth to the smaller players are > mostly off the hook - AS701 has no reason to be aware that some website in > Tortuga is in violation (which raises an intresting point - what if the > site *is* offshore?) mail to: abuse at uu.net Subject: Fraud through your network Hi! someone in tortuga on ip address 1.2.3.4 which I accessed through your network is fraudulently claiming to be the state-bank-of-elbonia. Just though you should know! Also, I think that HR3817 expects you'll now stop this from happening! -concerned-internet-user oops, now they have actual knowledge... I suppose this is a good reason though to: vi /etc/aliases -> abuse: /dev/null so, is this bill helping? or hurting? :( > > And the immediate usptreams will fail to obtain knowledge or awareness of > their customer's actions, the same way they always have. > > Move along, nothing to see.. ;) to my mind this is the exact same set of problems that the PA state anti-CP law brought forth... -chris From dr at cluenet.de Fri Nov 6 09:50:10 2009 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 6 Nov 2009 16:50:10 +0100 Subject: Upstream BGP community support In-Reply-To: <20091106050655.GZ51443@gerbil.cluepon.net> References: <20091031220938.GE51443@gerbil.cluepon.net> <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> <4AEF341D.7050009@bogus.com> <4AEF3518.7050006@brightok.net> <20091102201338.GZ51443@gerbil.cluepon.net> <20091105230418.GA12914@srv03.cluenet.de> <20091106050655.GZ51443@gerbil.cluepon.net> Message-ID: <20091106155010.GA2866@srv03.cluenet.de> On Thu, Nov 05, 2009 at 11:06:56PM -0600, Richard A Steenbergen wrote: > Definitely a problem. The point of using 65123:45678 in the first place > (with a private ASN field in the "AS part") is to avoid stepping on > anyone else's ASN with your internal use community. Actually, as far as I have seen yet, it's more like being able to derrive/describe community from ASN-to-act-on, e.g. 61234 meaning "prepend 3 times" 45678 meaning "this is the neighbor AS I want this to be applied to" Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From morrowc.lists at gmail.com Fri Nov 6 09:51:48 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 6 Nov 2009 10:51:48 -0500 Subject: Congress may require ISPs to block fraud sites H.R.3817 In-Reply-To: <4AF3716B.1040000@bennett.com> References: <4AF35449.8030700@inline.com> <23895.1257461806@turing-police.cc.vt.edu> <6EE2A54A-E255-471F-9D29-18237D19E991@cs.columbia.edu> <4AF3716B.1040000@bennett.com> Message-ID: <75cb24520911060751r74419f9eodd6bdb2574aa0d17@mail.gmail.com> On Thu, Nov 5, 2009 at 7:44 PM, Richard Bennett wrote: > I think the idea is for the government to create an official blacklist of > the offending sites, and for ISPs to consult it before routing a packet to this works exceptionally unwell for the Singaporese(ian) govt'... (list of bad sites comes out monthly, montly+1min all sites change ips, weee!) > the fraud site. The common implementation would be an ACL on the ISPs border 'common implementation' isn't 'common' nor 'implementable' in many cases. > router. The Congress doesn't yet understand the distinction between ISPs and > transit providers, of course, and typically says that proposed ISP nor 'web hosting farm' ... (of course FastFlux puts a hole in the 'hosting' part of that) > regulations (including the net neutrality regulations) apply only to > consumer-facing service providers. > > If this measure passes, you can expect expansion of blocking mandates for > rogue sites of other kinds, such as kiddie porn and DMCA scofflaws. sure, been there, done that... German anti-nazi-propganda laws anyone? (or france or singapore or ...) -Chris (Note, I don't think that NO LAW is a good answer, but often the laws proposed or passed seem to misunderstand how the networks are run/build/maintained/used) > RB > > Steven Bellovin wrote: >> >> On Nov 5, 2009, at 5:56 PM, Valdis.Kletnieks at vt.edu wrote: >> >>> On Thu, 05 Nov 2009 16:40:09 CST, Bryan King said: >>>> >>>> Did I miss a thread on this? Has anyone looked at this yet? >>> >>>> `(2) INTERNET SERVICE PROVIDERS- Any Internet service provider that, on >>>> or through a system or network controlled or operated by the Internet >>>> service provider, transmits, routes, provides connections for, or stores >>>> any material containing any misrepresentation of the kind prohibited in >>>> paragraph (1) shall be liable for any damages caused thereby, including >>>> damages suffered by SIPC, if the Internet service provider-- >>> >>> "routes" sounds the most dangerous part there. ?Does this mean that if >>> we have a BGP peering session with somebody, we need to filter it? >> >> Also "transmits". ?(I'm impressed that someone in Congress knows the word >> "routes"....) >>> >>> Fortunately, there's the conditions: >>> >>>> `(A) has actual knowledge that the material contains a misrepresentation >>>> of the kind prohibited in paragraph (1), or >>> >>>> `(B) in the absence of actual knowledge, is aware of facts or >>>> circumstances from which it is apparent that the material contains a >>>> misrepresentation of the kind prohibited in paragraph (1), and >>> >>>> upon obtaining such knowledge or awareness, fails to act expeditiously >>>> to remove, or disable access to, the material. >>> >>> So the big players that just provide bandwidth to the smaller players are >>> mostly off the hook - AS701 has no reason to be aware that some website >>> in >>> Tortuga is in violation (which raises an intresting point - what if the >>> site *is* offshore?) >>> >>> And the immediate usptreams will fail to obtain knowledge or awareness of >>> their customer's actions, the same way they always have. >> >> Note the word "circumstances"... >>> >>> Move along, nothing to see.. ;) >> >> Until, of course, some Assistant U.S. Attorney or some attorney in a civil >> lawsuit decides you were or should have been aware and takes you to court. >> ?You may win, but after spending O(\alph_0) zorkmids on lawyers defending >> yourself.... >> >> >> ? ? ? ?--Steve Bellovin, http://www.cs.columbia.edu/~smb >> >> >> >> >> >> > > -- > Richard Bennett > Research Fellow > Information Technology and Innovation Foundation > Washington, DC > > > From Jonathan.Brashear at hq.speakeasy.net Fri Nov 6 09:52:09 2009 From: Jonathan.Brashear at hq.speakeasy.net (Jonathan Brashear) Date: Fri, 6 Nov 2009 07:52:09 -0800 Subject: Congress may require ISPs to block fraud sites H.R.3817 In-Reply-To: <75cb24520911060747x3556e01tbb80be8c9e0d58b3@mail.gmail.com> References: <4AF35449.8030700@inline.com> <23895.1257461806@turing-police.cc.vt.edu> <75cb24520911060747x3556e01tbb80be8c9e0d58b3@mail.gmail.com> Message-ID: <725755F5E728EE4086DAAF1A54DACF4F1A2F40DF96@sea5exbe1.speakeasy.hq> Correct me if I'm wrong, but isn't there an RFC(2142 if memory serves) that states filtering certain email addresses(like abuse@, noc@, support@) isn't allowed? I understand your point, but it seems sending it to /dev/null only opens another set of problems for you down the road. Network Engineer, JNCIS-M > 214-981-1954 (office) > 214-642-4075 (cell) > jbrashear at hq.speakeasy.net http://www.speakeasy.net -----Original Message----- From: Christopher Morrow [mailto:morrowc.lists at gmail.com] Sent: Friday, November 06, 2009 9:47 AM To: Valdis.Kletnieks at vt.edu Cc: nanog at nanog.org Subject: Re: Congress may require ISPs to block fraud sites H.R.3817 On Thu, Nov 5, 2009 at 5:56 PM, wrote: > On Thu, 05 Nov 2009 16:40:09 CST, Bryan King said: >> Did I miss a thread on this? Has anyone looked at this yet? > >> `(2) INTERNET SERVICE PROVIDERS- Any Internet service provider that, on >> or through a system or network controlled or operated by the Internet >> service provider, transmits, routes, provides connections for, or stores >> any material containing any misrepresentation of the kind prohibited in >> paragraph (1) shall be liable for any damages caused thereby, including >> damages suffered by SIPC, if the Internet service provider-- > > "routes" sounds the most dangerous part there. ?Does this mean that if > we have a BGP peering session with somebody, we need to filter it? > > Fortunately, there's the conditions: > >> `(A) has actual knowledge that the material contains a misrepresentation >> of the kind prohibited in paragraph (1), or > >> `(B) in the absence of actual knowledge, is aware of facts or >> circumstances from which it is apparent that the material contains a >> misrepresentation of the kind prohibited in paragraph (1), and > >> upon obtaining such knowledge or awareness, fails to act expeditiously >> to remove, or disable access to, the material. > > So the big players that just provide bandwidth to the smaller players are > mostly off the hook - AS701 has no reason to be aware that some website in > Tortuga is in violation (which raises an intresting point - what if the > site *is* offshore?) mail to: abuse at uu.net Subject: Fraud through your network Hi! someone in tortuga on ip address 1.2.3.4 which I accessed through your network is fraudulently claiming to be the state-bank-of-elbonia. Just though you should know! Also, I think that HR3817 expects you'll now stop this from happening! -concerned-internet-user oops, now they have actual knowledge... I suppose this is a good reason though to: vi /etc/aliases -> abuse: /dev/null so, is this bill helping? or hurting? :( > > And the immediate usptreams will fail to obtain knowledge or awareness of > their customer's actions, the same way they always have. > > Move along, nothing to see.. ;) to my mind this is the exact same set of problems that the PA state anti-CP law brought forth... -chris From morrowc.lists at gmail.com Fri Nov 6 09:56:07 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 6 Nov 2009 10:56:07 -0500 Subject: Congress may require ISPs to block fraud sites H.R.3817 In-Reply-To: <5516225D-6B17-49AA-82C9-BD1492CB98D8@t1r.com> References: <4AF35449.8030700@inline.com> <23895.1257461806@turing-police.cc.vt.edu> <6EE2A54A-E255-471F-9D29-18237D19E991@cs.columbia.edu> <5516225D-6B17-49AA-82C9-BD1492CB98D8@t1r.com> Message-ID: <75cb24520911060756j6139ea40r3a24f6e8e6d26b78@mail.gmail.com> On Fri, Nov 6, 2009 at 9:58 AM, Dan Golding wrote: > > Don't get hung up on the wording. A DNS blackhole list will do the > trick as well. I don't think border ACLs on routers will be necessary. do you use your ISP's dns servers? does your corporate vpn? From morrowc.lists at gmail.com Fri Nov 6 09:58:35 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 6 Nov 2009 10:58:35 -0500 Subject: Congress may require ISPs to block fraud sites H.R.3817 In-Reply-To: <725755F5E728EE4086DAAF1A54DACF4F1A2F40DF96@sea5exbe1.speakeasy.hq> References: <4AF35449.8030700@inline.com> <23895.1257461806@turing-police.cc.vt.edu> <75cb24520911060747x3556e01tbb80be8c9e0d58b3@mail.gmail.com> <725755F5E728EE4086DAAF1A54DACF4F1A2F40DF96@sea5exbe1.speakeasy.hq> Message-ID: <75cb24520911060758r775ca9eey300b6a8bd89a7e3e@mail.gmail.com> (top posting makes it hard to follow the conversation, but...) On Fri, Nov 6, 2009 at 10:52 AM, Jonathan Brashear wrote: > Correct me if I'm wrong, but isn't there an RFC(2142 if memory serves) that states filtering certain email addresses(like abuse@, noc@, support@) isn't allowed? ?I understand your point, but it seems sending it to /dev/null only opens another set of problems for you down the road. There are some 'nice to have' ideas that postmaster/abuse/root/webmaster ought to go somewhere and be seen. If the business decides that any tom/dick/harry/mary can 'inform' them of something such as this you can bet your aliases file that abuse@ will get turned down somewhere. I don't support that activity, but I also don't support this incarnation of the anti-X regulation either. -Chris > > Network Engineer, JNCIS-M >> 214-981-1954 (office) >> 214-642-4075 (cell) >> jbrashear at hq.speakeasy.net > http://www.speakeasy.net > -----Original Message----- > From: Christopher Morrow [mailto:morrowc.lists at gmail.com] > Sent: Friday, November 06, 2009 9:47 AM > To: Valdis.Kletnieks at vt.edu > Cc: nanog at nanog.org > Subject: Re: Congress may require ISPs to block fraud sites H.R.3817 > > On Thu, Nov 5, 2009 at 5:56 PM, ? wrote: >> On Thu, 05 Nov 2009 16:40:09 CST, Bryan King said: >>> Did I miss a thread on this? Has anyone looked at this yet? >> >>> `(2) INTERNET SERVICE PROVIDERS- Any Internet service provider that, on >>> or through a system or network controlled or operated by the Internet >>> service provider, transmits, routes, provides connections for, or stores >>> any material containing any misrepresentation of the kind prohibited in >>> paragraph (1) shall be liable for any damages caused thereby, including >>> damages suffered by SIPC, if the Internet service provider-- >> >> "routes" sounds the most dangerous part there. ?Does this mean that if >> we have a BGP peering session with somebody, we need to filter it? >> >> Fortunately, there's the conditions: >> >>> `(A) has actual knowledge that the material contains a misrepresentation >>> of the kind prohibited in paragraph (1), or >> >>> `(B) in the absence of actual knowledge, is aware of facts or >>> circumstances from which it is apparent that the material contains a >>> misrepresentation of the kind prohibited in paragraph (1), and >> >>> upon obtaining such knowledge or awareness, fails to act expeditiously >>> to remove, or disable access to, the material. >> >> So the big players that just provide bandwidth to the smaller players are >> mostly off the hook - AS701 has no reason to be aware that some website in >> Tortuga is in violation (which raises an intresting point - what if the >> site *is* offshore?) > > mail to: abuse at uu.net > Subject: Fraud through your network > > Hi! someone in tortuga on ip address 1.2.3.4 which I accessed through > your network is fraudulently claiming to be the state-bank-of-elbonia. > Just though you should know! Also, I think that HR3817 expects you'll > now stop this from happening! > > -concerned-internet-user > > oops, now they have actual knowledge... I suppose this is a good > reason though to: > > vi /etc/aliases -> > abuse: /dev/null > > so, is this bill helping? or hurting? :( > >> >> And the immediate usptreams will fail to obtain knowledge or awareness of >> their customer's actions, the same way they always have. >> >> Move along, nothing to see.. ;) > > to my mind this is the exact same set of problems that the PA state > anti-CP law brought forth... > > -chris > > > From sthaug at nethelp.no Fri Nov 6 10:07:11 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 06 Nov 2009 17:07:11 +0100 (CET) Subject: Congress may require ISPs to block fraud sites H.R.3817 In-Reply-To: <75cb24520911060756j6139ea40r3a24f6e8e6d26b78@mail.gmail.com> References: <6EE2A54A-E255-471F-9D29-18237D19E991@cs.columbia.edu> <5516225D-6B17-49AA-82C9-BD1492CB98D8@t1r.com> <75cb24520911060756j6139ea40r3a24f6e8e6d26b78@mail.gmail.com> Message-ID: <20091106.170711.112592750.sthaug@nethelp.no> > > Don't get hung up on the wording. A DNS blackhole list will do the > > trick as well. I don't think border ACLs on routers will be necessary. > > do you use your ISP's dns servers? does your corporate vpn? A DNS blackhole list makes it *appear* as if the government/police is doing something. "We must do something. This is something, therefore we must do it." This way of thinking is alive and well in the form of DNS based child porn blackhole lists in Norway and several other countries. The fact that anybody who is *really interested* can easily evade these lists, for instance by using his own DNS server, does not seem to concern politicians or police... Steinar Haug, Nethelp consulting, sthaug at nethelp.no From morrowc.lists at gmail.com Fri Nov 6 10:09:31 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 6 Nov 2009 11:09:31 -0500 Subject: Congress may require ISPs to block fraud sites H.R.3817 In-Reply-To: <20091106.170711.112592750.sthaug@nethelp.no> References: <6EE2A54A-E255-471F-9D29-18237D19E991@cs.columbia.edu> <5516225D-6B17-49AA-82C9-BD1492CB98D8@t1r.com> <75cb24520911060756j6139ea40r3a24f6e8e6d26b78@mail.gmail.com> <20091106.170711.112592750.sthaug@nethelp.no> Message-ID: <75cb24520911060809u6e14468ap169a016f3d5474ba@mail.gmail.com> On Fri, Nov 6, 2009 at 11:07 AM, wrote: >> > Don't get hung up on the wording. A DNS blackhole list will do the >> > trick as well. I don't think border ACLs on routers will be necessary. >> >> do you use your ISP's dns servers? does your corporate vpn? > > A DNS blackhole list makes it *appear* as if the government/police > is doing something. right, so now the site I go to MUST BE the real elbonia bank site, because... the gov't protected me! oops :( > "We must do something. This is something, therefore we must do it." ah, the 'make work' plan :( > This way of thinking is alive and well in the form of DNS based child > porn blackhole lists in Norway and several other countries. The fact > that anybody who is *really interested* can easily evade these lists, > for instance by using his own DNS server, does not seem to concern > politicians or police... yes, though in the case of CP the properties of the user are reversed (in my mind at least)... 'searching out content' versus stumbling upon content. -Chris From noc.akrino at gmail.com Fri Nov 6 12:20:47 2009 From: noc.akrino at gmail.com (noc acrino) Date: Fri, 6 Nov 2009 21:20:47 +0300 Subject: Interesting Point of view - Russian police and RIPE accused of aiding RBN Message-ID: <3d8c027f0911061020g1dff43cfpc9e505602d8c0dcd@mail.gmail.com> Greetings! Let me introduce myself - I as a part of a support team represent NOC Akrino, the team responsible of the technical use of AKRINO Networks, AS44571 (91.202.61.0/21). It's a service network for DDoS-mitigation purposes, using a combination of hardware and self-developed software which allow us to efficiently filter mostly any kind of malicious traffic providing the white traffic to the client's server. Among our clients there are some e-businesses, e-shops, e-mass media, etc. with critical losses in case of possible DDoS-attacks. I'd apply in case it's necessary, the recommendations of our foreign resellers. Anyway we have never declared ourselves as an abuse-resistant service provider - every abuse sent to service email "noc.akrino at gmail.com" is being investigated and responded: we can block the exact URLS or even block completely the traffic redirection to the client in case of his abusive network behavior. We're completely shocked by the declaration that the RBN moved to our AS. We have no affiliation to RBN, the personal data is hidden and can be provided by request just because of our members' personal security - in rare cases we even had those risks (just because our filtration works cyber criminals often search for other ways of influence upon us, including coercion). In fact there are some problem clients like some adult sites whose advertising programs could be popular with the spammers, but our policy demands normal network behavior and in case of the abuse - their advert partner is blocked. So, if you have any evidence of abusive network behavior of our clients you should send it directly to noc.akrino at gmail.com and we'll respond. If there were any unsolved cases - we'll close them. Please, excuse us if in somehow Akrino Networks were the source of problems for you - we'll do our best to prevent it in the future. And I'll sincerely ask *Jeffrey Lyon *as a representative of Blacklotus team to clarify his accusations: aren't they connected with the fact that many of your DDoS-protected clients have chosen our reseller Blockdos (blockdos.net) just because our pricing doesn't depend on the amount of attack? As far as I understand it's a question of about $20k/month. Please, tell me if I'm not right. Thank you. Kanak Akrino Abuse Team From cscora at apnic.net Fri Nov 6 12:32:04 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 7 Nov 2009 04:32:04 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200911061832.nA6IW4II006231@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 07 Nov, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 301614 Prefixes after maximum aggregation: 141503 Deaggregation factor: 2.13 Unique aggregates announced to Internet: 149533 Total ASes present in the Internet Routing Table: 32604 Prefixes per ASN: 9.25 Origin-only ASes present in the Internet Routing Table: 28347 Origin ASes announcing only one prefix: 13795 Transit ASes present in the Internet Routing Table: 4257 Transit-only ASes present in the Internet Routing Table: 102 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 30 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 620 Unregistered ASNs in the Routing Table: 126 Number of 32-bit ASNs allocated by the RIRs: 312 Prefixes from 32-bit ASNs in the Routing Table: 256 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 202 Number of addresses announced to Internet: 2132041952 Equivalent to 127 /8s, 20 /16s and 96 /24s Percentage of available address space announced: 57.5 Percentage of allocated address space announced: 65.2 Percentage of available address space allocated: 88.2 Percentage of address space in use by end-sites: 79.8 Total number of prefixes smaller than registry allocations: 144805 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 72077 Total APNIC prefixes after maximum aggregation: 25252 APNIC Deaggregation factor: 2.85 Prefixes being announced from the APNIC address blocks: 68602 Unique aggregates announced from the APNIC address blocks: 30421 APNIC Region origin ASes present in the Internet Routing Table: 3847 APNIC Prefixes per ASN: 17.83 APNIC Region origin ASes announcing only one prefix: 1043 APNIC Region transit ASes present in the Internet Routing Table: 587 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 14 Number of APNIC addresses announced to Internet: 470541600 Equivalent to 28 /8s, 11 /16s and 229 /24s Percentage of available APNIC address space announced: 80.1 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 43/8, 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, 175/8, 180/8, 182/8, 183/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: 127441 Total ARIN prefixes after maximum aggregation: 67221 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 101848 Unique aggregates announced from the ARIN address blocks: 38884 ARIN Region origin ASes present in the Internet Routing Table: 13330 ARIN Prefixes per ASN: 7.64 ARIN Region origin ASes announcing only one prefix: 5159 ARIN Region transit ASes present in the Internet Routing Table: 1314 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 714201088 Equivalent to 42 /8s, 145 /16s and 216 /24s Percentage of available ARIN address space announced: 62.6 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 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/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, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 69537 Total RIPE prefixes after maximum aggregation: 40772 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 62836 Unique aggregates announced from the RIPE address blocks: 42111 RIPE Region origin ASes present in the Internet Routing Table: 13706 RIPE Prefixes per ASN: 4.58 RIPE Region origin ASes announcing only one prefix: 7114 RIPE Region transit ASes present in the Internet Routing Table: 2051 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 20 Number of RIPE addresses announced to Internet: 403252160 Equivalent to 24 /8s, 9 /16s and 35 /24s Percentage of available RIPE address space announced: 75.1 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-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 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, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 26058 Total LACNIC prefixes after maximum aggregation: 6385 LACNIC Deaggregation factor: 4.08 Prefixes being announced from the LACNIC address blocks: 24373 Unique aggregates announced from the LACNIC address blocks: 13436 LACNIC Region origin ASes present in the Internet Routing Table: 1202 LACNIC Prefixes per ASN: 20.28 LACNIC Region origin ASes announcing only one prefix: 382 LACNIC Region transit ASes present in the Internet Routing Table: 200 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 30 Number of LACNIC addresses announced to Internet: 68123136 Equivalent to 4 /8s, 15 /16s and 122 /24s Percentage of available LACNIC address space announced: 67.7 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 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: 6017 Total AfriNIC prefixes after maximum aggregation: 1577 AfriNIC Deaggregation factor: 3.82 Prefixes being announced from the AfriNIC address blocks: 4374 Unique aggregates announced from the AfriNIC address blocks: 1588 AfriNIC Region origin ASes present in the Internet Routing Table: 330 AfriNIC Prefixes per ASN: 13.25 AfriNIC Region origin ASes announcing only one prefix: 97 AfriNIC Region transit ASes present in the Internet Routing Table: 66 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 16 Number of AfriNIC addresses announced to Internet: 12886016 Equivalent to 0 /8s, 196 /16s and 160 /24s Percentage of available AfriNIC address space announced: 38.4 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1771 7505 456 Korea Telecom (KIX) 17488 1360 140 125 Hathway IP Over Cable Interne 4755 1271 293 147 TATA Communications formerly 9583 1096 86 530 Sify Limited 4134 1010 19185 393 CHINANET-BACKBONE 18101 975 204 33 Reliance Infocom Ltd Internet 7545 901 198 99 TPG Internet Pty Ltd 9829 852 664 24 BSNL National Internet Backbo 17974 822 252 104 PT TELEKOMUNIKASI INDONESIA 24560 793 291 171 Bharti Airtel Ltd., Telemedia 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 4262 3883 313 bellsouth.net, inc. 4323 3723 1054 399 Time Warner Telecom 1785 1785 715 140 PaeTec Communications, Inc. 7018 1572 5837 1042 AT&T WorldNet Services 20115 1486 1481 669 Charter Communications 6478 1321 270 433 AT&T Worldnet Services 2386 1304 638 942 AT&T Data Communications Serv 3356 1219 10964 440 Level 3 Communications, LLC 11492 1137 206 13 Cable One 22773 1101 2600 66 Cox Communications, Inc. 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 30890 515 98 209 Evolva Telecom 3292 448 1906 393 TDC Tele Danmark 702 415 1822 334 UUNET - Commercial IP service 9198 397 138 12 Kazakhtelecom Data Network Ad 35805 384 40 5 United Telecom of Georgia 8866 364 110 23 Bulgarian Telecommunication C 3320 354 7067 302 Deutsche Telekom AG 3215 349 3144 111 France Telecom Transpac 3301 348 1412 305 TeliaNet Sweden 9121 319 1698 26 TTnet Autonomous System 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 1556 2898 236 UniNet S.A. de C.V. 10620 1032 228 102 TVCABLE BOGOTA 28573 797 661 90 NET Servicos de Comunicao S.A 7303 661 349 97 Telecom Argentina Stet-France 22047 546 302 14 VTR PUNTO NET S.A. 11830 475 310 61 Instituto Costarricense de El 11172 444 99 70 Servicios Alestra S.A de C.V 14117 437 29 11 Telefonica del Sur S.A. 7738 430 858 29 Telecomunicacoes da Bahia S.A 6471 422 96 31 ENTEL CHILE 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 8452 949 188 7 TEDATA 24863 940 98 71 LINKdotNET AS number 3741 274 857 234 The Internet Solution 2018 194 188 117 Tertiary Education Network 6713 176 167 12 Itissalat Al-MAGHRIB 29571 145 15 8 Ci Telecom Autonomous system 33776 124 7 11 Starcomms Nigeria Limited 5536 122 8 13 Internet Egypt Network 5713 116 508 67 Telkom SA Ltd 20858 109 34 6 EgyNet 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 4262 3883 313 bellsouth.net, inc. 4323 3723 1054 399 Time Warner Telecom 1785 1785 715 140 PaeTec Communications, Inc. 4766 1771 7505 456 Korea Telecom (KIX) 7018 1572 5837 1042 AT&T WorldNet Services 8151 1556 2898 236 UniNet S.A. de C.V. 20115 1486 1481 669 Charter Communications 17488 1360 140 125 Hathway IP Over Cable Interne 6478 1321 270 433 AT&T Worldnet Services 2386 1304 638 942 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3723 3324 Time Warner Telecom 1785 1785 1645 PaeTec Communications, Inc. 8151 1556 1320 UniNet S.A. de C.V. 4766 1771 1315 Korea Telecom (KIX) 17488 1360 1235 Hathway IP Over Cable Interne 4755 1271 1124 TATA Communications formerly 11492 1137 1124 Cable One 18566 1062 1052 Covad Communications 22773 1101 1035 Cox Communications, Inc. 18101 975 942 Reliance Infocom Ltd Internet 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 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.64.0.0/15 15475 Nile Online 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 46.0.0.0/16 12654 RIPE NCC RIS Project 46.1.0.0/21 12654 RIPE NCC RIS Project 46.1.24.0/24 12654 RIPE NCC RIS Project 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:10 /10:25 /11:65 /12:177 /13:360 /14:639 /15:1217 /16:10738 /17:4943 /18:8503 /19:17557 /20:21191 /21:21157 /22:27429 /23:27278 /24:157443 /25:945 /26:1125 /27:563 /28:203 /29:10 /30:8 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2788 4262 bellsouth.net, inc. 4323 2351 3723 Time Warner Telecom 4766 1436 1771 Korea Telecom (KIX) 1785 1249 1785 PaeTec Communications, Inc. 17488 1136 1360 Hathway IP Over Cable Interne 11492 1061 1137 Cable One 18566 1043 1062 Covad Communications 9583 948 1096 Sify Limited 7018 944 1572 AT&T WorldNet Services 10620 937 1032 TVCABLE BOGOTA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 2:1 4:14 8:232 12:2137 13:7 15:22 16:3 17:5 20:36 24:1242 32:49 34:2 38:609 40:99 41:1737 43:1 44:2 46:1 47:21 52:6 55:2 56:2 57:23 58:622 59:611 60:443 61:987 62:966 63:1998 64:3669 65:2367 66:4088 67:1769 68:991 69:2781 70:590 71:153 72:1730 73:2 74:1981 75:184 76:362 77:859 78:581 79:376 80:939 81:818 82:480 83:440 84:542 85:1011 86:375 87:695 88:425 89:1499 90:52 91:2635 92:420 93:1180 94:1269 95:810 96:191 97:273 98:386 99:30 109:114 110:267 111:454 112:145 113:162 114:282 115:420 116:1005 117:589 118:346 119:786 120:127 121:702 122:1301 123:782 124:1054 125:1347 128:221 129:218 130:130 131:426 132:76 133:16 134:186 135:43 136:232 137:167 138:179 139:83 140:439 141:122 142:391 143:348 144:360 145:50 146:393 147:170 148:553 149:200 150:150 151:172 152:212 153:159 154:2 155:273 156:168 157:308 158:93 159:358 160:293 161:173 162:279 163:157 164:278 165:466 166:487 167:392 168:750 169:162 170:552 171:42 172:1 173:387 174:390 175:1 178:1 180:166 182:1 184:1 186:157 187:187 188:1259 189:622 190:3188 192:5746 193:4269 194:3321 195:2756 196:1167 198:3567 199:3356 200:5182 201:1351 202:7883 203:8231 204:3929 205:2144 206:2403 207:2998 208:3980 209:3428 210:2541 211:1145 212:1646 213:1629 214:164 215:39 216:4427 217:1335 218:471 219:436 220:1138 221:452 222:303 End of report From jeffrey.lyon at blacklotus.net Fri Nov 6 13:01:51 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 6 Nov 2009 14:01:51 -0500 Subject: Interesting Point of view - Russian police and RIPE accused of aiding RBN In-Reply-To: <3d8c027f0911061020g1dff43cfpc9e505602d8c0dcd@mail.gmail.com> References: <3d8c027f0911061020g1dff43cfpc9e505602d8c0dcd@mail.gmail.com> Message-ID: <16720fe00911061101o338189beu3ef96022a4d5c479@mail.gmail.com> Kanak, It's good to see you here. The primary issue is that we receive a fair deal of customers who end up with wide scale DDoS attacks followed by an offer for "protection" to move to your network. In almost every case the attacks cease once the customer has agreed to pay this "protection" fee. Every one of these attacks was nearly identical in signature. A couple of years back we followed up on this and a handful of trusted security analysts who focus on RBN alleged that Akrino was an RBN shill network thus prompting the spawn of this article: http://www.computerworld.com/s/article/9063418/Russian_hosting_network_running_a_protection_racket_researcher_says . Since first seeing your network arise in early 2008 i've never actually seen anyone claim to own it and a Google search for your name and ASN were completely devoid of any useful information. The ASN and IP assignment are registered to a BVI offshore corporation that based on my research do not seem to correlate to any legitimate commercial activity. All of these things seem to support the Computerworld article. I would love to be proven wrong on this issue as I do not like to see a good net op ostracized without just cause. Perhaps your reseller(s) are giving you a bad name? Either way I would love to chat, feel free to Skype: blacklotus.net . Best regards, Jeff On Fri, Nov 6, 2009 at 1:20 PM, noc acrino wrote: > Greetings! > > Let me introduce myself - I as a part of a support team represent NOC > Akrino, the team responsible of the technical use of AKRINO Networks, > AS44571 (91.202.61.0/21). It's a service network for DDoS-mitigation > purposes, using a combination of hardware and self-developed software which > allow us to efficiently filter mostly any kind of malicious traffic > providing the white traffic to the client's server. Among our clients there > are some e-businesses, e-shops, e-mass media, etc. with critical losses in > case of possible DDoS-attacks. I'd apply in case it's necessary, the > recommendations of our foreign resellers. Anyway we have never declared > ourselves as an abuse-resistant service provider - every abuse sent to > service email "noc.akrino at gmail.com" is being investigated and responded: we > can block the exact URLS or even block completely the traffic redirection to > the client in case of his abusive network behavior. > > We're completely shocked by the declaration that the RBN moved to our AS. We > have no affiliation to RBN, the personal data is hidden and can be provided > by request just because of our members' personal security - in rare cases we > even had those risks (just because our filtration works cyber criminals > often search for other ways of influence upon us, including coercion). > > In fact there are some problem clients like some adult sites whose > advertising programs could be popular with the spammers, but our policy > demands normal network behavior and in case of the abuse - their advert > partner is blocked. > > So, if you have any evidence of abusive network behavior of our clients you > should send it directly to noc.akrino at gmail.com and we'll respond. If there > were any unsolved cases - we'll close them. > > Please, excuse us if in somehow Akrino Networks were the source of problems > for you - we'll do our best to prevent it in the future. > > And I'll sincerely ask *Jeffrey Lyon *as a representative of Blacklotus team > to clarify his accusations: aren't they connected with the fact that many of > your DDoS-protected clients have chosen our reseller Blockdos (blockdos.net) > just because our pricing doesn't depend on the amount of attack? As far as I > understand it's a question of about $20k/month. Please, tell me if I'm not > right. > > Thank you. > > Kanak > > Akrino Abuse Team > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From jcdill.lists at gmail.com Fri Nov 6 14:04:45 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Fri, 06 Nov 2009 12:04:45 -0800 Subject: Human Factors and Accident reduction/mitigation In-Reply-To: <550BABDF-1A67-414D-8676-A875F16A93BF@delong.com> References: <200911051349.nA5DnljR007422@aurora.sol.net> <550BABDF-1A67-414D-8676-A875F16A93BF@delong.com> Message-ID: <4AF4815D.9070709@gmail.com> Owen DeLong wrote: > > We could learn a lot about this from Aviation. Nowhere in human > history has > more research, care, training, and discipline been applied to accident > prevention, > mitigation, and analysis as in aviation. A few examples: > > NTSB investigations of EVERY US aircraft accident and published > findings. Ask any commercial pilot (and especially a commercial commuter flight pilot) what they think of NTSB investigations when the pilot had a "bad schedule" that doesn't allow enough time for adequate sleep. They will point out that lack of sleep can't be determined in an autopsy. The NTSB routinely puts an accident down to "pilot error" even when pilots who regularly fly those routes and shifts are convinced that exhaustion (lack of sleep, long working days) was clearly involved. And for even worse news - the smaller the plane the more complicated it is to fly and the LESS rest the pilots receive in their overnight stays because commuter airlines are covered under part 135 while major airlines are covered under part 121. My ex flew turbo-prop planes for American Eagle (American Airlines commuter flights). It was common to have the pilot get off duty near 10 pm and be requited to report back at 6 am. That's just 8 hours for rest. The "rest period" starts with a wait for a shuttle to the hotel, then the drive to the hotel (often 15 minutes or more from the airport) then check-in - it can add up to 30-45 minutes before the pilot is actually inside a hotel room. These overnight stays are in smaller towns like Santa Rosa, Fresno, Bakersfield, etc. Usually the pilots are put up at hotels that don't have a restaurant open this late, and no neighboring restaurants (even fast food) so the pilot doesn't get dinner. (There is no time for dinner in the flight schedule - they get at most 20 minutes of free time between arrival and take-off - enough time to get a bio-break and hit a vending machine but not enough time to actually get a meal.) Take a shower, get to bed at about 11:30. Set the alarm for 4:45 am and catch the shuttle back to the airport at 5:15 to get there before the 6:00 reporting time. In that "8 hour" rest period you get less than 6 hours of sleep - if you can fall asleep easily in a strange hotel. Commuter route pilots have been fighting to get regulations changed to require longer overnight periods, and especially to get the required rest period changed to "behind the door" so that the airlines can't include the commute time to/from the airport in the "rest" period. This would force the airlines to select hotels closer to the airport or else allow longer overnight layovers - either way the pilots would get adequate rest. See: http://asrs.arc.nasa.gov/publications/directline/dl5_one.htm The NTSB does a great job with mechanical issues and with training issues, but they totally miss the boat when it comes to regulating adequate rest periods in the airline schedules. To bring this back to NANOG territory, how many times have you or one of your network admins made a mistake when working with inadequate sleep - due to extra early start hours (needless 8 am meetings), or working long/late hours, or being called to work in the middle of the night? Finally, having lived with a commercial aviation pilot for 5 years and having worked with network types for much longer, I can say that while there is some overlap between pilots and IT techs, there are also a LOT of people who go into computers (programming, network and system administration) who are totally unsuitable for the regimented environment required for commercial aviation - people who HATE following a lot of rules and regulations and fixed schedules. If you tried to impose FAA-type rules and regulations and airline schedules on an IT organization, you would have a revolt on your hands. Tread carefully when you consider to emulating Aviation. jc From ras at e-gerbil.net Fri Nov 6 14:34:45 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Fri, 6 Nov 2009 14:34:45 -0600 Subject: Upstream BGP community support In-Reply-To: <20091106155010.GA2866@srv03.cluenet.de> References: <75cb24520910311612hf5cd2e1y647ee9d35eccdab9@mail.gmail.com> <4AEF341D.7050009@bogus.com> <4AEF3518.7050006@brightok.net> <20091102201338.GZ51443@gerbil.cluepon.net> <20091105230418.GA12914@srv03.cluenet.de> <20091106050655.GZ51443@gerbil.cluepon.net> <20091106155010.GA2866@srv03.cluenet.de> Message-ID: <20091106203445.GN51443@gerbil.cluepon.net> On Fri, Nov 06, 2009 at 04:50:10PM +0100, Daniel Roesen wrote: > On Thu, Nov 05, 2009 at 11:06:56PM -0600, Richard A Steenbergen wrote: > > Definitely a problem. The point of using 65123:45678 in the first place > > (with a private ASN field in the "AS part") is to avoid stepping on > > anyone else's ASN with your internal use community. > > Actually, as far as I have seen yet, it's more like being able to > derrive/describe community from ASN-to-act-on, e.g. > > 61234 meaning "prepend 3 times" > 45678 meaning "this is the neighbor AS I want this to be applied to" No I'm not saying otherwise. My point was that the reason it is "65123:45678" instead of "45678:65123" is that they're using a value from the private ASN range for the "action" tag, thus eliminating the potential for collisions with anyone else's real ASNs. As you pointed out, the ASN and Data fields are no longer going to be the same bit size, so the "flipping the fields" trick will no longer work. The only solution will be to add a non-transitive target type and do "localtarget:45678:65123". -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From cidr-report at potaroo.net Fri Nov 6 16:00:03 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 6 Nov 2009 22:00:03 GMT Subject: BGP Update Report Message-ID: <200911062200.nA6M03g3045562@wattle.apnic.net> BGP Update Report Interval: 29-Oct-09 -to- 05-Nov-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 34630 2.2% 40.8 -- BSNL-NIB National Internet Backbone 2 - AS9706 33034 2.1% 4129.2 -- PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 3 - AS8452 21516 1.4% 20.5 -- TEDATA TEDATA 4 - AS35805 21363 1.4% 43.6 -- UTG-AS United Telecom AS 5 - AS23700 16405 1.0% 45.2 -- BM-AS-ID PT. Broadband Multimedia, Tbk 6 - AS6298 13338 0.8% 18.0 -- ASN-CXA-PH-6298-CBS - Cox Communications Inc. 7 - AS4323 11345 0.7% 2.6 -- TWTC - tw telecom holdings, inc. 8 - AS9198 8208 0.5% 20.2 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - AS24863 7754 0.5% 7.0 -- LINKdotNET-AS 10 - AS6389 7751 0.5% 1.9 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 11 - AS4795 7591 0.5% 30.6 -- INDOSATM2-ID INDOSATM2 ASN 12 - AS8151 7368 0.5% 4.7 -- Uninet S.A. de C.V. 13 - AS17488 7296 0.5% 4.9 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 14 - AS41661 6870 0.4% 208.2 -- ERTH-CHEL-AS CJSC "Company "ER-Telecom" Chelyabinsk 15 - AS14420 6446 0.4% 18.6 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 16 - AS3464 6217 0.4% 16.2 -- ASC-NET - Alabama Supercomputer Network 17 - AS747 6132 0.4% 62.6 -- TAEGU-AS - Headquarters, USAISC 18 - AS20115 5523 0.3% 3.7 -- CHARTER-NET-HKY-NC - Charter Communications 19 - AS22773 5450 0.3% 4.9 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 20 - AS30890 5436 0.3% 10.5 -- EVOLVA Evolva Telecom s.r.l. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9706 33034 2.1% 4129.2 -- PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 2 - AS48754 3939 0.2% 3939.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 3 - AS36239 2247 0.1% 2247.0 -- EXIGEN-CANADA - Exigen Canada 4 - AS27667 1175 0.1% 1175.0 -- Universidad Autonoma de la Laguna 5 - AS49645 430 0.0% 430.0 -- SOFT-EXPERT-AS SC Soft Expert SRL 6 - AS15936 403 0.0% 403.0 -- UTN Ukrtrans Network LLC 7 - AS16616 777 0.1% 388.5 -- CTS-07003 - Crown Travel Service Inc. 8 - AS9857 3605 0.2% 360.5 -- KOGAS-AS-KR KOREA GAS CORPORATION 9 - AS47817 360 0.0% 360.0 -- PSRGD-AS Bank Pasargad 10 - AS48922 347 0.0% 347.0 -- ZKTECH ZK Technologie S.A. 11 - AS3 343 0.0% 143.0 -- ELKATV ELEKTRONIKA - KATV d.o.o. 12 - AS39803 678 0.0% 339.0 -- UTI-AS SC UTI COMMUNICATIONS SYSTEMS SRL 13 - AS48309 653 0.0% 326.5 -- AGS-AS Ariana Gostar Spadana Autonomous Number 14 - AS49680 308 0.0% 308.0 -- DCI Armaghan Rahe Talaie 15 - AS4050 296 0.0% 296.0 -- OMNINET-PRI-AS - Omninet Communications Services 16 - AS48431 288 0.0% 288.0 -- MAXNET MAXNET Autonomous System 17 - AS8668 2015 0.1% 287.9 -- TELONE-AS TelOne Zimbabwe P/L 18 - AS48434 281 0.0% 281.0 -- TEBYAN Tebyan Cultural and Informative Institute 19 - AS44208 281 0.0% 281.0 -- FARAHOOSH Farahoosh Dena 20 - AS27817 3902 0.2% 278.7 -- Red Nacional Acad?mica de Tecnolog?a Avanzada - RENATA TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 211.43.64.0/21 4131 0.2% AS9706 -- PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 2 - 211.182.0.0/16 4129 0.2% AS9706 -- PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 3 - 211.43.32.0/19 4129 0.2% AS9706 -- PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 4 - 211.43.29.0/24 4129 0.2% AS9706 -- PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 5 - 211.43.72.0/22 4129 0.2% AS9706 -- PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 6 - 210.180.192.0/19 4129 0.2% AS9706 -- PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 7 - 210.180.128.0/18 4129 0.2% AS9706 -- PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 8 - 211.43.30.0/23 4129 0.2% AS9706 -- PETISNET-AS BUSAN EDUCATION RESEARCH & INFORMATION CENTER 9 - 91.212.23.0/24 3939 0.2% AS48754 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 10 - 143.138.107.0/24 3899 0.2% AS747 -- TAEGU-AS - Headquarters, USAISC 11 - 200.21.217.0/24 3848 0.2% AS27817 -- Red Nacional Acad?mica de Tecnolog?a Avanzada - RENATA 12 - 113.11.156.0/24 3253 0.2% AS17658 -- PRIMANET-AS PrimaNet - PT. Khasanah Timur Indonesia 13 - 203.11.114.0/24 2987 0.2% AS9822 -- AMNET-AU-AP Amnet IT Services Pty Ltd 14 - 192.12.120.0/24 2712 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 15 - 72.28.75.0/24 2247 0.1% AS36239 -- EXIGEN-CANADA - Exigen Canada 16 - 92.255.241.0/24 1817 0.1% AS41661 -- ERTH-CHEL-AS CJSC "Company "ER-Telecom" Chelyabinsk 17 - 202.167.227.0/24 1790 0.1% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 18 - 41.235.82.0/24 1781 0.1% AS8452 -- TEDATA TEDATA 19 - 41.235.83.0/24 1759 0.1% AS8452 -- TEDATA TEDATA 20 - 95.78.176.0/21 1480 0.1% AS41661 -- ERTH-CHEL-AS CJSC "Company "ER-Telecom" Chelyabinsk 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 Nov 6 16:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 6 Nov 2009 22:00:00 GMT Subject: The Cidr Report Message-ID: <200911062200.nA6M00pH045554@wattle.apnic.net> This report has been generated at Fri Nov 6 21:11:16 2009 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 30-10-09 306992 189664 31-10-09 306927 189274 01-11-09 306853 189460 02-11-09 307017 188249 03-11-09 307095 189068 04-11-09 307244 189361 05-11-09 307274 189626 06-11-09 307380 189665 AS Summary 32791 Number of ASes in routing system 13931 Number of ASes announcing only one prefix 4331 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 91482048 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 06Nov09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 307148 189698 117450 38.2% All ASes AS6389 4251 320 3931 92.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4331 1921 2410 55.6% TWTC - tw telecom holdings, inc. AS1785 1785 381 1404 78.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS4766 1888 581 1307 69.2% KIXS-AS-KR Korea Telecom AS17488 1360 285 1075 79.0% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 1101 71 1030 93.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1558 624 934 59.9% Uninet S.A. de C.V. AS4755 1271 390 881 69.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS19262 1038 231 807 77.7% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18566 1062 269 793 74.7% COVAD - Covad Communications Co. AS8452 1043 320 723 69.3% TEDATA TEDATA AS18101 975 263 712 73.0% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS6478 1321 679 642 48.6% ATT-INTERNET3 - AT&T WorldNet Services AS3356 1220 610 610 50.0% LEVEL3 Level 3 Communications AS10620 1032 449 583 56.5% TV Cable S.A. AS4804 635 72 563 88.7% MPX-AS Microplex PTY LTD AS7303 660 99 561 85.0% Telecom Argentina S.A. AS4808 761 201 560 73.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS9498 650 96 554 85.2% BBIL-AP BHARTI Airtel Ltd. AS7018 1573 1042 531 33.8% ATT-INTERNET4 - AT&T WorldNet Services AS22047 546 18 528 96.7% VTR BANDA ANCHA S.A. AS11492 1137 650 487 42.8% CABLEONE - CABLE ONE, INC. AS9443 531 80 451 84.9% INTERNETPRIMUS-AS-AP Primus Telecommunications AS855 627 187 440 70.2% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS17676 564 129 435 77.1% GIGAINFRA Softbank BB Corp. AS4780 565 145 420 74.3% SEEDNET Digital United Inc. AS5668 788 372 416 52.8% AS-5668 - CenturyTel Internet Holdings, Inc. AS7011 1032 625 407 39.4% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS7738 429 29 400 93.2% Telecomunicacoes da Bahia S.A. AS14117 437 44 393 89.9% Telefonica del Sur S.A. Total 36171 11183 24988 69.1% Top 30 total Possible Bogus Routes 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 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 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 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-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 89.248.71.0/24 AS11730 CIL-ASN - Circle Internet LTD 95.215.108.0/22 AS48924 VOLSBUD-NET BMP VolsBud Ltd 96.8.64.0/18 AS19166 ACRONOC - ACRONOC INC 96.8.127.0/24 AS19166 ACRONOC - ACRONOC INC 109.74.208.0/20 AS43782 DARS-IP-AS DARS Telecom 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.10.0/24 AS38236 121.50.13.0/24 AS38236 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.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.77.128.0/24 AS4323 TWTC - tw telecom holdings, inc. 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 X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 193.24.196.0/22 AS6714 ATOMNET ATOM SA 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom s.r.l. 193.104.113.0/24 AS29550 EUROCONNEX-AS Blueconnex Networks Ltd 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.207.128.0/20 AS26452 BRING-AS - BringCom, Inc. 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.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 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - 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 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 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.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.9.115.0/24 AS10292 CWJ-1 - Cable & Wireless Jamaica 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet 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.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 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.138.64.0/20 AS17536 202.138.65.0/24 AS17536 202.138.66.0/24 AS17536 202.138.68.0/24 AS17536 202.138.70.0/24 AS17536 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.147.96.0/19 AS17536 202.147.96.0/20 AS17536 202.147.98.0/24 AS18107 ASN-IPSYSTEMS-AP IP SYSTEMS 202.147.99.0/24 AS17536 202.147.100.0/24 AS17536 202.147.105.0/24 AS17536 202.147.112.0/20 AS17536 202.147.113.0/24 AS17536 202.147.114.0/24 AS17536 202.147.116.0/24 AS17536 202.147.121.0/24 AS18107 ASN-IPSYSTEMS-AP IP SYSTEMS 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 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.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.82.160.0/19 AS17536 203.82.160.0/20 AS17536 203.82.162.0/24 AS17536 203.82.163.0/24 AS23871 AINS-AS-AP Australia Internet Solutions 203.82.165.0/24 AS17536 203.82.167.0/24 AS17536 203.82.171.0/24 AS17536 203.82.175.0/24 AS17536 203.82.176.0/20 AS17536 203.82.183.0/24 AS17536 203.82.184.0/24 AS17536 203.82.185.0/24 AS17536 203.82.188.0/24 AS17536 203.82.189.0/24 AS17536 203.82.190.0/24 AS17536 203.86.96.0/19 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 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/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.144.96.0/19 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.190.4.0/22 AS9919 NCIC-TW New Century InfoComm Tech Co., Ltd. 203.201.64.0/20 AS17536 203.201.69.0/24 AS17536 203.201.70.0/24 AS17536 203.201.75.0/24 AS23871 AINS-AS-AP Australia Internet Solutions 203.201.112.0/24 AS4857 TVPLUS TVPlus 203.201.113.0/24 AS4857 TVPLUS TVPlus 203.201.114.0/24 AS4857 TVPLUS TVPlus 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.189.62.0/23 AS7132 SBIS-AS - AT&T Internet Services 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.88.0/21 AS36835 208.77.224.0/24 AS36835 208.77.225.0/24 AS36835 208.77.226.0/24 AS36835 208.77.227.0/24 AS36835 208.77.228.0/24 AS36835 208.77.229.0/24 AS36835 208.77.230.0/24 AS36835 208.77.231.0/24 AS36835 208.87.152.0/21 AS25973 MZIMA - Mzima Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 213.181.70.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.80.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.81.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.83.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.84.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.85.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.86.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.87.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.88.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.89.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.90.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.91.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.92.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.93.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.94.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 213.181.95.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, 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.251.207.0/24 AS1239 SPRINTLINK - Sprint 218.185.240.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 222.0.0.0/8 AS9484 MOBINET-AS-MN Mobicom Company. AS Mobinet Internet Service Provider 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 jeffrey.lyon at blacklotus.net Fri Nov 6 16:02:58 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 6 Nov 2009 17:02:58 -0500 Subject: Interesting Point of view - Russian police and RIPE accused of aiding RBN In-Reply-To: <3d8c027f0911061212k1cd7b765t200c26a49cee3358@mail.gmail.com> References: <3d8c027f0911061020g1dff43cfpc9e505602d8c0dcd@mail.gmail.com> <16720fe00911061101o338189beu3ef96022a4d5c479@mail.gmail.com> <3d8c027f0911061212k1cd7b765t200c26a49cee3358@mail.gmail.com> Message-ID: <16720fe00911061402q4d982594g7d6dec2062060506@mail.gmail.com> Kanak, Can you please detail your plans to correct the malware issues on your network? (reference: http://google.com/safebrowsing/diagnostic?site=AS:44571 ). Best regards, Jeff [offlist communication snipped for privacy] > > Kanak > > Akrino Abuse Team > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From berni at birkenwald.de Fri Nov 6 19:09:04 2009 From: berni at birkenwald.de (Bernhard Schmidt) Date: Sat, 7 Nov 2009 01:09:04 +0000 (UTC) Subject: {SPAM?} Re: IPv6 Deployment for the LAN References: <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <20091022192930.GA16755@ussenterprise.ufp.org> <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> <20091022195014.GA18237@ussenterprise.ufp.org> <7a6830090910221257v43920378m29e2f2629a5042ce@mail.gmail.com> <20091022234616.GC3418@isc.org> Message-ID: David W. Hankins wrote: > There are some wireless equipment that claim to have a setting that > forces all packets through the wireless bridge (where all traffic is > between clients and bridge, and never client to client), and so one > can filter DHCPv6 and maybe RA, but I am kind of skeptical about how > much of this is elective and dependent upon client implementation... As already said, wireless in infrastructure mode (with access points) always sends traffic between clients through the access point, so a decent AP can filter this. On the university network we frequently had the problem of rogue RAs (in 99% of the cases generated by Windows hosts running 6to4 and ICS). We are currently migrating from an unencrypted wireless with mandatory VPN towards full IPv4/IPv6 eduroam (WPA2 Enterprise) with about 500 concurrent hosts, spread around four large subnets. Fortunately our access point vendor (Colubris, which very sadly is HP Procurve now) supports pcap-style filters on the wireless side. We've deployed the ingress filter ether proto 0x888e or (ip6 and not (ip6[6] == 58 and ip6[40] == 134)) or (ip and not (udp port 137 or udp port 138 or udp port 139 or udp src port 67)) or arp six months ago and have never had any problems again. Bernhard From noc.akrino at gmail.com Fri Nov 6 19:39:10 2009 From: noc.akrino at gmail.com (noc acrino) Date: Sat, 7 Nov 2009 04:39:10 +0300 Subject: Fwd: Interesting Point of view - Russian police and RIPE accused of aiding RBN In-Reply-To: <3d8c027f0911061212k1cd7b765t200c26a49cee3358@mail.gmail.com> References: <3d8c027f0911061020g1dff43cfpc9e505602d8c0dcd@mail.gmail.com> <16720fe00911061101o338189beu3ef96022a4d5c479@mail.gmail.com> <3d8c027f0911061212k1cd7b765t200c26a49cee3358@mail.gmail.com> Message-ID: <3d8c027f0911061739s3fb148fdy719f2253f6219f61@mail.gmail.com> ---------- Forwarded message ---------- From: noc acrino Date: 2009/11/6 Subject: Re: Interesting Point of view - Russian police and RIPE accused of aiding RBN To: Jeffrey Lyon Thanks for the quick answer, Jeffrey. 2009/11/6 Jeffrey Lyon Kanak, > > It's good to see you here. The primary issue is that we receive a fair > deal of customers who end up with wide scale DDoS attacks followed by > an offer for "protection" to move to your network. In almost every > case the attacks cease once the customer has agreed to pay this > "protection" fee. Every one of these attacks was nearly identical in > signature. > > I would be very grateful if you provide the history of those communications - in fact we have never organized the DDoS-attacks ourselves, it's just nonsense. Our AS is ready for any public testing to see what we are really doing. I realize the fact that none of the normal network operators have any instruments to organize a heavy DDoS-attack but a single web-engineer can test any web-server in our network to see the algorithms of traffic analyzing and attacks mitigation. > A couple of years back we followed up on this and a handful of trusted > security analysts who focus on RBN alleged that Akrino was an RBN > shill network thus prompting the spawn of this article: > > http://www.computerworld.com/s/article/9063418/Russian_hosting_network_running_a_protection_racket_researcher_says > . > I'm sorry, in this article there's no concrete reference to Akrino Networks. And no evidence that we're affiliated. I would ask any person of the maillist to check the domain history (for example, using domaintools.com) to see whether the A-records of those domains (for example, TheCanadianMeds.com and OfficialMedicines.com) have ever been bind to Akrino Networks. I must buy some extra service units to make this kind of report - if you wait I'll be ready in a few days. And anyway this also won't be a proof of evidence - the malefactor could do this binding specially but we have never served these A-records. I'd be grateful if you show any current problems concerning this AS, let's investigate the issue together. We not long ago closed a number of spam sources within our networks (yes, there really were a few problem clents) in collaboration with the Spamhaus team and we are always ready to help our colleagues if there's a need to. > Since first seeing your network arise in early 2008 i've never > actually seen anyone claim to own it and a Google search for your name > and ASN were completely devoid of any useful information. The ASN and > IP assignment are registered to a BVI offshore corporation that based > on my research do not seem to correlate to any legitimate commercial > activity. All of these things seem to support the Computerworld > article. > > And as I've already mentioned, we're forced to hide because of the personal security. ( We can provide the documents concerning our activity only after an official request obligating the requesting organization to keep this data privately. Why have I written only now? I've discovered this claim now by chance and have been greatly disappointed. Now I have to prove that Akrino Networks has nothing to do with RBN and I can't even imagine a more comical and at the same time weird situation. > I would love to be proven wrong on this issue as I do not like to see > a good net op ostracized without just cause. Perhaps your reseller(s) > are giving you a bad name? Either way I would love to chat, feel free > to Skype: blacklotus.net . > > Thank you for this proposition, I'll contact you tomorrow. Kanak Akrino Abuse Team From adrian at creative.net.au Fri Nov 6 19:54:40 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Sat, 7 Nov 2009 09:54:40 +0800 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: References: <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <20091022192930.GA16755@ussenterprise.ufp.org> <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> <20091022195014.GA18237@ussenterprise.ufp.org> <7a6830090910221257v43920378m29e2f2629a5042ce@mail.gmail.com> <20091022234616.GC3418@isc.org> Message-ID: <20091107015440.GB21938@skywalker.creative.net.au> On Sat, Nov 07, 2009, Bernhard Schmidt wrote: > As already said, wireless in infrastructure mode (with access points) > always sends traffic between clients through the access point, so a > decent AP can filter this. How does the client determine that the traffic came from the AP versus another client? Adrian From richard at bennett.com Sat Nov 7 04:41:33 2009 From: richard at bennett.com (Richard Bennett) Date: Sat, 07 Nov 2009 02:41:33 -0800 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <20091107015440.GB21938@skywalker.creative.net.au> References: <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <20091022192930.GA16755@ussenterprise.ufp.org> <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> <20091022195014.GA18237@ussenterprise.ufp.org> <7a6830090910221257v43920378m29e2f2629a5042ce@mail.gmail.com> <20091022234616.GC3418@isc.org> <20091107015440.GB21938@skywalker.creative.net.au> Message-ID: <4AF54EDD.2020507@bennett.com> The Wi-Fi MAC protocol has a pair of header bits that mean "from AP" and "to AP." In ad-hoc mode, a designated station acts as an AP, so that's nothing special. There are a couple of non-AP modes for direct link exchanges and peer-to-peer exchances that probably don't set "from AP" but I'm not sure about that. Adrian Chadd wrote: On Sat, Nov 07, 2009, Bernhard Schmidt wrote: As already said, wireless in infrastructure mode (with access points) always sends traffic between clients through the access point, so a decent AP can filter this. How does the client determine that the traffic came from the AP versus another client? Adrian -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From berni at birkenwald.de Sat Nov 7 06:15:52 2009 From: berni at birkenwald.de (Bernhard Schmidt) Date: Sat, 7 Nov 2009 12:15:52 +0000 (UTC) Subject: {SPAM?} Re: IPv6 Deployment for the LAN References: <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <20091022192930.GA16755@ussenterprise.ufp.org> <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> <20091022195014.GA18237@ussenterprise.ufp.org> <7a6830090910221257v43920378m29e2f2629a5042ce@mail.gmail.com> <20091022234616.GC3418@isc.org> <20091107015440.GB21938@skywalker.creative.net.au> Message-ID: Adrian Chadd wrote: >> As already said, wireless in infrastructure mode (with access points) >> always sends traffic between clients through the access point, so a >> decent AP can filter this. > How does the client determine that the traffic came from the AP versus > another client? I'm not exactly a specialist for wireless, but as far as I remember my lectures the 802.11 has additional MAC fields for the wireless source/destination. Stations always send to the AP, the AP retransmits it to the station. IIRC WPA/WPA2 even has some protection against stations forging the AP MAC with the shared group key, but I don't remember any details. Bernhard From deric.kwok2000 at gmail.com Sat Nov 7 11:21:50 2009 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Sat, 7 Nov 2009 12:21:50 -0500 Subject: need your suggestion about switch Message-ID: <40d8a95a0911070921v48fc2162s119c4fc4bd01c598@mail.gmail.com> Hi I am requested to get not brand list switch how can I test it? any software or methods eg: reliable speed or any need Thank you so much From owen at delong.com Sat Nov 7 12:04:34 2009 From: owen at delong.com (Owen DeLong) Date: Sat, 7 Nov 2009 10:04:34 -0800 Subject: Human Factors and Accident reduction/mitigation In-Reply-To: <4AF4815D.9070709@gmail.com> References: <200911051349.nA5DnljR007422@aurora.sol.net> <550BABDF-1A67-414D-8676-A875F16A93BF@delong.com> <4AF4815D.9070709@gmail.com> Message-ID: <2A7054E4-5E81-45E9-A820-75064875A363@delong.com> On Nov 6, 2009, at 12:04 PM, JC Dill wrote: > Owen DeLong wrote: >> >> We could learn a lot about this from Aviation. Nowhere in human >> history has >> more research, care, training, and discipline been applied to >> accident prevention, >> mitigation, and analysis as in aviation. A few examples: >> >> NTSB investigations of EVERY US aircraft accident and published >> findings. > > Ask any commercial pilot (and especially a commercial commuter > flight pilot) what they think of NTSB investigations when the pilot > had a "bad schedule" that doesn't allow enough time for adequate > sleep. They will point out that lack of sleep can't be determined > in an autopsy. As a point of information, I _AM_ a commercial pilot. > The NTSB routinely puts an accident down to "pilot error" even when > pilots who regularly fly those routes and shifts are convinced that > exhaustion (lack of sleep, long working days) was clearly involved. > And for even worse news - the smaller the plane the more complicated > it is to fly and the LESS rest the pilots receive in their overnight > stays because commuter airlines are covered under part 135 while > major airlines are covered under part 121. My ex flew turbo-prop > planes for American Eagle (American Airlines commuter flights). It > was common to have the pilot get off duty near 10 pm and be requited > to report back at 6 am. That's just 8 hours for rest. The "rest > period" starts with a wait for a shuttle to the hotel, then the > drive to the hotel (often 15 minutes or more from the airport) then > check-in - it can add up to 30-45 minutes before the pilot is > actually inside a hotel room. These overnight stays are in smaller > towns like Santa Rosa, Fresno, Bakersfield, etc. Usually the pilots > are put up at hotels that don't have a restaurant open this late, > and no neighboring restaurants (even fast food) so the pilot doesn't > get dinner. (There is no time for dinner in the flight schedule - > they get at most 20 minutes of free time between arrival and take- > off - enough time to get a bio-break and hit a vending machine but > not enough time to actually get a meal.) Take a shower, get to bed > at about 11:30. Set the alarm for 4:45 am and catch the shuttle > back to the airport at 5:15 to get there before the 6:00 reporting > time. In that "8 hour" rest period you get less than 6 hours of > sleep - if you can fall asleep easily in a strange hotel. > Flying in such a state of exhaustion is, whether you like it or not, a form of pilot error. A pilot who chooses to fly on such a schedule is making an error in judgment. Sure, there are all kinds of pressures and employment issues that need to be resolved to reduce and eliminate that pressure, and, I support the idea of updating the crew duty time regulations with that in mind. That does not change the fact that FAR 91.3 still applies: Sec. 91.3 Responsibility and authority of the pilot in command. (a) The pilot in command of an aircraft is directly responsible for, and is the final authority as to, the operation of that aircraft. (b) In an in-flight emergency requiring immediate action, the pilot in command may deviate from any rule of this part to the extent required to meet that emergency. (c) Each pilot in command who deviates from a rule under paragraph (b) of this section shall, upon the request of the Administrator, send a written report of that deviation to the Administrator. A failure to declare him/herself to be incapable of safely completing the flight is a failure to meet the requirements of 91.3(a). > Commuter route pilots have been fighting to get regulations changed > to require longer overnight periods, and especially to get the > required rest period changed to "behind the door" so that the > airlines can't include the commute time to/from the airport in the > "rest" period. This would force the airlines to select hotels > closer to the airport or else allow longer overnight layovers - > either way the pilots would get adequate rest. See: > > http://asrs.arc.nasa.gov/publications/directline/dl5_one.htm > And that would be a good change. In part, that change is supported by the number of times that the NTSB has made statments such as: We find the probable cause of the accident was pilot error. We believe that fatigue was likely a factor in the accident. > The NTSB does a great job with mechanical issues and with training > issues, but they totally miss the boat when it comes to regulating > adequate rest periods in the airline schedules. No, you miss the boat on the relationship between the stakeholders. The NTSB has repeatedly commented on the need for better regulations and better studies of crew duty time requirements and fatigue as a factor in accidents and incidents. However, the NTSB CANNOT change regulations. They investigate accidents and make recommendations to the regulatory agencies. The FAA needs to be the one to change the regulations. The FAA has not done a particularly good job in addressing this topic, where they have done a better job in improving mechanical and training issues and have been more likely to follow up on NTSB recommendations in these areas. In part, that is the result of reduced pushback on the FAA in these areas from industry. After all, Boeing does NOT want to publicly say "We think that this mechanical factor the NTSB just determined as the cause of 400 fatalities isn't really an issue and the FAA should not issue an AD to make us correct it." On the other hand, it's much harder for the kind of public feedback loop that exists in the above statement to apply to crew fatigue issues. In any case, this has drifted well off the NANOG topic, and, I would be happy to discuss the NTSB, FAA, etc. with you off-list if you wish. > To bring this back to NANOG territory, how many times have you or > one of your network admins made a mistake when working with > inadequate sleep - due to extra early start hours (needless 8 am > meetings), or working long/late hours, or being called to work in > the middle of the night? > Sure, this happens, but, it's not the only thing that happens. > Finally, having lived with a commercial aviation pilot for 5 years > and having worked with network types for much longer, I can say that > while there is some overlap between pilots and IT techs, there are > also a LOT of people who go into computers (programming, network and > system administration) who are totally unsuitable for the regimented > environment required for commercial aviation - people who HATE > following a lot of rules and regulations and fixed schedules. If > you tried to impose FAA-type rules and regulations and airline > schedules on an IT organization, you would have a revolt on your > hands. Tread carefully when you consider to emulating Aviation. > That's very true. I wasn't advocating that we should emulate aviation, so much as I was attempting to point out that if you want to reduce accidents/incidents, there is a proven model for doing so and that it comes at a cost. Today, we actually seem, and in my opinion, rightly so, to prefer to live with the existing situation. However, given that is the choice we are making, we should realize that is the choice we have made and accept the tradeoffs or make a different choice. Owen From lcaron at unix-scripts.info Sat Nov 7 12:09:01 2009 From: lcaron at unix-scripts.info (Laurent CARON) Date: Sat, 07 Nov 2009 19:09:01 +0100 Subject: need your suggestion about switch In-Reply-To: <40d8a95a0911070921v48fc2162s119c4fc4bd01c598@mail.gmail.com> References: <40d8a95a0911070921v48fc2162s119c4fc4bd01c598@mail.gmail.com> Message-ID: <4AF5B7BD.1060703@unix-scripts.info> On 07/11/2009 18:21, Deric Kwok wrote: > Hi > > I am requested to get not brand list switch > > how can I test it? any software or methods > > eg: > reliable > speed > or any need > > Thank you so much Hi, Can you please make sentences that make sense ? Are you seeking for advice or help ? I think yes. So the least you can do is ease the pain of people reading your emails. Thanks From owen at delong.com Sat Nov 7 12:29:31 2009 From: owen at delong.com (Owen DeLong) Date: Sat, 7 Nov 2009 10:29:31 -0800 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <4AF54EDD.2020507@bennett.com> References: <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <20091022192930.GA16755@ussenterprise.ufp.org> <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> <20091022195014.GA18237@ussenterprise.ufp.org> <7a6830090910221257v43920378m29e2f2629a5042ce@mail.gmail.com> <20091022234616.GC3418@isc.org> <20091107015440.GB21938@skywalker.creative.net.au> <4AF54EDD.2020507@bennett.com> Message-ID: <2AB0A378-DA39-484D-8654-8FD0B62C6EEF@delong.com> And of course, a rogue RA station would _NEVER_ mess with that bit in what it transmits... Uh, yeah. Owen On Nov 7, 2009, at 2:41 AM, Richard Bennett wrote: > The Wi-Fi MAC protocol has a pair of header bits that mean "from AP" > and "to AP." In ad-hoc mode, a designated station acts as an AP, so > that's nothing special. There are a couple of non-AP modes for > direct > link exchanges and peer-to-peer exchances that probably don't set > "from > AP" but I'm not sure about that. > Adrian Chadd wrote: > > On Sat, Nov 07, 2009, Bernhard Schmidt wrote: > > > > As already said, wireless in infrastructure mode (with access points) > always sends traffic between clients through the access point, so a > decent AP can filter this. > > > How does the client determine that the traffic came from the AP versus > another client? > > > > Adrian > > > > > -- > Richard Bennett > Research Fellow > Information Technology and Innovation Foundation > Washington, DC From bfeeny at mac.com Sat Nov 7 12:37:19 2009 From: bfeeny at mac.com (Brian Feeny) Date: Sat, 07 Nov 2009 13:37:19 -0500 Subject: need your suggestion about switch In-Reply-To: <40d8a95a0911070921v48fc2162s119c4fc4bd01c598@mail.gmail.com> References: <40d8a95a0911070921v48fc2162s119c4fc4bd01c598@mail.gmail.com> Message-ID: What I am gathering is that you are looking to by a off brand switch? If this is the case, then I would argue reliability and speed aren't important to you, but rather price, so go for what you can afford I guess. If you lack the knowledge to purchase a switch or test it properly, I would hire a professional services company that can do this for you and stand by their product/decisions. Of course, that would be expensive, and sort of goes against buying a cheap switch in the first place. Most vendors that you should be shopping in the first place, publish data on their switches that is a decent guide to performance at a distance. Just make sure your comparing apples to apples (packet sizes, features, etc). There are also some independent tests you can find such as miercom. Brian On Nov 7, 2009, at 12:21 PM, Deric Kwok wrote: > Hi > > I am requested to get not brand list switch > > how can I test it? any software or methods > > eg: > reliable > speed > or any need > > Thank you so much From jcdill.lists at gmail.com Sat Nov 7 12:45:40 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Sat, 07 Nov 2009 10:45:40 -0800 Subject: Human Factors and Accident reduction/mitigation In-Reply-To: <2A7054E4-5E81-45E9-A820-75064875A363@delong.com> References: <200911051349.nA5DnljR007422@aurora.sol.net> <550BABDF-1A67-414D-8676-A875F16A93BF@delong.com> <4AF4815D.9070709@gmail.com> <2A7054E4-5E81-45E9-A820-75064875A363@delong.com> Message-ID: <4AF5C054.4080607@gmail.com> Owen DeLong wrote: > > On Nov 6, 2009, at 12:04 PM, JC Dill wrote: > >> Owen DeLong wrote: >>> >>> We could learn a lot about this from Aviation. Nowhere in human >>> history has >>> more research, care, training, and discipline been applied to >>> accident prevention, >>> mitigation, and analysis as in aviation. A few examples: >>> >>> NTSB investigations of EVERY US aircraft accident and published >>> findings. >> >> Ask any commercial pilot (and especially a commercial commuter flight >> pilot) what they think of NTSB investigations when the pilot had a >> "bad schedule" that doesn't allow enough time for adequate sleep. >> They will point out that lack of sleep can't be determined in an >> autopsy. > > As a point of information, I _AM_ a commercial pilot. There are commercial pilots who fly for a living, and there are those who have the certification but who don't fly for a living. Do you regularly fly for a commercial airline where your schedule is determined by the airline's needs, part 135 or part 121 rules, union rules, etc. with no ability to modify your work schedule to allow for adequate rest? > >> The NTSB routinely puts an accident down to "pilot error" even when >> pilots who regularly fly those routes and shifts are convinced that >> exhaustion (lack of sleep, long working days) was clearly involved. >> And for even worse news - the smaller the plane the more complicated >> it is to fly and the LESS rest the pilots receive in their overnight >> stays because commuter airlines are covered under part 135 while >> major airlines are covered under part 121. My ex flew turbo-prop >> planes for American Eagle (American Airlines commuter flights). It >> was common to have the pilot get off duty near 10 pm and be requited >> to report back at 6 am. That's just 8 hours for rest. The "rest >> period" starts with a wait for a shuttle to the hotel, then the drive >> to the hotel (often 15 minutes or more from the airport) then >> check-in - it can add up to 30-45 minutes before the pilot is >> actually inside a hotel room. These overnight stays are in smaller >> towns like Santa Rosa, Fresno, Bakersfield, etc. Usually the pilots >> are put up at hotels that don't have a restaurant open this late, and >> no neighboring restaurants (even fast food) so the pilot doesn't get >> dinner. (There is no time for dinner in the flight schedule - they >> get at most 20 minutes of free time between arrival and take-off - >> enough time to get a bio-break and hit a vending machine but not >> enough time to actually get a meal.) Take a shower, get to bed at >> about 11:30. Set the alarm for 4:45 am and catch the shuttle back to >> the airport at 5:15 to get there before the 6:00 reporting time. In >> that "8 hour" rest period you get less than 6 hours of sleep - if you >> can fall asleep easily in a strange hotel. >> > Flying in such a state of exhaustion is, whether you like it or not, a > form of pilot error. There is no other effective option. Almost all the commuter airline schedules have these short overnights, and it's impossible for most pilots to avoid being scheduled to fly them. If you bid for these schedules you are expected to fly them. You can't just decide at 11:30 pm that you need more than 5 hour's rest and that you won't be getting up at 4:30 am to get to the airport by your 6:00 am report time, or decide when your alarm wakes you at 4:30 that you are too tired and are going to get another 2 hours sleep, or decide at 7 pm that you are too exhausted from flying this schedule for 2 days and are not going to fly your last leg. If you do this *even once* you will get in very hot water with the company and if you do it repeatedly you will ultimately lose your job. They aren't going to change the schedule because it's "legal" under part 135. > > A pilot who chooses to fly on such a schedule is making an error in > judgment. Sure, there are > all kinds of pressures and employment issues that need to be resolved > to reduce and eliminate > that pressure, Right now there is no way to avoid putting your job in jeopardy by refusing to fly these unsafe schedules. > and, I support the idea of updating the crew duty time regulations > with that > in mind. > > That does not change the fact that FAR 91.3 still applies: > The airlines don't care. They draw up these unsafe schedules and expect pilots to magically be capable of flying them safely. If there's an accident it goes down as pilot error, but if you try to claim exhaustion and refuse to fly citing 91.3 on a repeated basis you WILL be fired. Catch 22. Sounds a lot like working in IT with clueless management, doesn't it? >> To bring this back to NANOG territory, how many times have you or one >> of your network admins made a mistake when working with inadequate >> sleep - due to extra early start hours (needless 8 am meetings), or >> working long/late hours, or being called to work in the middle of the >> night? >> > Sure, this happens, but, it's not the only thing that happens. > >> Finally, having lived with a commercial aviation pilot for 5 years >> and having worked with network types for much longer, I can say that >> while there is some overlap between pilots and IT techs, there are >> also a LOT of people who go into computers (programming, network and >> system administration) who are totally unsuitable for the regimented >> environment required for commercial aviation - people who HATE >> following a lot of rules and regulations and fixed schedules. If you >> tried to impose FAA-type rules and regulations and airline schedules >> on an IT organization, you would have a revolt on your hands. Tread >> carefully when you consider to emulating Aviation. >> > That's very true. I wasn't advocating that we should emulate > aviation, so much as I was attempting > to point out that if you want to reduce accidents/incidents, there is > a proven model for doing so > and that it comes at a cost. Agreed. > Today, we actually seem, and in my opinion, rightly so, to prefer > to live with the existing situation. However, given that is the > choice we are making, we should > realize that is the choice we have made and accept the tradeoffs or > make a different choice. Fast(big/powerful), cheap, good - pick any two. :-) jc From sfouant at shortestpathfirst.com Sat Nov 7 13:07:09 2009 From: sfouant at shortestpathfirst.com (Stefan Fouant) Date: Sat, 7 Nov 2009 14:07:09 -0500 Subject: Pros and Cons of Cloud Computing in dealing with DDoS In-Reply-To: <82tyx8m14c.fsf@mid.bfk.de> References: <002101ca5e42$bddeace0$399c06a0$@com> <16720fe00911051020m4327d713jfa0e1b4043adc23f@mail.gmail.com> <003101ca5e4b$cbe74550$63b5cff0$@com> <82tyx8m14c.fsf@mid.bfk.de> Message-ID: <000001ca5fdd$81fbbb90$85f332b0$@com> > -----Original Message----- > From: Florian Weimer [mailto:fweimer at bfk.de] > Sent: Friday, November 06, 2009 4:52 AM > To: Stefan Fouant > Cc: 'Jeffrey Lyon'; 'NANOG list' > Subject: Re: Pros and Cons of Cloud Computing in dealing with DDoS > > Some companies have already suffered from this because they completely > outsourced their authoritative DNS service to dedicated DNS service > providers. Only very few customers of those providers were attacked, > but the impact was felt across larger parts of their customer base. Been there, done that. I used to work for Ultra. 'Nuff said ;) Stefan Fouant GPG Key ID: 0xB5E3803D From sfouant at shortestpathfirst.com Sat Nov 7 13:33:44 2009 From: sfouant at shortestpathfirst.com (Stefan Fouant) Date: Sat, 7 Nov 2009 14:33:44 -0500 Subject: Pros and Cons of Cloud Computing in dealing with DDoS In-Reply-To: <82pr7wm0z7.fsf@mid.bfk.de> References: <002101ca5e42$bddeace0$399c06a0$@com> <16720fe00911051020m4327d713jfa0e1b4043adc23f@mail.gmail.com> <003101ca5e4b$cbe74550$63b5cff0$@com> <55F6AEA5-1FCB-425D-AB1E-9F541C5D44F3@arbor.net> <003801ca5e7a$9b5c9f00$d215dd00$@com> <6cd462c00911051725w200e5480tb33e68cf377592df@mail.gmail.com> <003901ca5e81$65b9ada0$312d08e0$@com> <82pr7wm0z7.fsf@mid.bfk.de> Message-ID: <000101ca5fe1$38848650$a98d92f0$@com> > -----Original Message----- > From: Florian Weimer [mailto:fweimer at bfk.de] > Sent: Friday, November 06, 2009 4:55 AM > > Not all attacks involve saturated pipes. > > There used to be anti-DDoS vendors whose boxes didn't even have WAN > links. Part of the problem is that operating systems come with TCP > stacks and web servers which are not very robust, so it's pretty easy > to create something which behaves spectacularly better under certain > attacks. I am in complete agreement with you here. And I don't think the things I've said are generally inconsistent with the views held by others. The original point I was trying to make before the discussion got so eloquently hijacked towards a discussion on flooding and its impact on availability is that with regards to cloud computing, if the discussion hasn't shifted from that of DDoS to EDoS, it should. Just take one look at Amazon's usage-based pricing model, and one can envision that a surplus of resources could actually be just as bad as a lack thereof. How long do you think it will take for the bad guys to realize that they don't need to cause an outage to cause havoc to the victim. A slow trickle of seemingly legitimate requests from just a few thousand hosts performed over several days or weeks might give some organizations pause and that $50k extortion might start looking pretty enticing. I second Roland's comments with regard to the CIA triad, and his opinion that availability of resources is the first among equals is spot on. But I'm willing to bet that if the attackers exploit the so-called elasticity of the cloud and the subsequent associated financial costs, integrity is going to take on a whole new level of importance. BTW, heuristic/behavioral based analysis has benefit here, it just needs to start happening on more granular level... Getting back to the original discussion, I'd still like to hear what some of you think are the Pros vs. the Cons of Cloud Computing in dealing with this situation. We've heard a few and now I'd like to hear what others have to say. BTW, I realize this is a sensitive subject and I can understand why some of you might not want to respond on-list (security through obscurity eh' ;). To those of you who have taken the time to respond to me off-list, I appreciate your feedback and promise to keep your identities confidential. Regards, Stefan Fouant GPG Key ID: 0xB5E3803D From sfouant at shortestpathfirst.com Sat Nov 7 14:02:18 2009 From: sfouant at shortestpathfirst.com (Stefan Fouant) Date: Sat, 7 Nov 2009 15:02:18 -0500 Subject: need your suggestion about switch In-Reply-To: References: <40d8a95a0911070921v48fc2162s119c4fc4bd01c598@mail.gmail.com> Message-ID: <000201ca5fe5$366f1700$a34d4500$@com> > -----Original Message----- > From: Brian Feeny [mailto:bfeeny at mac.com] > Sent: Saturday, November 07, 2009 1:37 PM > > (packet sizes, features, etc). There are also some independent tests > you can find such as miercom. Come on... I don't know if I'd use "Miercom" and "independent" in the same sentence? More like guns for hire. I've rarely seen a test report they came out with that wasn't commissioned by a particular vendor with the testing done in such a way as to slant the results in their favor. Stefan Fouant GPG Key ID: 0xB5E3803D From richard at bennett.com Sat Nov 7 14:36:34 2009 From: richard at bennett.com (Richard Bennett) Date: Sat, 07 Nov 2009 12:36:34 -0800 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <2AB0A378-DA39-484D-8654-8FD0B62C6EEF@delong.com> References: <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <20091022192930.GA16755@ussenterprise.ufp.org> <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> <20091022195014.GA18237@ussenterprise.ufp.org> <7a6830090910221257v43920378m29e2f2629a5042ce@mail.gmail.com> <20091022234616.GC3418@isc.org> <20091107015440.GB21938@skywalker.creative.net.au> <4AF54EDD.2020507@bennett.com> <2AB0A378-DA39-484D-8654-8FD0B62C6EEF@delong.com> Message-ID: <4AF5DA52.9050607@bennett.com> It's not all that easy unless the dude has hacked the device driver. Owen DeLong wrote: > And of course, a rogue RA station would _NEVER_ mess with that bit > in what it transmits... > > Uh, yeah. > > Owen > > On Nov 7, 2009, at 2:41 AM, Richard Bennett wrote: > >> The Wi-Fi MAC protocol has a pair of header bits that mean "from AP" >> and "to AP." In ad-hoc mode, a designated station acts as an AP, so >> that's nothing special. There are a couple of non-AP modes for direct >> link exchanges and peer-to-peer exchances that probably don't set >> "from >> AP" but I'm not sure about that. >> Adrian Chadd wrote: >> >> On Sat, Nov 07, 2009, Bernhard Schmidt wrote: >> >> >> >> As already said, wireless in infrastructure mode (with access points) >> always sends traffic between clients through the access point, so a >> decent AP can filter this. >> >> >> How does the client determine that the traffic came from the AP versus >> another client? >> >> >> >> Adrian >> >> >> >> >> -- >> Richard Bennett >> Research Fellow >> Information Technology and Innovation Foundation >> Washington, DC > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From sean at donelan.com Sat Nov 7 14:48:34 2009 From: sean at donelan.com (Sean Donelan) Date: Sat, 7 Nov 2009 15:48:34 -0500 (EST) Subject: Congress may require ISPs to block fraud sites H.R.3817 In-Reply-To: <75cb24520911060747x3556e01tbb80be8c9e0d58b3@mail.gmail.com> References: <4AF35449.8030700@inline.com> <23895.1257461806@turing-police.cc.vt.edu> <75cb24520911060747x3556e01tbb80be8c9e0d58b3@mail.gmail.com> Message-ID: <200911071517150.32BF5B92.5858@clifden.donelan.com> On Fri, 6 Nov 2009, Christopher Morrow wrote: >>> paragraph (1) shall be liable for any damages caused thereby, including >>> damages suffered by SIPC, if the Internet service provider-- Some phrases people might search in various combindations on Google SIPC Stratton Oakmont Prodigy 47 USC 230 House of Representatives Conference Report GAO Report: Securities Investor Protection: Steps needed to better disclose SIPC policies to investors From trejrco at gmail.com Sat Nov 7 15:40:42 2009 From: trejrco at gmail.com (TJ) Date: Sat, 7 Nov 2009 16:40:42 -0500 Subject: {SPAM?} Re: IPv6 Deployment for the LAN In-Reply-To: <4AF5DA52.9050607@bennett.com> References: <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <20091022.205135.74697009.sthaug@nethelp.no> <7a6830090910221223i7dcc04e4vbada0f9d7d1c1777@mail.gmail.com> <20091022192930.GA16755@ussenterprise.ufp.org> <7a6830090910221242l5486eb39s84a6de766f39f419@mail.gmail.com> <20091022195014.GA18237@ussenterprise.ufp.org> <7a6830090910221257v43920378m29e2f2629a5042ce@mail.gmail.com> <20091022234616.GC3418@isc.org> <20091107015440.GB21938@skywalker.creative.net.au> <4AF54EDD.2020507@bennett.com> <2AB0A378-DA39-484D-8654-8FD0B62C6EEF@delong.com> <4AF5DA52.9050607@bennett.com> Message-ID: <003701ca5ff2$f7eb7c90$e7c275b0$@com> Device driver? Nah. Just use a tool (like Scapy) to just arbitrarily, easily custom-craft any packet he|she wants ... Yes, it is that easy. Thanks! /TJ -----Original Message----- From: Richard Bennett [mailto:richard at bennett.com] Sent: Saturday, November 07, 2009 15:37 To: Owen DeLong Cc: Bernhard Schmidt; nanog at nanog.org Subject: Re: {SPAM?} Re: IPv6 Deployment for the LAN It's not all that easy unless the dude has hacked the device driver. Owen DeLong wrote: > And of course, a rogue RA station would _NEVER_ mess with that bit > in what it transmits... > > Uh, yeah. > > Owen > > On Nov 7, 2009, at 2:41 AM, Richard Bennett wrote: > >> The Wi-Fi MAC protocol has a pair of header bits that mean "from AP" >> and "to AP." In ad-hoc mode, a designated station acts as an AP, so >> that's nothing special. There are a couple of non-AP modes for direct >> link exchanges and peer-to-peer exchances that probably don't set >> "from >> AP" but I'm not sure about that. >> Adrian Chadd wrote: >> >> On Sat, Nov 07, 2009, Bernhard Schmidt wrote: >> >> >> >> As already said, wireless in infrastructure mode (with access points) >> always sends traffic between clients through the access point, so a >> decent AP can filter this. >> >> >> How does the client determine that the traffic came from the AP versus >> another client? >> >> >> >> Adrian >> >> >> >> >> -- >> Richard Bennett >> Research Fellow >> Information Technology and Innovation Foundation >> Washington, DC > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From noc.akrino at gmail.com Sat Nov 7 15:58:39 2009 From: noc.akrino at gmail.com (noc acrino) Date: Sun, 8 Nov 2009 00:58:39 +0300 Subject: Interesting Point of view - Russian police and RIPE accused of aiding RBN In-Reply-To: <16720fe00911061402q4d982594g7d6dec2062060506@mail.gmail.com> References: <3d8c027f0911061020g1dff43cfpc9e505602d8c0dcd@mail.gmail.com> <16720fe00911061101o338189beu3ef96022a4d5c479@mail.gmail.com> <3d8c027f0911061212k1cd7b765t200c26a49cee3358@mail.gmail.com> <16720fe00911061402q4d982594g7d6dec2062060506@mail.gmail.com> Message-ID: <3d8c027f0911071358x7795b5cfn1a52815d70d4ec28@mail.gmail.com> Hello, Jeffery and other NANOC members. Sorry for making another thread - I'm not too experienced in mailgroups. The problem is in structure of new generation advert or banner networks - they allow to return other subject traffic to the partner's URL. And this could also be used to redirect the traffic to different exploits (a simple way to compromise a banner network or hosting provider). This is extremely hard to monitor or to take preventive measures in case of a large banner or advert network. Unfortunately Google doesn't provide a detailed report on their check results: this could allow the resource's owner easily block their partners in that case. Anyway I'll contact the owner of this resource (91.202.63.96) now in order to perform a check of their partners. I suppose, just having a few domains would be enough. The other resource is situated on the public ip of our reseller - I'll ask him to check this domain, too. Thank you for that information, I'll report on that issue later. Kanak Akrino Support Team 2009/11/7 Jeffrey Lyon > Kanak, > > Can you please detail your plans to correct the malware issues on your > network? (reference: > http://google.com/safebrowsing/diagnostic?site=AS:44571 ). > > Best regards, Jeff > > > > [offlist communication snipped for privacy] > > > > > Kanak > > > > Akrino Abuse Team > > > > > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications of The IRC Company, Inc. > > Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - > 21 to find out how to "protect your booty." > From oberman at es.net Sat Nov 7 17:56:36 2009 From: oberman at es.net (Kevin Oberman) Date: Sat, 07 Nov 2009 15:56:36 -0800 Subject: Speed Testing and Throughput testing In-Reply-To: Your message of "Mon, 02 Nov 2009 18:22:19 EST." Message-ID: <20091107235636.2E51C1CC0E@ptavv.es.net> > Date: Mon, 2 Nov 2009 18:22:19 -0500 > From: Jon Meek > > I use iperf with packet capture on both sides, then analyze the packet > capture for per-second throughput and re-transmits. I usually do 10 > TCP streams for 30 seconds. > > Note that on GigE with significant RTTs (5-15 ms) some TCP tuning is > needed to deal with the bandwidth delay product. It is also possible > that Ethernet drivers will have an effect. Local testing of the pair > of test machines should be done if you can't get to about 980 Mbps on > a Gig link (keeping in mind the comment about TCP tuning as latency > increases). > > Jon > > On Mon, Nov 2, 2009 at 4:56 PM, Mark Urbach wrote: > > Anyone have a good solution to get "accurate" speed results when testing at 10/100/1000 Ethernet speeds? > > > > Do you have a server/software that customer can test too? I'll also suggest http://fasterdata.es.net as a resource for network tuning. Tuning TCP is hard. UDP is simple, but some things can even impact UDP. Many less than obvious things can have a huge impact on high-speed data transfer. The choice of congestion algorithms can be very significant. As anyone who has used bittorrent should have noticed, having multiple TCP streams works better than a single stream. An oddity we have noted is that some routers will process switch layer 2 traffic if a layer 3 interface exists on the port even if it is unconfigured and unused. Man, that kills performance, even in low latency situations! FWIW, we use mostly iperf, but may be biased as the iperf maintainer works here. We did start using iperf before we hired him, though. -- 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 rdobbins at arbor.net Sat Nov 7 20:33:39 2009 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 8 Nov 2009 02:33:39 +0000 Subject: Pros and Cons of Cloud Computing in dealing with DDoS In-Reply-To: <000101ca5fe1$38848650$a98d92f0$@com> References: <002101ca5e42$bddeace0$399c06a0$@com> <16720fe00911051020m4327d713jfa0e1b4043adc23f@mail.gmail.com> <003101ca5e4b$cbe74550$63b5cff0$@com> <55F6AEA5-1FCB-425D-AB1E-9F541C5D44F3@arbor.net> <003801ca5e7a$9b5c9f00$d215dd00$@com> <6cd462c00911051725w200e5480tb33e68cf377592df@mail.gmail.com> <003901ca5e81$65b9ada0$312d08e0$@com> <82pr7wm0z7.fsf@mid.bfk.de> <000101ca5fe1$38848650$a98d92f0$@com> Message-ID: <84AF8114-8F04-424B-A666-77CD7AA1BABD@arbor.net> On Nov 8, 2009, at 2:33 AM, Stefan Fouant wrote: > if the discussion hasn't shifted from that of DDoS to EDoS, it > should. All DDoS is 'EDoS' - it's a distinction without a difference, IMHO. DDoS costs opex, can cost direct revenue, can induce capex spends - it's all about economics at bottom, always has been, or nobody would care in the first place. And look at click-fraud attacks in which the miscreants either a) are committing fraud by causing botnets to make fake clicks so that they can be paid for same or b) wish to exhaust a rival's advertising budget when he's paying per-impression. Plain old packet-flooding DDoSes can cost victims/unwitting sources big money in transit costs, can cost SPs in transit and/or violating peering agreements, etc. There's no need or justification for a separate term; Chris Hoff bounced 'EDoS' around earlier this year, and the same arguments apply. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From noc.akrino at gmail.com Sun Nov 8 04:27:34 2009 From: noc.akrino at gmail.com (noc acrino) Date: Sun, 8 Nov 2009 13:27:34 +0300 Subject: Interesting Point of view - Russian police and RIPE accused of aiding RBN In-Reply-To: <16720fe00911061101o338189beu3ef96022a4d5c479@mail.gmail.com> References: <3d8c027f0911061020g1dff43cfpc9e505602d8c0dcd@mail.gmail.com> <16720fe00911061101o338189beu3ef96022a4d5c479@mail.gmail.com> Message-ID: <3d8c027f0911080227j259a5f67m4d847f35538d1ca3@mail.gmail.com> 2009/11/6 Jeffrey Lyon > The primary issue is that we receive a fair > deal of customers who end up with wide scale DDoS attacks followed by > an offer for "protection" to move to your network. In almost every > case the attacks cease once the customer has agreed to pay this > "protection" fee. Every one of these attacks was nearly identical in > signature. > By the way, Jeffrey, we can provide reports on HTTP-flood because our system builds it's signatures on http traffic dumps like === IP: 88.246.76.65, last receiving time: 2009-10-25T23:07:37+03:00, many identical requests (length 198): GET / HTTP/1.1 Accept: */* Accept-language: en-us User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 Host: [censored] Connection: Keep-Alive So using this info we can map botnets, learn different attacks and in collaboration with ISPs - find CCs of new botnets. And what are your accusations of the identical signatures based on when simple Staminus resellers (like you are) do not have access to their signatures database? Kanak Akrino Abuse Team From adel at baklawasecrets.com Sun Nov 8 05:51:37 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Sun, 08 Nov 2009 11:51:37 +0000 Subject: Failover how much complexity will it add? Message-ID: <53061.1257681097@baklawasecrets.com> HI, I was recently brought onto a project where some failover is desired, but I think that the number of connections provisioned is excessive. Also hoping to get some guidance with regards to how well I can get the failover to actually work. So currently 4 X 100Mb/s Internet connections have been provisioned. One is to be used for general Internet, out of the organisation, it also terminates VPNs from remote sites belonging to the organisation and some publicly accessible servers -routed DMZ and translated IPs. Second Internet connection to be used for a separate system which has a site-to-site VPN to a third party support vendor. Internet connections 3 and 4 are currently thought of as providing backups for one and two. Both connections firewalled by a Juniper SSG of some description. Now I couldn't get any good answers as to why Internet connections 1 and 2 need to be separate. I think the idea was to make sure that there was enough bandwidth for the third party support VPN. I feel that I can consolidate this into one connection and just use rate limiting to reserve some portion of the bandwidth on the connection and this should be fine. Now if I was to do this then I can make a case for just having one backup Internet connection. However I'm still concerned about failover and reliability issues. So my questions regarding this are: - Should I make sure that the backup Internet connection is from a separate provider? - How can I acheive a failover which doesn't require me to change all the remote VPN endpoints in case of a failover? Its possible to configure failover VPNs on the Junipers, which should take care of this, but how do I take care of the DMZ hosts and external translation? - In fact I think I'm asking what are my options with regard to failover between one Internet connection and the other? I'm hoping to figure out whether adding an extra Internet connection actually gives us that much, in fact whether it justifies the complexity and spend. Many Thanks for your comments. Adel From bpfankuch at cpgreeley.com Sun Nov 8 09:23:41 2009 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Sun, 8 Nov 2009 08:23:41 -0700 Subject: Failover how much complexity will it add? In-Reply-To: <53061.1257681097@baklawasecrets.com> References: <53061.1257681097@baklawasecrets.com> Message-ID: <01759D50DC387C45A018FE1817CE27D757887D7174@CPExchange1.cpgreeley.com> >> -----Original Message----- >> From: adel at baklawasecrets.com [mailto:adel at baklawasecrets.com] >> Sent: Sunday, November 08, 2009 4:52 AM >> To: nanog at nanog.org >> Subject: Failover how much complexity will it add? >> >> HI, >> >> I was recently brought onto a project where some failover is desired, but I think that the number of connections provisioned >> is excessive. Also hoping to get some guidance with regards to how well I can get the failover to actually work. So currently >> 4 X 100Mb/s Internet connections have been provisioned. One is to be used for general Internet, out of the organisation, it >> also terminates VPNs from remote sites belonging to the organisation and some publicly accessible servers -routed DMZ and >> translated IPs. Second Internet connection to be used for a separate system which has a site-to-site VPN to a third party >> support vendor. Internet connections 3 and 4 are currently thought of as providing backups for one and two. Both connections >> firewalled by a Juniper SSG of some description. >> >> Now I couldn't get any good answers as to why Internet connections 1 and 2 need to be separate. I think the idea was to make >> sure that there was enough bandwidth for the third party support VPN. I feel that I can consolidate this into one connection >> and just use rate limiting to reserve some portion of the bandwidth on the connection and this should be fine. Now if I was to >> do this then I can make a case for just having one backup Internet connection. However I'm still concerned about failover and >> reliability issues. So my questions regarding this are: >> >> - Should I make sure that the backup Internet connection is from a separate provider? >> Yes yes yes yes a thousand times yes. Depending on the criticality of internet connectivity you should also aim to have your redundant connections coming from a complete separate direction. Example, fiber from Level 3 come from the north in a dedicated conduit and fiber from Verizon coming in a dedicated conduit from the south of the building. Why? Put simply we had construction ignore the painted lines and dig up our conduit a few years back. At that point we have 4 bonded T1's from a single carrier. That was a long couple of days... Carrier diversity is not a bad thing, spend some time shopping an additional provider. Make sure they operate their own network for last mile, and also make sure they don?t piggyback off the same network your main carrier does anywhere locally. Comcast Ethernet, Verizon and Cogent make great secondary connections when you need high availability. You don?t need your secondary to have 99.999% uptime. 97% is usually good enough if it's on a separate network. I wouldn't sway from the big names for your primary connections either. >> >> - How can I acheive a failover which doesn't require me to change all the remote VPN endpoints in case of a failover? Its >> possible to configure failover VPNs on the Junipers, which should take care of this, but how do I take care of the DMZ hosts and >> external translation? >> With recent experience with the Juniper SSG VPN functions put nicely they suck. VPN failover is in there, but we had issues with the tunnel staying active for extended periods of time. Also depending on if you do a route based or a policy based VPN, it becomes so much of a headache. We used 2 SSG550 devices as a proof of concept and the one thing which annoyed me to no end was the complete and total crap options within then VPN configuration. When I typically set up a VPN, I use a SonicWall NSA or E-class device (yes I know hiss boo) or an ASA. Saying that the Juniper was lacking was a complete understatement. I personally would completely avoid even attempting VPN failover within a Juniper device. I will say they are rock solid though for generic firewall functionality, just try to keep the config simple or they turn into giant slow dogs. >> >> - In fact I think I'm asking what are my options with regard to failover between one Internet connection and the other? >> Considering you have 4x 100mbit lines, have you looked at BGP? Even if you drop line 2 and its associated backup, you have 2x 100mbit lines. Or even if you have 3 unique carriers with a 100mbit from each of them it makes BGP very appealing. I think this would be an ideal situation for a BGP setup using a couple of small routers. You could probably get away with something as small as a Cisco 3825 for each connection (purely redundancy). If the Cisco name scares you Juniper routers are great as well. Don?t forget Vyatta! If you do BGP, you have 1 VPN to configure, you have 1 tunnel to configure, there is no VPN failover configuration and hopefully you are not pushing more than 1 subnet across the VPN otherwise you end up doing a route based VPN instead of a policy based VPN and you will be significantly happier. That?s a Juniper headache for another day however. >> >> I'm hoping to figure out whether adding an extra Internet connection actually gives us that much, in fact whether it justifies the >> complexity and spend. >> What you really need to know to ask this is how much is Mr. Customer going to yell and scream if someone cuts only internet connection and it's going to be down for about 3 days while they patch the conduit and fiber. >> >> Many Thanks for your comments. >> >> Adel From jmaimon at ttec.com Sun Nov 8 09:47:35 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Sun, 08 Nov 2009 10:47:35 -0500 Subject: Failover how much complexity will it add? In-Reply-To: <53061.1257681097@baklawasecrets.com> References: <53061.1257681097@baklawasecrets.com> Message-ID: <4AF6E817.5040104@ttec.com> adel at baklawasecrets.com wrote: > HI, > > > Now I couldn't get any good answers as to why Internet connections 1 and 2 need to be separate. I think the idea was to make sure that there was enough bandwidth for the third party support VPN. I feel that I can consolidate this into one connection and just use rate limiting to reserve some portion of the bandwidth on the connection and this should be fine. Now if I was to do this then I can make a case for just having one backup Internet connection. However I'm still concerned about failover and reliability issues. So my questions regarding this are: > I wouldnt jump to any conclusions that everything will work properly if you are terminating multiple connections directly on the SSG, what with egress likely being different than the ingress, even if you are using the same IP range (BGP) on all the links. You could really be asking for trouble if you are planning on using a different ISP provided IP range on each connection for each purpose. Front it all with routers that can policy route, whether or not you also use BGP. Joe From tkapela at gmail.com Sun Nov 8 10:26:40 2009 From: tkapela at gmail.com (Anton Kapela) Date: Sun, 8 Nov 2009 11:26:40 -0500 Subject: Human Factors and Accident reduction/mitigation In-Reply-To: <550BABDF-1A67-414D-8676-A875F16A93BF@delong.com> References: <200911051349.nA5DnljR007422@aurora.sol.net> <550BABDF-1A67-414D-8676-A875F16A93BF@delong.com> Message-ID: <2e9d8ae50911080826u1cf41658kd5ef5918fa1f62a0@mail.gmail.com> Owen, > We could learn a lot about this from Aviation. ?Nowhere in human history has > more research, care, training, and discipline been applied to accident > prevention, > mitigation, and analysis as in aviation. ?A few examples: Others later in this thread duly noted a definite relationship of costs associated, which are clearly "worth it" given the particular application of these methods [snipped]. However, I assert this is warranted because of the specific public trust that commercial aviation must be given. Additionally, this form of professional or industry "standard" isn't unique in the world; you can find (albeit small) parallels in most states' PE certification tracks and the like. In the case of the big-I internet, I assert we can't (yet) successfully argue that it's deserving of similar public trust. In short, I'm arguing that big-I internet deserves special-pleading status in these sorts of "instrument -> record -> improve" strawmen and that we shouldn't apply similar concepts or regulation. (Robert B. then responded): > All, > The real problem is same human factors we have in aviation which cause most > accidents. Look at the list below and replace the word Pilot with Network > Engineer or Support Tech or Programmer or whatever... and think about all > the problems where something didn't work out right. It's because someone > circumvented the rules, processes, and cross checks put in place to prevent > the problem in the first place. Nothing can be made idiot proof because > idiots are so creative. I'd like to suggest we also swap "bug" for "software defect" or "hardware defect" - perhaps if operators started talking about problems like engineers, we'd get more global buy-in for a process-based solution. I certainly like the idea of improving the state of affairs where possible - especially the operator->device direction (i.e fat-fingering acl, prefix list, community list, etc). When people make mistakes, it seems very wise to accurately record the entrance criteria, the results of their actions, and ways to avoid it - then shared to all operators (like at NANOG meetings!). The part I don't like is being ultimately responsible for, or to "design around" a class of systemic problems which are entirely outside of an operators sphere of control. What curve must we shift to get routers with hardware and software that's both a) fast b) reliable and c) cheap -- in the hopes that the only problems left to solve indeed are human ones? -Tk From jcdill.lists at gmail.com Sun Nov 8 10:51:06 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Sun, 08 Nov 2009 08:51:06 -0800 Subject: Human Factors and Accident reduction/mitigation In-Reply-To: <2e9d8ae50911080826u1cf41658kd5ef5918fa1f62a0@mail.gmail.com> References: <200911051349.nA5DnljR007422@aurora.sol.net> <550BABDF-1A67-414D-8676-A875F16A93BF@delong.com> <2e9d8ae50911080826u1cf41658kd5ef5918fa1f62a0@mail.gmail.com> Message-ID: <4AF6F6FA.6030507@gmail.com> Anton Kapela wrote: > What curve must we shift to get routers with hardware and software > that's both a) fast b) reliable and c) cheap -- in the hopes that the > only problems left to solve indeed are human ones? Fast, Reliable, Cheap - pick any two. No, you can't have all three. The fastest(best) and most reliable *anything* can't be the cheapest one because someone will quickly seize the market opportunity to make one that is lower quality (slower) or less reliable and sell it for a lower price. jc From sethm at rollernet.us Sun Nov 8 11:23:53 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 08 Nov 2009 09:23:53 -0800 Subject: Failover how much complexity will it add? In-Reply-To: <53061.1257681097@baklawasecrets.com> References: <53061.1257681097@baklawasecrets.com> Message-ID: <4AF6FEA9.1020204@rollernet.us> adel at baklawasecrets.com wrote: > HI, > > I was recently brought onto a project where some failover is desired, but I think that the number of connections provisioned is excessive. Also hoping to get some guidance with regards to how well I can get the failover to actually work. So currently 4 X 100Mb/s Internet connections have been provisioned. One is to be used for general Internet, out of the organisation, it also terminates VPNs from remote sites belonging to the organisation and some publicly accessible servers -routed DMZ and translated IPs. Second Internet connection to be used for a separate system which has a site-to-site VPN to a third party support vendor. Internet connections 3 and 4 are currently thought of as providing backups for one and two. Both connections firewalled by a Juniper SSG of some description. > > Now I couldn't get any good answers as to why Internet connections 1 and 2 need to be separate. I think the idea was to make sure that there was enough bandwidth for the third party support VPN. I feel that I can consolidate this into one connection and just use rate limiting to reserve some portion of the bandwidth on the connection and this should be fine. Now if I was to do this then I can make a case for just having one backup Internet connection. However I'm still concerned about failover and reliability issues. So my questions regarding this are: > > - Should I make sure that the backup Internet connection is from a separate provider? > > - How can I acheive a failover which doesn't require me to change all the remote VPN endpoints in case of a failover? Its possible to configure failover VPNs on the Junipers, which should take care of this, but how do I take care of the DMZ hosts and external translation? > > - In fact I think I'm asking what are my options with regard to failover between one Internet connection and the other? Forget all of that and just multihome to two separate providers with BGP. Also make sure that of the providers you choose that one is not a customer of the other. Instant, painless redundancy. Having multiple circuits to one provider *will not* back anything up if that provider has an outage as they are %99.999 likely to be part of the same larger circuit and certainly share the same infrastructure at the provider. > > I'm hoping to figure out whether adding an extra Internet connection actually gives us that much, in fact whether it justifies the complexity and spend. > Only if you calculate the cost (money, time, angry customers, etc.) of an outage to be greater than the cost of additional connectivity. > Many Thanks for your comments. > ~Seth From asr+nanog at latency.net Sun Nov 8 11:29:08 2009 From: asr+nanog at latency.net (Adam Rothschild) Date: Sun, 8 Nov 2009 12:29:08 -0500 Subject: Failover how much complexity will it add? In-Reply-To: <01759D50DC387C45A018FE1817CE27D757887D7174@CPExchange1.cpgreeley.com> References: <53061.1257681097@baklawasecrets.com> <01759D50DC387C45A018FE1817CE27D757887D7174@CPExchange1.cpgreeley.com> Message-ID: <20091108172908.GA97960@latency.net> On 2009-11-08-10:23:41, Blake Pfankuch wrote: > Make sure they operate their own network for last mile [...] > I wouldn't sway from the big names for your primary connections > either. Because ownership of the provider/subsidiary delivering the last mile means one hand is talking to the other, and you're going to get good service and reliability as a result? And "big names" never have any peering-related spats and always deliver the best possible end-user experience, right? :-) (Some good points further on, though important we don't lead the OP down the wrong path or with a false sense of security there...) -a From adel at baklawasecrets.com Sun Nov 8 11:34:08 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Sun, 08 Nov 2009 17:34:08 +0000 Subject: Failover how much complexity will it add? Message-ID: <17938.1257701648@baklawasecrets.com> Thanks for all your comments guys. With regards to bgp I did think about placing two bgp routers in front of the ssg's. However my limited understanding makes me think that if I had two bgp connections from different providers I would still have issues. So I guess that if my primary Internet goes down I lose connectivity to all the publicly addressed devices on that connection. Like dmz hosts and so on. I would be interested to hear how this can be avoided if at all or do I have to use the same provider. I should add that we currently have provisioned two ssg in ha mode. Also is terminating bgp on the ssg also an option? I really like the flexibility of route based VPN with addresable tun interfaces. Thanks adel On Sun 3:47 PM , "Joe Maimon" jmaimon at ttec.com sent: > > > adel@ > baklawasecrets.com wrote:> HI, > > > > > > Now I couldn't get any good answers as to why > Internet connections 1 and 2 need to be separate. I think the idea was to > make sure that there was enough bandwidth for the third party support VPN. > I feel that I can consolidate this into one connection and just use rate > limiting to reserve some portion of the bandwidth on the connection and > this should be fine. Now if I was to do this then I can make a case for > just having one backup Internet connection. However I'm still concerned > about failover and reliability issues. So my questions regarding this > are:> > > I wouldnt jump to any conclusions that everything will work properly if > you are terminating multiple connections directly on the SSG, what with > egress likely being different than the ingress, even if you are using > the same IP range (BGP) on all the links. > > You could really be asking for trouble if you are planning on using a > different ISP provided IP range on each connection for each purpose. > > Front it all with routers that can policy route, whether or not you also > use BGP. > > > Joe > > > > > From John.Herbert at ins.com Sun Nov 8 12:09:11 2009 From: John.Herbert at ins.com (John.Herbert at ins.com) Date: Sun, 8 Nov 2009 12:09:11 -0600 Subject: Failover how much complexity will it add? In-Reply-To: <4AF6FEA9.1020204@rollernet.us> References: <53061.1257681097@baklawasecrets.com>, <4AF6FEA9.1020204@rollernet.us> Message-ID: Seth Mattinen [sethm at rollernet.us] said: >Forget all of that and just multihome to two separate providers with BGP --Assuming that you're advertising PI space or can work around that appropriately with your providers, I agree, that's the ideal situation. >Having multiple circuits to one provider *will not* back anything up if that provider >has an outage as they are %99.999 likely to be part of the same larger circuit --True - if you don't specify otherwise when you're ordering, then why would they make the effort? Comments made in some of the other responses in this thread are also valid even with a single service provider - diverse entry points into your facility, diverse upstream circuit routing, and homing to different POPs - which may mean backhauling your secondary circuit away from your local POP and taking a hit for the higher latency on that second link. The moral of this is that whether you're using one provider or more than one, state your diversity requirements clearly up front, and then stay involved and make sure that what's presented to you is _actually_ diverse (oldsflash: even the best intentioned people sometimes make mistakes, especially when there's a handoff to a different last mile provider who may not have been clear on the requirement ). Of course, all of this is potentially wasted effort if the data center you're providing connectivity for does not also maintain the same kind of diversity itself in terms of power, connectivity, architecture, etc. >and certainly share the same infrastructure at the provider. --If you enter a single provider's network at diverse points, then that local infrastructure isn't the same at least. But by the same measure, if that provider has a major BGP issue for example, then yeah - they're both screwed... in which case we loop back to the dual provider scenario you mentioned in the first place :) Ultimately choosing the appropriate solution will boil down to the what level of service unavailability one can tolerate in the first place, and put a business value on that impact. From that one can derive technical options, then go cap in hand with a business case to the poor soul paying the bill ;-) j. From sethm at rollernet.us Sun Nov 8 12:19:00 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 08 Nov 2009 10:19:00 -0800 Subject: Failover how much complexity will it add? In-Reply-To: <17938.1257701648@baklawasecrets.com> References: <17938.1257701648@baklawasecrets.com> Message-ID: <4AF70B94.1000406@rollernet.us> adel at baklawasecrets.com wrote: > Thanks for all your comments guys. With regards to bgp I did > think about placing two bgp routers in front of the ssg's. However > my limited understanding makes me think that if I had two bgp > connections from different providers I would still have issues. So > I guess that if my primary Internet goes down I lose connectivity > to all the publicly addressed devices on that connection. Like > dmz hosts and so on. I would be interested to hear how this > can be avoided if at all or do I have to use the same provider. > No, you will announce the same IP addresses (minimum of a /24 which you can easily obtain from one upstream just by saying "I want to multihome" if you don't already have a /24) over both. That's the whole point of multihoming. If cost is an issue you can just use one BGP speaking router. If you multihome there is no "primary" like you're thinking. ~Seth From Valdis.Kletnieks at vt.edu Sun Nov 8 13:46:20 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 08 Nov 2009 14:46:20 -0500 Subject: Failover how much complexity will it add? In-Reply-To: Your message of "Sun, 08 Nov 2009 08:23:41 MST." <01759D50DC387C45A018FE1817CE27D757887D7174@CPExchange1.cpgreeley.com> References: <53061.1257681097@baklawasecrets.com> <01759D50DC387C45A018FE1817CE27D757887D7174@CPExchange1.cpgreeley.com> Message-ID: <117673.1257709580@turing-police.cc.vt.edu> On Sun, 08 Nov 2009 08:23:41 MST, Blake Pfankuch said: > I wouldn't sway from the big names for your primary connections either. This is, of course, dependent on the OP's location and budget. I know when we were getting our NLR connection set up, there was a fair amount of "You want 40G worth of DWDM *where*?" involved, and the resulting topology was... complicated. At least at one time, there were places where our provider was running our link across lambdas of a subsidiary of ours, which are going across physical fiber owned by the provider... turtles all the way down. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jeffrey.lyon at blacklotus.net Sun Nov 8 14:01:57 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sun, 8 Nov 2009 15:01:57 -0500 Subject: Interesting Point of view - Russian police and RIPE accused of aiding RBN In-Reply-To: <3d8c027f0911080227j259a5f67m4d847f35538d1ca3@mail.gmail.com> References: <3d8c027f0911061020g1dff43cfpc9e505602d8c0dcd@mail.gmail.com> <16720fe00911061101o338189beu3ef96022a4d5c479@mail.gmail.com> <3d8c027f0911080227j259a5f67m4d847f35538d1ca3@mail.gmail.com> Message-ID: <16720fe00911081201x5ed20b62p330e61a1139b002c@mail.gmail.com> Kanak, We're not a Staminus reseller. Please do your homework: http://webtrace.info/asn/32421 . I'm not going to hold court on whether or not you or your resellers are DDoSing competitor's customers, I was merely stating my opinion. The reader can draw their own conclusion. I think your network is blackhat, you say it's not. I say your entire network has minimal legitimate traffic and you say you have a diverse customer base. The way I see it right now: - You're an anonymous BVI company with no physical location - This Computerworld article is referring to Akrino: http://www.computerworld.com/s/article/9063418/Russian_hosting_network_running_a_protection_racket_researcher_says. I was consulted on this article before it went to print and i'll put my reputation on that. - All of the sites on Akrino around early 2008 were on NEAVE LIMITED until shutdown by uplink Eltel. They all came back up under Akrino uplink to Anders (AS39792). - 91.202.60.0/22 has one actual company with legitimate commercially necessary traffic (will provide a full report if you want to push the issue) yet is responsible for hundreds of malware infections over the past 6 months (see again, http://google.com/safebrowsing/diagnostic?site=AS:44571 ) -- The aforementioned company (solidtrustpay.com) was a Black Lotus customer and had received several days of multi-Gbps DDoS that subsided only once the customer agreed to use your network --- Post-DDoS the customer's server began receiving SSH connections from some former Soviet country (forget which offhand) trying to debug a reverse proxy (not sure if you/they realize that we filter your announcements). In the real world DDoS does not stop just hours before the gaining host goes to setup a proxy. - The attacks you claim to be filtering would not be possible unless your connection to AS39792 is 10GE or they're doing the filters for you. - The above has occurred at least three times with Akrino, zero times with better known, respected providers. - A handful of respected net ops have contacted me off list to confirm much of this data and provide additional evidence. Again, these are merely *opinions* and form the foundation of why I believe Akrino is a black hat network. Perhaps if you didn't have black hat resellers you wouldn't have this reputation? Maybe you should reconsider who you allow to resell your network? I don't know for certain but you need to clean up your network so you don't end up like Atrivo. Clean up now and everyone wins. Jeff On Sun, Nov 8, 2009 at 5:27 AM, noc acrino wrote: > 2009/11/6 Jeffrey Lyon >> >> ?The primary issue is that we receive a fair >> deal of customers who end up with wide scale DDoS attacks followed by >> an offer for "protection" to move to your network. In almost every >> case the attacks cease once the customer has agreed to pay this >> "protection" fee. Every one of these attacks was nearly identical in >> signature. > > By the way, Jeffrey, we can provide reports on HTTP-flood because our system > builds it's signatures on http traffic dumps like > > === IP: 88.246.76.65, last receiving time: 2009-10-25T23:07:37+03:00, many > identical requests (length 198): > GET / HTTP/1.1 > Accept: */* > Accept-language: en-us > User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.1) > Gecko/20061204 Firefox/2.0.0.1 > Host: [censored] > Connection: Keep-Alive > > So using this info we can map botnets, learn different attacks and in > collaboration with ISPs - find CCs of new botnets. And what are your > accusations of the identical signatures based on when simple Staminus > resellers (like you are) do not have access to their signatures database? > > Kanak > > Akrino Abuse Team > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From adel at baklawasecrets.com Sun Nov 8 14:17:03 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Sun, 08 Nov 2009 20:17:03 +0000 Subject: Failover how much complexity will it add? Message-ID: <60758.1257711423@baklawasecrets.com> Thanks Seth and James, Things are getting a lot clearer. The BGP multihoming solution sounds like exactly what I want. I have more questions :-) Now I suppose I would get my allocation from RIPE as I am UK based? Do I also need to apply for an AS number? As the IP block is "mine", it is ISP independent. i.e. I can take it with me when I decide to use two completely different ISPs? Is the obtaining of this IP block, what is referred to as PI space? Of course internally I split the /24 up however I want - /28 for untrust range and maybe a routed DMZ block etc.? Assuming I apply for IP block and AS number, whats involved and how long does it take to get these babies? I know the SSG550's have BGP capabilites. As I have two of these in HA mode, does it make sense to do the BGP on these, or should I get dedicated BGP routers? Fixing the internal routing policy so traffic is directed at the active BGP connection. Whats involved here, preferring one BGP link over the other? Thanks again, I obviously need to do some reading of my own, but all the suggestions so far have been very valuable and definitely seem to be pointing in some fruitful directions. Adel On Sun 6:31 PM , "James Hess" mysidia at gmail.com sent: > On Sun, Nov 8, 2009 at 11:34 AM, baklawasecrets.com> wrote:[..] > > connections from different providers I would > still have issues. ?So> I guess that if my primary Internet goes down I > lose connectivity> to all the publicly addressed devices on that > connection. Like> dmz hosts and so on. ?I would be interested > to hear how this> can be avoided if at all or do I have to use the > same provider. > You assign multi-homed IP address space to your publicly addressed > devices,which are not specific to either ISP. You announce to both ISPs, and > you accept some routes from both ISPs. > > You get multi-homed IPs, either by having an existing ARIN allocation, > or getting a /22 from ARIN (special allocation available for > multi-homing), or ask for a /24 from ISP A or ISP B for > multihoming. > > > If Link A fails, the BGP session eventually times out and dies: ISP > A's BGP routers withdraw the routes, the IP addresses are then > associated only with provider B. > > And you design your internal routing policy to direct traffic > within your network to the router with an active BGP session. > > Link A's failure is _not_ a total non-event, but a 3-5 minute partial > disruption, while the BGP session times out and updates occur in other > people's routers, is minimal compared to a 3 day outage, if serious > repairs to upstream fiber are required. > > > -- > -J > > > From ken.gilmour at gmail.com Sun Nov 8 14:24:54 2009 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Sun, 8 Nov 2009 14:24:54 -0600 Subject: Failover how much complexity will it add? In-Reply-To: <60758.1257711423@baklawasecrets.com> References: <60758.1257711423@baklawasecrets.com> Message-ID: <5b6f80200911081224w8264cc5x615dd3aa5cc186d6@mail.gmail.com> Hi Adel There are companies like packet exchange (www.packetexchange.net) (whom i have personally used) who will do all of the legwork for you, such as applying for the ASN, address space, transit agreements, and get the tail connections directly to your building. You just need to pay them and buy the equipment (which they can also provide). Probably easier in the long run. NOTE: I am not an employee, or paid affiliate of packet exchange... I have used them for services and am promoting them due to my own good experiences with their services. Regards, Ken 2009/11/8 : > Thanks Seth and James, > > Things are getting a lot clearer. ?The BGP multihoming solution sounds like exactly what I want. ?I have more questions :-) > > Now I suppose I would get my allocation from RIPE as I am UK based? > > Do I also need to apply for an AS number? > > As the IP block is "mine", it is ISP independent. ?i.e. I can take it with me when I decide to use two completely different ISPs? > > Is the obtaining of this IP block, what is referred to as PI space? > > Of course internally I split the /24 up however I want - /28 for untrust range and maybe a routed DMZ block etc.? > > Assuming I apply for IP block and AS number, whats involved and how long does it take to get these babies? > > I know the SSG550's have BGP capabilites. ?As I have two of these in HA mode, does it make sense to do the BGP on these, or should I get dedicated BGP routers? > > Fixing the internal routing policy so traffic is directed at the active BGP connection. ?Whats involved here, preferring one BGP link over the other? > > Thanks again, I obviously need to do some reading of my own, but all the suggestions so far have been very valuable and definitely seem to be pointing in some > fruitful directions. > > Adel > > > > On Sun ? 6:31 PM , "James Hess" mysidia at gmail.com sent: >> On Sun, Nov 8, 2009 at 11:34 AM, ?> baklawasecrets.com> wrote:[..] >> > connections from different providers I would >> still have issues. ?So> I guess that if my primary Internet goes down I >> lose connectivity> to all the publicly addressed devices on that >> connection. Like> dmz hosts and so on. ?I would be interested >> to hear how this> can be avoided if at all or do I have to use the >> same provider. >> You assign multi-homed IP address space to your publicly addressed >> devices,which are not specific to either ISP. You announce to both ISPs, ?and >> you accept some routes from both ISPs. >> >> You get multi-homed IPs, either by having an existing ARIN allocation, >> or getting a /22 from ARIN ?(special allocation available for >> multi-homing), or ?ask for a /24 from ?ISP A or ISP B ?for >> multihoming. >> >> >> If ?Link A fails, the BGP session eventually times out and dies: ISP >> A's ?BGP routers withdraw the routes, ?the IP addresses are then >> associated only with provider B. >> >> And you design your internal routing policy ?to ?direct ?traffic >> within your network to the router with an active BGP session. >> >> Link A's failure is _not_ a total non-event, ?but a 3-5 minute partial >> disruption, while the BGP session times out and updates occur in other >> people's routers, is minimal compared to ?a ?3 day outage, if serious >> repairs to upstream fiber are required. >> >> >> -- >> -J >> >> >> > > > From adel at baklawasecrets.com Sun Nov 8 14:54:58 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Sun, 08 Nov 2009 20:54:58 +0000 Subject: Failover how much complexity will it add? Message-ID: <63854.1257713698@baklawasecrets.com> Hi, Thanks for the info on UKNOF. I've started a thread there with regards to RIPE and obtaining ASN numbers and so on., as this is I guess quite UK specific. Adel On Sun 8:40 PM , Arnold Nipper wrote: > Hi Adel, > > On 08.11.2009 21:24 Ken Gilmour wrote > > > There are companies like packet exchange (www.packetexchange.net [1]) > > I could also comment on PacketExchange, but I do not. If you get more UK > specific now you may perhaps want to post to UKNOF > (http://lists.uknof.org.uk/cgi-bin/mailman/listinfo/uknof/) [2] as well. > > For _independant_ consultancy you may want to have a look at Netsumo > (http://www.netsumo.com/) [3] Ask for Andy Davidson. > > Best regards, > Arnold > -- > Arnold Nipper / nIPper consulting, Sandhausen, Germany > email: arnold at nipper.de phone: +49 6224 9259 299 > mobile: +49 172 2650958 fax: +49 6224 9259 333 > > > > Links: > ------ > [1] > http://webmail.123-reg.co.uk/parse.php?redirect=http://www.packetexchange.n > et[2] > http://webmail.123-reg.co.uk/parse.php?redirect=http://lists.uknof.org.uk/c > gi-bin/mailman/listinfo/uknof/%29[3] > http://webmail.123-reg.co.uk/parse.php?redirect=http://www.netsumo.com/%29 > > From adel at baklawasecrets.com Sun Nov 8 15:00:25 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Sun, 08 Nov 2009 21:00:25 +0000 Subject: Failover how much complexity will it add? Message-ID: <64244.1257714025@baklawasecrets.com> Don't think I sent the below to the list, so resending: Thanks Seth and James, Things are getting a lot clearer. The BGP multihoming solution sounds like exactly what I want. I have more questions :-) Now I suppose I would get my allocation from RIPE as I am UK based? Do I also need to apply for an AS number? As the IP block is "mine", it is ISP independent. i.e. I can take it with me when I decide to use two completely different ISPs? Is the obtaining of this IP block, what is referred to as PI space? Of course internally I split the /24 up however I want - /28 for untrust range and maybe a routed DMZ block etc.? Assuming I apply for IP block and AS number, whats involved and how long does it take to get these babies?> I know the SSG550's have BGP capabilites. As I have two of these in HA mode, does it make sense to do the BGP on these, or should I get dedicated BGP routers? Fixing the internal routing policy so traffic is directed at the active BGP connection. Whats involved here, preferring one BGP link over the other? Thanks again, I obviously need to do some reading of my own, but all the suggestions so far have been very valuable and definitely seem to be pointing in some fruitful directions. Adel On Sun 6:31 PM , James Hess wrote: > On Sun, Nov 8, 2009 at 11:34 AM, wrote: > [..] > > connections from different providers I would still have issues. ?So > > I guess that if my primary Internet goes down I lose connectivity > > to all the publicly addressed devices on that connection. Like > > dmz hosts and so on. ?I would be interested to hear how this > > can be avoided if at all or do I have to use the same provider. > > You assign multi-homed IP address space to your publicly addressed > devices, > which are not specific to either ISP. You announce to both ISPs, and > you accept some routes from both ISPs. > > You get multi-homed IPs, either by having an existing ARIN allocation, > or getting a /22 from ARIN (special allocation available for > multi-homing), or ask for a /24 from ISP A or ISP B for > multihoming. > > If Link A fails, the BGP session eventually times out and dies: ISP > A's BGP routers withdraw the routes, the IP addresses are then > associated only with provider B. > > And you design your internal routing policy to direct traffic > within your network to the router with an active BGP session. > > Link A's failure is _not_ a total non-event, but a 3-5 minute partial > disruption, while the BGP session times out and updates occur in other > people's routers, is minimal compared to a 3 day outage, if serious > repairs to upstream fiber are required. > > -- > -J > > > From adel at baklawasecrets.com Sun Nov 8 15:39:33 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Sun, 08 Nov 2009 21:39:33 +0000 Subject: Failover how much complexity will it add? Message-ID: <65015.1257716373@baklawasecrets.com> Hi, Ok thanks for clearing that up. I'm getting some good feedback on applying for PI and ASN through Ripe LIRs over on the UKNOF so I think I have a handle on this. With regards to BGP and using separate BGP routers. I am announcing my PI space to my upstreams, but I don't need to carry a full Internet routing table, correct? So I can get away with some "lightweight" BGP routers not being an ISP if that makes sense? Adel On Sun 9:26 PM , Ken Gilmour wrote: > Hey, > > Yes you apply to RIPE for your allocation. You should ask them for a > /20 since it's the same price for that as a /24 if you can justify it > (at least with LACNIC where i now get my allocations)... > > You will also need to apply for an ASN > > Correct- the block belongs to you and as long as you contact the > transit provider from the address listed in WHOIS then you should be > able to set up a new agreement easily. > > Yes the block is PI space (provider independent) > > It can take up to 1 month to get your assignments. > > I would recommend getting some different routers for this. I use > OpenBSD in some of my locations which is extremely easy to work with. > I also have some old NS-208 devices running ScreenOS for internal BGP > in one other location. I would not recommend using any router with > less than 1GB of RAM for BGP. in HA Mode you can connect the two > tails, one to each SSG (if they are in active active mode) and > announce it that way (check out anycast), we also do this :). > > The way BGP works is that both connections are active at the same > time, there is no primary and backup, if one goes down you just have > one less to receive traffic over and more traffic on the other, but > unless you stop announcing from one connection traffic will go over > both. > > Regards, > > Ken > > 2009/11/8 : > > Don't think I sent the below to the list, so resending: > > > > Thanks Seth and James, > > > > ?Things are getting a lot clearer. ?The BGP multihoming solution > sounds like exactly what I want. ?I have more questions :-) > > > > Now I suppose I would get my allocation from RIPE as I am UK based? > > > > Do I also need to apply for an AS ?number? > > > > As the IP block is "mine", it is ISP ?independent. ?i.e. I can take > it with me when I decide to use two > > completely different ISPs? > > > > ?Is the obtaining of this IP block, what is referred to as PI space? > > > > Of course internally I split the /24 up however ?I want - /28 for > untrust range and maybe a routed DMZ block > > ?etc.? > > > > Assuming I apply for IP block and AS number, whats involved and how > long does it take to get these babies?> > > > > I know the SSG550's have BGP capabilites. ?As I have two of these in > HA mode, does it make sense to do the BGP > > ?on these, or should I get dedicated BGP routers? > > > > ?Fixing the internal routing policy so traffic is ?directed at the > active BGP connection. ?Whats involved here, > > ?preferring one BGP link over the other? > > > > ?Thanks again, I obviously need to do some ?reading of my own, but > all the suggestions so far have been very valuable > > ?and definitely seem to be pointing in some fruitful directions. > > > > ?Adel > > > > > > > > > > On Sun ? 6:31 PM , James Hess wrote: > > > >> On Sun, Nov 8, 2009 at 11:34 AM, ?wrote: > >> [..] > >> > connections from different providers I would still have issues. ?So > >> > I guess that if my primary Internet goes down I lose connectivity > >> > to all the publicly addressed devices on that connection. Like > >> > dmz hosts and so on. ?I would be interested to hear how this > >> > can be avoided if at all or do I have to use the same provider. > >> > >> You assign multi-homed IP address space to your publicly addressed > >> devices, > >> which are not specific to either ISP. You announce to both ISPs, and > >> you accept some routes from both ISPs. > >> > >> You get multi-homed IPs, either by having an existing ARIN allocation, > >> or getting a /22 from ARIN (special allocation available for > >> multi-homing), or ask for a /24 from ISP A or ISP B for > >> multihoming. > >> > >> If Link A fails, the BGP session eventually times out and dies: ISP > >> A's BGP routers withdraw the routes, the IP addresses are then > >> associated only with provider B. > >> > >> And you design your internal routing policy to direct traffic > >> within your network to the router with an active BGP session. > >> > >> Link A's failure is _not_ a total non-event, but a 3-5 minute partial > >> disruption, while the BGP session times out and updates occur in other > >> people's routers, is minimal compared to a 3 day outage, if serious > >> repairs to upstream fiber are required. > >> > >> -- > >> -J > >> > >> > >> > > > > > > > From sethm at rollernet.us Sun Nov 8 15:53:17 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 08 Nov 2009 13:53:17 -0800 Subject: Failover how much complexity will it add? In-Reply-To: <63854.1257713698@baklawasecrets.com> References: <63854.1257713698@baklawasecrets.com> Message-ID: <4AF73DCD.9020307@rollernet.us> adel at baklawasecrets.com wrote: > Hi, > > Thanks for the info on UKNOF. I've started a thread there with regards to RIPE and obtaining ASN numbers and so on., as > this is I guess quite UK specific. > You will need an AS number regardless of what path you get your addresses from to multihome. In ARIN land the minimum for a multihomed end-site is /22, so if I were to do this here, I would ask one of the upstreams for a /24. I don't know the first thing about RIPE policy. ~Seth From sethm at rollernet.us Sun Nov 8 16:01:47 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 08 Nov 2009 14:01:47 -0800 Subject: Failover how much complexity will it add? In-Reply-To: <65015.1257716373@baklawasecrets.com> References: <65015.1257716373@baklawasecrets.com> Message-ID: <4AF73FCB.60301@rollernet.us> adel at baklawasecrets.com wrote: > Hi, > > Ok thanks for clearing that up. I'm getting some good feedback on applying for PI and ASN through Ripe LIRs over on the UKNOF so I think I have a handle on this. > With regards to BGP and using separate BGP routers. I am announcing my PI space to my upstreams, but I don't need to carry a full Internet routing table, correct? > So I can get away with some "lightweight" BGP routers not being an ISP if that makes sense? > Most will give you three choices: full routes, partial routes (internal, their customers) with default, and default only. If you can't swing full routes then I would go for partial routes as it will at least send traffic for each ISP and their customers directly to them rather than randomly over the other link. It all depends on what you're going to use as your BGP speaking platform. ~Seth From adel at baklawasecrets.com Sun Nov 8 16:13:44 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Sun, 08 Nov 2009 22:13:44 +0000 Subject: Failover how much complexity will it add? Message-ID: <49314.1257718424@baklawasecrets.com> I think partial routes makes perfect sense, makes sense that traffic for customers who are connected to each of my upstreams should go out of the correct BGP link as long as they are up! Now I need to start thinking of BGP router choices, sure I have a plethora of choices :-( On Sun 10:01 PM , Seth Mattinen wrote: > adel at baklawasecrets.com wrote: > > Hi, > > > > Ok thanks for clearing that up. I'm getting some good feedback on > applying for PI and ASN through Ripe LIRs over on the UKNOF so I think I > have a handle on this. > > With regards to BGP and using separate BGP routers. I am announcing my > PI space to my upstreams, but I don't need to carry a full Internet > routing table, correct? > > So I can get away with some "lightweight" BGP routers not being an ISP > if that makes sense? > > > > Most will give you three choices: full routes, partial routes (internal, > their customers) with default, and default only. If you can't swing full > routes then I would go for partial routes as it will at least send > traffic for each ISP and their customers directly to them rather than > randomly over the other link. It all depends on what you're going to use > as your BGP speaking platform. > > ~Seth > > > From marka at isc.org Sun Nov 8 16:17:38 2009 From: marka at isc.org (Mark Andrews) Date: Mon, 09 Nov 2009 09:17:38 +1100 Subject: Congress may require ISPs to block fraud sites H.R.3817 In-Reply-To: Your message of "Fri, 06 Nov 2009 10:47:19 CDT." <75cb24520911060747x3556e01tbb80be8c9e0d58b3@mail.gmail.com> References: <4AF35449.8030700@inline.com> <23895.1257461806@turing-police.cc.vt.edu> <75cb24520911060747x3556e01tbb80be8c9e0d58b3@mail.gmail.com> Message-ID: <200911082217.nA8MHcpZ072848@drugs.dv.isc.org> In message <75cb24520911060747x3556e01tbb80be8c9e0d58b3 at mail.gmail.com>, Christ opher Morrow writes: > On Thu, Nov 5, 2009 at 5:56 PM, wrote: > > On Thu, 05 Nov 2009 16:40:09 CST, Bryan King said: > >> Did I miss a thread on this? Has anyone looked at this yet? > > > >> `(2) INTERNET SERVICE PROVIDERS- Any Internet service provider that, on > >> or through a system or network controlled or operated by the Internet > >> service provider, transmits, routes, provides connections for, or stores > >> any material containing any misrepresentation of the kind prohibited in > >> paragraph (1) shall be liable for any damages caused thereby, including > >> damages suffered by SIPC, if the Internet service provider-- > > > > "routes" sounds the most dangerous part there. =A0Does this mean that if > > we have a BGP peering session with somebody, we need to filter it? > > > > Fortunately, there's the conditions: > > > >> `(A) has actual knowledge that the material contains a misrepresentation > >> of the kind prohibited in paragraph (1), or > > > >> `(B) in the absence of actual knowledge, is aware of facts or > >> circumstances from which it is apparent that the material contains a > >> misrepresentation of the kind prohibited in paragraph (1), and > > > >> upon obtaining such knowledge or awareness, fails to act expeditiously > >> to remove, or disable access to, the material. > > > > So the big players that just provide bandwidth to the smaller players are > > mostly off the hook - AS701 has no reason to be aware that some website i= > n > > Tortuga is in violation (which raises an intresting point - what if the > > site *is* offshore?) > > mail to: abuse at uu.net > Subject: Fraud through your network > > Hi! someone in tortuga on ip address 1.2.3.4 which I accessed through > your network is fraudulently claiming to be the state-bank-of-elbonia. > Just though you should know! Also, I think that HR3817 expects you'll > now stop this from happening! > > -concerned-internet-user > > oops, now they have actual knowledge... I suppose this is a good > reason though to: > > vi /etc/aliases -> > abuse: /dev/null There are still plenty of way to inform a company. Ring up the support line. Registered mail. I suspect a court would see the practice of sending abuse@ to /dev/null in a very poor light especially once the court learns that this is the standard address. A consumer should be able to reasonably assume that the message was delivered. If you bounce then they should be aware that it didn't get through and they can take other steps to inform you. > so, is this bill helping? or hurting? :( > > > > > And the immediate usptreams will fail to obtain knowledge or awareness of > > their customer's actions, the same way they always have. > > > > Move along, nothing to see.. ;) > > to my mind this is the exact same set of problems that the PA state > anti-CP law brought forth... > > -chris > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From sethm at rollernet.us Sun Nov 8 16:18:51 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 08 Nov 2009 14:18:51 -0800 Subject: Failover how much complexity will it add? In-Reply-To: <49314.1257718424@baklawasecrets.com> References: <49314.1257718424@baklawasecrets.com> Message-ID: <4AF743CB.6010308@rollernet.us> adel at baklawasecrets.com wrote: > I think partial routes makes perfect sense, makes sense that traffic for customers who are connected to each of my upstreams should go out of > the correct BGP link as long as they are up! Now I need to start thinking of BGP router choices, sure I have a plethora of choices :-( > Personally I'll always go for full routes if the router has enough memory (software based) or TCAM space (hardware based). Cheaper to do on software platforms though. An entry level Cisco 2811 can take full tables from multiple upstreams with 786MB RAM or even 512. It won't push 100 meg of mixed traffic though. ~Seth From sean at donelan.com Sun Nov 8 16:27:01 2009 From: sean at donelan.com (Sean Donelan) Date: Sun, 8 Nov 2009 17:27:01 -0500 (EST) Subject: Pros and Cons of Cloud Computing in dealing with DDoS In-Reply-To: <84AF8114-8F04-424B-A666-77CD7AA1BABD@arbor.net> References: <002101ca5e42$bddeace0$399c06a0$@com> <16720fe00911051020m4327d713jfa0e1b4043adc23f@mail.gmail.com> <003101ca5e4b$cbe74550$63b5cff0$@com> <55F6AEA5-1FCB-425D-AB1E-9F541C5D44F3@arbor.net> <003801ca5e7a$9b5c9f00$d215dd00$@com> <6cd462c00911051725w200e5480tb33e68cf377592df@mail.gmail.com> <003901ca5e81$65b9ada0$312d08e0$@com> <82pr7wm0z7.fsf@mid.bfk.de> <000101ca5fe1$38848650$a98d92f0$@com> <84AF8114-8F04-424B-A666-77CD7AA1BABD@arbor.net> Message-ID: <200911081700290.32BF5B92.16789@clifden.donelan.com> On Sun, 8 Nov 2009, Dobbins, Roland wrote: >> if the discussion hasn't shifted from that of DDoS to EDoS, it >> should. > > All DDoS is 'EDoS' - it's a distinction without a difference, IMHO. > > DDoS costs opex, can cost direct revenue, can induce capex spends - > it's all about economics at bottom, always has been, or nobody would > care in the first place. And look at click-fraud attacks in which the > miscreants either a) are committing fraud by causing botnets to make > fake clicks so that they can be paid for same or b) wish to exhaust a > rival's advertising budget when he's paying per-impression. Plain old > packet-flooding DDoSes can cost victims/unwitting sources big money in > transit costs, can cost SPs in transit and/or violating peering > agreements, etc. > > There's no need or justification for a separate term; Chris Hoff > bounced 'EDoS' around earlier this year, and the same arguments apply. The so-called "E"DOS is easy to solve. Just re-negotiate your contract with the cloud service provider to exclude that traffic from your bill. After all, if the cloud security provider's security is great, they shouldn't have a problem giving their customers credit for those problems which the cloud solves. No more "E" problems for thec customer, the DOS risk is shifted to the service provider. But now the service provider still needs to solve the same problem. Oh, the cloud service provider won't negotiate, won't give you unlimited service credits, want to charge extra for that protection, don't want to make promises it will work, and so on :-) The same unsolved problems from the 1970's mainframe/timesharing era still haven't been solved with virtualization/cloud/etc. From sethm at rollernet.us Sun Nov 8 16:34:22 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 08 Nov 2009 14:34:22 -0800 Subject: Pros and Cons of Cloud Computing in dealing with DDoS In-Reply-To: <200911081700290.32BF5B92.16789@clifden.donelan.com> References: <002101ca5e42$bddeace0$399c06a0$@com> <16720fe00911051020m4327d713jfa0e1b4043adc23f@mail.gmail.com> <003101ca5e4b$cbe74550$63b5cff0$@com> <55F6AEA5-1FCB-425D-AB1E-9F541C5D44F3@arbor.net> <003801ca5e7a$9b5c9f00$d215dd00$@com> <6cd462c00911051725w200e5480tb33e68cf377592df@mail.gmail.com> <003901ca5e81$65b9ada0$312d08e0$@com> <82pr7wm0z7.fsf@mid.bfk.de> <000101ca5fe1$38848650$a98d92f0$@com> <84AF8114-8F04-424B-A666-77CD7AA1BABD@arbor.net> <200911081700290.32BF5B92.16789@clifden.donelan.com> Message-ID: <4AF7476E.1030904@rollernet.us> Sean Donelan wrote: > > Oh, the cloud service provider won't negotiate, won't give you unlimited > service credits, want to charge extra for that protection, don't want to > make promises it will work, and so on :-) > > The same unsolved problems from the 1970's mainframe/timesharing era > still haven't been solved with virtualization/cloud/etc. > I'm sorry, you must have not received the memo on how cloud computing is the bee's knees and solves all those silly problems that only affect non-cloud services. We'll get you a copy. ~Seth From adel at baklawasecrets.com Sun Nov 8 16:39:48 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Sun, 08 Nov 2009 22:39:48 +0000 Subject: Failover how much complexity will it add? Message-ID: <49883.1257719988@baklawasecrets.com> So if my requirements are as follows: - BGP router capable of holding full Internet routing table. (whether I go for partial or full, I think I want something with full capability). - Capable of pushing 100meg plus of mixed traffic. What are my options? I want to exclude openbsd, or linux with quagga. Probably looking at Cisco or Juniper products, but interested in any other alternatives people suggest. I realise this is quite a broad question, but hoping this will provide a starting point. Oh and if I have missed any specs I should have included above, please let me know. Thanks Adel On Sun 10:18 PM , Seth Mattinen wrote: > adel at baklawasecrets.com wrote: > > I think partial routes makes perfect sense, makes sense that traffic > for customers who are connected to each of my upstreams should go out of > > the correct BGP link as long as they are up! Now I need to start > thinking of BGP router choices, sure I have a plethora of choices :-( > > > > Personally I'll always go for full routes if the router has enough > memory (software based) or TCAM space (hardware based). Cheaper to do on > software platforms though. An entry level Cisco 2811 can take full > tables from multiple upstreams with 786MB RAM or even 512. It won't push > 100 meg of mixed traffic though. > > ~Seth > > > From adel at baklawasecrets.com Sun Nov 8 16:39:50 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Sun, 08 Nov 2009 22:39:50 +0000 Subject: Failover how much complexity will it add? Message-ID: <49885.1257719990@baklawasecrets.com> So if my requirements are as follows: - BGP router capable of holding full Internet routing table. (whether I go for partial or full, I think I want something with full capability). - Capable of pushing 100meg plus of mixed traffic. What are my options? I want to exclude openbsd, or linux with quagga. Probably looking at Cisco or Juniper products, but interested in any other alternatives people suggest. I realise this is quite a broad question, but hoping this will provide a starting point. Oh and if I have missed any specs I should have included above, please let me know. Thanks Adel On Sun 10:18 PM , Seth Mattinen wrote: > adel at baklawasecrets.com wrote: > > I think partial routes makes perfect sense, makes sense that traffic > for customers who are connected to each of my upstreams should go out of > > the correct BGP link as long as they are up! Now I need to start > thinking of BGP router choices, sure I have a plethora of choices :-( > > > > Personally I'll always go for full routes if the router has enough > memory (software based) or TCAM space (hardware based). Cheaper to do on > software platforms though. An entry level Cisco 2811 can take full > tables from multiple upstreams with 786MB RAM or even 512. It won't push > 100 meg of mixed traffic though. > > ~Seth > > > From abalashov at evaristesys.com Sun Nov 8 16:39:47 2009 From: abalashov at evaristesys.com (Alex Balashov) Date: Sun, 08 Nov 2009 17:39:47 -0500 Subject: What DNS Is Not Message-ID: <4AF748B3.7060606@evaristesys.com> Thought-provoking article by Paul Vixie: http://queue.acm.org/detail.cfm?id=1647302 -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 From John.Herbert at ins.com Sun Nov 8 16:46:35 2009 From: John.Herbert at ins.com (John.Herbert at ins.com) Date: Sun, 8 Nov 2009 16:46:35 -0600 Subject: Failover how much complexity will it add? In-Reply-To: <49885.1257719990@baklawasecrets.com> References: <49885.1257719990@baklawasecrets.com> Message-ID: >________________________________________ >From: adel at baklawasecrets.com [adel at baklawasecrets.com] >- BGP router capable of holding full Internet routing table. (whether I go for partial or full, >I think I want something with full capability). --Capable of holding _2_ full internet routing tables if you are looking for diversity. (just being picky ;-) j. From frederick at dahype.org Sun Nov 8 17:30:52 2009 From: frederick at dahype.org (Renato Frederick) Date: Sun, 8 Nov 2009 21:30:52 -0200 Subject: Failover how much complexity will it add? In-Reply-To: <49883.1257719988@baklawasecrets.com> References: <49883.1257719988@baklawasecrets.com> Message-ID: <4E44D13D67C04914BE4B9A33141381D7@medina> There are any problems with quagga+BSD/Linux that you know or something like that? Or in your scenario a "cisco/juniper box" is a requirement? I'm asking this because I'm always running BGP with upstreams providers using quagga on BSD and everything is fine until now. -------------------------------------------------- From: Sent: Sunday, November 08, 2009 8:39 PM To: Subject: Re: Failover how much complexity will it add? > > So if my requirements are as follows: > > - BGP router capable of holding full Internet routing table. (whether I > go for partial or full, I think I want something with full capability). > > - Capable of pushing 100meg plus of mixed traffic. > > What are my options? I want to exclude openbsd, or linux with quagga. > Probably looking at Cisco or Juniper products, but interested > in any other alternatives people suggest. I realise this is quite a broad > question, but hoping this will provide a starting point. Oh and > if I have missed any specs I should have included above, please let me > know. > > Thanks > > Adel From adel at baklawasecrets.com Sun Nov 8 17:36:31 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Sun, 08 Nov 2009 23:36:31 +0000 Subject: Failover how much complexity will it add? Message-ID: <51137.1257723391@baklawasecrets.com> Basically the organisation that I'm working for will not have the skills in house to support a linux or bsd box. They will have trouble with supporting the BGP configuration, however I don't think they will be happy with me if I leave them with a linux box when they don't have linux/unix resource internally. At least with a Cisco or Juniper they are familiar with IOS and it won't be too foreign to them. On Sun 11:30 PM , "Renato Frederick" wrote: > There are any problems with quagga+BSD/Linux that you know or something > like that? > > Or in your scenario a "cisco/juniper box" is a requirement? > > I'm asking this because I'm always running BGP with upstreams providers > using quagga on BSD and everything is fine until now. > > -------------------------------------------------- > From: > Sent: Sunday, November 08, 2009 8:39 PM > To: > Subject: Re: Failover how much complexity will it add? > > > > > So if my requirements are as follows: > > > > - BGP router capable of holding full Internet routing table. (whether I > > > go for partial or full, I think I want something with full capability). > > > > - Capable of pushing 100meg plus of mixed traffic. > > > > What are my options? I want to exclude openbsd, or linux with quagga. > > Probably looking at Cisco or Juniper products, but interested > > in any other alternatives people suggest. I realise this is quite a > broad > > question, but hoping this will provide a starting point. Oh and > > if I have missed any specs I should have included above, please let me > > know. > > > > Thanks > > > > Adel > > > From davet1 at gmail.com Sun Nov 8 17:58:35 2009 From: davet1 at gmail.com (Dave Temkin) Date: Sun, 08 Nov 2009 15:58:35 -0800 Subject: What DNS Is Not In-Reply-To: <4AF748B3.7060606@evaristesys.com> References: <4AF748B3.7060606@evaristesys.com> Message-ID: <4AF75B2B.8050609@gmail.com> Alex Balashov wrote: > Thought-provoking article by Paul Vixie: > > http://queue.acm.org/detail.cfm?id=1647302 > I doubt Henry Ford would appreciate the Mustang. -Dave From abalashov at evaristesys.com Sun Nov 8 18:01:38 2009 From: abalashov at evaristesys.com (Alex Balashov) Date: Sun, 08 Nov 2009 19:01:38 -0500 Subject: What DNS Is Not In-Reply-To: <4AF75B2B.8050609@gmail.com> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> Message-ID: <4AF75BE2.80002@evaristesys.com> Dave Temkin wrote: > Alex Balashov wrote: >> Thought-provoking article by Paul Vixie: >> >> http://queue.acm.org/detail.cfm?id=1647302 >> > I doubt Henry Ford would appreciate the Mustang. I don't think that is a very accurate analogy, and in any case, the argument is not that we should immediately cease at once all the things we do with DNS today. DNS is one of the more centralised systems of the Internet at large; it works because of its reliance on intermediate caching and end-to-end accuracy. It seems to me the claim is more that DNS was not designed to handle them and that if this is what we want to do, perhaps something should supplant DNS, or, alternate methods should be used. For example, perhaps in the case of CDNs geographic optimisation should be in the province of routing (e.g. anycast) and not DNS? -- Alex -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 From davet1 at gmail.com Sun Nov 8 18:06:51 2009 From: davet1 at gmail.com (Dave Temkin) Date: Sun, 08 Nov 2009 16:06:51 -0800 Subject: What DNS Is Not In-Reply-To: <4AF75BE2.80002@evaristesys.com> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> Message-ID: <4AF75D1B.7080307@gmail.com> Alex Balashov wrote: > > > > For example, perhaps in the case of CDNs geographic optimisation > should be in the province of routing (e.g. anycast) and not DNS? > > -- Alex > In most cases it already is. He completely fails to address the concept of Anycast DNS and assumes people are using statically mapped resolvers. He also assumes that DNS is some great expense and that by not allowing tons of caching we're taking money out of peoples' wallets. This is just not true with the exception of very few companies whose job it is to answer DNS requests. -Dave From dga at cs.cmu.edu Sun Nov 8 18:17:16 2009 From: dga at cs.cmu.edu (David Andersen) Date: Sun, 8 Nov 2009 19:17:16 -0500 Subject: What DNS Is Not In-Reply-To: <4AF75D1B.7080307@gmail.com> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> Message-ID: <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> On Nov 8, 2009, at 7:06 PM, Dave Temkin wrote: > Alex Balashov wrote: >> >> >> >> For example, perhaps in the case of CDNs geographic optimisation >> should be in the province of routing (e.g. anycast) and not DNS? >> >> -- Alex >> > In most cases it already is. He completely fails to address the > concept of Anycast DNS and assumes people are using statically > mapped resolvers. > > He also assumes that DNS is some great expense and that by not > allowing tons of caching we're taking money out of peoples' > wallets. This is just not true with the exception of very few > companies whose job it is to answer DNS requests. This myth (that Paul mentions, not to suggest Dave T's comment is a myth) was debunked years ago: "DNS Performance and the Effectiveness of Caching" Jaeyeon Jung, Emil Sit, Hari Balakrishnan, and Robert Morris http://pdos.csail.mit.edu/papers/dns:ton.pdf Basically: Caching of NS records is important, particularly higher up in the hierarchy. Caching of A records is drastically less important - and, not mentioned in the article, the cost imposed by low-TTL A records is shared mostly by the client and the DNS provider, not some third party infrastructure. From the paper: "Our trace-driven simulations yield two findings. First, reducing the TTLs of A records to as low as a few hundred seconds has little adverse effect on hit rates. Second, little benefit is obtained from sharing a forwarding DNS cache among more than 10 or 20 clients. This is consistent with the heavy-tailed nature of access to names. This suggests that the performance of DNS is not as dependent on aggressive caching as is commonly believed, and that the widespread use of dynamic low-TTL A-record bindings should not degrade DNS performance. The reasons for the scalability of DNS are due less to the hierarchical design of its name space or good A-record caching than seems to be widely believed; rather, the cacheability of NS records efficiently partition the name space and avoid overloading any single name server in the Internet." -Dave From bmanning at vacation.karoshi.com Sun Nov 8 18:17:23 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 9 Nov 2009 00:17:23 +0000 Subject: What DNS Is Not In-Reply-To: <4AF748B3.7060606@evaristesys.com> References: <4AF748B3.7060606@evaristesys.com> Message-ID: <20091109001723.GB10998@vacation.karoshi.com.> DNS is NOT always defined by Paul... :) --bill On Sun, Nov 08, 2009 at 05:39:47PM -0500, Alex Balashov wrote: > Thought-provoking article by Paul Vixie: > > http://queue.acm.org/detail.cfm?id=1647302 > > -- > Alex Balashov - Principal > Evariste Systems > Web : http://www.evaristesys.com/ > Tel : (+1) (678) 954-0670 > Direct : (+1) (678) 954-0671 From scott at doc.net.au Sun Nov 8 18:30:10 2009 From: scott at doc.net.au (Scott Howard) Date: Sun, 8 Nov 2009 16:30:10 -0800 Subject: What DNS Is Not In-Reply-To: <4AF75D1B.7080307@gmail.com> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> Message-ID: On Sun, Nov 8, 2009 at 4:06 PM, Dave Temkin wrote: > He also assumes that DNS is some great expense and that by not allowing > tons of caching we're taking money out of peoples' wallets. This is just > not true with the exception of very few companies whose job it is to answer > DNS requests. > And of course in many cases these are the same people who are benefiting significantly by the geo-aware (and sometimes, network-aware) CDN's that this type of DNS service provides. Scott. From bmanning at vacation.karoshi.com Sun Nov 8 18:30:28 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 9 Nov 2009 00:30:28 +0000 Subject: What DNS Is Not In-Reply-To: <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> Message-ID: <20091109003028.GD10998@vacation.karoshi.com.> On Sun, Nov 08, 2009 at 07:17:16PM -0500, David Andersen wrote: > > "Our trace-driven simulations yield two findings. First, reducing the ----------- > -Dave > a simulation is driven from a mathmatical model, not real world constructions. --bill From dga at cs.cmu.edu Sun Nov 8 18:42:18 2009 From: dga at cs.cmu.edu (David Andersen) Date: Sun, 8 Nov 2009 19:42:18 -0500 Subject: What DNS Is Not In-Reply-To: <20091109003028.GD10998@vacation.karoshi.com.> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <20091109003028.GD10998@vacation.karoshi.com.> Message-ID: <85B2BEB6-8E55-4CEF-B3AB-3BC19589B7EB@cs.cmu.edu> On Nov 8, 2009, at 7:30 PM, bmanning at vacation.karoshi.com wrote: > On Sun, Nov 08, 2009 at 07:17:16PM -0500, David Andersen wrote: >> >> "Our trace-driven simulations yield two findings. First, reducing the > > ----------- >> -Dave >> > > a simulation is driven from a mathmatical model, not real world > constructions. Hi, Bill - The paper is worth reading. "The paper also presents the results of trace-driven simulations that explore the effect of varying TTLs and varying degrees of cache sharing on DNS cache hit rates. " emphasis on *trace-driven*. Now, you can argue whether or not their traces are representative (whatever that means) -- they used client DNS and TCP connection traces from MIT and KAIST, so it definitely has a .edu bias, iff there is a bias in DNS traffic for universities vs. "the real world", but to the extent that their traces represent what other groups of users might see, their evaluation seems accurate. -Dave From pauldotwall at gmail.com Sun Nov 8 18:42:48 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Sun, 8 Nov 2009 18:42:48 -0600 Subject: What DNS Is Not In-Reply-To: <4AF75D1B.7080307@gmail.com> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> Message-ID: <620fd17c0911081642w5978196t226b34747dfd6356@mail.gmail.com> On Sun, Nov 8, 2009 at 6:06 PM, Dave Temkin wrote: > In most cases it already is. ?He completely fails to address the concept of > Anycast DNS and assumes people are using statically mapped resolvers. > > He also assumes that DNS is some great expense and that by not allowing tons > of caching we're taking money out of peoples' wallets. ?This is just not > true with the exception of very few companies whose job it is to answer DNS > requests. I don't know why Paul is so concerned, just think how many F root mirrors it helps him sell to unsuspecting saps. The Henry Ford analogy was amazingly apt, imagine 'ol Henry coming back and claiming that automatic transmissions were a misuse of the automobile. Drive Slow ('cause someone left the door open at the old folks home) From bmanning at vacation.karoshi.com Sun Nov 8 18:46:48 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 9 Nov 2009 00:46:48 +0000 Subject: What DNS Is Not In-Reply-To: <85B2BEB6-8E55-4CEF-B3AB-3BC19589B7EB@cs.cmu.edu> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <20091109003028.GD10998@vacation.karoshi.com.> <85B2BEB6-8E55-4CEF-B3AB-3BC19589B7EB@cs.cmu.edu> Message-ID: <20091109004648.GH10998@vacation.karoshi.com.> On Sun, Nov 08, 2009 at 07:42:18PM -0500, David Andersen wrote: > > On Nov 8, 2009, at 7:30 PM, bmanning at vacation.karoshi.com wrote: > > >On Sun, Nov 08, 2009 at 07:17:16PM -0500, David Andersen wrote: > >> > >>"Our trace-driven simulations yield two findings. First, reducing the > > > > ----------- > >> -Dave > >> > > > > a simulation is driven from a mathmatical model, not real world > > constructions. > > Hi, Bill - > > The paper is worth reading. > > "The paper also presents the results of trace-driven simulations that > explore the effect of varying TTLs and varying degrees of cache > sharing on DNS cache hit rates. " > > emphasis on *trace-driven*. Now, you can argue whether or not their > traces are representative (whatever that means) -- they used client > DNS and TCP connection traces from MIT and KAIST, so it definitely has > a .edu bias, iff there is a bias in DNS traffic for universities vs. > "the real world", but to the extent that their traces represent what > other groups of users might see, their evaluation seems accurate. > > -Dave I'm not debating the traces - I wonder about the simulation model. (and yes, I've read the paper) --bill From dga at cs.cmu.edu Sun Nov 8 18:59:24 2009 From: dga at cs.cmu.edu (David Andersen) Date: Sun, 8 Nov 2009 19:59:24 -0500 Subject: What DNS Is Not In-Reply-To: <20091109004648.GH10998@vacation.karoshi.com.> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <20091109003028.GD10998@vacation.karoshi.com.> <85B2BEB6-8E55-4CEF-B3AB-3BC19589B7EB@cs.cmu.edu> <20091109004648.GH10998@vacation.karoshi.com.> Message-ID: <14C46DA5-3CA5-472C-8739-D700666E2D83@cs.cmu.edu> On Nov 8, 2009, at 7:46 PM, bmanning at vacation.karoshi.com wrote: >> >> "The paper also presents the results of trace-driven simulations that >> explore the effect of varying TTLs and varying degrees of cache >> sharing on DNS cache hit rates. " > > I'm not debating the traces - I wonder about the simulation > model. (and yes, I've read the paper) I'm happy to chat about this offline if it bores people, but I'm curious what you're wondering about. The method was pretty simple: - Record the TCP SYN/FIN packets and the DNS packets - For every SYN, figure out what name the computer had resolved to open a connection to this IP address - From the TTL of the DNS, figure out whether finding that binding would have required a DNS lookup There are some obvious potential sources of error - most particularly, name-based HTTP virtual hosting may break some of the assumptions in this - but I'd guess that with a somewhat smaller trace, not too much error is introduced by clients going to different name-based vhosts on the same IP address within a small amount of time. There are certainly some, but I'd be surprised if it was more than a %age of the accesses. Are there other methodological concerns? I'd also point out for this discussion two studies that looked at how accurately one can geo-map clients based on the IP address of their chosen DNS resolver. There are obviously potential pitfalls here (e.g., someone who travels and still uses their "home" resolver). In 2002: Z. M. Mao, C. D. Cranor, F. Douglis, and M. Rabinovich. A Precise and Efficient Evaluation of the Proximity between Web Clients and their Local DNS Servers. In Proc. USENIX Annual Technical Conference, Berkeley, CA, June 2002. Bottom line: It's ok but not great. "We con- clude that DNS is good for very coarse-grained server selection, since 64% of the associations belong to the same Autonomous System. DNS is less useful for finer- grained server selection, since only 16% of the client and local DNS associations are in the same network-aware cluster [13] (based on BGP routing information from a wide set of routers)" We did a wardriving study in Pittsburgh recently where we found that, of the access points we could connect to, 99% of them used their ISP's provided DNS server. Pretty good if your target is residential users: http://www.cs.cmu.edu/~dga/papers/han-imc2008-abstract.html (it's a small part of the paper in section 4.3). -Dave From jgreco at ns.sol.net Sun Nov 8 19:27:19 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 8 Nov 2009 19:27:19 -0600 (CST) Subject: What DNS Is Not In-Reply-To: <4AF75D1B.7080307@gmail.com> from "Dave Temkin" at Nov 08, 2009 04:06:51 PM Message-ID: <200911090127.nA91RJoW022216@aurora.sol.net> > Alex Balashov wrote: > > For example, perhaps in the case of CDNs geographic optimisation > > should be in the province of routing (e.g. anycast) and not DNS? > > > > -- Alex > > In most cases it already is. He completely fails to address the concept > of Anycast DNS and assumes people are using statically mapped resolvers. I'm not sure that's a correct assumption. > He also assumes that DNS is some great expense and that by not allowing > tons of caching we're taking money out of peoples' wallets. This is > just not true with the exception of very few companies whose job it is > to answer DNS requests. It's kind of the same sort of thing that led to what is commonly called the "Kaminsky" vulnerability; the fact that it was predicted years before continues to be ignored. The reason that's relevant is because the resource consumption argument in question is the same one; in the last ten years, bandwidth, CPU, and memory resources have all moved by greater than an order of magnitude in a favorable direction for DNS operators. Paul's argument is best considered on an idealistic basis. For example, with the CDN stuff, people who muck with DNS should absolutely be aware of what Paul is saying; that does not mean that there aren't equally valid reasons to treat DNS in a different manner. The technical problems related to CDN-style use of DNS lookups are pretty well known and understood. The resource consumption issues are trivialized with the advent of high speed Internet, cheaper resources, etc. It doesn't make it idealistically *right*, but it means it is really much less damaging than ten or fifteen years ago. To classify NXDOMAIN mapping and CDN "stupid DNS tricks" in the same class of "DNS lies" is probably damaging to any debate. The former is evil for breaking a lot of things, the latter ia only handing out varied answers for questions one should have the answer to. It's the difference between being authorized to answer and just handing out answers that Paul objects to, and being unauthorized to answer and handing out answers that many people object to. My opinion is that it'd be better for Paul to avoid technical arguments that were weak even in the '90's to support his position. As it stands, people read outdated technical bits and say "well, we know better," which trivializes the remaining technical and idealistic bits. That's damaging, because Paul's dead on about a lot of things. DNS is essentially the wrong level at which to be doing "my web browser could not find X" mapping; it'd be better to build this into web browsers instead. But that's a discussion and a half. :-) ... 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 simon at darkmere.gen.nz Sun Nov 8 19:35:30 2009 From: simon at darkmere.gen.nz (Simon Lyall) Date: Mon, 9 Nov 2009 14:35:30 +1300 (NZDT) Subject: What DNS Is Not In-Reply-To: <4AF75BE2.80002@evaristesys.com> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> Message-ID: On Sun, 8 Nov 2009, Alex Balashov wrote: > For example, perhaps in the case of CDNs geographic optimisation should be in > the province of routing (e.g. anycast) and not DNS? Well my first answer to that would be that GSLB scales down a lot further than anycast. And my first question would be what would the load on the global routing system if a couple of thousand (say) extra sites started using anycast for their content? Each would have their own AS (perhaps reused from elsewher in the company) and a small network or two. Routes would be added and withdrawn regularly and various "stupid BGP tricks" attempted with communitees and prefixes. I heard some anti-spam people use DNS to distribute big databases of information. I bet Vixie would have nasty things to say to the guy who first thought that up. -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT. From jabley at hopcount.ca Sun Nov 8 19:58:16 2009 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 9 Nov 2009 10:58:16 +0900 Subject: What DNS Is Not In-Reply-To: References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> Message-ID: <6E19B84F-D5D7-413C-A918-3B422B8D191D@hopcount.ca> On 2009-11-09, at 10:35, Simon Lyall wrote: > And my first question would be what would the load on the global > routing system if a couple of thousand (say) extra sites started > using anycast for their content? Are you asking what the impact would be of a couple of thousand extra routes in the current full table of ~250,000? That sounds like noise to me (the number, not your question :-) Joe From jmamodio at gmail.com Sun Nov 8 20:02:07 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Sun, 8 Nov 2009 20:02:07 -0600 Subject: What DNS Is Not In-Reply-To: <20091109001723.GB10998@vacation.karoshi.com.> References: <4AF748B3.7060606@evaristesys.com> <20091109001723.GB10998@vacation.karoshi.com.> Message-ID: <202705b0911081802p13c96c4ejfdd5d655dd046096@mail.gmail.com> > DNS is NOT always defined by Paul... :) I agree Bill, but Paul is right on the money about how the DNS is being misused and abused to create more smoke and mirrors in the domain name biz. I really find annoying that some ISPs (several large ones among them) are still tampering with the DNS responses just to put few more coins on their coffers from click through advertising. What I'm really afraid is that all the buzz and $$ from the domain biz will create strong resistance to any efforts to develop a real directory service or better better scheme for resource naming and location. BTW simulations != real world. Cheers Jorge From nonobvious at gmail.com Sun Nov 8 22:38:51 2009 From: nonobvious at gmail.com (Bill Stewart) Date: Sun, 8 Nov 2009 20:38:51 -0800 Subject: Congress may require ISPs to block fraud sites H.R.3817 In-Reply-To: <200911082217.nA8MHcpZ072848@drugs.dv.isc.org> References: <4AF35449.8030700@inline.com> <23895.1257461806@turing-police.cc.vt.edu> <75cb24520911060747x3556e01tbb80be8c9e0d58b3@mail.gmail.com> <200911082217.nA8MHcpZ072848@drugs.dv.isc.org> Message-ID: <18a5e7cb0911082038r7841b04esda83f31a6111c12d@mail.gmail.com> If you're a consumer broadband provider, and you use a DNS blackhole list so that any of your subscribers who tries to reach bigbank1.fakebanks.example.com gets redirected to fakebankwebsitelist.sipc.gov, you might be able to claim that you complied with the law, though the law's aggressive enough that it could be argued otherwise. If you're a transit ISP providing upstream bandwidth the the broadband provider, and some packets are addressed to 1.1.1.257, which is the IP address of a hosting site in Elbonia that carries bigbank1.fakebanks.example.com and innocent.bystander.example.com, the fact that the broadband ISP was using a DNS blackhole list doesn't protect you, because you're still routing packets to 1.1.0.0/16. You could set up a /32 route to send that traffic to null0, censoring innocent.bystander.example.com, or you could get fancy and route it to some squid proxy that cleans up the traffic. But of course the phisher could be using fast-flux, so 5 minutes later that trick no longer works, and by tomorrow the 100,000 phishing websites on the list have added 1,000,000 routes to your peering routers... Not pleasant, but you don't really have much alternative. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From drc at virtualized.org Sun Nov 8 23:35:02 2009 From: drc at virtualized.org (David Conrad) Date: Sun, 8 Nov 2009 21:35:02 -0800 Subject: What DNS Is Not In-Reply-To: <14C46DA5-3CA5-472C-8739-D700666E2D83@cs.cmu.edu> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <20091109003028.GD10998@vacation.karoshi.com.> <85B2BEB6-8E55-4CEF-B3AB-3BC19589B7EB@cs.cmu.edu> <20091109004648.GH10998@vacation.karoshi.com.> <14C46DA5-3CA5-472C-8739-D700666E2D83@cs.cmu.edu> Message-ID: On Nov 8, 2009, at 4:59 PM, David Andersen wrote: > Z. M. Mao, C. D. Cranor, F. Douglis, and M. Rabinovich. A Precise and Efficient Evaluation of the Proximity between Web Clients and their Local DNS Servers. In Proc. USENIX Annual Technical Conference, Berkeley, CA, June 2002. Given that paper is 7 years old and the Internet has changed a bit since 2002 (and the DNS looks to change somewhat drastically in the relatively near future) it might be dangerous to rely too much on their results. This might be an interesting area of additional research... Regards, -drc From fergdawgster at gmail.com Sun Nov 8 23:40:08 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sun, 8 Nov 2009 21:40:08 -0800 Subject: What DNS Is Not In-Reply-To: References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <20091109003028.GD10998@vacation.karoshi.com.> <85B2BEB6-8E55-4CEF-B3AB-3BC19589B7EB@cs.cmu.edu> <20091109004648.GH10998@vacation.karoshi.com.> <14C46DA5-3CA5-472C-8739-D700666E2D83@cs.cmu.edu> Message-ID: <6cd462c00911082140v4f8dcb61tb5a1437134650c7f@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Nov 8, 2009 at 9:35 PM, David Conrad wrote: > On Nov 8, 2009, at 4:59 PM, David Andersen wrote: >> Z. M. Mao, C. D. Cranor, F. Douglis, and M. Rabinovich. A Precise and >> Efficient Evaluation of the Proximity between Web Clients and their >> Local DNS Servers. In Proc. USENIX Annual Technical Conference, >> Berkeley, CA, June 2002. > > Given that paper is 7 years old and the Internet has changed a bit since > 2002 (and the DNS looks to change somewhat drastically in the relatively > near future) it might be dangerous to rely too much on their results. > This might be an interesting area of additional research... > Well, the marketing folks have sure taken advantage of it. It would be nice to see the technology folks... not just lie there and take it. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFK96suq1pz9mNUZTMRAni8AKDyw1NMu2FuXFVQ8vDjLSOONy8T2ACg+tNJ 2sJl1I22u18nJw0PPg1juL4= =QI6K -----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 feldman at twincreeks.net Sun Nov 8 23:42:12 2009 From: feldman at twincreeks.net (Steve Feldman) Date: Sun, 8 Nov 2009 21:42:12 -0800 Subject: [NANOG-announce] Communications Committee members Message-ID: <527D9C1A-3602-4716-AA61-D4EA1C9F3CBC@twincreeks.net> Kris Foster and Michael K. Smith have been chosen to fill two year terms on the Communications Committee (formerly known as the Mailing List Committee.) They join Randy Epstein and Tim Yocum, who are starting the second year of their terms, and Sue Joiner, who is the Merit appointee to the CC. The Steering Committee would also like to thank Simon Lyall for his service on the MLC. His diligence and attention to refining and documenting the committee's processes was greatly appreciated. For the SC, Steve Feldman (chair) _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From adel at baklawasecrets.com Mon Nov 9 04:53:03 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Mon, 09 Nov 2009 10:53:03 +0000 Subject: Failover how much complexity will it add? Message-ID: <17067.1257763983@baklawasecrets.com> You will laugh, but the budget at the moment looks like ?13k. Impossible? Do only linux and openbsd solutions remain in the mix for this pittance? On Sun 11:47 PM , Dale Rumph wrote: > What does your budget look like? A pair of Cisco 7246vxr's with G1's > sitting on the edge of the network would be very effective and still allow > expansion. Or you could go up to the 7609. However this gear may be > slightly overkill. You might be ok with a 3660 enterprise and a ton of > ram. I have done single sessions on them but not with the level of HA your > looking for. > > Just my 2c > > ----- Original Message ----- > From: adel at baklawasecrets.com > To: nanog at nanog.org > Sent: Sun Nov 08 18:36:31 2009 > Subject: Re: Failover how much complexity will it add? > > Basically the organisation that I'm working for will not have the skills > in house to support a linux or bsd box. They will have trouble > with supporting the BGP configuration, however I don't think they will be > happy with me if I leave them with a linux box when they > don't have linux/unix resource internally. At least with a Cisco or > Juniper they are familiar with IOS and it won't be too foreign to them. > > On Sun 11:30 PM , "Renato Frederick" wrote: > > > There are any problems with quagga+BSD/Linux that you know or something > > > like that? > > > > Or in your scenario a "cisco/juniper box" is a requirement? > > > > I'm asking this because I'm always running BGP with upstreams providers > > > using quagga on BSD and everything is fine until now. > > > > -------------------------------------------------- > > From: > > Sent: Sunday, November 08, 2009 8:39 PM > > To: > > Subject: Re: Failover how much complexity will it add? > > > > > > > > So if my requirements are as follows: > > > > > > - BGP router capable of holding full Internet routing table. (whether > I > > > > > go for partial or full, I think I want something with full > capability). > > > > > > - Capable of pushing 100meg plus of mixed traffic. > > > > > > What are my options? I want to exclude openbsd, or linux with quagga. > > > > Probably looking at Cisco or Juniper products, but interested > > > in any other alternatives people suggest. I realise this is quite a > > broad > > > question, but hoping this will provide a starting point. Oh and > > > if I have missed any specs I should have included above, please let > me > > > know. > > > > > > Thanks > > > > > > Adel > > > > > > > > > From adel at baklawasecrets.com Mon Nov 9 05:32:41 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Mon, 09 Nov 2009 11:32:41 +0000 Subject: Failover how much complexity will it add? Message-ID: <18000.1257766361@baklawasecrets.com> Looking at two 100Mbit/s BGP connections, so I think I want something that will do more than 100 but nowhere close to a gig. So full routing table capability with throughput of mixed traffic around 200Mbit/s. If that makes sense. Do the 2850s fall into that sort of price point? Adel On Mon 11:13 AM , Joe Abley wrote: > On 2009-11-09, at 19:53, adel at baklawasecrets.com wrote: > > > You will laugh, but the budget at the moment looks like ?13k. > > Impossible? Do only linux and openbsd solutions remain in the mix > > for this pittance? > > I don't see an indication of the traffic you need to push (maybe I > deleted a message too enthusiastically) but check the 2800 series from > cisco. The 2850 will take full tables and has gigabit interfaces, but > don't expect them to do wire speed. Other 2800s suffer from reduced > RAM, but perhaps you don't need full tables. > > Also look at Juniper J-series boxes, and maybe Force10 S-series boxes. > > There's a healthy market in used cisco gear in most places I have ever > visited, if you don't need new. > > Joe > > > From jgreco at ns.sol.net Mon Nov 9 05:45:10 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 9 Nov 2009 05:45:10 -0600 (CST) Subject: Failover how much complexity will it add? In-Reply-To: <17067.1257763983@baklawasecrets.com> from "adel@baklawasecrets.com" at Nov 09, 2009 10:53:03 AM Message-ID: <200911091145.nA9BjA26085507@aurora.sol.net> > > > Basically the organisation that I'm working for will not have the skills > > > in house to support a linux or bsd box. They will have trouble > > > with supporting the BGP configuration, however I don't think they will be > > > happy with me if I leave them with a linux box when they > > > don't have linux/unix resource internally. At least with a Cisco or > > > Juniper they are familiar with IOS and it won't be too foreign to them. > > On Sun 11:47 PM , Dale Rumph wrote: > > > > What does your budget look like? A pair of Cisco 7246vxr's with G1's > > sitting on the edge of the network would be very effective and still allow > > expansion. Or you could go up to the 7609. However this gear may be > > slightly overkill. You might be ok with a 3660 enterprise and a ton of > > ram. I have done single sessions on them but not with the level of HA your > > looking for. > > > > Just my 2c > You will laugh, but the budget at the moment looks like ??13k. > Impossible? Do only linux and openbsd solutions remain in the mix > for this pittance? No, you have the buy-it-off-eBay solutions as well. "Beware the fakes." If they're familiar with IOS, then they can be familiar with Quagga about as easily as they could be familiar with a switch or other network gizmo that had a Ciscoesque CLI but wasn't actually Cisco. You've painted yourself into a corner. I have a word for you: Reconsider. I don't care what you reconsider, but reconsider something. You can reconsider taking BGP with a full table. You can reconsider Quagga. Or you can reconsider your budget. This is the end result of the "pick any two" problem. Most end user organizations have no need of full routes in BGP. To try to take them dooms TCAM-based equipment at some future point, though if you have a lot of money to throw at it, you can make that point be years in the future. It is essentially planned obsolescence. If you discard the requirement for full routes, you open up a bunch of reasonably-priced possibilities. Finding someone knowledgeable in BSD or Linux isn't that rough. Unlike a Cisco 76xx router, the hardest part of a Quagga-based solution is finding the right mix of hardware and software at the beginning. PC hardware has a lot going for AND against it. There is no reason you can't make a good router out of a PC. If you buy the Cisco software-based routers, you're essentially buying a prepackaged version, except that it'll be specced to avoid any real competition with their low-end TCAM-based offerings. A contemporary PC can easily route gigabits. Vyatta makes what I hear is a fantastic canned solution of some sort, for a reasonable cost, and they will sell just software or software/hardware. If you really can't put it together yourself, there's someone to do it for you. Reconsidering your budget is probably the most painful thing to do, but also opens up the "just buy big Cisco" option. I think my point here would have to be that what you're looking for would have needed big Cisco... ten years ago. Now, dealing with a few hundred megs of traffic, that's not that big a deal, the thing that's killing you is the BGP table size. Your best option may be to see if you can settle for partial routes plus a default. ... 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 adel at baklawasecrets.com Mon Nov 9 05:47:50 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Mon, 09 Nov 2009 11:47:50 +0000 Subject: Failover how much complexity will it add? Message-ID: <18366.1257767270@baklawasecrets.com> Thanks, Their offering certainly looks appealing. Will be interested to hear user experiences of the Vyatta BGP router range. Having said that I will still be examining the Cisco offering, just because of the support, larger user community and skills base issue. However if I can't meet the price point using Cisco, obviously other solutions are going to come into the picture. Adel On Mon 11:39 AM , Arnold Nipper wrote: > On 09.11.2009 11:53 adel at baklawasecrets.com wrote > > > You will laugh, but the budget at the moment looks like ?13k. > > Impossible? Do only linux and openbsd solutions remain in the mix > > for this pittance? > > > > Do you know Vyatta (http://www.vyatta.com/)? [1] CLI and config is > Cisco-ish. Prices e.g. > > Vyatta Appliance, Vyatta 2502, Enterprise Subscription, Basic Warranty, > 1 Year (ships with US Power Cord as standard) (Typically ships in 10-12 > business days) > Price: $2,997.00 > > Best regards, > Arnold > -- > Arnold Nipper / nIPper consulting, Sandhausen, Germany > email: arnold at nipper.de phone: +49 6224 9259 299 > mobile: +49 172 2650958 fax: +49 6224 9259 333 > > > > Links: > ------ > [1] > http://webmail.123-reg.co.uk/parse.php?redirect=http://www.vyatta.com/%29%3 > F > From adel at baklawasecrets.com Mon Nov 9 07:32:50 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Mon, 09 Nov 2009 13:32:50 +0000 Subject: Failover how much complexity will it add? Message-ID: <20391.1257773570@baklawasecrets.com> Thanks, I've taken your advice and decided to reconsider my requirement for a full routing table. I believe I'm being greedy and a partial table will be sufficient. With regards to Linux/BSD, its not the CLI of quagga that will be an issue, rather the sysadmin and lack of supporting infrastructure for Linux boxes within the organisation. So things like package management, syslog servers, monitoring, understanding of security issues etc. I don't want to leave them with a linux/bsd solution that they won't be able to maintain/manage effectively when I am gone. Thanks for your comments. Look forward to hearing which solutions come back into the mix having dropped the full routing table requirement. Regards, Adel On Mon 11:45 AM , Joe Greco wrote: > > > > Basically the organisation that I'm working for will not have the > skills > > > > in house to support a linux or bsd box. They will have trouble > > > > with supporting the BGP configuration, however I don't think they > will be > > > > happy with me if I leave them with a linux box when they > > > > don't have linux/unix resource internally. At least with a Cisco or > > > > Juniper they are familiar with IOS and it won't be too foreign to > them. > > > > On Sun 11:47 PM , Dale Rumph wrote: > > > > > > What does your budget look like? A pair of Cisco 7246vxr's with G1's > > > sitting on the edge of the network would be very effective and still > allow > > > expansion. Or you could go up to the 7609. However this gear may be > > > slightly overkill. You might be ok with a 3660 enterprise and a ton > of > > > ram. I have done single sessions on them but not with the level of HA > your > > > looking for. > > > > > > Just my 2c > > > You will laugh, but the budget at the moment looks like ??13k. > > Impossible? Do only linux and openbsd solutions remain in the mix > > for this pittance? > > No, you have the buy-it-off-eBay solutions as well. "Beware the > fakes." > > If they're familiar with IOS, then they can be familiar with Quagga > about as easily as they could be familiar with a switch or other > network gizmo that had a Ciscoesque CLI but wasn't actually Cisco. > > You've painted yourself into a corner. I have a word for you: > > Reconsider. > > I don't care what you reconsider, but reconsider something. You can > reconsider taking BGP with a full table. You can reconsider Quagga. > Or you can reconsider your budget. This is the end result of the > "pick any two" problem. > > Most end user organizations have no need of full routes in BGP. To > try to take them dooms TCAM-based equipment at some future point, > though if you have a lot of money to throw at it, you can make that > point be years in the future. It is essentially planned obsolescence. > If you discard the requirement for full routes, you open up a bunch > of reasonably-priced possibilities. > > Finding someone knowledgeable in BSD or Linux isn't that rough. > Unlike a Cisco 76xx router, the hardest part of a Quagga-based > solution is finding the right mix of hardware and software at the > beginning. PC hardware has a lot going for AND against it. There is > no reason you can't make a good router out of a PC. If you buy the > Cisco software-based routers, you're essentially buying a prepackaged > version, except that it'll be specced to avoid any real competition > with their low-end TCAM-based offerings. A contemporary PC can > easily route gigabits. Vyatta makes what I hear is a fantastic > canned solution of some sort, for a reasonable cost, and they will > sell just software or software/hardware. If you really can't put > it together yourself, there's someone to do it for you. > > Reconsidering your budget is probably the most painful thing to do, > but also opens up the "just buy big Cisco" option. I think my point > here would have to be that what you're looking for would have needed > big Cisco... ten years ago. Now, dealing with a few hundred megs of > traffic, that's not that big a deal, the thing that's killing you is > the BGP table size. > > Your best option may be to see if you can settle for partial routes > plus a default. > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > [1] > "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. > > > > Links: > ------ > [1] http://webmail.123-reg.co.uk/parse.php?redirect=http://www.sol.net > > From lists at memetic.org Mon Nov 9 07:39:34 2009 From: lists at memetic.org (Adam Armstrong) Date: Mon, 09 Nov 2009 13:39:34 +0000 Subject: Failover how much complexity will it add? In-Reply-To: <5b6f80200911081224w8264cc5x615dd3aa5cc186d6@mail.gmail.com> References: <60758.1257711423@baklawasecrets.com> <5b6f80200911081224w8264cc5x615dd3aa5cc186d6@mail.gmail.com> Message-ID: <4AF81B96.4030303@memetic.org> Ken Gilmour wrote: > Hi Adel > > There are companies like packet exchange (www.packetexchange.net) > (whom i have personally used) who will do all of the legwork for you, > such as applying for the ASN, address space, transit agreements, and > get the tail connections directly to your building. You just need to > pay them and buy the equipment (which they can also provide). Probably > easier in the long run. > Sure, if you want to hand over your entire profit margin to a 3rd party. Do you really want to give away the keys to your business, and rely entirely upon a third party organisation? Better to acquire the skills which are vital to your organisation yourself. > NOTE: I am not an employee, or paid affiliate of packet exchange... I > have used them for services and am promoting them due to my own good > experiences with their services. > I used to work for them. Then as now, I honestly can see little purpose in their productset. adam. > 2009/11/8 : > >> Thanks Seth and James, >> >> Things are getting a lot clearer. The BGP multihoming solution sounds like exactly what I want. I have more questions :-) >> >> Now I suppose I would get my allocation from RIPE as I am UK based? >> >> Do I also need to apply for an AS number? >> >> As the IP block is "mine", it is ISP independent. i.e. I can take it with me when I decide to use two completely different ISPs? >> >> Is the obtaining of this IP block, what is referred to as PI space? >> >> Of course internally I split the /24 up however I want - /28 for untrust range and maybe a routed DMZ block etc.? >> >> Assuming I apply for IP block and AS number, whats involved and how long does it take to get these babies? >> >> I know the SSG550's have BGP capabilites. As I have two of these in HA mode, does it make sense to do the BGP on these, or should I get dedicated BGP routers? >> >> Fixing the internal routing policy so traffic is directed at the active BGP connection. Whats involved here, preferring one BGP link over the other? >> >> Thanks again, I obviously need to do some reading of my own, but all the suggestions so far have been very valuable and definitely seem to be pointing in some >> fruitful directions. >> >> Adel >> >> >> >> On Sun 6:31 PM , "James Hess" mysidia at gmail.com sent: >> >>> On Sun, Nov 8, 2009 at 11:34 AM, >> baklawasecrets.com> wrote:[..] >>> >>>> connections from different providers I would >>>> >>> still have issues. So> I guess that if my primary Internet goes down I >>> lose connectivity> to all the publicly addressed devices on that >>> connection. Like> dmz hosts and so on. I would be interested >>> to hear how this> can be avoided if at all or do I have to use the >>> same provider. >>> You assign multi-homed IP address space to your publicly addressed >>> devices,which are not specific to either ISP. You announce to both ISPs, and >>> you accept some routes from both ISPs. >>> >>> You get multi-homed IPs, either by having an existing ARIN allocation, >>> or getting a /22 from ARIN (special allocation available for >>> multi-homing), or ask for a /24 from ISP A or ISP B for >>> multihoming. >>> >>> >>> If Link A fails, the BGP session eventually times out and dies: ISP >>> A's BGP routers withdraw the routes, the IP addresses are then >>> associated only with provider B. >>> >>> And you design your internal routing policy to direct traffic >>> within your network to the router with an active BGP session. >>> >>> Link A's failure is _not_ a total non-event, but a 3-5 minute partial >>> disruption, while the BGP session times out and updates occur in other >>> people's routers, is minimal compared to a 3 day outage, if serious >>> repairs to upstream fiber are required. >>> >>> >>> -- >>> -J >>> >>> >>> >>> >> >> > > From adel at baklawasecrets.com Mon Nov 9 08:21:52 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Mon, 09 Nov 2009 14:21:52 +0000 Subject: Failover how much complexity will it add? Message-ID: <21131.1257776512@baklawasecrets.com> Actually thinking about this, I still need to understand the implications of not taking a full routing table to my setup. So what is the likely impact going to be if I take partial instead of full routing table. Would appreciate any feedback on this. My organisation is only looking at using BGP as a means of failover between two separate upstream ISPs. We are not an ISP. Thanks Adel On Mon 1:32 PM , adel at baklawasecrets.com wrote: > Thanks, > > I've taken your advice and decided to reconsider my requirement for a > full routing table. I believe I'm being greedy and a partial table will be > sufficient. With regards to Linux/BSD, its not the CLI of quagga that will > be an issue, rather the sysadmin and lack of supporting infrastructure for > Linux boxes within the organisation. So things like package management, > syslog servers, monitoring, understanding of security issues etc. I don't > want to leave them with a linux/bsd solution that they won't be able to > maintain/manage effectively when I am gone. > > Thanks for your comments. Look forward to hearing which solutions come > back into the mix having dropped the full routing table requirement. > > Regards, > > Adel > > On Mon 11:45 AM , Joe Greco wrote: > > > > > > Basically the organisation that I'm working for will not have the > > skills > > > > > in house to support a linux or bsd box. They will have trouble > > > > > with supporting the BGP configuration, however I don't think they > > will be > > > > > happy with me if I leave them with a linux box when they > > > > > don't have linux/unix resource internally. At least with a Cisco > or > > > > > Juniper they are familiar with IOS and it won't be too foreign to > > them. > > > > > > On Sun 11:47 PM , Dale Rumph wrote: > > > > > > > > What does your budget look like? A pair of Cisco 7246vxr's with > G1's > > > > sitting on the edge of the network would be very effective and > still > > allow > > > > expansion. Or you could go up to the 7609. However this gear may be > > > > slightly overkill. You might be ok with a 3660 enterprise and a ton > > of > > > > ram. I have done single sessions on them but not with the level of > HA > > your > > > > looking for. > > > > > > > > Just my 2c > > > > > You will laugh, but the budget at the moment looks like ??13k. > > > Impossible? Do only linux and openbsd solutions remain in the mix > > > for this pittance? > > > > No, you have the buy-it-off-eBay solutions as well. "Beware the > > fakes." > > > > If they're familiar with IOS, then they can be familiar with Quagga > > about as easily as they could be familiar with a switch or other > > network gizmo that had a Ciscoesque CLI but wasn't actually Cisco. > > > > You've painted yourself into a corner. I have a word for you: > > > > Reconsider. > > > > I don't care what you reconsider, but reconsider something. You can > > reconsider taking BGP with a full table. You can reconsider Quagga. > > Or you can reconsider your budget. This is the end result of the > > "pick any two" problem. > > > > Most end user organizations have no need of full routes in BGP. To > > try to take them dooms TCAM-based equipment at some future point, > > though if you have a lot of money to throw at it, you can make that > > point be years in the future. It is essentially planned obsolescence. > > If you discard the requirement for full routes, you open up a bunch > > of reasonably-priced possibilities. > > > > Finding someone knowledgeable in BSD or Linux isn't that rough. > > Unlike a Cisco 76xx router, the hardest part of a Quagga-based > > solution is finding the right mix of hardware and software at the > > beginning. PC hardware has a lot going for AND against it. There is > > no reason you can't make a good router out of a PC. If you buy the > > Cisco software-based routers, you're essentially buying a prepackaged > > version, except that it'll be specced to avoid any real competition > > with their low-end TCAM-based offerings. A contemporary PC can > > easily route gigabits. Vyatta makes what I hear is a fantastic > > canned solution of some sort, for a reasonable cost, and they will > > sell just software or software/hardware. If you really can't put > > it together yourself, there's someone to do it for you. > > > > Reconsidering your budget is probably the most painful thing to do, > > but also opens up the "just buy big Cisco" option. I think my point > > here would have to be that what you're looking for would have needed > > big Cisco... ten years ago. Now, dealing with a few hundred megs of > > traffic, that's not that big a deal, the thing that's killing you is > > the BGP table size. > > > > Your best option may be to see if you can settle for partial routes > > plus a default. > > > > ... JG > > -- > > Joe Greco - sol.net Network Services - Milwaukee, WI - > http://www.sol.net [1] > > [1] > > "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. > > > > > > > > Links: > > ------ > > [1] http://webmail.123-reg.co.uk/parse.php?redirect=http://www.sol.net > [2] > > > > > > > > Links: > ------ > [1] http://webmail.123-reg.co.uk/parse.php?redirect=http://www.sol.net > [2] > http://webmail.123-reg.co.uk/parse.php?redirect=http://webmail.123-reg.co.u > k/parse.php%3Fredirect%3Dhttp://www.sol.net > From jgreco at ns.sol.net Mon Nov 9 09:20:28 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 9 Nov 2009 09:20:28 -0600 (CST) Subject: Failover how much complexity will it add? In-Reply-To: <20391.1257773570@baklawasecrets.com> from "adel@baklawasecrets.com" at Nov 09, 2009 01:32:50 PM Message-ID: <200911091520.nA9FKSjf095152@aurora.sol.net> > > Thanks, > > I've taken your advice and decided to reconsider my requirement for a full > routing table. I believe I'm being greedy and a partial table will be > sufficient. With regards to Linux/BSD, its not the CLI of quagga that will > be an issue, rather the sysadmin and lack of supporting infrastructure for > Linux boxes within the organisation. So things like package management, You don't need to run Apache on your router. > syslog servers, If you didn't have syslog servers for the Cisco, you don't need one for the Quagga. > monitoring, If you didn't monitor the Cisco, you don't need to monitor the Quagga. > understanding of security issues etc. What security issues? The thing is, people get all tied up over this idea that it is some major ongoing burden to support a Linux based device. I have a shocker for you. The CPE your residential broadband relies on may well run Linux, and you didn't even know it. The wifi router you use may run Linux. There are thousands of embedded uses for Linux. I highly doubt that the average TiVo user has a degree in Linux. Many different things you use in day-to-day life run Linux, BSD, VxWorks, or whatever ... mostly without any need of someone to handhold them on security issues. Of course, security issues do come up. But they do with Cisco as well. A proper Linux router doesn't have ports open, aside from bgp and ssh, and those can be firewalled appropriately. This makes it very difficult to have any meaningful "security problems" relating to the platform... You can expect the occasional issue. Just like anything else. But trying to compare it to security issues on a general Linux platform is only meaningful if you're trying to argue against the solution. (I'm a BSD guy myself, but I don't see any reason for undue Linux paranoia) > I don't want to leave them with a linux/bsd solution that they won't be > able to maintain/manage effectively when I am gone. If they're unable to maintain something as straightforward as BSD or Linux when you're gone, this raises alarm bells as to whether or not BGP is really suited for them. BGP is *much* more arcane, relatively speaking. You can go to your local bookstore and pick up a ton of Linux or BSD sysadm books, but you'll be lucky to find a book on BGP. > Thanks for your comments. Look forward to hearing which solutions come > back into the mix having dropped the full routing table requirement. There's a whole plethora of BGP-capable gear that becomes possible once you make that call. Cisco and Juniper both make good gear. A variety of other mfrs do as well. Something as old as an Ascend GRF 400 (fast ethernet, line speed, 150K routes, ~1998?) is perfectly capable of dealing with the load, though I mention this primarily to make the point that there is a lot of equipment within the last decade that can support 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 jbates at brightok.net Mon Nov 9 09:28:21 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 09 Nov 2009 09:28:21 -0600 Subject: What DNS Is Not In-Reply-To: <4AF748B3.7060606@evaristesys.com> References: <4AF748B3.7060606@evaristesys.com> Message-ID: <4AF83515.8040404@brightok.net> Alex Balashov wrote: > Thought-provoking article by Paul Vixie: > > http://queue.acm.org/detail.cfm?id=1647302 > Bah, many of the CDN's I've dealt with don't seed geographical responses based on DNS, but rather use many out of band methods for determining what response they will hand out. The primary reason for short cutting cache is to limit failures in case the system a requestor is going to goes down. And different CDN's behave differently, depending on how they deliver content, support provider interconnects, etc. I'd hardly call many of them DNS lies, as they do resolve you to the appropriate IP, and if that IP disappears, try and quickly get you to another appropriate IP. The rest of the article was informative,though. Jack From adel at baklawasecrets.com Mon Nov 9 10:36:08 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Mon, 09 Nov 2009 16:36:08 +0000 Subject: Failover how much complexity will it add? Message-ID: <23744.1257784568@baklawasecrets.com> Hi Joe, I agree with most of what you say below regarding linux sysadmin, BSD etc. I'm quite happy and actually would prefer building a linux solution on our own hardware. However, politically I think this is going to be difficult. I just feel that they will be more comfortable with embedded network boxes as a pose to a linux solution. I guess what I'm saying is this is partially a political thing. Adel On Mon 3:20 PM , Joe Greco wrote: > > > > Thanks, > > > > I've taken your advice and decided to reconsider my requirement for a > full > > routing table. I believe I'm being greedy and a partial table will be > > sufficient. With regards to Linux/BSD, its not the CLI of quagga that > will > > be an issue, rather the sysadmin and lack of supporting infrastructure > for > > Linux boxes within the organisation. So things like package management, > > > You don't need to run Apache on your router. > > > syslog servers, > > If you didn't have syslog servers for the Cisco, you don't need one for > the Quagga. > > > monitoring, > > If you didn't monitor the Cisco, you don't need to monitor the Quagga. > > > understanding of security issues etc. > > What security issues? > > The thing is, people get all tied up over this idea that it is some major > ongoing burden to support a Linux based device. > > I have a shocker for you. The CPE your residential broadband relies on > may > well run Linux, and you didn't even know it. The wifi router you use may > run > Linux. There are thousands of embedded uses for Linux. I highly doubt > that > the average TiVo user has a degree in Linux. Many different things you > use > in day-to-day life run Linux, BSD, VxWorks, or whatever ... mostly > without any > need of someone to handhold them on security issues. > > Of course, security issues do come up. But they do with Cisco as well. > > A proper Linux router doesn't have ports open, aside from bgp and ssh, > and > those can be firewalled appropriately. This makes it very difficult to > have > any meaningful "security problems" relating to the platform... > > You can expect the occasional issue. Just like anything else. But trying > to > compare it to security issues on a general Linux platform is only > meaningful > if you're trying to argue against the solution. > > (I'm a BSD guy myself, but I don't see any reason for undue Linux > paranoia) > > > I don't want to leave them with a linux/bsd solution that they won't be > > > able to maintain/manage effectively when I am gone. > > If they're unable to maintain something as straightforward as BSD or > Linux > when you're gone, this raises alarm bells as to whether or not BGP is > really suited for them. BGP is *much* more arcane, relatively speaking. > You can go to your local bookstore and pick up a ton of Linux or BSD > sysadm > books, but you'll be lucky to find a book on BGP. > > > Thanks for your comments. Look forward to hearing which solutions come > > back into the mix having dropped the full routing table requirement. > > There's a whole plethora of BGP-capable gear that becomes possible once > you make that call. Cisco and Juniper both make good gear. A variety > of other mfrs do as well. Something as old as an Ascend GRF 400 (fast > ethernet, line speed, 150K routes, ~1998?) is perfectly capable of > dealing > with the load, though I mention this primarily to make the point that > there > is a lot of equipment within the last decade that can support this. > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > [1] > "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. > > > > Links: > ------ > [1] http://webmail.123-reg.co.uk/parse.php?redirect=http://www.sol.net > > From psirt at cisco.com Mon Nov 9 11:30:03 2009 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Mon, 9 Nov 2009 12:30:03 -0500 Subject: Cisco Security Advisory: Transport Layer Security Renegotiation Vulnerability Message-ID: <200911091210.tls@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Transport Layer Security Renegotiation Vulnerability Advisory ID: cisco-sa-20091109-tls http://www.cisco.com/warp/public/707/cisco-sa-20091109-tls.shtml Revision 1.0 For Public Release 2009 November 9 1600 UTC (GMT) Summary ======= An industry-wide vulnerability exists in the Transport Layer Security (TLS) protocol that could impact any Cisco product that uses any version of TLS and SSL. The vulnerability exists in how the protocol handles session renegotiation and exposes users to a potential man-in-the-middle attack. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20091109-tls.shtml. Affected Products ================= Cisco is currently evaluating products for possible exposure to these TLS issues. Products will only be listed in the Vulnerable Products or Products Confirmed Not Vulnerable sections of this advisory when a final determination about product exposure is made. Products that are not listed in either of these two sections are still being evaluated. Vulnerable Products - ------------------- This section will be updated when more information is available. Products Confirmed Not Vulnerable - --------------------------------- The following products are confirmed not vulnerable: * Cisco AnyConnect VPN Client This section will be updated when more information is available. Details ======= TLS and its predecessor, SSL, are cryptographic protocols that provide security for communications over IP data networks such as the Internet. An industry-wide vulnerability exists in the TLS protocol that could impact any Cisco product that uses any version of TLS and SSL. The vulnerability exists in how the protocol handles session renegotiation and exposes users to a potential man-in-the-middle attack. The following Cisco Bug IDs are being used to track potential exposure to the SSL and TLS issues. The bugs listed below do not confirm that a product is vulnerable, but rather that the product is under investigation by the appropriate product teams. Registered Cisco customers can view these bugs via Cisco's Bug Toolkit: http://www.cisco.com/pcgi-bin/Support/Bugtool/launch_bugtool.pl +------------------------------------------------------------+ | Product | Bug ID | |----------------------------+-------------------------------| | Cisco Adaptive Security | CSCtd01491 | | Device Manager (ASDM) | | |----------------------------+-------------------------------| | Cisco AON Software | CSCtd01646 | | | | |----------------------------+-------------------------------| | Cisco AON Healthcare for | CSCtd01652 | | HIPAA and ePrescription | | |----------------------------+-------------------------------| | Cisco Application and | CSCtd01529 | | Content Networking System | | | (ACNS) Software | | |----------------------------+-------------------------------| | Cisco Application | CSCtd01480 | | Networking Manager | | |----------------------------+-------------------------------| | Cisco ASA 5500 Series | CSCtd00697 | | Adaptive Security | | | Appliances | | |----------------------------+-------------------------------| | Cisco ASA Advanced | | | Inspection and Prevention | CSCtd01539 | | (AIP) Security Services | | | Module | | |----------------------------+-------------------------------| | Cisco AVS 3100 Series | CSCtd01566 | | Application Velocity | | | System | | |----------------------------+-------------------------------| | Cisco Catalyst 6500 Series | CSCtd06389 | | SSL Services Module | | |----------------------------+-------------------------------| | Firewall Services Module | CSCtd04061 | | FWSM | | |----------------------------+-------------------------------| | Cisco CSS 11000 Series | CSCtd01636 | | Content Services Switches | | |----------------------------+-------------------------------| | Cisco Unified SIP Phones | CSCtd01446 | | | | |----------------------------+-------------------------------| | Cisco Data Center Network | CSCtd02635 | | Manager | | |----------------------------+-------------------------------| | Cisco Data Mobility | CSCtd02642 | | Manager | | |----------------------------+-------------------------------| | Cisco Digital Media | CSCtd01703 | | Encoders | | |----------------------------+-------------------------------| | Cisco Digital Media | CSCtd01692 | | Manager | | |----------------------------+-------------------------------| | Cisco Digital Media | CSCtd01718 | | Players | | |----------------------------+-------------------------------| | Cisco Emergency Responder | CSCtd02650 | | | | |----------------------------+-------------------------------| | Cisco IOS Software | CSCtd00658 | | | | |----------------------------+-------------------------------| | Cisco IOS XE Software | CSCtd00658 | | | | |----------------------------+-------------------------------| | Cisco IOS XR Software | CSCtd02658 | | | | |----------------------------+-------------------------------| | Cisco IP Communicator | CSCtd02662 | | | | |----------------------------+-------------------------------| | CATOS | CSCtd00662 | | | | |----------------------------+-------------------------------| | Cisco IronPort Appliances | CSCtd02069 | | | | |----------------------------+-------------------------------| | Cisco Unified MeetingPlace | CSCtd02709 | | | | |----------------------------+-------------------------------| | Cisco NAC Appliance (Clean | CSCtd01453 | | Access) | | |----------------------------+-------------------------------| | Cisco NAC Guest Server | CSCtd01462 | | | | |----------------------------+-------------------------------| | Cisco NAC Profiler | CSCtd02716 | | | | |----------------------------+-------------------------------| | Cisco Network Analysis | CSCtd02729 | | Module Software (NAM) | | |----------------------------+-------------------------------| | Cisco Network Registrar | CSCtd02748 | | | | |----------------------------+-------------------------------| | Cisco ONS 15500 Series | CSCtd02769 | | | | |----------------------------+-------------------------------| | Cisco Physical Access | CSCtd02777 | | Gateways | | |----------------------------+-------------------------------| | Cisco Physical Access | CSCtd03912 | | Manager | | |----------------------------+-------------------------------| | Cisco Physical Security | CSCtd03920 | | ISM | | |----------------------------+-------------------------------| | Cisco QoS Device Manager | CSCtd03923 | | | | |----------------------------+-------------------------------| | Cisco Secure Access | CSCtd00725 | | Control Server (ACS) | | |----------------------------+-------------------------------| | Cisco Secure Desktop | CSCtd03928 | | | | |----------------------------+-------------------------------| | Cisco Secure Services | CSCtd03935 | | Client | | |----------------------------+-------------------------------| | Cisco Security Agent CSA | CSCtd02689 | | | | |----------------------------+-------------------------------| | Cisco Security Monitoring, | CSCtd02654 | | Analysis and Response | | | System (MARS) | | |----------------------------+-------------------------------| | Cisco Unified IP Phones | CSCtd04121 | | | | |----------------------------+-------------------------------| | Cisco Service Control | CSCtd04171 | | Subscriber Manager | | |----------------------------+-------------------------------| | Cisco TelePresence Manager | CSCtd01771 | | | | |----------------------------+-------------------------------| | Telepresence for Consumer | CSCtd01752 | | | | |----------------------------+-------------------------------| | Cisco TelePresence | CSCtd01742 | | Recording Server | | |----------------------------+-------------------------------| | Cisco Network Asset | CSCtd04198 | | Collector | | |----------------------------+-------------------------------| | Cisco Unified | CSCtd01282 | | Communications Manager | | | (CallManager) | | |----------------------------+-------------------------------| | Cisco Unified Business | CSCtd05731 | | Attendant Console | | |----------------------------+-------------------------------| | Cisco Unified Contact | CSCtd05790 | | Center Enterprise | | |----------------------------+-------------------------------| | Cisco Unified Contact | CSCtd05790 | | Center Express | | |----------------------------+-------------------------------| | Cisco Unified Contact | CSCtd05755 | | Center Management Portal | | |----------------------------+-------------------------------| | Cisco Unified Contact | CSCtd05790 | | Center Products | | |----------------------------+-------------------------------| | Cisco Unified Department | CSCtd05733 | | Attendant Console | | |----------------------------+-------------------------------| | Cisco Unified E-Mail | CSCtd05756 | | Interaction Manager | | |----------------------------+-------------------------------| | Cisco Unified Enterprise | CSCtd05735 | | Attendant Console | | |----------------------------+-------------------------------| | Cisco Unified Mobile | CSCtd05762 | | Communicator | | |----------------------------+-------------------------------| | Cisco Unified Mobility | CSCtd05786 | | | | |----------------------------+-------------------------------| | Cisco Unified Mobility | CSCtd05783 | | Advantage | | |----------------------------+-------------------------------| | Cisco Unified Operations | CSCtd05784 | | Manager | | |----------------------------+-------------------------------| | Cisco Unified Personal | CSCtd05759 | | Communicator | | |----------------------------+-------------------------------| | Cisco Unified Presence | CSCtd05791 | | | | |----------------------------+-------------------------------| | Cisco Unified Provisioning | CSCtd05777 | | Manager | | |----------------------------+-------------------------------| | Cisco Unified Quick | CSCtd05738 | | Connect | | |----------------------------+-------------------------------| | Cisco Unified Service | CSCtd05780 | | Monitor | | |----------------------------+-------------------------------| | Cisco Unified Service | CStCd05778 | | Statistics Manager | | |----------------------------+-------------------------------| | Cisco Unified SIP Proxy | CSCtd05765 | | | | |----------------------------+-------------------------------| | Cisco Unity | CSCtd02855 | | | | |----------------------------+-------------------------------| | Cisco NX-OS Software | CSCtd00699 and CSCtd00703 | | | | |----------------------------+-------------------------------| | Cisco Video Portal | CSCtd04097 | | | | |----------------------------+-------------------------------| | Cisco Video Surveillance | CSCtd02831 | | Media Server Software | | |----------------------------+-------------------------------| | Cisco Video Surveillance | CSCtd02780 | | Operations Manager | | | Software | | |----------------------------+-------------------------------| | Cisco Wide Area File | CSCtd04106 | | Services Software (WAFS) | | |----------------------------+-------------------------------| | Cisco Wireless Control | CSCtd01625 | | System | | |----------------------------+-------------------------------| | Cisco Wireless LAN | CSCtd01611 | | Controller (WLAN) | | |----------------------------+-------------------------------| | Cisco Wireless Location | CSCtd04115 | | Appliance | | |----------------------------+-------------------------------| | CiscoWorks Common Services | CSCtd01597 | | Software | | |----------------------------+-------------------------------| | CiscoWorks Wireless LAN | CSCtd04111 | | Solution Engine (WLSE) | | +------------------------------------------------------------+ This vulnerability has been assigned the Common Vulnerabilities and Exposures (CVE) identifier CVE-2009-3555. Vulnerability Scoring Details +---------------------------- Cisco has provided scores for the vulnerability in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at: http://intellishield.cisco.com/security/alertmanager/cvss * TLS Renegotiation Vulnerability (all Cisco Bugs above) CVSS Base Score - 4.3 Access Vector - Network Access Complexity - Medium Authentication - None Confidentiality Impact - None Integrity Impact - Partial Availability Impact - None CVSS Temporal Score - 4.1 Exploitability - Functional Remediation Level - Unavailable Report Confidence - Confirmed Impact ====== This section will be updated when more information is available. Software Versions and Fixes =========================== This section will be updated to include fixed software versions for affected Cisco products as they become available. Workarounds =========== Workarounds are being investigated. This section will be updated when more information becomes available. Obtaining Fixed Software ======================== Cisco has released free software updates that address this vulnerability. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml. Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts - -------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com. Customers using Third Party Support Organizations - ------------------------------------------------- Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts - ----------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== This vulnerability was initially discovered by Marsh Ray and Steve Dispensa from PhoneFactor, Inc. Cisco is not aware of any malicious exploitation of this vulnerability. Proof-of-concept exploit code has been published for this vulnerability. Status of this Notice: INTERIM ============================== THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at: http://www.cisco.com/warp/public/707/cisco-sa-20091109-tls.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +------------------------------------------------------------+ | Revision 1.0 | 2009-November-9 | Initial public release | +------------------------------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html. This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt. +-------------------------------------------------------------------- Copyright 2008-2009 Cisco Systems, Inc. All rights reserved. +-------------------------------------------------------------------- Updated: Nov 09, 2009 Document ID: 111046 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkr4TCsACgkQ86n/Gc8U/uDNWgCfYptXVZhz0qn2DvRh2zUtZ5EF OS4AoJediPm3/t9XqYIdrjR5PNP25iY/ =SkAu -----END PGP SIGNATURE----- From sethm at rollernet.us Mon Nov 9 11:23:41 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 09 Nov 2009 09:23:41 -0800 Subject: Failover how much complexity will it add? In-Reply-To: <21131.1257776512@baklawasecrets.com> References: <21131.1257776512@baklawasecrets.com> Message-ID: <4AF8501D.6080904@rollernet.us> adel at baklawasecrets.com wrote: > Actually thinking about this, I still need to understand the implications of not taking a full routing table to my setup. So what is the likely impact going to be if I take partial instead of full routing table. Would appreciate any feedback on this. My organisation is only looking at using BGP as a means of failover between two separate upstream ISPs. We are not an ISP. > Some Cisco L3 switches should support this fine. A 3560 or 3750 can speak BGP and route at line rate as long as your total number of routes will fit in its TCAM space. Ask your upstreams how big a partial feed from them is. "desktop routing" template: The selected template optimizes the resources in the switch to support this level of features for 8 routed interfaces and 1024 VLANs. number of unicast mac addresses: 3K number of IPv4 IGMP groups + multicast routes: 1K number of IPv4 unicast routes: 11K number of directly-connected IPv4 hosts: 3K number of indirect IPv4 routes: 8K number of IPv4 policy based routing aces: 0.5K number of IPv4/MAC qos aces: 0.5K number of IPv4/MAC security aces: 1K If you ever need IPv6 it gets smaller: number of unicast mac addresses: 2K number of IPv4 IGMP groups + multicast routes: 1K number of IPv4 unicast routes: 3K number of directly-connected IPv4 hosts: 2K number of indirect IPv4 routes: 1K number of IPv6 multicast groups: 1.125k number of directly-connected IPv6 addresses: 2K number of indirect IPv6 unicast routes: 1K number of IPv4 policy based routing aces: 0 number of IPv4/MAC qos aces: 0.5K number of IPv4/MAC security aces: 1K number of IPv6 policy based routing aces: 0 number of IPv6 qos aces: 0.625k number of IPv6 security aces: 0.5K Anything in Cisco land that can hold two full tables in hardware and can do line rate is going to be hideously expensive. ~Seth From Valdis.Kletnieks at vt.edu Mon Nov 9 11:36:42 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 09 Nov 2009 12:36:42 -0500 Subject: Failover how much complexity will it add? In-Reply-To: Your message of "Mon, 09 Nov 2009 13:39:34 GMT." <4AF81B96.4030303@memetic.org> References: <60758.1257711423@baklawasecrets.com> <5b6f80200911081224w8264cc5x615dd3aa5cc186d6@mail.gmail.com> <4AF81B96.4030303@memetic.org> Message-ID: <11584.1257788202@turing-police.cc.vt.edu> On Mon, 09 Nov 2009 13:39:34 GMT, Adam Armstrong said: > Sure, if you want to hand over your entire profit margin to a 3rd party. > Do you really want to give away the keys to your business, and rely > entirely upon a third party organisation? Better to acquire the skills > which are vital to your organisation yourself. Umm.. You did that *anyhow* the instant you paid somebody else to run the cables to your location rather than dig your own ditches. Similarly for electricity and everything else you don't create yourself. > > NOTE: I am not an employee, or paid affiliate of packet exchange... I > > have used them for services and am promoting them due to my own good > > experiences with their services. > > > I used to work for them. Then as now, I honestly can see little purpose > in their productset. There's little purpose if you're an ISP that's supposed to be good at BGP yourself. If however, your business is running a /24 worth of webservers that sells your company's product, and Best Practices says you should be multi-homed but the in-house skill set runs more to Apache than BGP, a well-designed BGP appliance can be a ghodsend. (I admit I missed the OP's statement of what business line they were in). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From adel at baklawasecrets.com Mon Nov 9 11:40:07 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Mon, 09 Nov 2009 17:40:07 +0000 Subject: BGP Peer Selection Considerations Message-ID: <24278.1257788407@baklawasecrets.com> Hi, Thanks to everyone that replied to my post on failover configuration. This has lead me to this post. I'm at a point now where I'm looking at dual-homing with two BGP peers upstream. Now what I am looking at doing is as follows: BGP Peer with Provider A who is multihomed to other providers. BGP Peer with Provider B who is not peered with provider A I have an existing relationship with provider A, colo, cross connects etc. Provider A has offered to get the PI space, ASN number, purchase the transit for us with provider B and manage cross connects to provider B (they say they have a diverse "fibre backhaul network"). This is quite attractive from a support and billing perspective. Also suspect that provider A will be able to get more attractive pricing from Provider B than I would be able to. Am I missing things that I need to consider? From charles at thewybles.com Mon Nov 9 11:42:19 2009 From: charles at thewybles.com (Charles Wyble) Date: Mon, 9 Nov 2009 09:42:19 -0800 Subject: Failover how much complexity will it add? In-Reply-To: <49883.1257719988@baklawasecrets.com> References: <49883.1257719988@baklawasecrets.com> Message-ID: On Nov 8, 2009, at 2:39 PM, adel at baklawasecrets.com wrote: > > So if my requirements are as follows: > > - BGP router capable of holding full Internet routing table. > (whether I go for partial or full, I think I want something with > full capability). > > - Capable of pushing 100meg plus of mixed traffic. > > What are my options? I want to exclude openbsd, or linux with quagga. Why is that? From dholmes at mwdh2o.com Mon Nov 9 11:58:47 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Mon, 9 Nov 2009 09:58:47 -0800 Subject: Failover how much complexity will it add? In-Reply-To: <23744.1257784568@baklawasecrets.com> References: <23744.1257784568@baklawasecrets.com> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E0A004C3E@usmsxt104.mwd.h2o> Most purpose-built routing "appliances" use ternary content addressable memory (TCAM) in order to accomplish deterministic, hardware-based, longest-prefix lookups in large routing tables, such as a full Internet BGP feed. TCAM is used to replace software-based table lookup algorithms which have been empirically shown to lack scalability as the number of routes in the routing table increases, and as the line rate in/out of the routers increases. Current TCAM hardware-based routing engines scale to 10 Gbps, and beyond. Much research has been done in this area in the last 15 years. I don't think general purpose BSD/Linux systems meet the scalability requirement for deterministic network design. Nothing political about that. -----Original Message----- From: adel at baklawasecrets.com [mailto:adel at baklawasecrets.com] Sent: Monday, November 09, 2009 8:36 AM To: nanog at nanog.org Subject: Re: Failover how much complexity will it add? Hi Joe, I agree with most of what you say below regarding linux sysadmin, BSD etc. I'm quite happy and actually would prefer building a linux solution on our own hardware. However, politically I think this is going to be difficult. I just feel that they will be more comfortable with embedded network boxes as a pose to a linux solution. I guess what I'm saying is this is partially a political thing. Adel On Mon 3:20 PM , Joe Greco wrote: > > > > Thanks, > > > > I've taken your advice and decided to reconsider my requirement for a > full > > routing table. I believe I'm being greedy and a partial table will be > > sufficient. With regards to Linux/BSD, its not the CLI of quagga that > will > > be an issue, rather the sysadmin and lack of supporting infrastructure > for > > Linux boxes within the organisation. So things like package management, > > > You don't need to run Apache on your router. > > > syslog servers, > > If you didn't have syslog servers for the Cisco, you don't need one for > the Quagga. > > > monitoring, > > If you didn't monitor the Cisco, you don't need to monitor the Quagga. > > > understanding of security issues etc. > > What security issues? > > The thing is, people get all tied up over this idea that it is some major > ongoing burden to support a Linux based device. > > I have a shocker for you. The CPE your residential broadband relies on > may > well run Linux, and you didn't even know it. The wifi router you use may > run > Linux. There are thousands of embedded uses for Linux. I highly doubt > that > the average TiVo user has a degree in Linux. Many different things you > use > in day-to-day life run Linux, BSD, VxWorks, or whatever ... mostly > without any > need of someone to handhold them on security issues. > > Of course, security issues do come up. But they do with Cisco as well. > > A proper Linux router doesn't have ports open, aside from bgp and ssh, > and > those can be firewalled appropriately. This makes it very difficult to > have > any meaningful "security problems" relating to the platform... > > You can expect the occasional issue. Just like anything else. But trying > to > compare it to security issues on a general Linux platform is only > meaningful > if you're trying to argue against the solution. > > (I'm a BSD guy myself, but I don't see any reason for undue Linux > paranoia) > > > I don't want to leave them with a linux/bsd solution that they won't be > > > able to maintain/manage effectively when I am gone. > > If they're unable to maintain something as straightforward as BSD or > Linux > when you're gone, this raises alarm bells as to whether or not BGP is > really suited for them. BGP is *much* more arcane, relatively speaking. > You can go to your local bookstore and pick up a ton of Linux or BSD > sysadm > books, but you'll be lucky to find a book on BGP. > > > Thanks for your comments. Look forward to hearing which solutions come > > back into the mix having dropped the full routing table requirement. > > There's a whole plethora of BGP-capable gear that becomes possible once > you make that call. Cisco and Juniper both make good gear. A variety > of other mfrs do as well. Something as old as an Ascend GRF 400 (fast > ethernet, line speed, 150K routes, ~1998?) is perfectly capable of > dealing > with the load, though I mention this primarily to make the point that > there > is a lot of equipment within the last decade that can support this. > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > [1] > "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. > > > > Links: > ------ > [1] http://webmail.123-reg.co.uk/parse.php?redirect=http://www.sol.net > > From sethm at rollernet.us Mon Nov 9 13:04:49 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 09 Nov 2009 11:04:49 -0800 Subject: BGP Peer Selection Considerations In-Reply-To: <24278.1257788407@baklawasecrets.com> References: <24278.1257788407@baklawasecrets.com> Message-ID: <4AF867D1.1020700@rollernet.us> adel at baklawasecrets.com wrote: > Hi, > > Thanks to everyone that replied to my post on failover configuration. This has lead me to this post. I'm at a point now where I'm looking at dual-homing with two BGP peers upstream. Now what I am looking at doing is as follows: > > BGP Peer with Provider A who is multihomed to other providers. > BGP Peer with Provider B who is not peered with provider A > > I have an existing relationship with provider A, colo, cross connects etc. Provider A has offered to get the PI space, ASN number, purchase the transit for us with provider B and manage cross connects to provider B (they say they have a diverse "fibre backhaul network"). This is quite attractive from a support and billing perspective. Also suspect that provider A will be able to get more attractive pricing from Provider B than I would be able to. > > Am I missing things that I need to consider? > Don't let them cross connect over their network. Bring it in to your site separate from A, otherwise there's no point in the multihoming exercise. ~Seth From herrin-nanog at dirtside.com Mon Nov 9 13:10:43 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Mon, 9 Nov 2009 14:10:43 -0500 Subject: BGP Peer Selection Considerations In-Reply-To: <24278.1257788407@baklawasecrets.com> References: <24278.1257788407@baklawasecrets.com> Message-ID: <3c3e3fca0911091110v7dc7823crba12803ac64e407b@mail.gmail.com> On Mon, Nov 9, 2009 at 12:40 PM, wrote: > I have an existing relationship with provider A, colo, cross connects > etc. ?Provider A has offered to get the PI space, ASN number, > purchase the transit for us with provider B and manage cross > connects to provider B (they say they have a diverse "fibre > backhaul network"). ?This is quite attractive from a support > and billing perspective. ?Also suspect that provider A will be > able to get more attractive pricing from Provider B than I > would be able to. > > Am I missing things that I need to consider? What happens when provider A is bought by provider C and you want to dump provider C but keep provider B? You'll have created a conflict of interest for provider B in any negotiation you have with them. Be aware that provider A's diverse network for provider A's service is the same diverse network they'll use to connect you to provider B. As a result, many or most of the outages which impact provider A will also impact your connectivity to provider B, defeating the central purpose of having a provider B. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jgreco at ns.sol.net Mon Nov 9 13:19:32 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 9 Nov 2009 13:19:32 -0600 (CST) Subject: Failover how much complexity will it add? In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E0A004C3E@usmsxt104.mwd.h2o> from "Holmes, David A" at Nov 09, 2009 09:58:47 AM Message-ID: <200911091919.nA9JJWAm003567@aurora.sol.net> > Most purpose-built routing "appliances" use ternary content > addressable memory (TCAM) in order to accomplish deterministic, > hardware-based, longest-prefix lookups in large routing tables, > such as a full Internet BGP feed. TCAM is used to replace > software-based table lookup algorithms which have been > empirically shown to lack scalability as the number of routes > in the routing table increases, and as the line rate in/out of > the routers increases. Current TCAM hardware-based routing > engines scale to 10 Gbps, and beyond. Much research has been > done in this area in the last 15 years. > > I don't think general purpose BSD/Linux systems meet the > scalability requirement for deterministic network design. > Nothing political about that. Whoa. How'd you manage to get it completely inverted? It's the TCAM based platforms that are a scaling problem. You have to do a forklift upgrade of them every now and then in order to assure yourself of being able to continue to hold a full table. Put another way: Software-based lookup tables do tend to perform more slowly as the number of routes grows. However, a Linux or BSD router that was operational in 1999 will still be functional today, able to route a full table today. It will suffer a mild degradation in forwarding capabilities as the route table grows, but this is mild. Hardware-based lookup tables have a really bad failure mode: they fill. When they fill, generally speaking, parts of the Internet may vanish. It is great to be able to forward at line speed up to the table capacity of the box, but you can do the same thing on a software-based platform... to get line rate simply means you need to ensure you've got sufficient excess resources. Software-based platforms are finicky at high PPS rates, but these days it'd be kinda hard to come up with a platform that *couldn't* route 1Gbps. We're talking a fraction of that for this guy who has a few 100Mbps links. Now, of course, if he plans to scale that few 100Mbps links up to a few 10Gbps links in the next few years, then there is definitely a question about the suitability of a software-based platform, but it is also the case that any inexpensive TCAM-based platform that might be selected will also need to be upgraded ... at significant expense. I would have thought that this lesson would still be fresh in the minds of people, as we just passed 256K routes a little while ago and broke a whole bunch of Catalyst 6500/7600 SUP720-3B's (etc). I guess the pain isn't as memorable as I thought. ... 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 jgreco at ns.sol.net Mon Nov 9 13:20:59 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 9 Nov 2009 13:20:59 -0600 (CST) Subject: BGP Peer Selection Considerations In-Reply-To: <4AF867D1.1020700@rollernet.us> from "Seth Mattinen" at Nov 09, 2009 11:04:49 AM Message-ID: <200911091920.nA9JKxJB003644@aurora.sol.net> > Don't let them cross connect over their network. Bring it in to your > site separate from A, otherwise there's no point in the multihoming > exercise. s/no point/less benefit/ ... 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 sethm at rollernet.us Mon Nov 9 13:57:17 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 09 Nov 2009 11:57:17 -0800 Subject: BGP Peer Selection Considerations In-Reply-To: <3c3e3fca0911091110v7dc7823crba12803ac64e407b@mail.gmail.com> References: <24278.1257788407@baklawasecrets.com> <3c3e3fca0911091110v7dc7823crba12803ac64e407b@mail.gmail.com> Message-ID: <4AF8741D.30600@rollernet.us> William Herrin wrote: > > Be aware that provider A's diverse network for provider A's service is > the same diverse network they'll use to connect you to provider B. As > a result, many or most of the outages which impact provider A will > also impact your connectivity to provider B, defeating the central > purpose of having a provider B. > I'll just add to the OP: you want them independent *to you* not internally diverse between themselves. How would that help your site be independent? I'm sure the billing/support sounds attractive (and they get to upsell you), but you won't gain provider independence, only a larger bill. ~Seth From aaron at wholesaleinternet.net Mon Nov 9 13:58:56 2009 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Mon, 9 Nov 2009 13:58:56 -0600 Subject: AT&T Admin In-Reply-To: <200911091920.nA9JKxJB003644@aurora.sol.net> References: <4AF867D1.1020700@rollernet.us> from "Seth Mattinen" at Nov 09, 2009 11:04:49 AM <200911091920.nA9JKxJB003644@aurora.sol.net> Message-ID: <06e701ca6177$122ef430$368cdc90$@net> Ok, guess we'll see if this really works or not. Would an AT&T mail admin contact me offlist? I have an issue I need to start moving up the chain since I'm getting nowhere fast with normal channels. Thanks, Aaron From vixie at isc.org Mon Nov 9 14:00:49 2009 From: vixie at isc.org (Paul Vixie) Date: Mon, 09 Nov 2009 20:00:49 +0000 Subject: What DNS Is Not In-Reply-To: <4AF75D1B.7080307@gmail.com> (Dave Temkin's message of "Sun\, 08 Nov 2009 16\:06\:51 -0800") References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> Message-ID: i loved the henry ford analogy -- but i think henry ford would have said that the automatic transmission was a huge step forward since he wanted everybody to have a car. i can't think of anything that's happened in the automobile market that henry ford wouldn't've wished he'd thought of. i knew that the "incoherent DNS" market would rise up on its hind legs and say all kinds of things in its defense against the ACM Queue article, and i'm not going to engage with every such speaker. there three more-specific replies below. Dave Temkin writes: > Alex Balashov wrote: >> >> For example, perhaps in the case of CDNs geographic optimisation should >> be in the province of routing (e.g. anycast) and not DNS? > > In most cases it already is. He completely fails to address the concept > of Anycast DNS and assumes people are using statically mapped resolvers. "anycast DNS" appears to mean different things to different people. i didn't mention it because to me anycast dns is a bgp level construct whereby the same (coherent) answer is available from many servers having the same IP address but not actually being the same server. see for example how several root name servers are distributed. . if you are using "anycast DNS" to mean carefully crafted (noncoherent) responses from a similarly distributed/advertised set of servers, then i did address your topic in the ACM Queue article. David Andersen writes: > This myth ... was debunked years ago: > > "DNS Performance and the Effectiveness of Caching" > Jaeyeon Jung, Emil Sit, Hari Balakrishnan, and Robert Morris > http://pdos.csail.mit.edu/papers/dns:ton.pdf my reason for completely dismissing that paper at the time it came out was that it tried to predict the system level impact of DNS caching while only looking at the resolver side and only from one client population having a small and uniform user base. show me a "trace driven simulation" of the whole system, that takes into account significant authority servers (which would include root, tld, and amazon and google) as well as significant caching servers (which would not include MIT's or any university's but which would definitely include comcast's and cox's and att's), and i'll read it with high hopes. note that ISC SIE (see http://sie.isc.org/ may yet grow into a possible data source for this kind of study, which is one of the reasons we created it.) Simon Lyall writes: > I heard some anti-spam people use DNS to distribute big databases of > information. I bet Vixie would have nasty things to say to the guy who > first thought that up. someone made this same comment in the slashdot thread. my response there and here is: the MAPS RBL has always delivered coherent responses where the answer is an expressed fact, not kerned in any way based on the identity of the querier. perhaps my language in the ACM Queue article was imprecise ("delivering facts rather than policy") and i should have stuck with the longer formulation ("incoherent responses crafted based on the identity of the querier rather than on the authoritative data"). -- Paul Vixie KI6YSY From sethm at rollernet.us Mon Nov 9 14:02:49 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 09 Nov 2009 12:02:49 -0800 Subject: AT&T Admin In-Reply-To: <06e701ca6177$122ef430$368cdc90$@net> References: <4AF867D1.1020700@rollernet.us> from "Seth Mattinen" at Nov 09, 2009 11:04:49 AM <200911091920.nA9JKxJB003644@aurora.sol.net> <06e701ca6177$122ef430$368cdc90$@net> Message-ID: <4AF87569.1030304@rollernet.us> Aaron Wendel wrote: > Ok, guess we'll see if this really works or not. > > Would an AT&T mail admin contact me offlist? I have an issue I need to > start moving up the chain since I'm getting nowhere fast with normal > channels. > FYI replying and changing the subject keeps your message under the same thread. You should start a new message. ~Seth From nonobvious at gmail.com Mon Nov 9 17:04:06 2009 From: nonobvious at gmail.com (Bill Stewart) Date: Mon, 9 Nov 2009 15:04:06 -0800 Subject: What DNS Is Not In-Reply-To: References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <4AF75D1B.7080307@gmail.com> Message-ID: <18a5e7cb0911091504t60035f2m902eb7873c3e7e14@mail.gmail.com> Hi, Paul - I share your dislike of DNS services that break the DNS model for profit in ways that break applications. For instance, returning the IP address of your company's port-80 web server instead of NXDOMAIN not only breaks non-port-80-http applications, it also breaks the behaviour that browsers such as IE and Firefox expect, which is that if a domain isn't found, they'll do something that the user chooses, such as sending another query to the user's favorite search engine. There is one special case for which I don't mind having DNS servers lie about query results, which is the phishing/malware protection service. In that case, the DNS response is redirecting you to the IP address of a server that'll tell you "You really didn't want to visit PayPa11.com - it's a fake" or "You really didn't want to visit dgfdsgsdfgdfgsdfgsfd.example.ru - it's malware". It's technically broken, but you really _didn't_ want to go there anyway. It's a bit friendlier to administrators and security people if the response page gives you the IP address that the query would have otherwise returned, though obviously you don't want it to be a clickable hyperlink. However, I disagree with your objections to CDN, and load balancers in general - returning the address of the server that example.com thinks will give you the best performance is reasonable. (I'll leave the question of whether DNS queries are any good at determining that to the vendors.) Maintaining a cachable ns.example.com record in the process is friendly to everybody; maintaining cachable A records is less important. If reality is changing rapidly, then the directory that points to the reality can reasonably change also. On Mon, Nov 9, 2009 at 12:00 PM, Paul Vixie wrote: > i loved the henry ford analogy -- but i think henry ford would have said that > the automatic transmission was a huge step forward since he wanted everybody > to have a car. ?i can't think of anything that's happened in the automobile > market that henry ford wouldn't've wished he'd thought of. Well, there's the built-in GPS navigation system that tells you to go drive off the dock into the water, because it wasn't smart enough to know that the route the map database showed in dotted lines was a ferryboat... -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From abalashov at evaristesys.com Mon Nov 9 17:06:56 2009 From: abalashov at evaristesys.com (Alex Balashov) Date: Mon, 09 Nov 2009 18:06:56 -0500 Subject: What DNS Is Not In-Reply-To: References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> Message-ID: <4AF8A090.9050201@evaristesys.com> When I write applications that make DNS queries, I expect the request to turn NXDOMAIN if the host does not exist - HTTP as well as non-HTTP, but especially non-HTTP. Anything else is COMPLETELY UNACCEPTABLE. I don't understand how or why this could possibly be controversial. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 From davidu at everydns.net Mon Nov 9 17:15:09 2009 From: davidu at everydns.net (David Ulevitch) Date: Mon, 09 Nov 2009 18:15:09 -0500 Subject: What DNS Is Not In-Reply-To: <4AF8A090.9050201@evaristesys.com> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <4AF8A090.9050201@evaristesys.com> Message-ID: <4AF8A27D.2080405@everydns.net> On 11/9/09 6:06 PM, Alex Balashov wrote: > Anything else is COMPLETELY UNACCEPTABLE. I don't understand how or why > this could possibly be controversial. Because some people want the ability and choice to block DNS responses they don't like; just as they have the ability and choice to reject email they don't want to accept. When the conficker worms phones home to one of the 50,000 potential domains names it computes each day, there are a lot of IT folks out there that wish their local resolver would simply reject those DNS requests so that infected machines in their network fail to phone home. To use your language, I don't understand how or why this could possibly be controversial. -- Apparently it is. -David From patrick at ianai.net Mon Nov 9 17:24:52 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 9 Nov 2009 18:24:52 -0500 Subject: What DNS Is Not In-Reply-To: References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> Message-ID: On Nov 9, 2009, at 3:00 PM, Paul Vixie wrote: > i loved the henry ford analogy -- but i think henry ford would have > said that > the automatic transmission was a huge step forward since he wanted > everybody > to have a car. i can't think of anything that's happened in the > automobile > market that henry ford wouldn't've wished he'd thought of. > > i knew that the "incoherent DNS" market would rise up on its hind > legs and > say all kinds of things in its defense against the ACM Queue > article, and i'm > not going to engage with every such speaker. Paul: I completely agree with you that putting wildcards into the roots, GTLDs, CCTLDs, etc. is a Bad Idea and should be squashed. Users have little (no?) choice on their TLDs. Stopping those is a Good Thing, IMHO. However, I own a domain (or couple hundred :). I have a wildcard on my domain. I point it where I want. I feel not the slightest twinge of guilt at this. Do you think this is a Bad Thing, or should this be allowed? Also, why are you upset at OpenDNS. People _intentionally_ select to use OpenDNS, which is clear in its terms of service, and even allows users to turn off the bits that annoy you. Exactly what is the issue? And lastly, DNS is not "truth". DNS is the Domain Name System, it is what people configure it to be. You yourself have argued things like responding with "192.0.2.1" for DNSBLs that are being shut down. That is clearly NOT "truth". -- TTFN, patrick P.S. Yes, I am intentionally ignoring the CDN side of things. Find me in private, preferably with a shot of single-malt, if you want my opinion. > there three more-specific replies below. > > Dave Temkin writes: > >> Alex Balashov wrote: >>> >>> For example, perhaps in the case of CDNs geographic optimisation >>> should >>> be in the province of routing (e.g. anycast) and not DNS? >> >> In most cases it already is. He completely fails to address the >> concept >> of Anycast DNS and assumes people are using statically mapped >> resolvers. > > "anycast DNS" appears to mean different things to different people. > i didn't > mention it because to me anycast dns is a bgp level construct > whereby the > same (coherent) answer is available from many servers having the > same IP > address but not actually being the same server. see for example how > several > root name servers are distributed. . > if you > are using "anycast DNS" to mean carefully crafted (noncoherent) > responses > from a similarly distributed/advertised set of servers, then i did > address > your topic in the ACM Queue article. > > David Andersen writes: > >> This myth ... was debunked years ago: >> >> "DNS Performance and the Effectiveness of Caching" >> Jaeyeon Jung, Emil Sit, Hari Balakrishnan, and Robert Morris >> http://pdos.csail.mit.edu/papers/dns:ton.pdf > > my reason for completely dismissing that paper at the time it came > out was > that it tried to predict the system level impact of DNS caching > while only > looking at the resolver side and only from one client population > having a > small and uniform user base. show me a "trace driven simulation" of > the > whole system, that takes into account significant authority servers > (which > would include root, tld, and amazon and google) as well as significant > caching servers (which would not include MIT's or any university's but > which would definitely include comcast's and cox's and att's), and > i'll > read it with high hopes. note that ISC SIE (see http://sie.isc.org/ > may > yet grow into a possible data source for this kind of study, which > is one > of the reasons we created it.) > > Simon Lyall writes: > >> I heard some anti-spam people use DNS to distribute big databases of >> information. I bet Vixie would have nasty things to say to the guy >> who >> first thought that up. > > someone made this same comment in the slashdot thread. my response > there > and here is: the MAPS RBL has always delivered coherent responses > where the > answer is an expressed fact, not kerned in any way based on the > identity of > the querier. perhaps my language in the ACM Queue article was > imprecise > ("delivering facts rather than policy") and i should have stuck with > the > longer formulation ("incoherent responses crafted based on the > identity of > the querier rather than on the authoritative data"). > -- > Paul Vixie > KI6YSY > From jbates at brightok.net Mon Nov 9 17:26:16 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 09 Nov 2009 17:26:16 -0600 Subject: What DNS Is Not In-Reply-To: <4AF8A090.9050201@evaristesys.com> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <4AF8A090.9050201@evaristesys.com> Message-ID: <4AF8A518.8020806@brightok.net> Alex Balashov wrote: > When I write applications that make DNS queries, I expect the request to > turn NXDOMAIN if the host does not exist - HTTP as well as non-HTTP, but > especially non-HTTP. > Actually, the one I hate is when they return NXDOMAIN for any RR type other than A, breaking DNS. Most common is AAAA to return NXDOMAIN, which immediately has the effect of breaking the ability to fallback to A (why query for another RR, when the domain doesn't exist?). Several high end load balancers have the ability to do this according to the content providers I have addressed the matter with. As a side note, any IPv6 capable stack which has determined there is IPv6 connectivity (through 6to4, native, teredo, etc) cannot access these sites. For an example (an ongoing issue) see www.txu.com. Responds to A, gives NXDOMAIN to AAAA. I will not shame the high profile websites that have fixed their loadbalancers/DNS servers, but everyone on this list knows and has probably used them. Jack From oberman at es.net Mon Nov 9 17:47:13 2009 From: oberman at es.net (Kevin Oberman) Date: Mon, 09 Nov 2009 15:47:13 -0800 Subject: What DNS Is Not In-Reply-To: Your message of "Mon, 09 Nov 2009 18:24:52 EST." Message-ID: <20091109234713.7849F1CC2E@ptavv.es.net> > From: "Patrick W. Gilmore" > Date: Mon, 9 Nov 2009 18:24:52 -0500 > > On Nov 9, 2009, at 3:00 PM, Paul Vixie wrote: > > > i loved the henry ford analogy -- but i think henry ford would have > > said that > > the automatic transmission was a huge step forward since he wanted > > everybody > > to have a car. i can't think of anything that's happened in the > > automobile > > market that henry ford wouldn't've wished he'd thought of. > > > > i knew that the "incoherent DNS" market would rise up on its hind > > legs and > > say all kinds of things in its defense against the ACM Queue > > article, and i'm > > not going to engage with every such speaker. > > Paul: I completely agree with you that putting wildcards into the > roots, GTLDs, CCTLDs, etc. is a Bad Idea and should be squashed. > Users have little (no?) choice on their TLDs. Stopping those is a > Good Thing, IMHO. > > However, I own a domain (or couple hundred :). I have a wildcard on > my domain. I point it where I want. I feel not the slightest twinge > of guilt at this. Do you think this is a Bad Thing, or should this be > allowed? > > Also, why are you upset at OpenDNS. People _intentionally_ select to > use OpenDNS, which is clear in its terms of service, and even allows > users to turn off the bits that annoy you. Exactly what is the issue? > > And lastly, DNS is not "truth". DNS is the Domain Name System, it is > what people configure it to be. You yourself have argued things like > responding with "192.0.2.1" for DNSBLs that are being shut down. > That is clearly NOT "truth". I find it mildly amusing that my first contact with Paul was about 25 years ago when he was at DEC and I objected to his use of a wildcard for dec.com. The situations are not parallel and the Internet was a very different animal in those days (and DEC was mostly DECnet), but still I managed to maintain a full set of MX records for all of our DECnet systems. That said, I really, really get annoyed by the abuse of the DNS system. -- 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 andrew at accessplus.com.au Mon Nov 9 17:53:52 2009 From: andrew at accessplus.com.au (Andrew Cox) Date: Tue, 10 Nov 2009 10:23:52 +1030 Subject: What DNS Is Not In-Reply-To: <4AF8A27D.2080405@everydns.net> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <4AF8A090.9050201@evaristesys.com> <4AF8A27D.2080405@everydns.net> Message-ID: <4AF8AB90.1000706@accessplus.com.au> David Ulevitch wrote: > On 11/9/09 6:06 PM, Alex Balashov wrote: > >> Anything else is COMPLETELY UNACCEPTABLE. I don't understand how or why >> this could possibly be controversial. > > Because some people want the ability and choice to block DNS responses > they don't like; just as they have the ability and choice to reject > email they don't want to accept. > > When the conficker worms phones home to one of the 50,000 potential > domains names it computes each day, there are a lot of IT folks out > there that wish their local resolver would simply reject those DNS > requests so that infected machines in their network fail to phone home. Dealing with 10k~ uni students who like to spread new viruses faster than STD's I often make light of the fact that we can use OpenDNS to a) keep tabs on who's infected at what sites and b) prevent them from possibly doing more damage by phoning home with info or to collect instructions. > > To use your language, I don't understand how or why this could > possibly be controversial. -- Apparently it is. > > -David > It's as David says, there are a lot of us who would rather have the choice than not have it. If that's not acceptable to some then that's their decision however as a part of our network this DNS 'tomfoolery' is something that both we and the end user see benefits from so I don't see it going away anytime soon. Regards, Andrew Cox AccessPlus HNA From bmanning at vacation.karoshi.com Mon Nov 9 18:32:21 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 10 Nov 2009 00:32:21 +0000 Subject: What DNS Is Not In-Reply-To: References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> Message-ID: <20091110003221.GC25626@vacation.karoshi.com.> On Mon, Nov 09, 2009 at 06:24:52PM -0500, Patrick W. Gilmore wrote: > On Nov 9, 2009, at 3:00 PM, Paul Vixie wrote: > > >i loved the henry ford analogy -- but i think henry ford would have > >said that > >the automatic transmission was a huge step forward since he wanted > >everybody > >to have a car. i can't think of anything that's happened in the > >automobile > >market that henry ford wouldn't've wished he'd thought of. > > > >i knew that the "incoherent DNS" market would rise up on its hind > >legs and > >say all kinds of things in its defense against the ACM Queue > >article, and i'm > >not going to engage with every such speaker. > > Paul: I completely agree with you that putting wildcards into the > roots, GTLDs, CCTLDs, etc. is a Bad Idea and should be squashed. > Users have little (no?) choice on their TLDs. Stopping those is a > Good Thing, IMHO. > > However, I own a domain (or couple hundred :). I have a wildcard on > my domain. I point it where I want. I feel not the slightest twinge > of guilt at this. Do you think this is a Bad Thing, or should this be > allowed? > notbeing Paul, its rude of me to respond - yet you posted this to a public list ... so here goes. Why do you find your behaviour in your domains acceptable and yet the same behaviour in others zones to be "a Bad Thing" and should be stopped? --bill From gtb at slac.stanford.edu Mon Nov 9 18:52:35 2009 From: gtb at slac.stanford.edu (Buhrmaster, Gary) Date: Mon, 9 Nov 2009 16:52:35 -0800 Subject: What DNS Is Not In-Reply-To: <20091110003221.GC25626@vacation.karoshi.com.> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <20091110003221.GC25626@vacation.karoshi.com.> Message-ID: <6F51B50ECF32084788B9B3A8469A71B52916559D1E@EXCHCLUSTER1-02.win.slac.stanford.edu> > -----Original Message----- > From: bmanning at vacation.karoshi.com > [mailto:bmanning at vacation.karoshi.com] > Sent: Monday, November 09, 2009 4:32 PM > To: Patrick W. Gilmore > Cc: NANOG list > Subject: Re: What DNS Is Not ... > notbeing Paul, its rude of me to respond - yet you posted this > to a public list ... so here goes. > > Why do you find your behaviour in your domains acceptable and yet > the same behaviour in others zones to be "a Bad Thing" and should be > stopped? Ok, devils advocate argument. Is there is a difference between being a domain "owner" (Patrick wanting to wildcard the domain he has paid for), and a domain "custodian" (Verisign for the .com example) in whether wildcards are ever acceptable in the DNS responses you provide? From Ed.Lewis at neustar.biz Mon Nov 9 18:59:58 2009 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 10 Nov 2009 09:59:58 +0900 Subject: What DNS Is Not In-Reply-To: <20091110003221.GC25626@vacation.karoshi.com.> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <20091110003221.GC25626@vacation.karoshi.com.> Message-ID: At 0:32 +0000 11/10/09, bmanning at vacation.karoshi.com wrote: > not being Paul, its rude of me to respond - yet you posted this > to a public list ... so here goes. > > Why do you find your behaviour in your domains acceptable and yet the > same behaviour in others zones to be "a Bad Thing"... Not being anyone who has posted on this thread on a public list... I agree that the rules for what is acceptable in the operations of DNS zones vary from zone to zone. This is because of the different relationships between the zone administrator and the entities represented in the zone and the different relationships between the zone administrator and the relying parties. (I"m just going to pick on one "reason.") For the root zone or aTLD (which themselves have differences) the relationships tend to be global, multilingual, etc. Stability and coherence here are vital for operations, because as you know being in "operations" really means "handling outages." Once a problem pops up, it might take a while (hours, days) to go from report to root cause analysis to long-term fix. If the root and TLDs have lots of "bells and whistles" then, well, this is hard, so the root and TLDs are kept simple. For a zone "lower in the stack" assumptions are different. Generally speaking, the zone represents a single entity (a government agency, store, school) who will have a varying degree of active management of what is in the zone. They may even be able to "roll back" to some point in time and see what is in the zone. On-the-fly response generation is even acceptable because they can see what mislead someone, etc. (if they zone is properly run). And by on-the-fly I am including wildcards generated answers, calculated answers or answers based on source of the request, etc., and other demographics or current load measures. As far as relying parties, think about "who do I call?" when I can't get through. They have two obvious choices - their ISP or the organization they want to reach. Calls will end up with the ISP if the issue is high up in the zone, calls might get to the organization if the problems are lower in the tree. (Because perhaps they got to the main web page but not to the department page.) This is just one reason why it's reasonable to manage different DNS zones differently, why the "rules" don't apply the same everywhere. There are many other reasons. But this is a public list. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. From dga at cs.cmu.edu Mon Nov 9 19:01:29 2009 From: dga at cs.cmu.edu (David Andersen) Date: Mon, 9 Nov 2009 20:01:29 -0500 Subject: What DNS Is Not In-Reply-To: <6F51B50ECF32084788B9B3A8469A71B52916559D1E@EXCHCLUSTER1-02.win.slac.stanford.edu> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <20091110003221.GC25626@vacation.karoshi.com.> <6F51B50ECF32084788B9B3A8469A71B52916559D1E@EXCHCLUSTER1-02.win.slac.stanford.edu> Message-ID: On Nov 9, 2009, at 7:52 PM, Buhrmaster, Gary wrote: > >> -----Original Message----- >> From: bmanning at vacation.karoshi.com >> [mailto:bmanning at vacation.karoshi.com] >> Sent: Monday, November 09, 2009 4:32 PM >> To: Patrick W. Gilmore >> Cc: NANOG list >> Subject: Re: What DNS Is Not > > ... > >> notbeing Paul, its rude of me to respond - yet you posted this >> to a public list ... so here goes. >> >> Why do you find your behaviour in your domains acceptable and yet >> the same behaviour in others zones to be "a Bad Thing" and >> should be >> stopped? > > Ok, devils advocate argument. > > Is there is a difference between being a domain "owner" > (Patrick wanting to wildcard the domain he has paid for), > and a domain "custodian" (Verisign for the .com example) > in whether wildcards are ever acceptable in the DNS > responses you provide? I think this is spot on. In particular: Patrick, for some domains at least, can implement a wildcard with the full cooperation and agreement of all of the customers of sub-zones within his domain. Particularly if he doesn't resell any subdomains within it. Verisign cannot. [1] [1] As a customer of .com, my own disagreement on this is sufficient to prove that they don't have unanimous agreement. :-) -Dave From bmanning at vacation.karoshi.com Mon Nov 9 19:10:14 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 10 Nov 2009 01:10:14 +0000 Subject: What DNS Is Not In-Reply-To: <6F51B50ECF32084788B9B3A8469A71B52916559D1E@EXCHCLUSTER1-02.win.slac.stanford.edu> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <20091110003221.GC25626@vacation.karoshi.com.> <6F51B50ECF32084788B9B3A8469A71B52916559D1E@EXCHCLUSTER1-02.win.slac.stanford.edu> Message-ID: <20091110011014.GB25917@vacation.karoshi.com.> On Mon, Nov 09, 2009 at 04:52:35PM -0800, Buhrmaster, Gary wrote: > > > > -----Original Message----- > > From: bmanning at vacation.karoshi.com > > [mailto:bmanning at vacation.karoshi.com] > > Sent: Monday, November 09, 2009 4:32 PM > > To: Patrick W. Gilmore > > Cc: NANOG list > > Subject: Re: What DNS Is Not > > ... > > > notbeing Paul, its rude of me to respond - yet you posted this > > to a public list ... so here goes. > > > > Why do you find your behaviour in your domains acceptable and yet > > the same behaviour in others zones to be "a Bad Thing" and should be > > stopped? > > Ok, devils advocate argument. > > Is there is a difference between being a domain "owner" > (Patrick wanting to wildcard the domain he has paid for), > and a domain "custodian" (Verisign for the .com example) > in whether wildcards are ever acceptable in the DNS > responses you provide? > good question - does patrick own the domain or has he paid for the registration of mapping a string into a database? either? both? neither? I'll lay out what I just did in private email a moment ago. regardless of payment, ownership, or other considerations, we all (who manage a delegation point) are stewards of that delegation. Patrick, as steward of a domain, feels certain behaviours are acceptable when he performs them within his stewardship, yet is nonplused when another steward does the exact same thing in a different delegation. not being able to resist the analogy.... Its ok for me to practice indentured servitude in my home, yet when I see my neighbor practicing it in their home - I call the cops on her for practicing slavery. and hope that no one notices me. --bill From patrick at ianai.net Mon Nov 9 19:32:38 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 9 Nov 2009 20:32:38 -0500 Subject: What DNS Is Not In-Reply-To: <20091110003221.GC25626@vacation.karoshi.com.> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <20091110003221.GC25626@vacation.karoshi.com.> Message-ID: <94FA02C4-14C0-43CD-807A-BC1F0B432F23@ianai.net> Sent from my iPhone, please excuse any errors. On Nov 9, 2009, at 19:32, bmanning at vacation.karoshi.com wrote: > On Mon, Nov 09, 2009 at 06:24:52PM -0500, Patrick W. Gilmore wrote: >> On Nov 9, 2009, at 3:00 PM, Paul Vixie wrote: >> >>> i loved the henry ford analogy -- but i think henry ford would have >>> said that >>> the automatic transmission was a huge step forward since he wanted >>> everybody >>> to have a car. i can't think of anything that's happened in the >>> automobile >>> market that henry ford wouldn't've wished he'd thought of. >>> >>> i knew that the "incoherent DNS" market would rise up on its hind >>> legs and >>> say all kinds of things in its defense against the ACM Queue >>> article, and i'm >>> not going to engage with every such speaker. >> >> Paul: I completely agree with you that putting wildcards into the >> roots, GTLDs, CCTLDs, etc. is a Bad Idea and should be squashed. >> Users have little (no?) choice on their TLDs. Stopping those is a >> Good Thing, IMHO. >> >> However, I own a domain (or couple hundred :). I have a wildcard on >> my domain. I point it where I want. I feel not the slightest twinge >> of guilt at this. Do you think this is a Bad Thing, or should this >> be >> allowed? >> > > notbeing Paul, its rude of me to respond - yet you posted this > to a public list ... so here goes. > > Why do you find your behaviour in your domains acceptable and yet > the > same behaviour in others zones to be "a Bad Thing" and should be > stopped? Thought I was clear: Choice. I believe there is a qualitative difference between a *TLD and a second level domain. /Especially/ for the GTLDs. I guess one could argue CCTLDs are different, but I disagree. If you are in Germany, a .de is nearly as important as .com in the US. (Don't believe me? Go to www.dtag.com.) But no one has to use ianai.net. Or aa.com. Or .... A second issue is ownership. I own my domain. The .com domain is not owed by Verisign (despite what they may think :-). Again, one could make an argument that the CCTLDs are different - "owned" by their host countries. I personally disagree, but I admit that argument is less objective than the GTLDs. Do you disagree wih my logic? Do you believe Verisign should be allowed to do with .net the same things I should be allowed to do with ianai.net ? If so, please explain why. If not, uh ... Why did you ask? =) -- TTFN, patrick From jmamodio at gmail.com Mon Nov 9 19:54:17 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 9 Nov 2009 19:54:17 -0600 Subject: What DNS Is Not In-Reply-To: <94FA02C4-14C0-43CD-807A-BC1F0B432F23@ianai.net> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <20091110003221.GC25626@vacation.karoshi.com.> <94FA02C4-14C0-43CD-807A-BC1F0B432F23@ianai.net> Message-ID: <202705b0911091754q4944082au79f92e65fd8a53bb@mail.gmail.com> > A second issue is ownership. ?I own my domain. Interesting statement, did you get a property title with your domain name ? Just curious From bin.danieldai at gmail.com Mon Nov 9 19:56:10 2009 From: bin.danieldai at gmail.com (Bin Dai) Date: Tue, 10 Nov 2009 09:56:10 +0800 Subject: about interdomain multipath routing. Message-ID: <7F804FE1-F08F-41E2-86AF-548CF1F1FE1B@gmail.com> Hi: These days, in the research, the interdomain multipath routing is pretty hot but i doubt its actually use in reality. Does anyone tell me any use of interdomain multipath routing like multipath BGP in the real world? Best, Daniel From bmanning at vacation.karoshi.com Mon Nov 9 19:55:54 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 10 Nov 2009 01:55:54 +0000 Subject: What DNS Is Not In-Reply-To: <94FA02C4-14C0-43CD-807A-BC1F0B432F23@ianai.net> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <20091110003221.GC25626@vacation.karoshi.com.> <94FA02C4-14C0-43CD-807A-BC1F0B432F23@ianai.net> Message-ID: <20091110015554.GC25917@vacation.karoshi.com.> On Mon, Nov 09, 2009 at 08:32:38PM -0500, Patrick W. Gilmore wrote: > > notbeing Paul, its rude of me to respond - yet you posted this > > to a public list ... so here goes. > > > > Why do you find your behaviour in your domains acceptable and yet > >the > > same behaviour in others zones to be "a Bad Thing" and should be > >stopped? > > Thought I was clear: Choice. > > I believe there is a qualitative difference between a *TLD and a > second level domain. /Especially/ for the GTLDs. so you are making the arguement that as one navigates the dns heirarchy, operational choices nearer the root affect more people. as may be. - yet we see ICANN under serious pressure to flatten out the root zone - to create the same amount of choice at the root as one might find in .COM I will echo your original question to Paul, If its a "Bad Thing" at the root or TLD, is it a "Bad Thing" in ianai.com? I would say yes it is - looking for consistency in the stewardship guidelines for any delegation. personally, I take the path less traveled and woudl suggest that a wildcard - at any delegation point - can be a useful tool. the unspoken compoent here is the diversity of expectation on what one might do with a wildcard. Is the wildcard in and of itself a "Bad Thing" or has the wildcard been used in conjunction with other heinous practice to unfairly exploit the gullible masses? I don't think it fair to blame wildcards here - they are a symptom but not the actual cause of "Bad Thing" - for that you need other bits in play. --bill From Valdis.Kletnieks at vt.edu Mon Nov 9 20:21:54 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 09 Nov 2009 21:21:54 -0500 Subject: What DNS Is Not In-Reply-To: Your message of "Mon, 09 Nov 2009 15:04:06 PST." <18a5e7cb0911091504t60035f2m902eb7873c3e7e14@mail.gmail.com> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <4AF75D1B.7080307@gmail.com> <18a5e7cb0911091504t60035f2m902eb7873c3e7e14@mail.gmail.com> Message-ID: <6028.1257819714@turing-police.cc.vt.edu> On Mon, 09 Nov 2009 15:04:06 PST, Bill Stewart said: > For instance, returning the IP address of your company's port-80 web > server instead of NXDOMAIN > not only breaks non-port-80-http applications Remember this... > There is one special case for which I don't mind having DNS servers > lie about query results, > which is the phishing/malware protection service. In that case, the > DNS response is redirecting you to > the IP address of a server that'll tell you > "You really didn't want to visit PayPa11.com - it's a fake" or > "You really didn't want to visit > dgfdsgsdfgdfgsdfgsfd.example.ru - it's malware". > It's technically broken, but you really _didn't_ want to go there anyway. > It's a bit friendlier to administrators and security people if the > response page gives you the Returning bogus non-NXODMAIN gives non-port-80-http apps heartburn as well. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From steve at ibctech.ca Mon Nov 9 20:43:48 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Mon, 09 Nov 2009 21:43:48 -0500 Subject: BGP Peer Selection Considerations In-Reply-To: <24278.1257788407@baklawasecrets.com> References: <24278.1257788407@baklawasecrets.com> Message-ID: <4AF8D364.3030108@ibctech.ca> adel at baklawasecrets.com wrote: > Hi, > > Thanks to everyone that replied to my post on failover configuration. This has lead me to this post. I'm at a point now where I'm looking at dual-homing with two BGP peers upstream. Now what I am looking at doing is as follows: > > BGP Peer with Provider A who is multihomed to other providers. > BGP Peer with Provider B who is not peered with provider A > > I have an existing relationship with provider A, colo, cross connects etc. Provider A has offered to get the PI space, ASN number, purchase the transit for us with provider B and manage cross connects to provider B ...I've likely missed something, but get the IP/ASN for yourself. *ensure* that A & B will peer and provide transit for you. > (they say they have a diverse "fibre backhaul network"). This is quite attractive from a support and billing perspective. ...until you find out that the backhaul network is owned by Provider B, or virtualized within an existing circuit to someplace else. > Also suspect that provider A will be able to get more attractive pricing from Provider B than I would be able to. But at what cost? > Am I missing things that I need to consider? I think so. Long-term survival for one. If you are budgeted for a diverse and redundant network, then I recommend that you ensure one. My current understanding is that you can negotiate terms with potential providers where there is competition. Don't allow any of your ISPs to manage/dictate the use of your address space. It will bite you, and cause undue frustration. Steve From sking at kingrst.com Mon Nov 9 21:30:34 2009 From: sking at kingrst.com (Steven King) Date: Mon, 09 Nov 2009 22:30:34 -0500 Subject: about interdomain multipath routing. In-Reply-To: <7F804FE1-F08F-41E2-86AF-548CF1F1FE1B@gmail.com> References: <7F804FE1-F08F-41E2-86AF-548CF1F1FE1B@gmail.com> Message-ID: <4AF8DE5A.70006@kingrst.com> We use eBGP multipath where I work. We usually get two or more connections to each provider we have. Using multipath we are able to add hardware redundancy with bandwidth balancing (to an extent) with this method. There are some providers who will only allow multipath eBGP and not even let you run multihop eBGP. Bin Dai wrote: > Hi: > These days, in the research, the interdomain multipath routing is > pretty hot but i doubt its actually use in reality. > Does anyone tell me any use of interdomain multipath routing like > multipath BGP in the real world? > > Best, > Daniel > -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From mpetach at netflight.com Mon Nov 9 21:50:32 2009 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 9 Nov 2009 19:50:32 -0800 Subject: about interdomain multipath routing. In-Reply-To: <7F804FE1-F08F-41E2-86AF-548CF1F1FE1B@gmail.com> References: <7F804FE1-F08F-41E2-86AF-548CF1F1FE1B@gmail.com> Message-ID: <63ac96a50911091950t719a3267lfc1c289d97ce5216@mail.gmail.com> On Mon, Nov 9, 2009 at 5:56 PM, Bin Dai wrote: > Hi: > These days, in the research, the interdomain multipath routing is pretty hot > but i doubt its actually use in reality. > Does anyone tell me any use of interdomain multipath routing like multipath > BGP in the real world? I've outlawed the use of multihop eBGP for load-sharing here; when we get multiple links off the same router to a peer or upstream, they are configured with multipath. We've got hundreds of BGP sessions across the network configured with multipath on them. Matt > Best, > Daniel > > From andrew at accessplus.com.au Mon Nov 9 22:15:19 2009 From: andrew at accessplus.com.au (Andrew Cox) Date: Tue, 10 Nov 2009 14:45:19 +1030 Subject: What DNS Is Not In-Reply-To: <6028.1257819714@turing-police.cc.vt.edu> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <4AF75D1B.7080307@gmail.com> <18a5e7cb0911091504t60035f2m902eb7873c3e7e14@mail.gmail.com> <6028.1257819714@turing-police.cc.vt.edu> Message-ID: <4AF8E8D7.9070207@accessplus.com.au> Shouldn't such apps be checking the content they receive back from a server anyway? Regardless of if they think they're getting to the right server (due to a bogus non-NXDOMAIN response) there should be some sort of validation in place.. otherwise you're open in any sort of man-in-the-middle attack. I think the issue is more that older apps would expect that if they can get a response then everything is ok.. perhaps this simply an outdated method and needs to be rethought. Valdis.Kletnieks at vt.edu wrote: > On Mon, 09 Nov 2009 15:04:06 PST, Bill Stewart said: > > >> For instance, returning the IP address of your company's port-80 web >> server instead of NXDOMAIN >> not only breaks non-port-80-http applications >> > > Remember this... > > >> There is one special case for which I don't mind having DNS servers >> lie about query results, >> which is the phishing/malware protection service. In that case, the >> DNS response is redirecting you to >> the IP address of a server that'll tell you >> "You really didn't want to visit PayPa11.com - it's a fake" or >> "You really didn't want to visit >> dgfdsgsdfgdfgsdfgsfd.example.ru - it's malware". >> It's technically broken, but you really _didn't_ want to go there anyway. >> It's a bit friendlier to administrators and security people if the >> response page gives you the >> > > Returning bogus non-NXODMAIN gives non-port-80-http apps heartburn as well. > > From jbates at brightok.net Mon Nov 9 22:16:38 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 09 Nov 2009 22:16:38 -0600 Subject: about interdomain multipath routing. In-Reply-To: <63ac96a50911091950t719a3267lfc1c289d97ce5216@mail.gmail.com> References: <7F804FE1-F08F-41E2-86AF-548CF1F1FE1B@gmail.com> <63ac96a50911091950t719a3267lfc1c289d97ce5216@mail.gmail.com> Message-ID: <4AF8E926.1010004@brightok.net> Matthew Petach wrote: > > I've outlawed the use of multihop eBGP for load-sharing here; when we get > multiple links off the same router to a peer or upstream, they are configured > with multipath. We've got hundreds of BGP sessions across the network > configured with multipath on them. > Same here for my connections, though some of my customers are stuck with multihop eBGP in certain remote areas, but that's a completely different scenario (single link, but obsolete equipment) and out of my control. I much prefer multipath, especially given that the standard multihop config uses static routing and there are conditions that could cause the flap of the eBGP session during a single link outage. With Multipath, only the effected path goes down, as it should. Jack From jbates at brightok.net Mon Nov 9 22:18:31 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 09 Nov 2009 22:18:31 -0600 Subject: What DNS Is Not In-Reply-To: <4AF8E8D7.9070207@accessplus.com.au> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <4AF75D1B.7080307@gmail.com> <18a5e7cb0911091504t60035f2m902eb7873c3e7e14@mail.gmail.com> <6028.1257819714@turing-police.cc.vt.edu> <4AF8E8D7.9070207@accessplus.com.au> Message-ID: <4AF8E997.3070203@brightok.net> Andrew Cox wrote: > I think the issue is more that older apps would expect that if they can > get a response then everything is ok.. perhaps this simply an outdated > method and needs to be rethought. > The app is expecting a response of some kind. When it gets back bogus information that has it connecting to an IP that may not respond at all, the app will have to sit around waiting on a timeout. Jack From kloch at kl.net Mon Nov 9 22:23:06 2009 From: kloch at kl.net (Kevin Loch) Date: Mon, 09 Nov 2009 23:23:06 -0500 Subject: about interdomain multipath routing. In-Reply-To: <7F804FE1-F08F-41E2-86AF-548CF1F1FE1B@gmail.com> References: <7F804FE1-F08F-41E2-86AF-548CF1F1FE1B@gmail.com> Message-ID: <4AF8EAAA.4030403@kl.net> Bin Dai wrote: > Hi: > These days, in the research, the interdomain multipath routing is pretty > hot but i doubt its actually use in reality. > Does anyone tell me any use of interdomain multipath routing like > multipath BGP in the real world? "BGP multipath" is extremely common and used to load balance multiple links to the same neighbor ASN. As implemented by popular vendors it requires most attributes (like as-path) to be identical. Did you really mean this or something that uses different as-paths in parallel? - Kevin From sking at kingrst.com Mon Nov 9 22:22:23 2009 From: sking at kingrst.com (Steven King) Date: Mon, 09 Nov 2009 23:22:23 -0500 Subject: about interdomain multipath routing. In-Reply-To: <4AF8E926.1010004@brightok.net> References: <7F804FE1-F08F-41E2-86AF-548CF1F1FE1B@gmail.com> <63ac96a50911091950t719a3267lfc1c289d97ce5216@mail.gmail.com> <4AF8E926.1010004@brightok.net> Message-ID: <4AF8EA7F.9000905@kingrst.com> Those are very good points Jack. We stopped using multihop for those same reasons. Jack Bates wrote: > Matthew Petach wrote: >> >> I've outlawed the use of multihop eBGP for load-sharing here; when we >> get >> multiple links off the same router to a peer or upstream, they are >> configured >> with multipath. We've got hundreds of BGP sessions across the network >> configured with multipath on them. >> > > Same here for my connections, though some of my customers are stuck > with multihop eBGP in certain remote areas, but that's a completely > different scenario (single link, but obsolete equipment) and out of my > control. > > I much prefer multipath, especially given that the standard multihop > config uses static routing and there are conditions that could cause > the flap of the eBGP session during a single link outage. With > Multipath, only the effected path goes down, as it should. > > > Jack > -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From patrick at ianai.net Mon Nov 9 23:12:42 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 10 Nov 2009 00:12:42 -0500 Subject: What DNS Is Not In-Reply-To: <20091110011014.GB25917@vacation.karoshi.com.> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <20091110003221.GC25626@vacation.karoshi.com.> <6F51B50ECF32084788B9B3A8469A71B52916559D1E@EXCHCLUSTER1-02.win.slac.stanford.edu> <20091110011014.GB25917@vacation.karoshi.com.> Message-ID: <36F94656-5C4A-4F16-A173-63ABE225F83C@ianai.net> As someone just said to me privately: "I dislike the pedantic **** nerds pull sometimes." (The "****" is mine, not the original quote, so the Communications Committee doesn't send me a warning.) On Nov 9, 2009, at 8:10 PM, bmanning at vacation.karoshi.com wrote: > good question - does patrick own the domain or has he paid for > the registration of mapping a string into a database? either? both? > neither? The argument is silly at best. I "own" the domain for the year I paid for it. You call it "stewardship". I won't argue if you want to play that game. (BTW, I seriously considered putting the word "own" in quotes, but it would have required five extra keystrokes on the iPhone and I didn't think it was worth the effort. Everyone - including Bill - knows exactly what I meant. I mean, we're not newbies or idiots or .... Oh, right. Teach me to be lazy.) Let's use "stewardship", or any other string of characters that makes you happy. The basic premise does not change. My "stewardship" of ianai.net (and it's not ".com" - one would think someone like you would realize the difference) is qualitatively different than the "stewardship" of the *TLDs. For one thing, I have every right to point any hostname in my domain at any IP address I want.[*] I could create a zone file with 36^N entries pointing them all at the same IP address. No one would blink an eye. It is not unexpected, inappropriate, or in any way "wrong". Putting "* IN A 1.2.3.4" has the exact same results for any hostname up to N letters. Consider it shorthand. Think of all the RAM I'll save! Verisign putting a domain into .com that does not exist is not only unexpected, it is inappropriate, and Just Plain Wrong. They do not "own" the zone, they have _no_right_ to put any entries in that zone that are not requested through the appropriate method. If you do not (want to) see that, we will have to agree to disagree. Also, you were so busy picking on my choice of words that you completely ignored the "choice" point. Guess you couldn't come up with any feeble semantic arguments on that one? > not being able to resist the analogy.... s/the/a really bad/ > Its ok for me to practice indentured servitude in my home, yet when I > see my neighbor practicing it in their home - I call the cops on her > for practicing slavery. and hope that no one notices me. Honestly, Bill, don't you think that was a little pathetic? Why don't you just compare me to Hitler and get it over with. -- TTFN, patrick [*] I'm not going to explain things like "I shouldn't point hostnames at IP addresses I do not own" (er, "steward") because anyone who brings up that point is not worth talking to. If your best counter argument is so stupid that anyone with more than three brain cells to rub together already knows, understands, and has gone right past, then please un-sub from NANOG, throw your laptop in a lake, and go get a job a HS drop out can do. Because that's all you deserve. From martin at theicelandguy.com Mon Nov 9 23:13:34 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Tue, 10 Nov 2009 00:13:34 -0500 Subject: What DNS Is Not In-Reply-To: <202705b0911091754q4944082au79f92e65fd8a53bb@mail.gmail.com> References: <4AF748B3.7060606@evaristesys.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <20091110003221.GC25626@vacation.karoshi.com.> <94FA02C4-14C0-43CD-807A-BC1F0B432F23@ianai.net> <202705b0911091754q4944082au79f92e65fd8a53bb@mail.gmail.com> Message-ID: On Mon, Nov 9, 2009 at 8:54 PM, Jorge Amodio wrote: > > A second issue is ownership. I own my domain. > > Interesting statement, did you get a property title with your domain name ? > > Just curious > > I'd take that question up with your IP attorney. [ Summary: lots of lawyers and courts seem to think that domain names are property ] http://news.cnet.com/2100-1023-223597.html http://www.domainnamenews.com/legal-issues/are-domain-names-considered-property-or-not/2917 http://newmedialaw.proskauer.com/2008/12/articles/domain-names/appellate-watch-are-domain-names-property-that-can-be-seized-under-state-forfeiture-laws/ http://www.law.duke.edu/journals/dltr/articles/2001dltr0032.html http://pblog.bna.com/techlaw/2009/09/domain-name-deemed-tangible-property-web-pages-too-in-utah.html -M< -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From laned1 at gmail.com Tue Nov 10 03:10:59 2009 From: laned1 at gmail.com (Doug Lane) Date: Tue, 10 Nov 2009 09:10:59 +0000 Subject: about interdomain multipath routing. In-Reply-To: <63ac96a50911091950t719a3267lfc1c289d97ce5216@mail.gmail.com> References: <7F804FE1-F08F-41E2-86AF-548CF1F1FE1B@gmail.com> <63ac96a50911091950t719a3267lfc1c289d97ce5216@mail.gmail.com> Message-ID: <970c8dea0911100110n5c547297u260964431a045220@mail.gmail.com> On Tue, Nov 10, 2009 at 3:50 AM, Matthew Petach wrote: > I've outlawed the use of multihop eBGP for load-sharing here; when we get > multiple links off the same router to a peer or upstream, they are configured > with multipath. ?We've got hundreds of BGP sessions across the network > configured with multipath on them. > Do you use iBGP multipath as well to load-balance between links on different routers? I know eBGP multipath is fairly common, but I wonder how many are using iBGP multipath as well. I doubt any carriers would support it, so it's probably only useful for load-balancing outbound traffic. The problem with eBGP multipath alone is that you might want to terminate circuits from a given carrier on two different routers for redundancy reasons, but that precludes any load-balancing with eBGP multipath. Obviously your network has to be designed with equal-cost paths for iBGP multipath to be of any value. -Doug From mpetach at netflight.com Tue Nov 10 03:23:13 2009 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 10 Nov 2009 01:23:13 -0800 Subject: about interdomain multipath routing. In-Reply-To: <970c8dea0911100110n5c547297u260964431a045220@mail.gmail.com> References: <7F804FE1-F08F-41E2-86AF-548CF1F1FE1B@gmail.com> <63ac96a50911091950t719a3267lfc1c289d97ce5216@mail.gmail.com> <970c8dea0911100110n5c547297u260964431a045220@mail.gmail.com> Message-ID: <63ac96a50911100123w4f61ae7asd1e0e058d67d9504@mail.gmail.com> On Tue, Nov 10, 2009 at 1:10 AM, Doug Lane wrote: > On Tue, Nov 10, 2009 at 3:50 AM, Matthew Petach wrote: >> I've outlawed the use of multihop eBGP for load-sharing here; when we get >> multiple links off the same router to a peer or upstream, they are configured >> with multipath. ?We've got hundreds of BGP sessions across the network >> configured with multipath on them. >> > > Do you use iBGP multipath as well to load-balance between links on > different routers? Yes. > I know eBGP multipath is fairly common, but I wonder how many are > using iBGP multipath as well. I doubt any carriers would support it, > so it's probably only useful for load-balancing outbound traffic. The > problem with eBGP multipath alone is that you might want to terminate > circuits from a given carrier on two different routers for redundancy > reasons, but that precludes any load-balancing with eBGP multipath. > Obviously your network has to be designed with equal-cost paths for > iBGP multipath to be of any value. > > -Doug iBGP with multipath, multiple LSPs to each BGP next-hop...much load balancing across all same-cost internal links to each of the eBGP multihop next-hops. inet.0: 300787 destinations, 2675963 routes (300092 active, 2 holddown, 2086 hidden) Yes...takes up a chunk more memory keeping track of all the different paths, but it does provide more end-to-end load balancing of traffic even on different routers. Matt From adel at baklawasecrets.com Tue Nov 10 03:52:59 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Tue, 10 Nov 2009 09:52:59 +0000 Subject: BGP Peer Selection Considerations Message-ID: <29129.1257846779@baklawasecrets.com> If nothing else by the time this deployment is finished I will surely have become extremely cynical. Now reading through peoples answers, I think the general consensus is that I would be giving too much control to provider A in the scenario I suggested below. So as someone mentioned they have the ability to foul up my connections all by themselves. >From all of this I gather that the most resilience would be provided by: 1) Go to two tier 1 carriers myself - say Global Crossing and Level 3. Arrange to get two 100meg BGP feeds, burstable. Pick them up at different datacentres as well I suppose to provide datacentre redundancy? Negotiate pricing, any tips on negotiating appreciated. 2) Arrange cross connects to these providers i.e. get to the datacentres the Tier1 providers are in. They are not on net at the colo we are in. With regards to arranging the cross connects am I able to ask the cross connect providers for fibre maps? Is this a done thing or will they brush me off with "you don't need this our network is diverse?" 3) Arrange for PI space and ASN myself, so become an LIR through RIPE. Do I really lose a lot by asking Level3 or GBLX to get the PI and ASN for me? I think the failure mode cited by someone was if the PI and ASN provider goes out of business. I would prefer not to go through becoming an LIR and maintaining the membership, as they are not an ISP and so it is more attractive to do that through one of the Tier 1 providers. I'm not sure what my options are in terms of getting to the datacentres to pick up the Tier1 providers. The "provider A" below has said they run a diverse fibre backhaul network etc etc. and I should go with them for connectivity to other datacentres. Now it would be easier to go with them just because they are running colo for us and they run the datacentre we are in. However I assume that I should not be scared of arranging a second cross connect with someone else altogether. In all of the above, I'm most worried about administrative overhead. Managing two cross connect providers, managing ongoing relationship with two Tier1 providers and so on. However resilience comes at a cost I suppose is the answer. Comments appreciated. Adel On Mon 7:10 PM , "William Herrin" herrin-nanog at dirtside.com sent: > On Mon, Nov 9, 2009 at 12:40 PM, baklawasecrets.com> wrote:> I have an existing relationship with provider A, > colo, cross connects> etc. ?Provider A has offered to get the PI > space, ASN number,> purchase the transit for us with provider B and > manage cross> connects to provider B (they say they have a > diverse "fibre> backhaul network"). ?This is quite > attractive from a support> and billing perspective. ?Also suspect that > provider A will be> able to get more attractive pricing from > Provider B than I> would be able to. > > > > Am I missing things that I need to > consider? > What happens when provider A is bought by provider C and you want to > dump provider C but keep provider B? You'll have created a conflict of > interest for provider B in any negotiation you have with them. > > Be aware that provider A's diverse network for provider A's service is > the same diverse network they'll use to connect you to provider B. As > a result, many or most of the outages which impact provider A will > also impact your connectivity to provider B, defeating the central > purpose of having a provider B. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at di > rtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 > > > From nick at foobar.org Tue Nov 10 04:02:10 2009 From: nick at foobar.org (Nick Hilliard) Date: Tue, 10 Nov 2009 10:02:10 +0000 Subject: BGP Peer Selection Considerations In-Reply-To: <29129.1257846779@baklawasecrets.com> References: <29129.1257846779@baklawasecrets.com> Message-ID: <4AF93A22.6040103@foobar.org> On 10/11/2009 09:52, adel at baklawasecrets.com wrote: > 3) Arrange for PI space and ASN myself, so become an LIR through RIPE. You don't need to become a LIR to get PI space and an ASN. > Do I really lose a lot by asking Level3 or GBLX to get the PI and ASN > for me? You lose relatively little. If you wish to move your provider independent resources to another LIR at a later stage, RIPE are very happy to assist. > I think the failure mode cited by someone was if the PI and ASN > provider goes out of business. If they go out of business, there's a small amount of overhead - you find yourself a new LIR and life will continue on. I wouldn't worry about it too much. > I would prefer not to go through becoming an LIR and maintaining the > membership Probably sensible. Nick From john-nanog at johnpeach.com Tue Nov 10 07:05:39 2009 From: john-nanog at johnpeach.com (John Peach) Date: Tue, 10 Nov 2009 08:05:39 -0500 Subject: What DNS Is Not In-Reply-To: <4AF8A27D.2080405@everydns.net> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <4AF8A090.9050201@evaristesys.com> <4AF8A27D.2080405@everydns.net> Message-ID: <20091110080539.35005525@jpeach-desktop.1425mad.mountsinai.org> On Mon, 09 Nov 2009 18:15:09 -0500 David Ulevitch wrote: > On 11/9/09 6:06 PM, Alex Balashov wrote: > > > Anything else is COMPLETELY UNACCEPTABLE. I don't understand how or > > why this could possibly be controversial. > > Because some people want the ability and choice to block DNS > responses they don't like; just as they have the ability and choice > to reject email they don't want to accept. > > When the conficker worms phones home to one of the 50,000 potential > domains names it computes each day, there are a lot of IT folks out > there that wish their local resolver would simply reject those DNS > requests so that infected machines in their network fail to phone > home. > > To use your language, I don't understand how or why this could > possibly be controversial. -- Apparently it is. In which case, make your own nameserver authoritative for those domains; do not foist your own wishes on other people. -- John From sthaug at nethelp.no Tue Nov 10 07:30:45 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 10 Nov 2009 14:30:45 +0100 (CET) Subject: What DNS Is Not In-Reply-To: <20091110080539.35005525@jpeach-desktop.1425mad.mountsinai.org> References: <4AF8A090.9050201@evaristesys.com> <4AF8A27D.2080405@everydns.net> <20091110080539.35005525@jpeach-desktop.1425mad.mountsinai.org> Message-ID: <20091110.143045.74683595.sthaug@nethelp.no> > > When the conficker worms phones home to one of the 50,000 potential > > domains names it computes each day, there are a lot of IT folks out > > there that wish their local resolver would simply reject those DNS > > requests so that infected machines in their network fail to phone > > home. > > > > To use your language, I don't understand how or why this could > > possibly be controversial. -- Apparently it is. > > In which case, make your own nameserver authoritative for those > domains; do not foist your own wishes on other people. Since people need to *explicitly* choose using the OpenDNS servers, I can hardly see how anybody's wishes are foisted on these people. If you don't like the answers you get from this (free) service, you can of course choose to use a different service - for instance your ISP's name servers. (I may or may not agree with what OpenDNS does - that is completely irrelevant in this case.) Steinar Haug, Nethelp consulting, sthaug at nethelp.no From bortzmeyer at nic.fr Tue Nov 10 07:34:15 2009 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 10 Nov 2009 22:34:15 +0900 Subject: What DNS Is Not In-Reply-To: <4AF8A27D.2080405@everydns.net> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <4AF8A090.9050201@evaristesys.com> <4AF8A27D.2080405@everydns.net> Message-ID: <20091110133415.GA11801@laperouse.bortzmeyer.org> On Mon, Nov 09, 2009 at 06:15:09PM -0500, David Ulevitch wrote a message of 18 lines which said: > When the conficker worms phones home to one of the 50,000 potential > domains names it computes each day, there are a lot of IT folks out > there that wish their local resolver would simply reject those DNS > requests so that infected machines in their network fail to phone > home. That's an extremely bad idea: many of the domains generated by the Conficker algorithm are already registered by a legitimate registrant (in .FR: the national railways, a national TV, etc). Also, the example is not a good choice since Conficker now mostly uses P2P: for those who like assembly code and awful technical details. From randy at psg.com Tue Nov 10 07:48:07 2009 From: randy at psg.com (Randy Bush) Date: Tue, 10 Nov 2009 22:48:07 +0900 Subject: AfNOG 2010 Message-ID: AfNOG-11 and AfriNIC-12: Meetings 23 May-4 June, 2010 The African Network Operators' Group (AfNOG) and the African Network Information Centre (AfriNIC) are pleased to announce that the 11th AfNOG Meeting and the AfriNIC-12 Meeting would be held in Kigali, Rwanda during May & June 2010. About the Entire Event AfNOG and AfriNIC are jointly organizing a two-week event that includes the AfNOG Workshop on Network Technology (offering advanced training in a week-long hands-on workshop), several full-day Advanced Tutorials, a one-day AfNOG Meeting, and a two-day AfriNIC Meeting. In addition, several side meetings and workshops will be hosted in collaboration with other organizations. Timetable Unix Boot Camp 23 May 2010 (Sunday) AfNOG Workshop 24 - 28 May 2010 (Monday - Friday) AfriNIC IPv6 Workshop 29 - 30 May 2010 (Saturday - Sunday) AfREN Meeting / AAF 29 - 30 May 2010 (Saturday - Sunday) AfNOG Tutorials 30 - 31 May 2010(Sunday - Monday) AfriNIC LIR Workshop 31 May 2010 (Monday) AfNOG-11 Meeting 1 June 2010 (Tuesday) AfriNIC-12 Meeting 2- 3 June 2010 (Wednesday - Thursday) Africa INET Day 4 June 2010 (Friday) Venue & Hotel Venue & hotel for the event will be announced shortly. About AfNOG AfNOG (See ) is a forum for cooperation and the exchange of technical information between operators of Internet-connected networks in Africa. AfNOG has organized an event like this one every year since 2000. About AfriNIC AfriNIC (See ) is a Regional Internet Registry (RIR), responsible for Internet Number resources Management in the Africa region. AfriNIC organizes two Public Policy meetings every year (see < http://www.afrinic.net/meeting/>). AfNOG Workshop on Network Technology The AfNOG Workshop on Network Technology aims to offer advanced training to people who are in the process of developing and enhancing an Internet-connected network with regional and international connectivity. The target audience includes senior and mid-level technical staff of commercial Internet service providers (ISPs), academic networks, government networks, or NGO networks. This workshop builds on the experience of previous AfNOG workshops held annually from 2000 to 2009 in ten different African countries, and also the Internet Society's INET workshops, held annually from 1993 to 2000 at eight locations around the world. The workshop's instructors are an international team with many years of experience operating large networks and teaching about network operations. The workshop is divided into four parallel tracks: * SA-E - Unix System Administration (in English), focused on using a Unix-like operating system as a platform for delivery of Internet services. * SS-E - Scalable Internet Services (in English), focused on the design and operation of email, web, and other Internet services, in ways that can scale to handle large numbers of end users. * SI-E - Scalable Network Infrastructure (in English), focused on the design and operation of networks using routers and switches, in ways that can scale to handle large numbers of interconnected sites. * SI-F - Infrastructure Reseaux IP (en francais), similar to track SI-E, but given in French. Workshop application information is available here: http://www.afnog.org/afnog2010/workshop/online_application_en.html http://www.afnog.org/afnog2010/workshop/online_application_fr.html AfREN Meeting The Africa Research and Education Networking community will be holding a two-day meeting on 29 - 30 May 2010. The meeting will discuss issues of interest to the NREN community such as coordination on activites in the region, advocacy, bandwidth consortia, regional RENs etc. Additional information about AfREN 2010 will be provided shortly. AfNOG Tutorials AfNOG will offer 1 to 2 full-day(s) tutorials on advanced topics. Tutorials take place in a classroom-style environment, and may include a hands-on practical component. Tutorials are non-commercial in nature, and most are technically oriented. They are intended to offer advanced training on technology already deployed or soon to be deployed on networking and related services provisioning for ISP operations. Additional information about AfNOG 2010 Tutorials will be availabe here: < http://www.afnog.org/afnog2010/tutorial/> 11th AfNOG Meeting The 11th AfNOG meeting will be held in Kigali, Rwanda on 01 June 2010. AfNOG conferences provide a forum for the coordination and dissemination of technical information related to backbone/enterprise networking technologies and operational practices. The meetings are informal, with an emphasis on relevance to current and future African backbone engineering practices. The AfNOG 2009 conference in Cairo, Egypt drew over 150 participants, mainly consisting of network engineering staff from national service providers, and members of the research and education community. Additional information and the Conference schedule will be available here: < http://www.afnog.org/afnog2010/conference/> AfriNIC-12 Meeting The AfriNIC-12 meeting will be held in Kigali, Rwanda for two days from 02-03 June, 2010. AfriNIC Meetings are open to everyone and provide an excellent opportunity to take part in Internet policy discussions. These policies, which describe how Internet Number Resources should be managed and distributed, are developed by the community. The meeting will include tutorials, presentations, update on the various working groups and the AfriNIC Public Policy Meeting. The two day meeting will be preceeded by a two-day IPv6 training. The meeting will focus on the IPv6 protocol and its deployment, especially in Africa and the issue of the exhaustion of the IPv4 pool of address space. There will be an opportunity to discuss the challenges which our region will be facing with IPv4 address space exhaustion. Further information will be available at < http://www.afrinic.net/meeting/>. ISOC - INET Africa Conference The Internet Society will be organizing an INET Africa Conference on 4th June 2010 in conjunction with the AfriNIC 12 and AfNOG 11 meetings in Kigali, Rwanda. The conference will discuss the situation of Internet Interconnection in Africa, the challenges as well as the solutions, including Internet Exchange Points. The meeting agenda will be available shortly. Visa Requirements Citizens of certain countries require a visa to enter Rwanda. Please check with the Rwandan -30- From sthaug at nethelp.no Tue Nov 10 08:04:28 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 10 Nov 2009 15:04:28 +0100 (CET) Subject: What DNS Is Not In-Reply-To: <20091110133415.GA11801@laperouse.bortzmeyer.org> References: <4AF8A090.9050201@evaristesys.com> <4AF8A27D.2080405@everydns.net> <20091110133415.GA11801@laperouse.bortzmeyer.org> Message-ID: <20091110.150428.41705067.sthaug@nethelp.no> > > When the conficker worms phones home to one of the 50,000 potential > > domains names it computes each day, there are a lot of IT folks out > > there that wish their local resolver would simply reject those DNS > > requests so that infected machines in their network fail to phone > > home. > > That's an extremely bad idea: many of the domains generated by the > Conficker algorithm are already registered by a legitimate registrant > (in .FR: the national railways, a national TV, etc). It's an idea that needs to be used *with caution*. We did something similar as part of testing a new DNS product, and found that any such list of domain names needed to be *manually* vetted before being used as input to a DNS-based blackhole system. We also found that we had to explicitly whitelist a number of domains (generated by Conficker but registered many years ago and pretty clearly legit). Steinar Haug, Nethelp consulting, sthaug at nethelp.no From davidu at everydns.net Tue Nov 10 09:17:15 2009 From: davidu at everydns.net (David Ulevitch) Date: Tue, 10 Nov 2009 10:17:15 -0500 Subject: What DNS Is Not In-Reply-To: <20091110.150428.41705067.sthaug@nethelp.no> References: <4AF8A090.9050201@evaristesys.com> <4AF8A27D.2080405@everydns.net> <20091110133415.GA11801@laperouse.bortzmeyer.org> <20091110.150428.41705067.sthaug@nethelp.no> Message-ID: <4AF983FB.90604@everydns.net> On 11/10/09 9:04 AM, sthaug at nethelp.no wrote: >>> When the conficker worms phones home to one of the 50,000 potential >>> domains names it computes each day, there are a lot of IT folks out >>> there that wish their local resolver would simply reject those DNS >>> requests so that infected machines in their network fail to phone >>> home. >> >> That's an extremely bad idea: many of the domains generated by the >> Conficker algorithm are already registered by a legitimate registrant >> (in .FR: the national railways, a national TV, etc). > > It's an idea that needs to be used *with caution*. We did something > similar as part of testing a new DNS product, and found that any such > list of domain names needed to be *manually* vetted before being used > as input to a DNS-based blackhole system. We also found that we had > to explicitly whitelist a number of domains (generated by Conficker > but registered many years ago and pretty clearly legit). This is correct. And we take this into consideration in determining what to block using our existing datasets, which are sufficient considering the volume of DNS traffic that crosses our network. -David From davidu at everydns.net Tue Nov 10 09:31:55 2009 From: davidu at everydns.net (David Ulevitch) Date: Tue, 10 Nov 2009 10:31:55 -0500 Subject: What DNS Is Not In-Reply-To: <20091110080539.35005525@jpeach-desktop.1425mad.mountsinai.org> References: <4AF748B3.7060606@evaristesys.com> <4AF75B2B.8050609@gmail.com> <4AF75BE2.80002@evaristesys.com> <4AF75D1B.7080307@gmail.com> <2CA9568B-0205-4C12-9F1D-7EB7B20BF839@cs.cmu.edu> <4AF8A090.9050201@evaristesys.com> <4AF8A27D.2080405@everydns.net> <20091110080539.35005525@jpeach-desktop.1425mad.mountsinai.org> Message-ID: <4AF9876B.7060400@everydns.net> On 11/10/09 8:05 AM, John Peach wrote: > On Mon, 09 Nov 2009 18:15:09 -0500 > David Ulevitch wrote: > >> On 11/9/09 6:06 PM, Alex Balashov wrote: >> >>> Anything else is COMPLETELY UNACCEPTABLE. I don't understand how or >>> why this could possibly be controversial. >> >> Because some people want the ability and choice to block DNS >> responses they don't like; just as they have the ability and choice >> to reject email they don't want to accept. >> >> When the conficker worms phones home to one of the 50,000 potential >> domains names it computes each day, there are a lot of IT folks out >> there that wish their local resolver would simply reject those DNS >> requests so that infected machines in their network fail to phone >> home. >> >> To use your language, I don't understand how or why this could >> possibly be controversial. -- Apparently it is. > > In which case, make your own nameserver authoritative for those > domains; do not foist your own wishes on other people. Umm... That's precisely what I've done. Please read the thread. -David From drew.weaver at thenap.com Tue Nov 10 12:31:01 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Tue, 10 Nov 2009 13:31:01 -0500 Subject: BGP Traffic Engineering question Message-ID: Howdy, If you have several transit providers connected to your network and much of your traffic is generally directed by the "BGP tiebreaker" (i.e. lowest IP address) is there a way, without specifying on a per-prefix basis to prefer the "tie breaker winner" slightly less often? I don't want to "completely flip" the preference so that it just saturates a different link, I am just trying to see if there is any good way to influence the "natural" selection method. We have 6 transit providers, and Level3 always wins because it is 4/8, normally this isn't a problem because we have traffic engineering systems (route science/avaya) which move traffic away from that link, but if we need to reboot the RS, or something catastrophic happens we would like it to spread out a little more evenly. Anyone have any thoughts on this? -Drew From jeffrey.lyon at blacklotus.net Tue Nov 10 12:33:34 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 10 Nov 2009 13:33:34 -0500 Subject: BGP Traffic Engineering question In-Reply-To: References: Message-ID: <16720fe00911101033k2abdd7b9y6c5165ea11e92d30@mail.gmail.com> Isn't Route Science EOL? Jeff On Tue, Nov 10, 2009 at 1:31 PM, Drew Weaver wrote: > Howdy, > > If you have several transit providers connected to your network and much of your traffic is generally directed by the "BGP tiebreaker" (i.e. lowest IP address) is there a way, without specifying on a per-prefix basis to prefer the "tie breaker winner" slightly less often? I don't want to "completely flip" the preference so that it just saturates a different link, I am just trying to see if there is any good way to influence the "natural" selection method. > > We have 6 transit providers, and Level3 always wins because it is 4/8, normally this isn't a problem because we have traffic engineering systems (route science/avaya) which move traffic away from that link, but if we need to reboot the RS, or something catastrophic happens we would like it to spread out a little more evenly. > > Anyone have any thoughts on this? > > -Drew > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From drew.weaver at thenap.com Tue Nov 10 12:36:17 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Tue, 10 Nov 2009 13:36:17 -0500 Subject: BGP Traffic Engineering question In-Reply-To: <16720fe00911101033k2abdd7b9y6c5165ea11e92d30@mail.gmail.com> References: <16720fe00911101033k2abdd7b9y6c5165ea11e92d30@mail.gmail.com> Message-ID: Sure, it still works however (for now). -Drew -----Original Message----- From: jeffrey.lyon at gmail.com [mailto:jeffrey.lyon at gmail.com] On Behalf Of Jeffrey Lyon Sent: Tuesday, November 10, 2009 1:34 PM To: Drew Weaver Cc: nanog at nanog.org Subject: Re: BGP Traffic Engineering question Isn't Route Science EOL? Jeff On Tue, Nov 10, 2009 at 1:31 PM, Drew Weaver wrote: > Howdy, > > If you have several transit providers connected to your network and much of your traffic is generally directed by the "BGP tiebreaker" (i.e. lowest IP address) is there a way, without specifying on a per-prefix basis to prefer the "tie breaker winner" slightly less often? I don't want to "completely flip" the preference so that it just saturates a different link, I am just trying to see if there is any good way to influence the "natural" selection method. > > We have 6 transit providers, and Level3 always wins because it is 4/8, normally this isn't a problem because we have traffic engineering systems (route science/avaya) which move traffic away from that link, but if we need to reboot the RS, or something catastrophic happens we would like it to spread out a little more evenly. > > Anyone have any thoughts on this? > > -Drew > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From noc.akrino at gmail.com Tue Nov 10 12:50:14 2009 From: noc.akrino at gmail.com (noc acrino) Date: Tue, 10 Nov 2009 21:50:14 +0300 Subject: Interesting Point of view - Russian police and RIPE accused of aiding RBN In-Reply-To: <16720fe00911081201x5ed20b62p330e61a1139b002c@mail.gmail.com> References: <3d8c027f0911061020g1dff43cfpc9e505602d8c0dcd@mail.gmail.com> <16720fe00911061101o338189beu3ef96022a4d5c479@mail.gmail.com> <3d8c027f0911080227j259a5f67m4d847f35538d1ca3@mail.gmail.com> <16720fe00911081201x5ed20b62p330e61a1139b002c@mail.gmail.com> Message-ID: <3d8c027f0911101050rbb330f2x77b5b974c4932c15@mail.gmail.com> Greetings! By the way, Jeffrey, by the 24th of October, when you posted the information that the RBN is located in our networks we couldn't even know about any malware redirectors on our clients resources - http://www.stopbadware.org/reports/asn/44571. I'm trying to solve the Google SB issue (still under investigation both by our team and the resource owner, but NB - it's only 1 ip from 345 sites tested by Google ) but one little question - how did you get to know about the malware abuse _before_ the actual report on stopbadware.org or on google? What were your conclusions based on? Why didn't you write to the abuse email the way it's traditionally done in the network operators' sphere? Kanak Akrino Abuse Team From jeffrey.lyon at blacklotus.net Tue Nov 10 13:09:05 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 10 Nov 2009 14:09:05 -0500 Subject: Interesting Point of view - Russian police and RIPE accused of aiding RBN In-Reply-To: <3d8c027f0911101050rbb330f2x77b5b974c4932c15@mail.gmail.com> References: <3d8c027f0911061020g1dff43cfpc9e505602d8c0dcd@mail.gmail.com> <16720fe00911061101o338189beu3ef96022a4d5c479@mail.gmail.com> <3d8c027f0911080227j259a5f67m4d847f35538d1ca3@mail.gmail.com> <16720fe00911081201x5ed20b62p330e61a1139b002c@mail.gmail.com> <3d8c027f0911101050rbb330f2x77b5b974c4932c15@mail.gmail.com> Message-ID: <16720fe00911101109k3f1aae75h358e7fb90ecf492d@mail.gmail.com> Kanak, NANOG moderators have requested this conversation go off list. Jeff On Tue, Nov 10, 2009 at 1:50 PM, noc acrino wrote: > Greetings! > > By the way, Jeffrey, by the 24th of October, when you posted the information > that the RBN is located in our networks we couldn't even know about any > malware redirectors on our clients resources - > http://www.stopbadware.org/reports/asn/44571. I'm trying to solve the Google > SB issue (still under investigation both by our team and the resource owner, > but NB - it's only 1 ip from 345 sites tested by Google ) but one little > question - how did you get to know about the malware abuse _before_ the > actual report on stopbadware.org or on google? What were your conclusions > based on? Why didn't you write to the abuse email the way it's traditionally > done in the network operators' sphere? > > Kanak > > Akrino Abuse Team > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From sking at kingrst.com Tue Nov 10 13:13:46 2009 From: sking at kingrst.com (Steven King) Date: Tue, 10 Nov 2009 14:13:46 -0500 Subject: about interdomain multipath routing. In-Reply-To: <970c8dea0911100110n5c547297u260964431a045220@mail.gmail.com> References: <7F804FE1-F08F-41E2-86AF-548CF1F1FE1B@gmail.com> <63ac96a50911091950t719a3267lfc1c289d97ce5216@mail.gmail.com> <970c8dea0911100110n5c547297u260964431a045220@mail.gmail.com> Message-ID: <4AF9BB6A.2060409@kingrst.com> We use multipath setups for our EIGRP and iBGP configurations for our internal routing as well. Although for larger networks iBGP multipath might be of use due to memory limitations on a lot of devices. Doug Lane wrote: > On Tue, Nov 10, 2009 at 3:50 AM, Matthew Petach wrote: > >> I've outlawed the use of multihop eBGP for load-sharing here; when we get >> multiple links off the same router to a peer or upstream, they are configured >> with multipath. We've got hundreds of BGP sessions across the network >> configured with multipath on them. >> >> > > Do you use iBGP multipath as well to load-balance between links on > different routers? > > I know eBGP multipath is fairly common, but I wonder how many are > using iBGP multipath as well. I doubt any carriers would support it, > so it's probably only useful for load-balancing outbound traffic. The > problem with eBGP multipath alone is that you might want to terminate > circuits from a given carrier on two different routers for redundancy > reasons, but that precludes any load-balancing with eBGP multipath. > Obviously your network has to be designed with equal-cost paths for > iBGP multipath to be of any value. > > -Doug > > -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From lists at die.net Tue Nov 10 14:04:11 2009 From: lists at die.net (Aaron Hopkins) Date: Tue, 10 Nov 2009 12:04:11 -0800 (PST) Subject: BGP Traffic Engineering question In-Reply-To: References: Message-ID: On Tue, 10 Nov 2009, Drew Weaver wrote: > If you have several transit providers connected to your network and much > of your traffic is generally directed by the "BGP tiebreaker" (i.e. lowest > IP address) is there a way, without specifying on a per-prefix basis to > prefer the "tie breaker winner" slightly less often? Assuming Cisco, set "bgp always-compare-med", "bgp deterministic-med", and in your route-map in, "set origin igp" and "set metric X". You can then vary X as you see fit as an alternate tie-breaker. As long as you never set the metric the same on two different paths for the same prefix, it'll never fall back to router-id. Depending on the transit provider, you can often match bgp communities to determine which are customer routes or the region where the announcement was heard, which you can then use as a tie-breaker when setting the metric. Barring that, as-path access-lists matching specific path fragments can do the same thing, but seems to take more work to maintain as relationships change over time. -- Aaron From jmaimon at ttec.com Tue Nov 10 14:46:07 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Tue, 10 Nov 2009 15:46:07 -0500 Subject: BGP Traffic Engineering question In-Reply-To: References: Message-ID: <4AF9D10F.6030203@ttec.com> Aaron Hopkins wrote: > On Tue, 10 Nov 2009, Drew Weaver wrote: > >> If you have several transit providers connected to your network and much >> of your traffic is generally directed by the "BGP tiebreaker" (i.e. >> lowest >> IP address) is there a way, without specifying on a per-prefix basis to >> prefer the "tie breaker winner" slightly less often? > > Assuming Cisco, set "bgp always-compare-med", "bgp deterministic-med", and > in your route-map in, "set origin igp" and "set metric X". You can then > vary X as you see fit as an alternate tie-breaker. As long as you never set > the metric the same on two different paths for the same prefix, it'll never > fall back to router-id. > > Depending on the transit provider, you can often match bgp communities to > determine which are customer routes or the region where the announcement > was > heard, which you can then use as a tie-breaker when setting the metric. > Barring that, as-path access-lists matching specific path fragments can do > the same thing, but seems to take more work to maintain as relationships > change over time. > > -- Aaron > Tutorial: Effective BGP Load Balancing Using "The Metric System" Dani Roisman, Peak Web Consulting http://tinyurl.com/yzlmmo8 From stef-list at memberwebs.com Tue Nov 10 15:19:01 2009 From: stef-list at memberwebs.com (Stef Walter) Date: Tue, 10 Nov 2009 15:19:01 -0600 Subject: Failover how much complexity will it add? In-Reply-To: <21131.1257776512@baklawasecrets.com> References: <21131.1257776512@baklawasecrets.com> Message-ID: <4AF9D8C5.5070009@memberwebs.com> adel at baklawasecrets.com wrote: > Actually thinking about this, I still need to understand the > implications of not taking a full routing table to my setup. So what > is the likely impact going to be if I take partial instead of full > routing table. Would appreciate any feedback on this. My > organisation is only looking at using BGP as a means of failover > between two separate upstream ISPs. We are not an ISP. I'm up against the same issue. I'm having a hard time understanding what partial routes will accomplish in the following scenario. Let's say we were BGP multi homed and accepting partial tables from two top level ISPs (like Sprint, Cogent, Telia, AT&T whatever). Let's say they get into a peering spat with another top level ISP. This results in one of your upstreams not routing packets to one or more ASs. In this situation, as far as I can tell, you'd want a full routing tables from your upstreams. Without a full routing table how would your router know that certain ASs are reachable through one upstream, but not the other? In this day of and age of wild-west, cowboy attitudes between some of the biggest players on the Internet, does protecting against these problems require a routing device that can handle multiple full routing tables? It would seem so... Cheers, Stef From adel at baklawasecrets.com Tue Nov 10 17:00:08 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Tue, 10 Nov 2009 23:00:08 +0000 Subject: BGP Peer Selection Considerations Message-ID: <59387.1257894008@baklawasecrets.com> I've decided to get transit from provider B independently of A, so I don't create a conflict of interest as mentioned below. However I think that I will have to use provider A's dark fibre network to connect to both peerings. Provider A tells me that they will use different routes and different entry points to get to their peering and separate routes, entries to get to B's peering. As they own the datacentre and can probably provide the bests costs for getting into the datacentres where the second transit provider is, I think I will have to use I should mention there are no transit providers on net at the datacentre facility which has been acquired by the business. I suspect it will be cheaper to get the cross connects to where the transit provider is from provider A, (did I mention provider A owns the datacentre?). I know I'll be sacrificing some resilience by using A's network to get to both Internet services, however I think I will just have to outline the risks to the business and go with it. Moving datacentres isn't an option and as long as I understand exactly what resilience I sacrifice by getting A to provide all the cross connects, I can explain that to the business. Adel On Mon 7:10 PM , William Herrin wrote: > On Mon, Nov 9, 2009 at 12:40 PM, wrote: > > I have an existing relationship with provider A, colo, cross connects > > etc. ?Provider A has offered to get the PI space, ASN number, > > purchase the transit for us with provider B and manage cross > > connects to provider B (they say they have a diverse "fibre > > backhaul network"). ?This is quite attractive from a support > > and billing perspective. ?Also suspect that provider A will be > > able to get more attractive pricing from Provider B than I > > would be able to. > > > > Am I missing things that I need to consider? > > What happens when provider A is bought by provider C and you want to > dump provider C but keep provider B? You'll have created a conflict of > interest for provider B in any negotiation you have with them. > > Be aware that provider A's diverse network for provider A's service is > the same diverse network they'll use to connect you to provider B. As > a result, many or most of the outages which impact provider A will > also impact your connectivity to provider B, defeating the central > purpose of having a provider B. > > Regards, > Bill Herrin > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > From joelja at bogus.com Tue Nov 10 17:13:55 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 11 Nov 2009 08:13:55 +0900 Subject: Failover how much complexity will it add? In-Reply-To: <4AF9D8C5.5070009@memberwebs.com> References: <21131.1257776512@baklawasecrets.com> <4AF9D8C5.5070009@memberwebs.com> Message-ID: <4AF9F3B3.3030200@bogus.com> Stef Walter wrote: > In this day of and age of wild-west, cowboy attitudes between some of > the biggest players on the Internet, does protecting against these > problems require a routing device that can handle multiple full routing > tables? It would seem so... It has been routinely observed in nanog presentations that settlement free providers by their nature miss a few prefixes that well connected transit purchasing ISPs carry. If business requirements for reachability necessitate multi-homing then carrying the tables if probably also a requirement. joel > Cheers, > > Stef > > From randy at psg.com Tue Nov 10 18:29:51 2009 From: randy at psg.com (Randy Bush) Date: Wed, 11 Nov 2009 09:29:51 +0900 Subject: Failover how much complexity will it add? In-Reply-To: <4AF9F3B3.3030200@bogus.com> References: <21131.1257776512@baklawasecrets.com> <4AF9D8C5.5070009@memberwebs.com> <4AF9F3B3.3030200@bogus.com> Message-ID: > It has been routinely observed in nanog presentations that settlement > free providers by their nature miss a few prefixes that well connected > transit purchasing ISPs carry. just trying to understand what you mean, o no transit-free provider actually has all (covering) prefixes needed to cover the active space, but o one or more reasonably small subsets of the set of transit-free providers do cover the whole active space. randy From bdfleming at kanren.net Tue Nov 10 23:28:45 2009 From: bdfleming at kanren.net (Brad Fleming) Date: Tue, 10 Nov 2009 23:28:45 -0600 Subject: Failover how much complexity will it add? In-Reply-To: <200911091919.nA9JJWAm003567@aurora.sol.net> References: <200911091919.nA9JJWAm003567@aurora.sol.net> Message-ID: <88D877E0-0E38-4536-B743-7B0F41CF271C@kanren.net> > I would have thought that this lesson would still be fresh in the > minds of people, as we just passed 256K routes a little while ago > and broke a whole bunch of Catalyst 6500/7600 SUP720-3B's (etc). > I guess the pain isn't as memorable as I thought. > Not all of us forgot... I remember the day our 7606's filled and started trying to software switch. Was a painful day indeed. At least we knew it was coming.. just couldn't do anything about it due to budgets. From adel at baklawasecrets.com Wed Nov 11 03:25:44 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Wed, 11 Nov 2009 09:25:44 +0000 Subject: Gig Throughput on IPSEC Message-ID: <6706.1257931544@baklawasecrets.com> Hi, I have a requirement to encrypt data using IPSEC over a p-t-p gig fibre link.? In the past I've normally used Juniper to terminate VPNs, as I have found them excellent devices and the route based VPN functionality very useful.? However looking at their range, only the ISG will do a gig of IPSEC.? I'm leaning towards keeping my exising Juniper SSG550's for firewall/routing capability at each site.? Then having a separate encryption devices to handle the site-to-site vpn requiring the gig throughput.? Does anyone have any suggestions on devices to use? ? Adel From adel at baklawasecrets.com Wed Nov 11 04:01:14 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Wed, 11 Nov 2009 10:01:14 +0000 Subject: Gig Throughput on IPSEC Message-ID: <29660.1257933674@baklawasecrets.com> On second thoughts, thinking about this I am probably looking for some kind of Layer2 encryption devices.? This will make things a lot easier for the deployment.? Any experiences, thoughts on these types of devices, would be much appreciated. Adel On Wed 9:25 AM , adel at baklawasecrets.com sent: Hi, I have a requirement to encrypt data using IPSEC over a p-t-p gig fibre link.? In the past I've normally used Juniper to terminate VPNs, as I have found them excellent devices and the route based VPN functionality very useful.? However looking at their range, only the ISG will do a gig of IPSEC.? I'm leaning towards keeping my exising Juniper SSG550's for firewall/routing capability at each site.? Then having a separate encryption devices to handle the site-to-site vpn requiring the gig throughput.? Does anyone have any suggestions on devices to use? ? Adel From adel at baklawasecrets.com Wed Nov 11 09:04:50 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Wed, 11 Nov 2009 15:04:50 +0000 Subject: Transit from Cogent - thoughts? Message-ID: <17717.1257951890@baklawasecrets.com> Contemplating using Cogent Communications for transit as pricing looks favourable.? Just trying to get a feel for what sort of a reputation they have in the network operators community.? I'm sure people have horror stories for every provider, but just trying to get a general idea of what sort of regard they are held in the community. Thanks Adel From bclark at spectraaccess.com Wed Nov 11 09:10:23 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Wed, 11 Nov 2009 10:10:23 -0500 Subject: Transit from Cogent - thoughts? In-Reply-To: <17717.1257951890@baklawasecrets.com> References: <17717.1257951890@baklawasecrets.com> Message-ID: <1257952223.10576.4.camel@acer-laptop> Cogent has been brought up several times over the last year. I suggest searching http://www.gossamer-threads.com/lists/nanog/users/ Otherwise you've just reopened a can of worms again. On Wed, 2009-11-11 at 15:04 +0000, adel at baklawasecrets.com wrote: > > Contemplating using Cogent Communications for transit as pricing looks > favourable. Just trying to get a feel for what sort of a reputation they > have in the network operators community. I'm sure people have horror > stories for every provider, but just trying to get a general idea of what > sort of regard they are held in the community. > > Thanks > > Adel > From jay+NANOG at tp.org Wed Nov 11 09:12:08 2009 From: jay+NANOG at tp.org (Jay Moran) Date: Wed, 11 Nov 2009 10:12:08 -0500 Subject: Transit from Cogent - thoughts? In-Reply-To: <17717.1257951890@baklawasecrets.com> References: <17717.1257951890@baklawasecrets.com> Message-ID: <7386f4500911110712r45fa0603l740d49d9228123ef@mail.gmail.com> Adel, Perhaps the best way for you to get an answer to your question without the entire list erupting for no good reason is to click on the following link which will show all messages from the NANOG mailing list about Cogent. Then you can make your decision based on past conversations as opposed to adding more messages to that archive on the topic. BTW, if you don't want to click on the link I've pasted because you are careful and prudent, just go to the nanog.markmail.org website and search for "Cogent". http://nanog.markmail.org/search/?q=cogent Good luck! Jay On Wed, Nov 11, 2009 at 10:04 AM, wrote: > > > Contemplating using Cogent Communications for transit as pricing looks > favourable. Just trying to get a feel for what sort of a reputation they > have in the network operators community. I'm sure people have horror > stories for every provider, but just trying to get a general idea of what > sort of regard they are held in the community. > > Thanks > > Adel > > From guxiaojian at gmail.com Wed Nov 11 09:13:24 2009 From: guxiaojian at gmail.com (Jian Gu) Date: Wed, 11 Nov 2009 07:13:24 -0800 Subject: Gig Throughput on IPSEC In-Reply-To: <29660.1257933674@baklawasecrets.com> References: <29660.1257933674@baklawasecrets.com> Message-ID: You can run L2TPv3 (available on IOS routers) between sites, not sure about the throughput though. On Wed, Nov 11, 2009 at 2:01 AM, wrote: > > > ?On second thoughts, thinking about this I am probably looking for some > kind of Layer2 encryption devices.? This will make things a lot easier > for the deployment.? Any experiences, thoughts on these types of devices, > would be much appreciated. > > Adel > > ?On Wed 9:25 AM , adel at baklawasecrets.com sent: > > ?Hi, > > ?I have a requirement to encrypt data using IPSEC over a p-t-p gig fibre > ?link.? In the past I've normally used Juniper to terminate VPNs, as I > ?have found them excellent devices and the route based VPN functionality > ?very useful.? However looking at their range, only the ISG will do a gig > ?of IPSEC.? I'm leaning towards keeping my exising Juniper SSG550's for > ?firewall/routing capability at each site.? Then having a separate > ?encryption devices to handle the site-to-site vpn requiring the gig > ?throughput.? Does anyone have any suggestions on devices to use? > > > > ?Adel > > > From scott at sberkman.net Wed Nov 11 09:46:12 2009 From: scott at sberkman.net (Scott Berkman) Date: Wed, 11 Nov 2009 10:46:12 -0500 Subject: Transit from Cogent - thoughts? In-Reply-To: <7386f4500911110712r45fa0603l740d49d9228123ef@mail.gmail.com> References: <17717.1257951890@baklawasecrets.com> <7386f4500911110712r45fa0603l740d49d9228123ef@mail.gmail.com> Message-ID: <01fd01ca62e6$18ffd520$4aff7f60$@net> I also suggest reading the Wikipedia page on Cogent. -Scott -----Original Message----- From: Jay Moran [mailto:jay+NANOG at tp.org] Sent: Wednesday, November 11, 2009 10:12 AM To: adel at baklawasecrets.com Cc: nanog at nanog.org Subject: Re: Transit from Cogent - thoughts? Adel, Perhaps the best way for you to get an answer to your question without the entire list erupting for no good reason is to click on the following link which will show all messages from the NANOG mailing list about Cogent. Then you can make your decision based on past conversations as opposed to adding more messages to that archive on the topic. BTW, if you don't want to click on the link I've pasted because you are careful and prudent, just go to the nanog.markmail.org website and search for "Cogent". http://nanog.markmail.org/search/?q=cogent Good luck! Jay On Wed, Nov 11, 2009 at 10:04 AM, wrote: > > > Contemplating using Cogent Communications for transit as pricing looks > favourable. Just trying to get a feel for what sort of a reputation they > have in the network operators community. I'm sure people have horror > stories for every provider, but just trying to get a general idea of what > sort of regard they are held in the community. > > Thanks > > Adel > > From adel at baklawasecrets.com Wed Nov 11 11:14:12 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Wed, 11 Nov 2009 17:14:12 +0000 Subject: Resilience - How many BGP providers Message-ID: <27203.1257959652@baklawasecrets.com> Hi, After recent discussions on the list, I've been thinking about the affects of multiple BGP feeds to the overall resilience of Internet connectivity for my organisation.? So originally when I looked at the design proposals, there was a provision in there for four connections with the same Internet provider.? Thinking about it and with the valuable input of members on this list, it was obvious that multiple connections from the same provider defeated the aim of providing resilience. So having come to the decision to use two providers and BGP peer with both, I'm wondering how much more resilience I would get by peering with?more than two?providers.? So will it significantly increase my resilience by peering with three providers for example, as both of the upstreams I choose will be multihomed to other providers.? Especially as I am only looking at peering out of the UK. Hope the above makes sense. Adel From dylan.ebner at crlmed.com Wed Nov 11 11:27:23 2009 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Wed, 11 Nov 2009 17:27:23 +0000 Subject: Resilience - How many BGP providers In-Reply-To: <27203.1257959652@baklawasecrets.com> References: <27203.1257959652@baklawasecrets.com> Message-ID: <017265BF3B9640499754DD48777C3D2066697BD885@MBX9.EXCHPROD.USA.NET> You question has many caveats. Just having two providers does not necessarily get you more resiliency. If you have two providers and they are terminating on the same router, then you still have a SPOF problem. You also need to look at pysical paths as well. If you have two (or three) providers and they are using a common carrier, then you have a problem as well. For example, GLBX has a small prescence in the Minneapolis metro. If I were to use them as a provider, they would use Qwest as a last mile. If my other provider is Qwest (which it is), I may not have path divergence. Facilities are important too. We have three upstreams; Qwest, MCI and ATT. The facility only has two entrances, so that means two of these are in the same conduit. IF you only have one entrance, all you connections are going to run through that conduit, and that makes you susceptable to a rouge backhoe. You are on the right track to question your resilancy. Some upstreams can offer good resilancy with multiple feeds. Others cannot. I would start with your provider and see what you are getting. Maybe you already have path divergence, sperate last miles, and multiple paths in the isp core. If you go with multiple providers, you want to make sure you don't risk losing something you already have. -----Original Message----- From: adel at baklawasecrets.com [mailto:adel at baklawasecrets.com] Sent: Wednesday, November 11, 2009 11:14 AM To: nanog at nanog.org Subject: Resilience - How many BGP providers Hi, After recent discussions on the list, I've been thinking about the affects of multiple BGP feeds to the overall resilience of Internet connectivity for my organisation.? So originally when I looked at the design proposals, there was a provision in there for four connections with the same Internet provider.? Thinking about it and with the valuable input of members on this list, it was obvious that multiple connections from the same provider defeated the aim of providing resilience. So having come to the decision to use two providers and BGP peer with both, I'm wondering how much more resilience I would get by peering with?more than two?providers.? So will it significantly increase my resilience by peering with three providers for example, as both of the upstreams I choose will be multihomed to other providers.? Especially as I am only looking at peering out of the UK. Hope the above makes sense. Adel From jay at west.net Wed Nov 11 11:49:04 2009 From: jay at west.net (Jay Hennigan) Date: Wed, 11 Nov 2009 09:49:04 -0800 Subject: Resilience - How many BGP providers In-Reply-To: <017265BF3B9640499754DD48777C3D2066697BD885@MBX9.EXCHPROD.USA.NET> References: <27203.1257959652@baklawasecrets.com> <017265BF3B9640499754DD48777C3D2066697BD885@MBX9.EXCHPROD.USA.NET> Message-ID: <4AFAF910.9020403@west.net> Dylan Ebner wrote: > IF you only have one entrance, all you connections are going to run through that conduit, and that makes you susceptable to a rouge backhoe. Not just the rouge ones. The big yellow ones are far more common and can do just as much damage. -- 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 bdfleming at kanren.net Wed Nov 11 12:45:44 2009 From: bdfleming at kanren.net (Brad Fleming) Date: Wed, 11 Nov 2009 12:45:44 -0600 Subject: Gig Throughput on IPSEC In-Reply-To: <6706.1257931544@baklawasecrets.com> References: <6706.1257931544@baklawasecrets.com> Message-ID: <743D8E24-AA62-40D0-A067-80D5E0EDACFC@kanren.net> On Nov 11, 2009, at 3:25 AM, adel at baklawasecrets.com wrote: > > > Hi, > > I have a requirement to encrypt data using IPSEC over a p-t-p gig > fibre > link. In the past I've normally used Juniper to terminate VPNs, as I > have found them excellent devices and the route based VPN > functionality > very useful. However looking at their range, only the ISG will do a > gig > of IPSEC. I'm leaning towards keeping my exising Juniper SSG550's for > firewall/routing capability at each site. Then having a separate > encryption devices to handle the site-to-site vpn requiring the gig > throughput. Does anyone have any suggestions on devices to use? > > > > Adel > > Not knowing all your other needs, I won't swear to it... but would the Juniper SRX650 work for your situation? It can pass 1.5Gbps of encrypted traffic according to their datasheet. I've never actually tried to move that much data through the box so I can't testify to it. Also, the Juniper SRX3400 is advertised as handling 6Gbps of encrypted traffic. Of course, these are JunosES devices as opposed to ScreenOS, but the transition isn't as painful as you might expect. We actually use the J- series devices with JunosES as site routers/firewalls with a great deal of success. From scg at gibbard.org Wed Nov 11 13:18:20 2009 From: scg at gibbard.org (Steve Gibbard) Date: Wed, 11 Nov 2009 11:18:20 -0800 (PST) Subject: Resilience - How many BGP providers In-Reply-To: <27203.1257959652@baklawasecrets.com> References: <27203.1257959652@baklawasecrets.com> Message-ID: The thing to remember about redundancy is that it's a statistical game rather than a magic formula. You can be reasonably sure that any single component will go down at some point. Nothing works perfectly. Few things last forever. If you have two fairly reliable components, and if they're suffciently isolated from eachother that they won't be broken by the same event, it's much less likely that they'll both break at the same time. That means that if one breaks, and you're not unlucky, you'll have time to fix it before the other breaks. If you have three components, the chances of all three being broken at once are even less than the chances of two of them being broken at once. With four, you're even safer, and so on and so forth. But once you get beyond two, you hit a point of diminishing returns pretty quickly. That doesn't mean you should always do two of any given component. Some things may be so important that you're not willing to take that level of risk and are willing to spend significantly more money to get a small amount more protection. Some things may be sufficiently unimportant that you're willing to deal with occasional outages, and you can get by without a spare (few people -- with obvious exceptions who we don't need to hear about right now -- have fully redundant home connectivity, for instance). It's just a matter of understanding the risks, and doing the cost-benefit analysis to determine how much protection you need and how much you're willing to pay for it. -Steve On Wed, 11 Nov 2009, adel at baklawasecrets.com wrote: > > > Hi, > > After recent discussions on the list, I've been thinking about the affects > of multiple BGP feeds to the overall resilience of Internet connectivity > for my organisation.? So originally when I looked at the design > proposals, there was a provision in there for four connections with the > same Internet provider.? Thinking about it and with the valuable input of > members on this list, it was obvious that multiple connections from the > same provider defeated the aim of providing resilience. > > So having come to the decision to use two providers and BGP peer with > both, I'm wondering how much more resilience I would get by peering > with?more than two?providers.? So will it significantly increase my > resilience by peering with three providers for example, as both of the > upstreams I choose will be multihomed to other providers.? Especially as > I am only looking at peering out of the UK. > > Hope the above makes sense. > > Adel > > From adel at baklawasecrets.com Wed Nov 11 14:07:03 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Wed, 11 Nov 2009 20:07:03 +0000 Subject: Gig Throughput on IPSEC - alternatively Layer2 encryption devices Message-ID: <58061.1257970023@baklawasecrets.com> Hi, Thanks for the pointers to the Juniper devices. I think I'm really thinking about layer2 encryption, rather than do the encryption using IPSEC. I feel that as its a p-t-p fibre link, this makes most sense in terms of throughput and least impact on the network. Operating at layer3 the IPSEC solution introduces more complexity than I would like across this link. As I understand it, with layer2 encryption devices VLANs between the sites, would "just work". I'm interested to hear of peoples experiences with layer 2 encryption devices out there, as I don't have that much experience with them. I think my subject line mentioning IPSEC is a bit confusing as I'm really after information on Layer2 encryption hardware. Adel On Wed 6:45 PM , Brad Fleming bdfleming at kanren.net sent: > > On Nov 11, 2009, at 3:25 AM, adel@ > baklawasecrets.com wrote: > > > > > > Hi, > > > > I have a requirement to encrypt data using IPSEC > over a p-t-p gig > fibre > > link. In the past I've normally used Juniper to > terminate VPNs, as I> have found them excellent devices and the route > based VPN > functionality > > very useful. However looking at their range, > only the ISG will do a > gig > > of IPSEC. I'm leaning towards keeping my > exising Juniper SSG550's for> firewall/routing capability at each site. Then > having a separate> encryption devices to handle the site-to-site > vpn requiring the gig> throughput. Does anyone have any suggestions on > devices to use?> > > > > > > Adel > > > > > > Not knowing all your other needs, I won't swear to it... but would the > Juniper SRX650 work for your situation? It can pass 1.5Gbps of > encrypted traffic according to their datasheet. I've never actually > tried to move that much data through the box so I can't testify to it. > > Also, the Juniper SRX3400 is advertised as handling 6Gbps of encrypted > traffic. > > Of course, these are JunosES devices as opposed to ScreenOS, but the > transition isn't as painful as you might expect. We actually use the J- > series devices with JunosES as site routers/firewalls with a great > deal of success. > > > From nj at critical.net Wed Nov 11 14:34:24 2009 From: nj at critical.net (Operations) Date: Wed, 11 Nov 2009 12:34:24 -0800 Subject: Performance to and from Japan (who to connect to?) Message-ID: Greetings, Im sure someone here is GREAT with connecting to Japan so I ask the following: We have a POP in 600 West 7th street, Los Angeles. What provider can I cross-connect to there to get better performance to Japan? Are there Japanese providers on net in that building? Anyone want to peer with me there that can give me better routing to Japan? Thank you very much Nanog. NJ Critical Data Network http://www.critical.net From fw at deneb.enyo.de Wed Nov 11 14:48:39 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 11 Nov 2009 21:48:39 +0100 Subject: What DNS Is Not In-Reply-To: <20091110.143045.74683595.sthaug@nethelp.no> (sthaug@nethelp.no's message of "Tue, 10 Nov 2009 14:30:45 +0100 (CET)") References: <4AF8A090.9050201@evaristesys.com> <4AF8A27D.2080405@everydns.net> <20091110080539.35005525@jpeach-desktop.1425mad.mountsinai.org> <20091110.143045.74683595.sthaug@nethelp.no> Message-ID: <873a4k3hzs.fsf@mid.deneb.enyo.de> > Since people need to *explicitly* choose using the OpenDNS servers, I > can hardly see how anybody's wishes are foisted on these people. > > If you don't like the answers you get from this (free) service, you > can of course choose to use a different service - for instance your > ISP's name servers. What if your ISP's name servers are those from OpenDNS? From jg at slash128.com Wed Nov 11 14:52:58 2009 From: jg at slash128.com (Jason Granat) Date: Wed, 11 Nov 2009 12:52:58 -0800 Subject: What DNS Is Not In-Reply-To: <873a4k3hzs.fsf@mid.deneb.enyo.de> References: <4AF8A090.9050201@evaristesys.com> <4AF8A27D.2080405@everydns.net> <20091110080539.35005525@jpeach-desktop.1425mad.mountsinai.org> <20091110.143045.74683595.sthaug@nethelp.no> <873a4k3hzs.fsf@mid.deneb.enyo.de> Message-ID: <4B7C6FA1C76F2E45B236701F379AD4AD01E0F1B6E75E@mx2.lab.local> Run your own nameservers or get a different ISP that doesn't force you to be filtered :-) -----Original Message----- From: Florian Weimer [mailto:fw at deneb.enyo.de] Sent: Wednesday, November 11, 2009 12:49 PM To: sthaug at nethelp.no Cc: nanog at nanog.org Subject: Re: What DNS Is Not > Since people need to *explicitly* choose using the OpenDNS servers, I > can hardly see how anybody's wishes are foisted on these people. > > If you don't like the answers you get from this (free) service, you > can of course choose to use a different service - for instance your > ISP's name servers. What if your ISP's name servers are those from OpenDNS? http://slash128.com From patrick at ianai.net Wed Nov 11 14:56:55 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 11 Nov 2009 15:56:55 -0500 Subject: What DNS Is Not In-Reply-To: <873a4k3hzs.fsf@mid.deneb.enyo.de> References: <4AF8A090.9050201@evaristesys.com> <4AF8A27D.2080405@everydns.net> <20091110080539.35005525@jpeach-desktop.1425mad.mountsinai.org> <20091110.143045.74683595.sthaug@nethelp.no> <873a4k3hzs.fsf@mid.deneb.enyo.de> Message-ID: <6A2DDFD6-BE85-4773-8B12-0223EB60EBF6@ianai.net> On Nov 11, 2009, at 3:48 PM, Florian Weimer wrote: >> Since people need to *explicitly* choose using the OpenDNS servers, I >> can hardly see how anybody's wishes are foisted on these people. >> >> If you don't like the answers you get from this (free) service, you >> can of course choose to use a different service - for instance your >> ISP's name servers. > > What if your ISP's name servers are those from OpenDNS? 1) You can personally opt-out of OpenDNS' NXDOMAIN stuff & such. 2) I don't really see how that makes a difference. The point is, OpenDNS is not forcing anyone. Your ISP has a policy you don't like, use a different ISP. If there is no other ISP, well, I don't know what to tell you? Start one? Move? End of day, it is an OPT-IN service. If you happen to "opt-in" by buying service from your ISP, that does not change the basic premise. -- TTFN, patrick From sthaug at nethelp.no Wed Nov 11 14:57:48 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 11 Nov 2009 21:57:48 +0100 (CET) Subject: What DNS Is Not In-Reply-To: <873a4k3hzs.fsf@mid.deneb.enyo.de> References: <20091110080539.35005525@jpeach-desktop.1425mad.mountsinai.org> <20091110.143045.74683595.sthaug@nethelp.no> <873a4k3hzs.fsf@mid.deneb.enyo.de> Message-ID: <20091111.215748.41642581.sthaug@nethelp.no> > > Since people need to *explicitly* choose using the OpenDNS servers, I > > can hardly see how anybody's wishes are foisted on these people. > > > > If you don't like the answers you get from this (free) service, you > > can of course choose to use a different service - for instance your > > ISP's name servers. > > What if your ISP's name servers are those from OpenDNS? Then I guess you need to vote with your wallet and find a different ISP. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From Valdis.Kletnieks at vt.edu Wed Nov 11 15:34:49 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 11 Nov 2009 16:34:49 -0500 Subject: What DNS Is Not In-Reply-To: Your message of "Wed, 11 Nov 2009 21:48:39 +0100." <873a4k3hzs.fsf@mid.deneb.enyo.de> References: <4AF8A090.9050201@evaristesys.com> <4AF8A27D.2080405@everydns.net> <20091110080539.35005525@jpeach-desktop.1425mad.mountsinai.org> <20091110.143045.74683595.sthaug@nethelp.no> <873a4k3hzs.fsf@mid.deneb.enyo.de> Message-ID: <14355.1257975289@turing-police.cc.vt.edu> On Wed, 11 Nov 2009 21:48:39 +0100, Florian Weimer said: > > Since people need to *explicitly* choose using the OpenDNS servers, I > > can hardly see how anybody's wishes are foisted on these people. > > > > If you don't like the answers you get from this (free) service, you > > can of course choose to use a different service - for instance your > > ISP's name servers. > > What if your ISP's name servers are those from OpenDNS? # vi /etc/resolv.conf -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dmm at 1-4-5.net Wed Nov 11 15:50:37 2009 From: dmm at 1-4-5.net (David Meyer) Date: Wed, 11 Nov 2009 13:50:37 -0800 Subject: [NANOG-announce] NANOG 48 Call for Presentations now available Message-ID: <20091111215037.GA8106@1-4-5.net> Folks, The NANOG 48 Call for Presentations is now available at http://www.nanog.org/meetings/nanog48/index.php. Please take a look at the important dates, and submit your proposals at http://pc.nanog.org. Look forward to seeing you all in Austin. Thanks, Dave (for the NANOG PC) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From adel at baklawasecrets.com Wed Nov 11 17:41:37 2009 From: adel at baklawasecrets.com (adel at baklawasecrets.com) Date: Wed, 11 Nov 2009 23:41:37 +0000 Subject: Resilience - How many BGP providers Message-ID: <63076.1257982897@baklawasecrets.com> I suppose I could take the whole resilience thing further and further and further. One of the replies used a phrase which I thing captured the problem quite nicely: "diminishing returns". Basically I could spend lots and lots of money to try and eliminate all single points of failure. Clearly I don't have the money to do this and what I'm really trying to establish is at what point do the returns start to diminish with regards to obtaining multiple transit providers. The answer appears to be "it depends". So if getting a third BGP peering with divergent paths, separate last mile, separate facility and separate router will increase costs by 5x but only increase resilience by 0.001% is it really worth it? I'm trying to quantify the resilience of my Internet connectivity and quantify the effects of adding more providers. Now to run through my case: - I have one facility to locate BGP routers at. Thats not changing for the moment. - I can afford two BGP routers. - The facility I'm located at tell me they have divergent fibre paths and multiple entries into the facility. (Still need to verify this by getting them to walk the routes with me) - I am going to take transit from two upstreams. - I could ask the question as to whether I can peer with separate routers on each of the upstreams. i.e. to protect against router failures on their side. - I will make sure that neither upstream peers with the other directly. (Does this give me some AS path redundancy?) So from the above: - I have no resilience with regards to datacentre location. i.e. if a plane fell out of the sky etc., I'm done. - I can afford some BGP router resilience on my side. So I should be able to continue working if a router failure which only affects one of my routers occurs. - I have some resilience in terms of actual fibre paths to the facilites where I will be picking up the BGP feeds from. (to be verified) - I have some "AS resilience" if this is the right term. So if the AS of one of my upstreams drops off the face of the Internet, I can still get to the Internet through the AS of my other provider - Peering with separate routers may give me some resilience for router failure on the side of my upstreams? (not totally sure on this) In this situation, if I add another peering with another upstream, am I really getting much return in terms of resilience? Or should I spend this money examining the many other SPOFs in my architecture? I'm perfectly sure there is absolutely no point me peering with 6 providers, but maybe some gains in peering with 3? I'm trying to figure out at what point is adding another peering in my case a waste of money. I haven't gone into switch and power redundancy, because I "think" I understand it. I wanted to concentrate on the multiple upstreams question. Heads starting to whirl right about now. Adel On Wed 5:27 PM , "Dylan Ebner" dylan.ebner at crlmed.com sent: > > You question has many caveats. Just having two providers does not > necessarily get you more resiliency. If you have two providers and they are > terminating on the same router, then you still have a SPOF problem. You > also need to look at pysical paths as well. If you have two (or three) > providers and they are using a common carrier, then you have a problem as > well. For example, GLBX has a small prescence in the Minneapolis metro. If > I were to use them as a provider, they would use Qwest as a last mile. If > my other provider is Qwest (which it is), I may not have path > divergence.Facilities are important too. We have three upstreams; Qwest, MCI and ATT. > The facility only has two entrances, so that means two of these are in the > same conduit. IF you only have one entrance, all you connections are going > to run through that conduit, and that makes you susceptable to a rouge > backhoe. > You are on the right track to question your resilancy. Some upstreams can > offer good resilancy with multiple feeds. Others cannot. I would start with > your provider and see what you are getting. Maybe you already have path > divergence, sperate last miles, and multiple paths in the isp core. If you > go with multiple providers, you want to make sure you don't risk losing > something you already have. > > > > -----Original Message----- > From: adel at baklawasecrets.com [adel@ > baklawasecrets.com] Sent: Wednesday, November 11, 2009 11:14 AM > To: nanog at nanog.o > rgSubject: Resilience - How many BGP providers > > > > Hi, > > After recent discussions on the list, I've been thinking about the > affectsof multiple BGP feeds to the overall resilience of Internet > connectivityfor my organisation.? So originally when I looked at the design > proposals, there was a provision in there for four connections with the > same Internet provider.? Thinking about it and with the valuable input > ofmembers on this list, it was obvious that multiple connections from the > same provider defeated the aim of providing resilience. > > So having come to the decision to use two providers and BGP peer with > both, I'm wondering how much more resilience I would get by peering > with?more than two?providers.? So will it significantly > increase myresilience by peering with three providers for example, as both of the > upstreams I choose will be multihomed to other providers.? Especially > asI am only looking at peering out of the UK. > > Hope the above makes sense. > > Adel > > > > > From hiersd at gmail.com Wed Nov 11 18:05:55 2009 From: hiersd at gmail.com (David Hiers) Date: Wed, 11 Nov 2009 16:05:55 -0800 Subject: Resilience - How many BGP providers In-Reply-To: <63076.1257982897@baklawasecrets.com> References: <63076.1257982897@baklawasecrets.com> Message-ID: <2873f3700911111605s125f039aja44fa02a4c27ef0f@mail.gmail.com> It is wise to stack the deck in your favor, but you'll never really know how much real redundancy you've purchased: http://www.atis.org/ndai/ATIS_NDAI_Final_Report_2006.pdf David On Wed, Nov 11, 2009 at 3:41 PM, wrote: > I suppose I could take the whole resilience thing further and further and further. ?One of the replies used a phrase which I thing captured the problem quite nicely: "diminishing returns". > Basically I could spend lots and lots of money to try and eliminate all single points of failure. ?Clearly I don't have the money to do this and what I'm really trying to establish is at what > point do the returns start to diminish with regards to obtaining multiple transit providers. ?The answer appears to be "it depends". ?So if getting a third BGP peering with divergent paths, > separate last mile, separate facility and separate router will increase costs by 5x but only increase resilience by 0.001% is it really worth it? ?I'm trying to quantify the resilience of my > Internet connectivity and quantify the effects of adding more providers. ?Now to run through my case: > > - I have one facility to locate BGP routers at. ?Thats not changing for the moment. > - I can afford two BGP routers. > - The facility I'm located at tell me they have divergent fibre paths and multiple entries into the facility. (Still need to verify this by getting them to walk the routes with me) > - I am going to take transit from two upstreams. > - I could ask the question as to whether I can peer with separate routers on each of the upstreams. ?i.e. to protect against router failures on their side. > - I will make sure that neither upstream peers with the other directly. (Does this give me some AS path redundancy?) > > So from the above: > > - I have no resilience with regards to datacentre location. ?i.e. if a plane fell out of the sky etc., I'm done. > - I can afford some BGP router resilience on my side. ?So I should be able to continue working if a router failure which only affects one of my routers occurs. > - I have some resilience in terms of actual fibre paths to the facilites where I will be picking up the BGP feeds from. (to be verified) > - I have some "AS resilience" if this is the right term. ?So if the AS of one of my upstreams drops off the face of the Internet, I can still get to the Internet through the AS of my other > provider > - Peering with separate routers may give me some resilience for router failure on the side of my upstreams? (not totally sure on this) > > In this situation, if I add another peering with another upstream, am I really getting much return in terms of resilience? ?Or should I spend this money examining the many other SPOFs in > my architecture? ?I'm perfectly sure there is absolutely no point me peering with 6 providers, but maybe some gains in peering with 3? ?I'm trying to figure out at what point is adding > another peering in my case a waste of money. > > I haven't gone into switch and power redundancy, because I "think" I understand it. ?I wanted to concentrate on the multiple upstreams question. ?Heads starting to whirl right about now. > > Adel > > > On Wed ? 5:27 PM , "Dylan Ebner" dylan.ebner at crlmed.com sent: >> >> You question has many caveats. Just having two providers does not >> necessarily get you more resiliency. If you have two providers and they are >> terminating on the same router, then you still have a SPOF problem. You >> also need to look at pysical paths as well. If you have two (or three) >> providers and they are using a common carrier, then you have a problem as >> well. For example, GLBX has a small prescence in the Minneapolis metro. If >> I were to use them as a provider, they would use Qwest as a last mile. If >> my other provider is Qwest (which it is), I may not have path >> divergence.Facilities are important too. We have three upstreams; Qwest, MCI and ATT. >> The facility only has two entrances, so that means two of these are in the >> same conduit. IF you only have one entrance, all you connections are going >> to run through that conduit, and that makes you susceptable to a rouge >> backhoe. >> You are on the right track to question your resilancy. Some upstreams can >> offer good resilancy with multiple feeds. Others cannot. I would start with >> your provider and see what you are getting. Maybe you already have path >> divergence, sperate last miles, and multiple paths in the isp core. ?If you >> go with multiple providers, you want to make sure you don't risk losing >> something you already have. >> >> >> >> -----Original Message----- >> From: adel at baklawasecrets.com [adel@ >> baklawasecrets.com] Sent: Wednesday, November 11, 2009 11:14 AM >> To: nanog at nanog.o >> rgSubject: Resilience - How many BGP providers >> >> >> >> Hi, >> >> After recent discussions on the list, I've been thinking about the >> affectsof multiple BGP feeds to the overall resilience of Internet >> connectivityfor my organisation.? So originally when I looked at the design >> proposals, there was a provision in there for four connections with the >> same Internet provider.? Thinking about it and with the valuable input >> ofmembers on this list, it was obvious that multiple connections from the >> same provider defeated the aim of providing resilience. >> >> So having come to the decision to use two providers and BGP peer with >> both, I'm wondering how much more resilience I would get by peering >> with?more than two?providers.? So will it significantly >> increase myresilience by peering with three providers for example, as both of the >> upstreams I choose will be multihomed to other providers.? Especially >> asI am only looking at peering out of the UK. >> >> Hope the above makes sense. >> >> Adel >> >> >> >> >> > > > From davidu at everydns.net Wed Nov 11 20:26:30 2009 From: davidu at everydns.net (David Ulevitch) Date: Wed, 11 Nov 2009 18:26:30 -0800 Subject: What DNS Is Not In-Reply-To: <873a4k3hzs.fsf@mid.deneb.enyo.de> References: <4AF8A090.9050201@evaristesys.com> <4AF8A27D.2080405@everydns.net> <20091110080539.35005525@jpeach-desktop.1425mad.mountsinai.org> <20091110.143045.74683595.sthaug@nethelp.no> <873a4k3hzs.fsf@mid.deneb.enyo.de> Message-ID: <4AFB7256.2080909@everydns.net> On 11/11/09 12:48 PM, Florian Weimer wrote: >> Since people need to *explicitly* choose using the OpenDNS servers, I >> can hardly see how anybody's wishes are foisted on these people. >> >> If you don't like the answers you get from this (free) service, you >> can of course choose to use a different service - for instance your >> ISP's name servers. > > What if your ISP's name servers are those from OpenDNS? We don't sell service to ISPs. That's a deliberate decision. But you already knew that. -David From truman at suspicious.org Wed Nov 11 21:56:19 2009 From: truman at suspicious.org (Truman Boyes) Date: Thu, 12 Nov 2009 14:56:19 +1100 Subject: Gig Throughput on IPSEC In-Reply-To: <743D8E24-AA62-40D0-A067-80D5E0EDACFC@kanren.net> References: <6706.1257931544@baklawasecrets.com> <743D8E24-AA62-40D0-A067-80D5E0EDACFC@kanren.net> Message-ID: On 12/11/2009, at 5:45 AM, Brad Fleming wrote: > > On Nov 11, 2009, at 3:25 AM, adel at baklawasecrets.com wrote: > >> >> >> Hi, >> >> I have a requirement to encrypt data using IPSEC over a p-t-p gig >> fibre >> link. In the past I've normally used Juniper to terminate VPNs, as I >> have found them excellent devices and the route based VPN >> functionality >> very useful. However looking at their range, only the ISG will do >> a gig >> of IPSEC. I'm leaning towards keeping my exising Juniper SSG550's >> for >> firewall/routing capability at each site. Then having a separate >> encryption devices to handle the site-to-site vpn requiring the gig >> throughput. Does anyone have any suggestions on devices to use? >> >> >> >> Adel >> >> > > Not knowing all your other needs, I won't swear to it... but would > the Juniper SRX650 work for your situation? It can pass 1.5Gbps of > encrypted traffic according to their datasheet. I've never actually > tried to move that much data through the box so I can't testify to it. > > Also, the Juniper SRX3400 is advertised as handling 6Gbps of > encrypted traffic. > > Of course, these are JunosES devices as opposed to ScreenOS, but the > transition isn't as painful as you might expect. We actually use the > J-series devices with JunosES as site routers/firewalls with a great > deal of success. The usual caveats apply: packet size, packets per second, etc; but with an SRX 3400/3600 you can scale up the performance of IPSEC VPN throughput with additional SPCs. You should be able to scale to over 6Gbps of IPSEC with enough SPCs. Truman From joakim at aronius.com Thu Nov 12 01:46:41 2009 From: joakim at aronius.com (Joakim Aronius) Date: Thu, 12 Nov 2009 08:46:41 +0100 Subject: Gig Throughput on IPSEC In-Reply-To: References: <6706.1257931544@baklawasecrets.com> <743D8E24-AA62-40D0-A067-80D5E0EDACFC@kanren.net> Message-ID: <20091112074641.GA1578@maya.aronius.com> * Truman Boyes (truman at suspicious.org) wrote: > > an SRX 3400/3600 you can scale up the performance of IPSEC VPN > throughput with additional SPCs. You should be able to scale to over > 6Gbps of IPSEC with enough SPCs. > > Truman Yes, the SRX line of products is the most future-proof way to go. I had a meeting with Juniper technical sales a short while ago and they also stated that "performace figures of the SRX is more in line what you get in real deployments" (compared to the ISG and NS marketing material which have IPsec throughput figures which you probably not will see in the field, same as most vendors). In the ISG and NS series you also need to be aware on capacity limitations in the cards and the backplane. ...and as no one else has commented on L2 security devices I assume that there is not many products for this (IEEE 802.1AE MAC Security). But on the other hand I suppose that there is mostly L3 people on this list and that the Metro Ethernet folks hangs elsewhere.. (I would go for IPsec.) Cheers, /Joakim From tore at linpro.no Thu Nov 12 02:11:38 2009 From: tore at linpro.no (Tore Anderson) Date: Thu, 12 Nov 2009 09:11:38 +0100 Subject: Resilience - How many BGP providers In-Reply-To: <63076.1257982897@baklawasecrets.com> References: <63076.1257982897@baklawasecrets.com> Message-ID: <4AFBC33A.7010103@linpro.no> * adel at baklawasecrets.com > - I could ask the question as to whether I can peer with separate > routers on each of the upstreams. i.e. to protect against router > failures on their side. If you're getting transit from two different upstreams, you're pretty much guaranteed to be connected to two different routers. Unless you're thinking about establishing redundant connections to each provider, that is. What you should ensure, though, is that the PoPs of the two upstreams are not found in the same physical building (or neighbourhood for that matter), and that the fibres that connects you to those PoPs never cross - it doesn't really help that much with two trenches on each side of your building if the paths converge 1km away from it. You might also want to consider getting the fibres from two different providers to guard against contract-related disputes, unexpected bankruptcies, or similar that would cause the fibre provider to terminating/suspending your service. > - I will make sure that neither upstream peers with the other > directly. This does not make any sense, if you're talking about peering. Peering is a good thing for reliability and performance. I see from the rest of your e-mail that you're mixing up the terms peering and transit, though, so if you're taking about your provider A purchasing transit from provider B, it makes perfect sense - at least if provider A is _only_ getting transit from B. If on the other hand provider A is getting transit from C, D, and E in addition to B, it's not really a problem. It might also be the case that A and B both get transit from C only, which would make C a single point of failure for you. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From shoshon at shoshon.ro Thu Nov 12 04:11:49 2009 From: shoshon at shoshon.ro (Bogdan) Date: Thu, 12 Nov 2009 12:11:49 +0200 Subject: qos 3560 Message-ID: <4AFBDF65.5050208@shoshon.ro> hello i am playing with qos on some devices - cisco 3560 - cisco 7609 and i have some things that i don't seem to understand. 1. in 3560, i enable mls qos, on the ingress port applyed policy map, classify the packets with acl, mark, all good. on the egress ports i use srr-queue with shape/share, everything is fine, it is working. http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_20_se/configuration/guide/swqos.html#wp1028614 2. reset to defaults the 3560 in 7606 i pick up a vlan, and apply a policy-map and set dscp 40 on egress of that vlan 3560 in uplinked in 7609 in 3560 i can see the "marked" packets, and i have matches on the dscp set earlier (sh mls qos int xx stat). the problem is: when i apply the srr-queue in 3560 on egress (towards the test port), it does not work. if i enable mls qos on 3560, i cannot match anymore the dscp 40 from the 7609 is it normal? do i have to apply the qos stuff (point1) on all switches i want qos on? i mean, i cannot set dscp in one "core" device and use that in the whole network ? thanks From fweimer at bfk.de Thu Nov 12 04:23:48 2009 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 12 Nov 2009 10:23:48 +0000 Subject: Gig Throughput on IPSEC In-Reply-To: <29660.1257933674@baklawasecrets.com> (adel@baklawasecrets.com's message of "Wed\, 11 Nov 2009 10\:01\:14 +0000") References: <29660.1257933674@baklawasecrets.com> Message-ID: <82r5s4kpmz.fsf@mid.bfk.de> > On second thoughts, thinking about this I am probably looking for some > kind of Layer2 encryption devices.? This will make things a lot easier > for the deployment.? Any experiences, thoughts on these types of devices, > would be much appreciated. You could use OpenVPN, but that would be cheating. 8-) -- 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 bfeeny at mac.com Thu Nov 12 07:21:55 2009 From: bfeeny at mac.com (Brian Feeny) Date: Thu, 12 Nov 2009 08:21:55 -0500 Subject: qos 3560 In-Reply-To: <4AFBDF65.5050208@shoshon.ro> References: <4AFBDF65.5050208@shoshon.ro> Message-ID: <6C0DDCBD-D8AB-4CCD-96B0-81908831CA16@mac.com> You should make sure that any links that go between devices have trust set. In your case if your doing DSCP, then make sure each link that goes between devices which must carry tagged packets have trust dscp set. Brian On Nov 12, 2009, at 5:11 AM, Bogdan wrote: > hello > > i am playing with qos on some devices > - cisco 3560 > - cisco 7609 > and i have some things that i don't seem to understand. > > 1. in 3560, i enable mls qos, on the ingress port applyed policy map, > classify the packets with acl, mark, all good. on the egress ports i > use > srr-queue with shape/share, everything is fine, it is working. > > http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_20_se/configuration/guide/swqos.html#wp1028614 > > > 2. reset to defaults the 3560 > in 7606 i pick up a vlan, and apply a policy-map and set dscp 40 on > egress of that vlan > 3560 in uplinked in 7609 > in 3560 i can see the "marked" packets, and i have matches on the dscp > set earlier (sh mls qos int xx stat). > the problem is: when i apply the srr-queue in 3560 on egress (towards > the test port), it does not work. > if i enable mls qos on 3560, i cannot match anymore the dscp 40 from > the > 7609 > > is it normal? do i have to apply the qos stuff (point1) on all > switches > i want qos on? i mean, i cannot set dscp in one "core" device and use > that in the whole network ? > > > thanks > > From bmanning at vacation.karoshi.com Thu Nov 12 07:21:23 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 12 Nov 2009 13:21:23 +0000 Subject: Performance to and from Japan (who to connect to?) In-Reply-To: References: Message-ID: <20091112132123.GC2274@vacation.karoshi.com.> KDDI, NTT, and WIDE are all on or adjacent to LAIIX. if you hit those, your pretty much covered. --bill On Wed, Nov 11, 2009 at 12:34:24PM -0800, Operations wrote: > Greetings, > > Im sure someone here is GREAT with connecting to Japan so I ask the > following: > > > We have a POP in 600 West 7th street, Los Angeles. > > What provider can I cross-connect to there to get better performance > to Japan? > Are there Japanese providers on net in that building? > > Anyone want to peer with me there that can give me better routing to > Japan? > > Thank you very much Nanog. > > NJ > Critical Data Network > http://www.critical.net > > From shoshon at shoshon.ro Thu Nov 12 08:04:07 2009 From: shoshon at shoshon.ro (Bogdan) Date: Thu, 12 Nov 2009 16:04:07 +0200 Subject: qos 3560 In-Reply-To: <6C0DDCBD-D8AB-4CCD-96B0-81908831CA16@mac.com> References: <4AFBDF65.5050208@shoshon.ro> <6C0DDCBD-D8AB-4CCD-96B0-81908831CA16@mac.com> Message-ID: <4AFC15D7.4040409@shoshon.ro> hello indeed, a fellow nanoger gave me this hint. 1. i had to enable mls qos globally in "network" switches 2. set the mls qos trust dscp on the uplinks (ingress port) thanks ps thanks to andrey.gordon too :) On 11/12/2009 03:21 PM, Brian Feeny wrote: > > You should make sure that any links that go between devices have trust > set. In your case if your doing DSCP, > then make sure each link that goes between devices which must carry > tagged packets have trust dscp set. > > Brian > > On Nov 12, 2009, at 5:11 AM, Bogdan wrote: > >> hello >> >> i am playing with qos on some devices >> - cisco 3560 >> - cisco 7609 >> and i have some things that i don't seem to understand. >> >> 1. in 3560, i enable mls qos, on the ingress port applyed policy map, >> classify the packets with acl, mark, all good. on the egress ports i use >> srr-queue with shape/share, everything is fine, it is working. >> >> http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_20_se/configuration/guide/swqos.html#wp1028614 >> >> >> >> 2. reset to defaults the 3560 >> in 7606 i pick up a vlan, and apply a policy-map and set dscp 40 on >> egress of that vlan >> 3560 in uplinked in 7609 >> in 3560 i can see the "marked" packets, and i have matches on the dscp >> set earlier (sh mls qos int xx stat). >> the problem is: when i apply the srr-queue in 3560 on egress (towards >> the test port), it does not work. >> if i enable mls qos on 3560, i cannot match anymore the dscp 40 from the >> 7609 >> >> is it normal? do i have to apply the qos stuff (point1) on all switches >> i want qos on? i mean, i cannot set dscp in one "core" device and use >> that in the whole network ? >> >> >> thanks >> >> > > From swm at emanon.com Thu Nov 12 08:40:54 2009 From: swm at emanon.com (Scott Morris) Date: Thu, 12 Nov 2009 09:40:54 -0500 Subject: qos 3560 In-Reply-To: <4AFC15D7.4040409@shoshon.ro> References: <4AFBDF65.5050208@shoshon.ro> <6C0DDCBD-D8AB-4CCD-96B0-81908831CA16@mac.com> <4AFC15D7.4040409@shoshon.ro> Message-ID: <4AFC1E76.8070006@emanon.com> Look at "show mls qos map" to see the defaults that may be rewriting your information depending on trust (or non-trust) mechanisms you have configured. If you trust CoS, a frame received with cos5 and dscp46 will get rewritten to dscp 40 with default maps... "show mls qos interface (intf)" is also good to see status. Scott Bogdan wrote: > hello > > indeed, a fellow nanoger gave me this hint. > > 1. i had to enable mls qos globally in "network" switches > 2. set the mls qos trust dscp on the uplinks (ingress port) > > > thanks > > ps thanks to andrey.gordon too :) > > > > > > On 11/12/2009 03:21 PM, Brian Feeny wrote: > >> You should make sure that any links that go between devices have trust >> set. In your case if your doing DSCP, >> then make sure each link that goes between devices which must carry >> tagged packets have trust dscp set. >> >> Brian >> >> On Nov 12, 2009, at 5:11 AM, Bogdan wrote: >> >> >>> hello >>> >>> i am playing with qos on some devices >>> - cisco 3560 >>> - cisco 7609 >>> and i have some things that i don't seem to understand. >>> >>> 1. in 3560, i enable mls qos, on the ingress port applyed policy map, >>> classify the packets with acl, mark, all good. on the egress ports i use >>> srr-queue with shape/share, everything is fine, it is working. >>> >>> http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_20_se/configuration/guide/swqos.html#wp1028614 >>> >>> >>> >>> 2. reset to defaults the 3560 >>> in 7606 i pick up a vlan, and apply a policy-map and set dscp 40 on >>> egress of that vlan >>> 3560 in uplinked in 7609 >>> in 3560 i can see the "marked" packets, and i have matches on the dscp >>> set earlier (sh mls qos int xx stat). >>> the problem is: when i apply the srr-queue in 3560 on egress (towards >>> the test port), it does not work. >>> if i enable mls qos on 3560, i cannot match anymore the dscp 40 from the >>> 7609 >>> >>> is it normal? do i have to apply the qos stuff (point1) on all switches >>> i want qos on? i mean, i cannot set dscp in one "core" device and use >>> that in the whole network ? >>> >>> >>> thanks >>> >>> >>> >> > > > > > From Paul.Martin at viatel.com Thu Nov 12 09:31:02 2009 From: Paul.Martin at viatel.com (Martin, Paul) Date: Thu, 12 Nov 2009 15:31:02 -0000 Subject: qos 3560 In-Reply-To: <4AFC1E76.8070006@emanon.com> References: <4AFBDF65.5050208@shoshon.ro> <6C0DDCBD-D8AB-4CCD-96B0-81908831CA16@mac.com><4AFC15D7.4040409@shoshon.ro> <4AFC1E76.8070006@emanon.com> Message-ID: <6E91D15697439543A9636FCA11BDA1C51123522B@eghexch01.viatel.local> Following on, the best way is to 'trust' on all uplinks between devices and filter at the edge. So you have a customer who shouldn't be sending tagged traffic, set the port to not trusted (should be the default state) and any customer using QoS should have "mls qos trust dscp" on the demark port. If you don't have a trusted core, then all it takes is a simple switch in the path traffic takes and you'll find yourself scratching your head as to why the DSCP tags are disappearing all of a sudden! Paul -----Original Message----- From: Scott Morris [mailto:swm at emanon.com] Sent: 12 November 2009 14:41 To: Bogdan Cc: nanog at nanog.org Subject: Re: qos 3560 Look at "show mls qos map" to see the defaults that may be rewriting your information depending on trust (or non-trust) mechanisms you have configured. If you trust CoS, a frame received with cos5 and dscp46 will get rewritten to dscp 40 with default maps... "show mls qos interface (intf)" is also good to see status. Scott Bogdan wrote: > hello > > indeed, a fellow nanoger gave me this hint. > > 1. i had to enable mls qos globally in "network" switches > 2. set the mls qos trust dscp on the uplinks (ingress port) > > > thanks > > ps thanks to andrey.gordon too :) > > > > > > On 11/12/2009 03:21 PM, Brian Feeny wrote: > >> You should make sure that any links that go between devices have trust >> set. In your case if your doing DSCP, >> then make sure each link that goes between devices which must carry >> tagged packets have trust dscp set. >> >> Brian >> >> On Nov 12, 2009, at 5:11 AM, Bogdan wrote: >> >> >>> hello >>> >>> i am playing with qos on some devices >>> - cisco 3560 >>> - cisco 7609 >>> and i have some things that i don't seem to understand. >>> >>> 1. in 3560, i enable mls qos, on the ingress port applyed policy map, >>> classify the packets with acl, mark, all good. on the egress ports i use >>> srr-queue with shape/share, everything is fine, it is working. >>> >>> http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/relea se/12.2_20_se/configuration/guide/swqos.html#wp1028614 >>> >>> >>> >>> 2. reset to defaults the 3560 >>> in 7606 i pick up a vlan, and apply a policy-map and set dscp 40 on >>> egress of that vlan >>> 3560 in uplinked in 7609 >>> in 3560 i can see the "marked" packets, and i have matches on the dscp >>> set earlier (sh mls qos int xx stat). >>> the problem is: when i apply the srr-queue in 3560 on egress (towards >>> the test port), it does not work. >>> if i enable mls qos on 3560, i cannot match anymore the dscp 40 from the >>> 7609 >>> >>> is it normal? do i have to apply the qos stuff (point1) on all switches >>> i want qos on? i mean, i cannot set dscp in one "core" device and use >>> that in the whole network ? >>> >>> >>> thanks >>> >>> >>> >> > > > > > For more information about the Viatel Group, please visit www.viatel.com VTL (UK) Limited Registered in England and Wales Registered Address: Inbucon House, Wick Road, Egham, Surrey TW20 0HR Company Registration No: 04287100 VAT Registration Number: 781 4991 88 THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INTENDED RECIPIENT TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, you are notified that any dissemination, distribution or copying of this e-mail is prohibited, and you should delete this e-mail from your system. This message has been scanned for viruses and spam by Viatel MailControl - www.viatel.com From esavage at digitalrage.org Thu Nov 12 09:42:40 2009 From: esavage at digitalrage.org (Elijah Savage) Date: Thu, 12 Nov 2009 10:42:40 -0500 (EST) Subject: Spyware and Antivirus detection increase In-Reply-To: <18667724.61258040240031.JavaMail.root@mail> Message-ID: <15634609.81258040560690.JavaMail.root@mail> All, This may not be the right audience but I do not know of a better set of experts to ask this question. We monitor antivirus and spyware activity very close on our desktop and laptop environment. Often you can correlate this activity with an increase in bandwidth. The bandwidth is not an issue but this month we see a very big spike in antivirus and spyware detection compared to last month, 12,000 detections last month compared to 38,000 so far this month. We have all the data and know what signatures are being tripped and a good idea of where they are coming from. The question I have is this, is anyone else seeing an increase and have any idea why? Is it just the time of the year with it being the holiday season? From Grzegorz at Janoszka.pl Thu Nov 12 11:32:16 2009 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Thu, 12 Nov 2009 18:32:16 +0100 Subject: Minimum IPv6 size In-Reply-To: <4AC7C245.80008@strato-rz.de> References: <20091003210118.4F5981CC0E@ptavv.es.net> <4AC7C245.80008@strato-rz.de> Message-ID: <4AFC46A0.1090501@Janoszka.pl> Christian Seitz wrote: > There ist also a loose and a strict filter recommendation by Gert Doering [1], > but the strict filter is very strict at the moment. It allows only /48s from > RIPEs IPv6 PI space 2001:678::/29 for example, although RIPE currently also > assignes /47 or /46 from this range. Also there should be some deaggregation > allowed. When RIPE allocates a /32 to a LIR and LIR has to deaggregate it for > some reason, because he cannot get a second /32, he should be able to use (eg.) > 4 bits for deaggreation. I don't want to see a /48 where RIPE allocates only /32 > prefixes, but I would accept prefixes up to a /36. > > [1] http://www.space.net/~gert/RIPE/ipv6-filters.html I was thinking about such filters still for v4. Does anyone know if there are any /8's which have no /24 prefixes assigned? I thought about filtering out all deaggregated /24's from such /8's. (I care more about memory of my routers than on a traffic profile of a small company on another continent). Another thing: http://www.db.ripe.net/whois?form_type=simple&full_query_string=&searchtext=193.34.199.0&submit.x=0&submit.y=0&submit=Search This is a normal /25 assigned as PI with route record /25. Are they assigned in any given /8 prefix? If yes, you could easily allow /25's from given /8. -- Grzegorz Janoszka From shoshon at shoshon.ro Thu Nov 12 12:18:09 2009 From: shoshon at shoshon.ro (Bogdan) Date: Thu, 12 Nov 2009 20:18:09 +0200 (EET) Subject: qos 3560 In-Reply-To: <6E91D15697439543A9636FCA11BDA1C51123522B@eghexch01.viatel.local> References: <4AFBDF65.5050208@shoshon.ro> <6C0DDCBD-D8AB-4CCD-96B0-81908831CA16@mac.com><4AFC15D7.4040409@shoshon.ro> <4AFC1E76.8070006@emanon.com> <6E91D15697439543A9636FCA11BDA1C51123522B@eghexch01.viatel.local> Message-ID: <1625.83.166.207.2.1258049889.squirrel@webmail2.ines.ro> > Following on, the best way is to 'trust' on all uplinks between devices > and filter at the edge. So you have a customer who shouldn't be sending > tagged traffic, set the port to not trusted (should be the default > state) and any customer using QoS should have "mls qos trust dscp" on > the demark port. > > If you don't have a trusted core, then all it takes is a simple switch > in the path traffic takes and you'll find yourself scratching your head > as to why the DSCP tags are disappearing all of a sudden! indeed, i do see another dscp value in the counters. (besides mine). i tried with dscp mutation and re-mapping, but it did't work. so..start NOT trusting the edge/customers ports. > > > Paul > > > > -----Original Message----- > From: Scott Morris [mailto:swm at emanon.com] > Sent: 12 November 2009 14:41 > To: Bogdan > Cc: nanog at nanog.org > Subject: Re: qos 3560 > > Look at "show mls qos map" to see the defaults that may be rewriting > your information depending on trust (or non-trust) mechanisms you have > configured. > > If you trust CoS, a frame received with cos5 and dscp46 will get > rewritten to dscp 40 with default maps... > > "show mls qos interface (intf)" is also good to see status. > > Scott > > > > Bogdan wrote: >> hello >> >> indeed, a fellow nanoger gave me this hint. >> >> 1. i had to enable mls qos globally in "network" switches >> 2. set the mls qos trust dscp on the uplinks (ingress port) >> >> >> thanks >> >> ps thanks to andrey.gordon too :) >> >> >> >> >> >> On 11/12/2009 03:21 PM, Brian Feeny wrote: >> >>> You should make sure that any links that go between devices have > trust >>> set. In your case if your doing DSCP, >>> then make sure each link that goes between devices which must carry >>> tagged packets have trust dscp set. >>> >>> Brian >>> >>> On Nov 12, 2009, at 5:11 AM, Bogdan wrote: >>> >>> >>>> hello >>>> >>>> i am playing with qos on some devices >>>> - cisco 3560 >>>> - cisco 7609 >>>> and i have some things that i don't seem to understand. >>>> >>>> 1. in 3560, i enable mls qos, on the ingress port applyed policy > map, >>>> classify the packets with acl, mark, all good. on the egress ports i > use >>>> srr-queue with shape/share, everything is fine, it is working. >>>> >>>> > http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/relea > se/12.2_20_se/configuration/guide/swqos.html#wp1028614 >>>> >>>> >>>> >>>> 2. reset to defaults the 3560 >>>> in 7606 i pick up a vlan, and apply a policy-map and set dscp 40 on >>>> egress of that vlan >>>> 3560 in uplinked in 7609 >>>> in 3560 i can see the "marked" packets, and i have matches on the > dscp >>>> set earlier (sh mls qos int xx stat). >>>> the problem is: when i apply the srr-queue in 3560 on egress > (towards >>>> the test port), it does not work. >>>> if i enable mls qos on 3560, i cannot match anymore the dscp 40 from > the >>>> 7609 >>>> >>>> is it normal? do i have to apply the qos stuff (point1) on all > switches >>>> i want qos on? i mean, i cannot set dscp in one "core" device and > use >>>> that in the whole network ? >>>> >>>> >>>> thanks >>>> >>>> >>>> >>> >> >> >> >> >> > > > > For more information about the Viatel Group, please visit www.viatel.com > > VTL (UK) Limited Registered in England and Wales > Registered Address: Inbucon House, Wick Road, Egham, Surrey TW20 0HR > Company Registration No: 04287100 VAT Registration Number: 781 4991 88 > > THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INTENDED RECIPIENT TO > WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, > CONFIDENTIAL AND EXEMPT FROM DISCLOSURE. If the reader of this message is > not the intended recipient, or an employee or agent responsible for > delivering the message to the intended recipient, you are notified that > any dissemination, distribution or copying of this e-mail is prohibited, > and you should delete this e-mail from your system. > > This message has been scanned for viruses and spam by Viatel MailControl - > www.viatel.com > > From chris at uplogon.com Thu Nov 12 12:27:32 2009 From: chris at uplogon.com (Chris Gotstein) Date: Thu, 12 Nov 2009 12:27:32 -0600 Subject: ESPN360 Access Message-ID: <4AFC5394.7040200@uplogon.com> We've been getting more and more requests for ESPN360 from our customers. From what i understand, ESPN requires that the ISP "subscribe" to their content and pay a fee to do so. I have been unable to find much information on what it takes to subscribe and what the fees are to do so. Does anyone have more info on ESPN360? Thanks. -- ---- ---- ---- ---- Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP http://uplogon.com | +1 906 774 4847 | chris at uplogon.com From ras at e-gerbil.net Thu Nov 12 13:44:41 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Thu, 12 Nov 2009 13:44:41 -0600 Subject: Resilience - How many BGP providers In-Reply-To: References: <27203.1257959652@baklawasecrets.com> Message-ID: <20091112194440.GA51443@gerbil.cluepon.net> On Wed, Nov 11, 2009 at 11:18:20AM -0800, Steve Gibbard wrote: > If you have three components, the chances of all three being broken at > once are even less than the chances of two of them being broken at > once. With four, you're even safer, and so on and so forth. But once > you get beyond two, you hit a point of diminishing returns pretty > quickly. Not only that, but you have to ask yourself what are the chances that all these extra components will become extra points of failure and actually increase the likelihood of something going wrong. I know a lot of folks who have gotten themselves into a lot of trouble buying transit from everyone they can possibly buy from, thinking it will make their network more reliable. In most cases all it does is make their network more unstable. The more transit paths you have out there, the more likely you are to have something flap and wipe you out w/flap dampening, and the more likely you are to see any single event cause a massive amount of churn. I've seen people with 8 transit providers appear to others on the internet as though they flapped 100+ times over a single session flap, because of all the churn as the network reconverges. More transit providers also means more 95th calculations, and thus a higher bill, but that is another story for another day. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From raj.singh at demandmedia.com Thu Nov 12 13:48:55 2009 From: raj.singh at demandmedia.com (Raj Singh) Date: Thu, 12 Nov 2009 11:48:55 -0800 Subject: Layer 2 vs. Layer 3 to TOR Message-ID: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> Guys, I am wondering how many of you are doing layer 3 to top of rack switches and what the pros and cons are. Also, if you are doing layer 3 to top of rack do you guys have any links to published white papers on it? Thanks, Raj Singh From pstewart at nexicomgroup.net Thu Nov 12 13:52:56 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Thu, 12 Nov 2009 14:52:56 -0500 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> Message-ID: We are heading towards that type of deployment beginning next year with Juniper EX4200 switches in a redundant configuration. This will be pure Layer2 in nature on the switches and they will "uplink" to Juniper M10i's for layer3... the power savings, space savings etc over traditional Cisco 6500 chassis (plus all the cabling between cabinets which is in our case a nightmare) made this a pretty easy choice... and price too..;) Somewhere on Juniper's website in the product info section they have deployment whitepapers on this kind of stuff if that's of interest.... Hope this helps.. Paul -----Original Message----- From: Raj Singh [mailto:raj.singh at demandmedia.com] Sent: November-12-09 2:49 PM To: 'nanog at nanog.org' Subject: Layer 2 vs. Layer 3 to TOR Guys, I am wondering how many of you are doing layer 3 to top of rack switches and what the pros and cons are. Also, if you are doing layer 3 to top of rack do you guys have any links to published white papers on it? Thanks, Raj Singh ---------------------------------------------------------------------------- "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 feldman at twincreeks.net Thu Nov 12 14:03:12 2009 From: feldman at twincreeks.net (Steve Feldman) Date: Thu, 12 Nov 2009 15:03:12 -0500 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> Message-ID: <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> On Nov 12, 2009, at 2:48 PM, Raj Singh wrote: > Guys, > > I am wondering how many of you are doing layer 3 to top of rack > switches and what the pros and cons are. Also, if you are doing > layer 3 to top of rack do you guys have any links to published > white papers on it? Dani Roisman gave an excellent talk on this subject at NANOG 46 in Philadelpha: http://www.nanog.org/meetings/nanog46/abstracts.php?pt=MTQwOCZuYW5vZzQ2&nm=nanog46 Steve From raj.singh at demandmedia.com Thu Nov 12 14:04:06 2009 From: raj.singh at demandmedia.com (Raj Singh) Date: Thu, 12 Nov 2009 12:04:06 -0800 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> Message-ID: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DD@BLV11EXVS01.corp.dm.local> We are actually looking at going Layer 3 all the way to the top of rack and make each rack its own /24. This provides us flexibility when doing maintenance (spanning-tree). Also, troubleshooting during outages is much easier by using common tools like ping and trace routes. I want to make sure this is something other people are doing out there and want to know if anyone ran into any issues with this setup. Thanks, Raj Singh???|????Director Network Engineering _________________________________ Demand Media | eNom, Inc. Direct: 425.974.4679 15801 NE 24th St. Bellevue, WA 98008 Raj.Singh at DemandMedia.com -----Original Message----- From: Paul Stewart [mailto:pstewart at nexicomgroup.net] Sent: Thursday, November 12, 2009 11:53 AM To: Raj Singh; nanog at nanog.org Subject: RE: Layer 2 vs. Layer 3 to TOR We are heading towards that type of deployment beginning next year with Juniper EX4200 switches in a redundant configuration. This will be pure Layer2 in nature on the switches and they will "uplink" to Juniper M10i's for layer3... the power savings, space savings etc over traditional Cisco 6500 chassis (plus all the cabling between cabinets which is in our case a nightmare) made this a pretty easy choice... and price too..;) Somewhere on Juniper's website in the product info section they have deployment whitepapers on this kind of stuff if that's of interest.... Hope this helps.. Paul -----Original Message----- From: Raj Singh [mailto:raj.singh at demandmedia.com] Sent: November-12-09 2:49 PM To: 'nanog at nanog.org' Subject: Layer 2 vs. Layer 3 to TOR Guys, I am wondering how many of you are doing layer 3 to top of rack switches and what the pros and cons are. Also, if you are doing layer 3 to top of rack do you guys have any links to published white papers on it? Thanks, Raj Singh ---------------------------------------------------------------------------- "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 sethm at rollernet.us Thu Nov 12 14:19:36 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 12 Nov 2009 12:19:36 -0800 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> Message-ID: <4AFC6DD8.5050502@rollernet.us> Steve Feldman wrote: > > On Nov 12, 2009, at 2:48 PM, Raj Singh wrote: > >> Guys, >> >> I am wondering how many of you are doing layer 3 to top of rack >> switches and what the pros and cons are. Also, if you are doing layer >> 3 to top of rack do you guys have any links to published white papers >> on it? > > Dani Roisman gave an excellent talk on this subject at NANOG 46 in > Philadelpha: > > > http://www.nanog.org/meetings/nanog46/abstracts.php?pt=MTQwOCZuYW5vZzQ2&nm=nanog46 > I'd always wondered how you make a subnet available across racks with L3 rack switching. It seems that you don't. ~Seth From nicotine at warningg.com Thu Nov 12 14:39:01 2009 From: nicotine at warningg.com (Brandon Ewing) Date: Thu, 12 Nov 2009 14:39:01 -0600 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <4AFC6DD8.5050502@rollernet.us> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> <4AFC6DD8.5050502@rollernet.us> Message-ID: <20091112203901.GB29517@radiological.warningg.com> On Thu, Nov 12, 2009 at 12:19:36PM -0800, Seth Mattinen wrote: > > I'd always wondered how you make a subnet available across racks with L3 > rack switching. It seems that you don't. > > ~Seth It's possible, with prior planning. You can have the uplinks be layer 2 trunks, with a layer 3 SVI in the trunk acting as your actual routed uplink. Requires much planning in advance regarding what vlans are trunked where, etc. Allows one to do layer 3 termination at top of rack for single servers, but offer vlans that span multiple layer 3 switches with HSRP at distribution as an option for systems/services that require a common broadcast domain. -- Brandon Ewing (nicotine at warningg.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Tim_Bulger at polk.com Thu Nov 12 14:40:26 2009 From: Tim_Bulger at polk.com (Bulger, Tim) Date: Thu, 12 Nov 2009 15:40:26 -0500 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <4AFC6DD8.5050502@rollernet.us> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local><3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> <4AFC6DD8.5050502@rollernet.us> Message-ID: <550031AE4E25FE40BCD5D6894BC95DD5013F17DC@DCPWMF303.polk.com> If you use stackable switches, you can stack across cabinets (up to 3 with 1 meter Cisco 3750 Stackwise), and uplink on the ends. It's a pretty solid layout if you plan your port needs properly based on NIC density and cabinet size, plus you can cable cleanly to an adjacent cabinet's switch if necessary. Slightly off-topic.. Consider offloading 100Mb connections like PDUs, DRAC/iLO, etc. to lower cost switches to get the most out of your premium ports. -Tim -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Thursday, November 12, 2009 3:20 PM To: 'nanog at nanog.org' Subject: Re: Layer 2 vs. Layer 3 to TOR Steve Feldman wrote: > > On Nov 12, 2009, at 2:48 PM, Raj Singh wrote: > >> Guys, >> >> I am wondering how many of you are doing layer 3 to top of rack >> switches and what the pros and cons are. Also, if you are doing layer >> 3 to top of rack do you guys have any links to published white papers >> on it? > > Dani Roisman gave an excellent talk on this subject at NANOG 46 in > Philadelpha: > > > http://www.nanog.org/meetings/nanog46/abstracts.php?pt=MTQwOCZuYW5vZzQ2&nm=nanog46 > I'd always wondered how you make a subnet available across racks with L3 rack switching. It seems that you don't. ~Seth From fw at deneb.enyo.de Thu Nov 12 14:45:30 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 12 Nov 2009 21:45:30 +0100 Subject: What DNS Is Not In-Reply-To: <4AFB7256.2080909@everydns.net> (David Ulevitch's message of "Wed, 11 Nov 2009 18:26:30 -0800") References: <4AF8A090.9050201@evaristesys.com> <4AF8A27D.2080405@everydns.net> <20091110080539.35005525@jpeach-desktop.1425mad.mountsinai.org> <20091110.143045.74683595.sthaug@nethelp.no> <873a4k3hzs.fsf@mid.deneb.enyo.de> <4AFB7256.2080909@everydns.net> Message-ID: <87vdhfjwut.fsf@mid.deneb.enyo.de> * David Ulevitch: > On 11/11/09 12:48 PM, Florian Weimer wrote: >>> Since people need to *explicitly* choose using the OpenDNS servers, I >>> can hardly see how anybody's wishes are foisted on these people. >>> >>> If you don't like the answers you get from this (free) service, you >>> can of course choose to use a different service - for instance your >>> ISP's name servers. >> >> What if your ISP's name servers are those from OpenDNS? > > We don't sell service to ISPs. That's a deliberate decision. But you > already knew that. No, I'm genuinely surprised, really. After all, there is . Generally, I've got less knowledge about OpenDNS than you might think. From brandon.galbraith at gmail.com Thu Nov 12 14:49:37 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Thu, 12 Nov 2009 14:49:37 -0600 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <550031AE4E25FE40BCD5D6894BC95DD5013F17DC@DCPWMF303.polk.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> <4AFC6DD8.5050502@rollernet.us> <550031AE4E25FE40BCD5D6894BC95DD5013F17DC@DCPWMF303.polk.com> Message-ID: <366100670911121249u1dbe8a32s1564989dad33ca49@mail.gmail.com> On Thu, Nov 12, 2009 at 2:40 PM, Bulger, Tim wrote: > If you use stackable switches, you can stack across cabinets (up to 3 with > 1 meter Cisco 3750 Stackwise), and uplink on the ends. It's a pretty solid > layout if you plan your port needs properly based on NIC density and cabinet > size, plus you can cable cleanly to an adjacent cabinet's switch if > necessary. > > Slightly off-topic.. Consider offloading 100Mb connections like PDUs, > DRAC/iLO, etc. to lower cost switches to get the most out of your premium > ports. > Agreed. We use Netgear gigabit unmanaged switches for what Tim suggests to save the higher-cost-per-port switchports for server gear. -brandon > -Tim > > -----Original Message----- > From: Seth Mattinen [mailto:sethm at rollernet.us] > Sent: Thursday, November 12, 2009 3:20 PM > To: 'nanog at nanog.org' > Subject: Re: Layer 2 vs. Layer 3 to TOR > > Steve Feldman wrote: > > > > On Nov 12, 2009, at 2:48 PM, Raj Singh wrote: > > > >> Guys, > >> > >> I am wondering how many of you are doing layer 3 to top of rack > >> switches and what the pros and cons are. Also, if you are doing layer > >> 3 to top of rack do you guys have any links to published white papers > >> on it? > > > > Dani Roisman gave an excellent talk on this subject at NANOG 46 in > > Philadelpha: > > > > > > > http://www.nanog.org/meetings/nanog46/abstracts.php?pt=MTQwOCZuYW5vZzQ2&nm=nanog46 > > > > > I'd always wondered how you make a subnet available across racks with L3 > rack switching. It seems that you don't. > > ~Seth > > -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From nick at foobar.org Thu Nov 12 15:00:11 2009 From: nick at foobar.org (Nick Hilliard) Date: Thu, 12 Nov 2009 21:00:11 +0000 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <550031AE4E25FE40BCD5D6894BC95DD5013F17DC@DCPWMF303.polk.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local><3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> <4AFC6DD8.5050502@rollernet.us> <550031AE4E25FE40BCD5D6894BC95DD5013F17DC@DCPWMF303.polk.com> Message-ID: <4AFC775B.5010308@foobar.org> On 12/11/2009 20:40, Bulger, Tim wrote: > Slightly off-topic.. Consider offloading 100Mb connections like PDUs, > DRAC/iLO, etc. to lower cost switches to get the most out of your > premium ports. Not just that, you can also use lower cost switches to move your management fully out-of-band with respect to your production traffic. This can work well in times of catastrophe. Nick From david at davidcoulson.net Thu Nov 12 15:07:35 2009 From: david at davidcoulson.net (David Coulson) Date: Thu, 12 Nov 2009 16:07:35 -0500 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <4AFC6DD8.5050502@rollernet.us> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> <4AFC6DD8.5050502@rollernet.us> Message-ID: <4AFC7917.5040002@davidcoulson.net> Seth Mattinen wrote: > I'd always wondered how you make a subnet available across racks with L3 > rack switching. It seems that you don't. You could route /32s within your L3 environment, or maybe even leverage something like VPLS - Not sure of any TOR-level switches that MPLS pseudowire a port into a VPLS cloud though. Kinda makes L3 and spanning tree sound like a great option, doesn't it? From mvh at hosteurope.de Thu Nov 12 15:08:57 2009 From: mvh at hosteurope.de (Malte von dem Hagen) Date: Thu, 12 Nov 2009 22:08:57 +0100 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DD@BLV11EXVS01.corp.dm.local> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DD@BLV11EXVS01.corp.dm.local> Message-ID: <4AFC7969.7050006@hosteurope.de> Hej, Am 12.11.2009 21:04 Uhr schrieb Raj Singh: > We are actually looking at going Layer 3 all the way to the top of rack and > make each rack its own /24. what a waste of IPs and unnecessary loss of flexibility! > This provides us flexibility when doing maintenance (spanning-tree). If you use a simple setup for aggregation, you do not need xSTP. Even including redundancy, RTG (big C: flex-link) will be sufficient. Spanning the L2 over more than one rack is dirty when you do L3 on the TORs, because you need to build a Virtual Chassis or VPLS tunnels (not sure if EX4200 does that as of today). > Also, troubleshooting during outages is much easier by using > common tools like ping and trace routes. Oh, c'mon. Yes, Layer 2 is a wild jungle compared to clean routing, but tracing isn't that magic there. You have LLDP, mac-address-tables, arp-tables... > I want to make sure this is something other people are doing out there and > want to know if anyone ran into any issues with this setup. From the design POV, it is a clean and nice concept to do L3 on the TOR-switches, but in real life, it's not working very well. Everytime I played with such, with every vendor I've seen, there is just always the same conclusion: Let routers route and let switches switch. Switches which are supposed to do routing never scale, provide almost always immature implementations of common L3 features and run into capacity problems just too fast (too small tables for firewall roules, route entries, no full IPv6 capabilities, sometimes expensive licenses needed for stuff like IS-IS...). I understand the wish to keep broadcast domains small and network paths deterministic and clean, but the switches you can buy today for not-too-much-money aren't ready yet. So my hint is: Look at model #4 from the mentioned NANOG presentation. My 2 Euro-Cents, .m -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From david at davidcoulson.net Thu Nov 12 15:09:18 2009 From: david at davidcoulson.net (David Coulson) Date: Thu, 12 Nov 2009 16:09:18 -0500 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DD@BLV11EXVS01.corp.dm.local> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DD@BLV11EXVS01.corp.dm.local> Message-ID: <4AFC797E.4030407@davidcoulson.net> Raj Singh wrote: > We are actually looking at going Layer 3 all the way to the top of rack and make each rack its own /24. This provides us flexibility when doing maintenance (spanning-tree). Also, troubleshooting during outages is much easier by using common tools like ping and trace routes. I'm confused where STP fits into this. If you're doing /24s to each switch, why even bring STP into the picture? Do /31s to each TOR switch and use OSPF or ISIS. I don't know too many people who have not had an awful experience with STP at some point. From jof at thejof.com Thu Nov 12 15:29:29 2009 From: jof at thejof.com (Jonathan Lassoff) Date: Thu, 12 Nov 2009 13:29:29 -0800 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <4AFC7917.5040002@davidcoulson.net> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> <4AFC6DD8.5050502@rollernet.us> <4AFC7917.5040002@davidcoulson.net> Message-ID: <1258060985-sup-4132@sfo.thejof.com> Excerpts from David Coulson's message of Thu Nov 12 13:07:35 -0800 2009: > You could route /32s within your L3 environment, or maybe even leverage > something like VPLS - Not sure of any TOR-level switches that MPLS > pseudowire a port into a VPLS cloud though. I was recently looking into this (top-of-rack VPLS PE box). Doesn't seem to be any obvious options, though the new Juniper MX80 sounds like it can do this. It's 2 RU, and looks like it can take a DPC card or comes in a fixed 48-port GigE variety. I like the idea of doing IP routing to a top-of-rack or edge device, but have found others to be skeptical. Are there any applications that absolutely *have* to sit on the same LAN/broadcast domain and can't be configured to use unicast or multicast IP? --j From david at davidcoulson.net Thu Nov 12 15:37:24 2009 From: david at davidcoulson.net (David Coulson) Date: Thu, 12 Nov 2009 16:37:24 -0500 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <1258060985-sup-4132@sfo.thejof.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> <4AFC6DD8.5050502@rollernet.us> <4AFC7917.5040002@davidcoulson.net> <1258060985-sup-4132@sfo.thejof.com> Message-ID: <4AFC8014.3010407@davidcoulson.net> Jonathan Lassoff wrote: > I was recently looking into this (top-of-rack VPLS PE box). Doesn't seem > to be any obvious options, though the new Juniper MX80 sounds like it > can do this. It's 2 RU, and looks like it can take a DPC card or comes > in a fixed 48-port GigE variety. > The MX-series are pretty nice. That should be able to do VPLS PE, however I've never tried it - MX240 did it pretty well last time I tried. I've no clue how the cost of that switch compares to a cisco 4900 or something (not that a 4900 is anything special - L3 is all in software). > Are there any applications that absolutely *have* to sit on the same > LAN/broadcast domain and can't be configured to use unicast or multicast > IP? > The biggest hurdle we hit when trying to do TOR L3 (Cisco 4948s w/ /24s routed to each one) was devices that either required multiple physical Ethernet connections that we typically use LACP with, or any environments that do IP takeover for redundancy. Both are obviously easily worked around if you run an IGP on your servers, but that was just insanely complex for our environment. It's hard to convince people that a HP-UX box needs to work like a router now. So now we have a datacenter full of 4948s doing pure L2 and spanning tree... What a waste :-) From mvh at hosteurope.de Thu Nov 12 16:25:58 2009 From: mvh at hosteurope.de (Malte von dem Hagen) Date: Thu, 12 Nov 2009 23:25:58 +0100 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <1258060985-sup-4132@sfo.thejof.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> <4AFC6DD8.5050502@rollernet.us> <4AFC7917.5040002@davidcoulson.net> <1258060985-sup-4132@sfo.thejof.com> Message-ID: <4AFC8B76.3030805@hosteurope.de> Hi, Am 12.11.2009 22:29 Uhr schrieb Jonathan Lassoff: > Are there any applications that absolutely *have* to sit on the same > LAN/broadcast domain and can't be configured to use unicast or multicast > IP? yes. There are at least some implementations of iSCSI and the accompanying management services (e.g., for redundancy) that do not work well via routed connections. Generally, storage services may be difficult being routed. Further, some aspects of VMware (clusters) including management "need" L2 connectivity, for example when you want to dynamically shift VMs from one hardware node to another transparently and so on and so forth. The same applies to several load balancing and/or redundancy/failover mechanisms. rgds, .m -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From gbonser at seven.com Thu Nov 12 16:46:49 2009 From: gbonser at seven.com (George Bonser) Date: Thu, 12 Nov 2009 14:46:49 -0800 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> Message-ID: <5A6D953473350C4B9995546AFE9939EE075CB967@RWC-EX1.corp.seven.com> I believe the issue will become a moot point in the next 12 months when vendors begin to ship switches with TRILL. TRILL is basically a layer 2 routing protocol that will replace spanning tree. It will allow you to connect several uplinks, utilize all the bandwidth of the uplinks, prevent loops, and find the best path to the destination through the switch fabric. Think of it like OSPF for layer 2. It should be shipping within the next 6 to 9 months. -----Original Message----- From: Raj Singh [mailto:raj.singh at demandmedia.com] Sent: Thursday, November 12, 2009 11:49 AM To: 'nanog at nanog.org' Subject: Layer 2 vs. Layer 3 to TOR Guys, I am wondering how many of you are doing layer 3 to top of rack switches and what the pros and cons are. Also, if you are doing layer 3 to top of rack do you guys have any links to published white papers on it? Thanks, Raj Singh From gbonser at seven.com Thu Nov 12 16:48:38 2009 From: gbonser at seven.com (George Bonser) Date: Thu, 12 Nov 2009 14:48:38 -0800 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <4AFC7969.7050006@hosteurope.de> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DD@BLV11EXVS01.corp.dm.local> <4AFC7969.7050006@hosteurope.de> Message-ID: <5A6D953473350C4B9995546AFE9939EE075CB969@RWC-EX1.corp.seven.com> I believe TRILL will render this discussion moot. It should be shipping on gear from various vendors within the next year. -----Original Message----- From: Malte von dem Hagen [mailto:mvh at hosteurope.de] Sent: Thursday, November 12, 2009 1:09 PM To: Raj Singh Cc: nanog at nanog.org Subject: Re: Layer 2 vs. Layer 3 to TOR Hej, Am 12.11.2009 21:04 Uhr schrieb Raj Singh: > We are actually looking at going Layer 3 all the way to the top of > rack and make each rack its own /24. what a waste of IPs and unnecessary loss of flexibility! From lukasz at bromirski.net Thu Nov 12 17:45:48 2009 From: lukasz at bromirski.net (=?ISO-8859-2?Q?=A3ukasz_Bromirski?=) Date: Fri, 13 Nov 2009 00:45:48 +0100 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <4AFC8014.3010407@davidcoulson.net> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> <4AFC6DD8.5050502@rollernet.us> <4AFC7917.5040002@davidcoulson.net> <1258060985-sup-4132@sfo.thejof.com> <4AFC8014.3010407@davidcoulson.net> Message-ID: <4AFC9E2C.2040900@bromirski.net> On 2009-11-12 22:37, David Coulson wrote: > The MX-series are pretty nice. That should be able to do VPLS PE, > however I've never tried it - MX240 did it pretty well last time I > tried. I've no clue how the cost of that switch compares to a cisco 4900 > or something (not that a 4900 is anything special - L3 is all in software). For both 4948/4948-10GE and 4900M L3 is in hardware. For 4948/4948-10GE IPv6 is in software, for 4900M it's in hardware. -- "Everything will be okay in the end. | ?ukasz Bromirski If it's not okay, it's not the end. | http://lukasz.bromirski.net From joelja at bogus.com Thu Nov 12 19:40:51 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 13 Nov 2009 10:40:51 +0900 Subject: Failover how much complexity will it add? In-Reply-To: References: <21131.1257776512@baklawasecrets.com> <4AF9D8C5.5070009@memberwebs.com> <4AF9F3B3.3030200@bogus.com> Message-ID: <4AFCB923.1060607@bogus.com> Randy Bush wrote: >> It has been routinely observed in nanog presentations that settlement >> free providers by their nature miss a few prefixes that well connected >> transit purchasing ISPs carry. > > just trying to understand what you mean, > > o no transit-free provider actually has all (covering) prefixes needed > to cover the active space, but > > o one or more reasonably small subsets of the set of transit-free > providers do cover the whole active space. If your goal is near-complete coverage, under normal circumstances you need more than one (your subset). Settlement-free provider peering spats are a degenerate condition of the normal state of affairs. The non-settlement-free provider has some subset already. Pointing default into a settlement-free provider, that is deliberately not speaking to another is obviously a recipe to lose data, which speaks to the question of whether one should as for a full table from settlement free upstreams. My somewhat obtuse point was that this isn't some wild west frontier justice sort of affair, but rather, the normal state of affairs. > randy > From vixie at isc.org Thu Nov 12 19:57:56 2009 From: vixie at isc.org (Paul Vixie) Date: Fri, 13 Nov 2009 01:57:56 +0000 Subject: What DNS Is Not In-Reply-To: <20091109234713.7849F1CC2E@ptavv.es.net> (Kevin Oberman's message of "Mon\, 09 Nov 2009 15\:47\:13 -0800") References: <20091109234713.7849F1CC2E@ptavv.es.net> Message-ID: "Kevin Oberman" writes: > I find it mildly amusing that my first contact with Paul was about 25 > years ago when he was at DEC and I objected to his use of a wildcard for > dec.com. I was only an egg. > The situations are not parallel and the Internet was a very different > animal in those days (and DEC was mostly DECnet), but still I managed to > maintain a full set of MX records for all of our DECnet systems. Based partly on my conversation with you, I ended up pulling over the list of DECnet nodes and generating MX's for each one, just to remove that wildcard. You were right, and I listened. Probably I forgot to thank you until now. Thanks. -- Paul Vixie KI6YSY From wbailey at gci.com Fri Nov 13 00:17:22 2009 From: wbailey at gci.com (Warren Bailey) Date: Thu, 12 Nov 2009 21:17:22 -0900 Subject: What DNS Is Not In-Reply-To: References: <20091109234713.7849F1CC2E@ptavv.es.net> Message-ID: <5B3743FC2D0D8B41B27EE4F5EACA79D10C13E252@DTN1EX01.gci.com> Well, If it counts Paul, thanks for vixie cron. ;) -----Original Message----- From: Paul Vixie [mailto:vixie at isc.org] Sent: Thursday, November 12, 2009 4:58 PM To: nanog at merit.edu Subject: Re: What DNS Is Not "Kevin Oberman" writes: > I find it mildly amusing that my first contact with Paul was about 25 > years ago when he was at DEC and I objected to his use of a wildcard > for dec.com. I was only an egg. > The situations are not parallel and the Internet was a very different > animal in those days (and DEC was mostly DECnet), but still I managed > to maintain a full set of MX records for all of our DECnet systems. Based partly on my conversation with you, I ended up pulling over the list of DECnet nodes and generating MX's for each one, just to remove that wildcard. You were right, and I listened. Probably I forgot to thank you until now. Thanks. -- Paul Vixie KI6YSY From olof.kasselstrand at gmail.com Fri Nov 13 01:01:32 2009 From: olof.kasselstrand at gmail.com (Olof Kasselstrand) Date: Fri, 13 Nov 2009 08:01:32 +0100 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <4AFC9E2C.2040900@bromirski.net> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> <4AFC6DD8.5050502@rollernet.us> <4AFC7917.5040002@davidcoulson.net> <1258060985-sup-4132@sfo.thejof.com> <4AFC8014.3010407@davidcoulson.net> <4AFC9E2C.2040900@bromirski.net> Message-ID: I would suggest doing a VC with the TOR switches. That way you can have "one" switch for a lot of racks (I believe 10 would be the upper limit if using Juniper). If you have a VC you could do L3 and L2 where needed on every rack that the VC covers. // Olof 2009/11/13 ?ukasz Bromirski : > On 2009-11-12 22:37, David Coulson wrote: > >> The MX-series are pretty nice. That should be able to do VPLS PE, >> however I've never tried it - MX240 did it pretty well last time I >> tried. I've no clue how the cost of that switch compares to a cisco 4900 >> or something (not that a 4900 is anything special - L3 is all in >> software). > > For both 4948/4948-10GE and 4900M L3 is in hardware. For > 4948/4948-10GE IPv6 is in software, for 4900M it's in hardware. > > -- > "Everything will be okay in the end. | ? ? ? ? ? ? ? ? ??ukasz Bromirski > ?If it's not okay, it's not the end. | ? ? ? http://lukasz.bromirski.net > > From tore at linpro.no Fri Nov 13 02:44:52 2009 From: tore at linpro.no (Tore Anderson) Date: Fri, 13 Nov 2009 09:44:52 +0100 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <1258060985-sup-4132@sfo.thejof.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> <4AFC6DD8.5050502@rollernet.us> <4AFC7917.5040002@davidcoulson.net> <1258060985-sup-4132@sfo.thejof.com> Message-ID: <4AFD1C84.2020408@linpro.no> * Jonathan Lassoff > Are there any applications that absolutely *have* to sit on the same > LAN/broadcast domain and can't be configured to use unicast or multicast > IP? FCoE comes to mind. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From matthew at walster.org Fri Nov 13 06:14:27 2009 From: matthew at walster.org (Matthew Walster) Date: Fri, 13 Nov 2009 12:14:27 +0000 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <4AFC7917.5040002@davidcoulson.net> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> <4AFC6DD8.5050502@rollernet.us> <4AFC7917.5040002@davidcoulson.net> Message-ID: 2009/11/12 David Coulson > You could route /32s within your L3 environment, or maybe even leverage > something like VPLS - Not sure of any TOR-level switches that MPLS > pseudowire a port into a VPLS cloud though. > Just to let you know - the Juniper EX4200 series only support a single label stack, and RSVP not LDP - plus they have a restricted BGP table size, so VPLS is out of the question. Matthew Walster From randy at psg.com Fri Nov 13 07:33:12 2009 From: randy at psg.com (Randy Bush) Date: Fri, 13 Nov 2009 22:33:12 +0900 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> <4AFC6DD8.5050502@rollernet.us> <4AFC7917.5040002@davidcoulson.net> Message-ID: i have seen no mention of arista as a tos switch/router, yet folk tell me it is one of the hottest on the block today. is there anyone who is actuallly using it who would care to report? randy From netfortius at gmail.com Fri Nov 13 08:29:16 2009 From: netfortius at gmail.com (Stefan) Date: Fri, 13 Nov 2009 08:29:16 -0600 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> <4AFC6DD8.5050502@rollernet.us> <4AFC7917.5040002@davidcoulson.net> Message-ID: Good point about Arista - Doug Gourlay, of [ex-]Cisco fame, is probably the person to ask all possible questions about those solutions. Cisco UCS is missing, also - looking at the Nexus deployment as ToR solution (2K + 5K, even 1KV, considering the needs for virtualization, also) with all benefits of both traditional ToR and E/MoR will definitely shed some light in the debate on whether L3 in ToR makes any sense at all (e..g how would you VMotion across racks?!? - how you you sync SANs across L3 in the DC (tunnel?!?), etc.). Here are some interesting articles associated with technologies in new DC designs, for example, allowing some rethinking of the L3 question: http://www.internetworkexpert.org/ - search for ToR and VMotion articles (actually poke arond the whole blog - it is very good) http://blogstu.wordpress.com/2009/10/05/fcoe-ecosystem/ (start from 1, of course) ...etc. ***Stefan On Fri, Nov 13, 2009 at 7:33 AM, Randy Bush wrote: > i have seen no mention of arista as a tos switch/router, yet folk tell > me it is one of the hottest on the block today. is there anyone who is > actuallly using it who would care to report? > > randy > > From rodrick.brown at gmail.com Fri Nov 13 09:08:42 2009 From: rodrick.brown at gmail.com (rodrick brown) Date: Fri, 13 Nov 2009 10:08:42 -0500 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> <4AFC6DD8.5050502@rollernet.us> <4AFC7917.5040002@davidcoulson.net> Message-ID: <9FA9D31D-D4FA-4DCB-81F7-782F1C983966@gmail.com> I've been using Arista's 7124S in a ToR deployment for a new build out for a high frequency trading client I've been engaged with. For the aggregation layer I went with Cisco 4900m's and have had much success with this deployment especially with the Arista's. Sent from my iPhone 3GS. On Nov 13, 2009, at 8:33 AM, Randy Bush wrote: > i have seen no mention of arista as a tos switch/router, yet folk tell > me it is one of the hottest on the block today. is there anyone who > is > actuallly using it who would care to report? > > randy > From jloiacon at csc.com Fri Nov 13 10:29:17 2009 From: jloiacon at csc.com (Joe Loiacono) Date: Fri, 13 Nov 2009 11:29:17 -0500 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> <4AFC6DD8.5050502@rollernet.us> <4AFC7917.5040002@davidcoulson.net> Message-ID: >From a colleague here at NASA (high-performance computing area): "We are currently using our three Arista switches as an extremely economical way to get a 10G non-blocking testbed for our various test areas. We have every intention of looking at them as an option for their routing capabilities, but have been buried with setup and testing of our testbed equipment and getting ready for Super Computing 2009. They seem to have a number of very promising possibilities and have so far proven to be very capable switches. Paul Lang" Joe From: Randy Bush To: Matthew Walster Cc: nanog list Date: 11/13/2009 08:34 AM Subject: Re: Layer 2 vs. Layer 3 to TOR i have seen no mention of arista as a tos switch/router, yet folk tell me it is one of the hottest on the block today. is there anyone who is actuallly using it who would care to report? randy From cordmacleod at gmail.com Fri Nov 13 12:17:20 2009 From: cordmacleod at gmail.com (Cord MacLeod) Date: Fri, 13 Nov 2009 10:17:20 -0800 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> <4AFC6DD8.5050502@rollernet.us> <4AFC7917.5040002@davidcoulson.net> Message-ID: <727A0177-4F97-4186-8697-A232C3B52351@gmail.com> On Nov 13, 2009, at 4:14 AM, Matthew Walster wrote: > 2009/11/12 David Coulson > >> You could route /32s within your L3 environment, or maybe even >> leverage >> something like VPLS - Not sure of any TOR-level switches that MPLS >> pseudowire a port into a VPLS cloud though. >> > > Just to let you know - the Juniper EX4200 series only support a > single label > stack, and RSVP not LDP - plus they have a restricted BGP table > size, so > VPLS is out of the question. If you wanted something to do this, it's called an MX series. The ex is a switch... l3, but still a switch. From cscora at apnic.net Fri Nov 13 12:34:33 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 14 Nov 2009 04:34:33 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200911131834.nADIYXGF025681@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 14 Nov, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 302501 Prefixes after maximum aggregation: 141653 Deaggregation factor: 2.14 Unique aggregates announced to Internet: 149678 Total ASes present in the Internet Routing Table: 32670 Prefixes per ASN: 9.26 Origin-only ASes present in the Internet Routing Table: 28386 Origin ASes announcing only one prefix: 13852 Transit ASes present in the Internet Routing Table: 4284 Transit-only ASes present in the Internet Routing Table: 99 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 39 Max AS path prepend of ASN (22394) 36 Prefixes from unregistered ASNs in the Routing Table: 635 Unregistered ASNs in the Routing Table: 131 Number of 32-bit ASNs allocated by the RIRs: 317 Prefixes from 32-bit ASNs in the Routing Table: 263 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 177 Number of addresses announced to Internet: 2116745984 Equivalent to 126 /8s, 42 /16s and 251 /24s Percentage of available address space announced: 57.1 Percentage of allocated address space announced: 64.7 Percentage of available address space allocated: 88.2 Percentage of address space in use by end-sites: 80.0 Total number of prefixes smaller than registry allocations: 145338 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 72284 Total APNIC prefixes after maximum aggregation: 25310 APNIC Deaggregation factor: 2.86 Prefixes being announced from the APNIC address blocks: 68830 Unique aggregates announced from the APNIC address blocks: 30438 APNIC Region origin ASes present in the Internet Routing Table: 3858 APNIC Prefixes per ASN: 17.84 APNIC Region origin ASes announcing only one prefix: 1046 APNIC Region transit ASes present in the Internet Routing Table: 597 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 23 Number of APNIC addresses announced to Internet: 470486048 Equivalent to 28 /8s, 11 /16s and 12 /24s Percentage of available APNIC address space announced: 80.1 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 43/8, 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, 175/8, 180/8, 182/8, 183/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: 127674 Total ARIN prefixes after maximum aggregation: 67188 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 102073 Unique aggregates announced from the ARIN address blocks: 38770 ARIN Region origin ASes present in the Internet Routing Table: 13337 ARIN Prefixes per ASN: 7.65 ARIN Region origin ASes announcing only one prefix: 5169 ARIN Region transit ASes present in the Internet Routing Table: 1313 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 39 Number of ARIN addresses announced to Internet: 714745632 Equivalent to 42 /8s, 154 /16s and 39 /24s Percentage of available ARIN address space announced: 62.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 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/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, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 69750 Total RIPE prefixes after maximum aggregation: 40882 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 63032 Unique aggregates announced from the RIPE address blocks: 42158 RIPE Region origin ASes present in the Internet Routing Table: 13751 RIPE Prefixes per ASN: 4.58 RIPE Region origin ASes announcing only one prefix: 7150 RIPE Region transit ASes present in the Internet Routing Table: 2064 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 20 Number of RIPE addresses announced to Internet: 404254144 Equivalent to 24 /8s, 24 /16s and 109 /24s Percentage of available RIPE address space announced: 75.3 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-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 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, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 26248 Total LACNIC prefixes after maximum aggregation: 6386 LACNIC Deaggregation factor: 4.11 Prefixes being announced from the LACNIC address blocks: 24557 Unique aggregates announced from the LACNIC address blocks: 13594 LACNIC Region origin ASes present in the Internet Routing Table: 1205 LACNIC Prefixes per ASN: 20.38 LACNIC Region origin ASes announcing only one prefix: 387 LACNIC Region transit ASes present in the Internet Routing Table: 200 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 30 Number of LACNIC addresses announced to Internet: 68200192 Equivalent to 4 /8s, 16 /16s and 167 /24s Percentage of available LACNIC address space announced: 67.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 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: 6052 Total AfriNIC prefixes after maximum aggregation: 1588 AfriNIC Deaggregation factor: 3.81 Prefixes being announced from the AfriNIC address blocks: 4414 Unique aggregates announced from the AfriNIC address blocks: 1583 AfriNIC Region origin ASes present in the Internet Routing Table: 333 AfriNIC Prefixes per ASN: 13.26 AfriNIC Region origin ASes announcing only one prefix: 100 AfriNIC Region transit ASes present in the Internet Routing Table: 69 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 13027584 Equivalent to 0 /8s, 198 /16s and 201 /24s Percentage of available AfriNIC address space announced: 38.8 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1770 7505 456 Korea Telecom (KIX) 17488 1477 142 125 Hathway IP Over Cable Interne 4755 1277 292 148 TATA Communications formerly 9583 1045 81 515 Sify Limited 4134 1007 19185 393 CHINANET-BACKBONE 18101 982 204 33 Reliance Infocom Ltd Internet 7545 900 199 100 TPG Internet Pty Ltd 9829 853 665 21 BSNL National Internet Backbo 17974 836 252 103 PT TELEKOMUNIKASI INDONESIA 24560 797 292 172 Bharti Airtel Ltd., Telemedia 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 4257 3883 315 bellsouth.net, inc. 4323 3733 1054 399 Time Warner Telecom 1785 1787 715 140 PaeTec Communications, Inc. 7018 1586 5839 1039 AT&T WorldNet Services 20115 1515 1481 675 Charter Communications 6478 1312 270 415 AT&T Worldnet Services 2386 1307 638 943 AT&T Data Communications Serv 3356 1218 10966 442 Level 3 Communications, LLC 11492 1145 222 14 Cable One 22773 1118 2600 66 Cox Communications, Inc. 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 30890 515 98 208 Evolva Telecom 3292 445 1905 390 TDC Tele Danmark 35805 436 40 5 United Telecom of Georgia 702 416 1822 335 UUNET - Commercial IP service 9198 404 138 12 Kazakhtelecom Data Network Ad 8866 364 110 23 Bulgarian Telecommunication C 3320 358 7068 305 Deutsche Telekom AG 3215 349 3144 111 France Telecom Transpac 3301 347 1412 302 TeliaNet Sweden 8551 316 294 40 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 1569 2899 230 UniNet S.A. de C.V. 10620 1030 228 102 TVCABLE BOGOTA 28573 803 664 89 NET Servicos de Comunicao S.A 7303 663 349 95 Telecom Argentina Stet-France 22047 546 302 14 VTR PUNTO NET S.A. 11830 473 308 59 Instituto Costarricense de El 11172 444 99 70 Servicios Alestra S.A de C.V 14117 437 29 11 Telefonica del Sur S.A. 7738 430 858 29 Telecomunicacoes da Bahia S.A 6471 422 96 31 ENTEL CHILE 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 8452 1044 188 7 TEDATA 24863 943 98 72 LINKdotNET AS number 3741 274 857 234 The Internet Solution 2018 191 188 118 Tertiary Education Network 6713 176 167 12 Itissalat Al-MAGHRIB 29571 128 15 8 Ci Telecom Autonomous system 33776 124 7 11 Starcomms Nigeria Limited 5536 122 8 13 Internet Egypt Network 5713 116 508 67 Telkom SA Ltd 20858 109 34 6 EgyNet 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 4257 3883 315 bellsouth.net, inc. 4323 3733 1054 399 Time Warner Telecom 1785 1787 715 140 PaeTec Communications, Inc. 4766 1770 7505 456 Korea Telecom (KIX) 7018 1586 5839 1039 AT&T WorldNet Services 8151 1569 2899 230 UniNet S.A. de C.V. 20115 1515 1481 675 Charter Communications 17488 1477 142 125 Hathway IP Over Cable Interne 6478 1312 270 415 AT&T Worldnet Services 2386 1307 638 943 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3733 3334 Time Warner Telecom 1785 1787 1647 PaeTec Communications, Inc. 17488 1477 1352 Hathway IP Over Cable Interne 8151 1569 1339 UniNet S.A. de C.V. 4766 1770 1314 Korea Telecom (KIX) 11492 1145 1131 Cable One 4755 1277 1129 TATA Communications formerly 22773 1118 1052 Cox Communications, Inc. 18566 1059 1049 Covad Communications 8452 1044 1037 TEDATA 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 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 46.0.0.0/16 12654 RIPE NCC RIS Project 46.1.0.0/21 12654 RIPE NCC RIS Project 46.1.24.0/24 12654 RIPE NCC RIS Project 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 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:10 /10:25 /11:65 /12:177 /13:361 /14:640 /15:1220 /16:10741 /17:4960 /18:8511 /19:17574 /20:21253 /21:21202 /22:27534 /23:27360 /24:157968 /25:944 /26:1126 /27:565 /28:219 /29:11 /30:8 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2782 4257 bellsouth.net, inc. 4323 2357 3733 Time Warner Telecom 4766 1435 1770 Korea Telecom (KIX) 17488 1254 1477 Hathway IP Over Cable Interne 1785 1251 1787 PaeTec Communications, Inc. 11492 1068 1145 Cable One 18566 1040 1059 Covad Communications 7018 947 1586 AT&T WorldNet Services 8452 944 1044 TEDATA 10620 935 1030 TVCABLE BOGOTA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 2:1 4:14 8:233 12:2134 13:8 15:22 16:3 17:5 20:36 24:1251 32:49 34:2 38:612 40:99 41:1795 43:1 44:2 46:1 47:21 52:6 55:2 56:2 57:23 58:628 59:610 60:443 61:992 62:948 63:1994 64:3656 65:2363 66:4091 67:1755 68:995 69:2795 70:588 71:156 72:1748 73:2 74:1989 75:183 76:352 77:842 78:569 79:376 80:940 81:814 82:472 83:441 84:529 85:1016 86:382 87:697 88:425 89:1500 90:63 91:2645 92:424 93:1158 94:1297 95:825 96:200 97:273 98:412 99:31 109:160 110:270 111:460 112:146 113:174 114:285 115:355 116:1123 117:596 118:349 119:785 120:127 121:703 122:1304 123:777 124:1059 125:1350 128:222 129:218 130:133 131:425 132:75 133:16 134:186 135:43 136:233 137:166 138:180 139:84 140:441 141:122 142:387 143:343 144:365 145:49 146:395 147:171 148:559 149:196 150:150 151:172 152:216 153:160 154:2 155:274 156:167 157:313 158:95 159:360 160:293 161:173 162:274 163:159 164:278 165:468 166:490 167:390 168:750 169:160 170:554 171:43 172:1 173:391 174:392 178:1 180:174 184:1 186:157 187:190 188:1281 189:628 190:3250 192:5738 193:4282 194:3340 195:2730 196:1154 198:3566 199:3373 200:5206 201:1390 202:7901 203:8241 204:3937 205:2159 206:2403 207:3011 208:3975 209:3436 210:2541 211:1149 212:1652 213:1621 214:189 215:40 216:4416 217:1343 218:475 219:424 220:1140 221:452 222:304 End of report From sronan at fattoc.com Fri Nov 13 12:51:48 2009 From: sronan at fattoc.com (Shane Ronan) Date: Fri, 13 Nov 2009 13:51:48 -0500 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <727A0177-4F97-4186-8697-A232C3B52351@gmail.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> <4AFC6DD8.5050502@rollernet.us> <4AFC7917.5040002@davidcoulson.net> <727A0177-4F97-4186-8697-A232C3B52351@gmail.com> Message-ID: Disagree, the EX is a very capable L3 router for LANs. On Nov 13, 2009, at 1:17 PM, Cord MacLeod wrote: > On Nov 13, 2009, at 4:14 AM, Matthew Walster wrote: > >> 2009/11/12 David Coulson >> >>> You could route /32s within your L3 environment, or maybe even leverage >>> something like VPLS - Not sure of any TOR-level switches that MPLS >>> pseudowire a port into a VPLS cloud though. >>> >> >> Just to let you know - the Juniper EX4200 series only support a single label >> stack, and RSVP not LDP - plus they have a restricted BGP table size, so >> VPLS is out of the question. > > If you wanted something to do this, it's called an MX series. The ex is a switch... l3, but still a switch. > From cidr-report at potaroo.net Fri Nov 13 16:00:09 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 13 Nov 2009 22:00:09 GMT Subject: BGP Update Report Message-ID: <200911132200.nADM0990054115@wattle.apnic.net> BGP Update Report Interval: 05-Nov-09 -to- 12-Nov-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9808 28471 2.5% 167.5 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 2 - AS9829 22029 2.0% 26.4 -- BSNL-NIB National Internet Backbone 3 - AS24560 21178 1.9% 38.7 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 4 - AS8452 20533 1.8% 31.1 -- TEDATA TEDATA 5 - AS6389 9327 0.8% 2.2 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 6 - AS9583 8622 0.8% 9.1 -- SIFY-AS-IN Sify Limited 7 - AS14420 8194 0.7% 23.5 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 8 - AS17488 7973 0.7% 5.5 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 9 - AS701 7560 0.7% 9.9 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 10 - AS35805 7206 0.6% 16.5 -- UTG-AS United Telecom AS 11 - AS8151 6803 0.6% 6.0 -- Uninet S.A. de C.V. 12 - AS25184 5674 0.5% 270.2 -- AFRANET AFRANET Co. Tehran, Iran 13 - AS20115 5199 0.5% 4.8 -- CHARTER-NET-HKY-NC - Charter Communications 14 - AS5668 5115 0.5% 10.2 -- AS-5668 - CenturyTel Internet Holdings, Inc. 15 - AS6298 4906 0.4% 6.9 -- ASN-CXA-PH-6298-CBS - Cox Communications Inc. 16 - AS26610 4790 0.4% 266.1 -- Universidad Tecnica Federico Santa Maria 17 - AS18566 4730 0.4% 5.1 -- COVAD - Covad Communications Co. 18 - AS9198 4704 0.4% 16.9 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 19 - AS39386 4514 0.4% 322.4 -- STC-IGW-AS Saudi Telecom Company 20 - AS48754 4481 0.4% 4481.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS48754 4481 0.4% 4481.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 2 - AS36239 2612 0.2% 2612.0 -- EXIGEN-CANADA - Exigen Canada 3 - AS45782 1461 0.1% 1461.0 -- PHILIPPINEAIRLINES-PH-AP Philippine Airlines Inc. 4 - AS5691 2879 0.3% 1439.5 -- MITRE-AS-5 - The MITRE Corporation 5 - AS32390 2832 0.2% 1416.0 -- SARATOGA-TECHNOLOGY-ACCELERATOR - Saratoga Technology Accelerator, LLC 6 - AS28690 1324 0.1% 1324.0 -- ING-DIRECT-UK ING DIRECT UK N.V. 7 - AS27667 560 0.1% 560.0 -- Universidad Autonoma de la Laguna 8 - AS12732 552 0.1% 552.0 -- bbTT GmbH 9 - AS31699 2879 0.3% 479.8 -- BANK-AL-JAZIRA-AS bank al jazira aut.name 10 - AS49680 352 0.0% 352.0 -- DCI Armaghan Rahe Talaie 11 - AS39803 688 0.1% 344.0 -- UTI-AS SC UTI COMMUNICATIONS SYSTEMS SRL 12 - AS31529 686 0.1% 343.0 -- DENIC-ANYCAST-AS DENIC eG 13 - AS39386 4514 0.4% 322.4 -- STC-IGW-AS Saudi Telecom Company 14 - AS44208 318 0.0% 318.0 -- FARAHOOSH Farahoosh Dena 15 - AS3 317 0.0% 143.0 -- ELKATV ELEKTRONIKA - KATV d.o.o. 16 - AS48434 312 0.0% 312.0 -- TEBYAN Tebyan Cultural and Informative Institute 17 - AS29577 312 0.0% 312.0 -- IUT-AS Isfahan University of Technology AS 18 - AS44375 924 0.1% 308.0 -- AISDP Asmanfaraz ISDP 19 - AS26758 610 0.1% 305.0 -- MCNABWEB - MCNAB EXECUTIVE PLAZA 20 - AS11613 289 0.0% 289.0 -- U-SAVE - U-Save Auto Rental of America, Inc. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 91.212.23.0/24 4481 0.4% AS48754 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 2 - 218.206.120.0/24 3745 0.3% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 3 - 221.130.64.0/22 3736 0.3% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 4 - 92.255.241.0/24 3647 0.3% AS41661 -- ERTH-CHEL-AS CJSC "Company "ER-Telecom" Chelyabinsk 5 - 221.131.184.0/22 3644 0.3% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 6 - 218.206.118.0/23 3642 0.3% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 7 - 221.131.172.0/22 3592 0.3% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 8 - 221.178.192.0/22 3563 0.3% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 9 - 221.178.188.0/22 3503 0.3% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 10 - 41.235.83.0/24 2923 0.2% AS8452 -- TEDATA TEDATA 11 - 192.12.120.0/24 2875 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 12 - 216.130.239.0/24 2826 0.2% AS32390 -- SARATOGA-TECHNOLOGY-ACCELERATOR - Saratoga Technology Accelerator, LLC 13 - 149.117.190.0/24 2771 0.2% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 14 - 41.235.85.0/24 2716 0.2% AS8452 -- TEDATA TEDATA 15 - 41.235.87.0/24 2671 0.2% AS8452 -- TEDATA TEDATA 16 - 41.235.86.0/24 2633 0.2% AS8452 -- TEDATA TEDATA 17 - 72.28.75.0/24 2612 0.2% AS36239 -- EXIGEN-CANADA - Exigen Canada 18 - 143.138.107.0/24 2609 0.2% AS747 -- TAEGU-AS - Headquarters, USAISC 19 - 41.235.82.0/24 2383 0.2% AS8452 -- TEDATA TEDATA 20 - 208.54.82.0/24 2004 0.2% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 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 Nov 13 16:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 13 Nov 2009 22:00:00 GMT Subject: The Cidr Report Message-ID: <200911132200.nADM00ww054062@wattle.apnic.net> This report has been generated at Fri Nov 13 21:11:22 2009 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 06-11-09 307380 189705 07-11-09 307163 189662 08-11-09 307176 189813 09-11-09 307199 189761 10-11-09 307335 190250 11-11-09 307357 190329 12-11-09 307371 190597 13-11-09 307775 190807 AS Summary 32857 Number of ASes in routing system 13976 Number of ASes announcing only one prefix 4335 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 91482048 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 13Nov09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 308014 190768 117246 38.1% All ASes AS6389 4258 321 3937 92.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4335 1924 2411 55.6% TWTC - tw telecom holdings, inc. AS1785 1787 384 1403 78.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS4766 1886 580 1306 69.2% KIXS-AS-KR Korea Telecom AS17488 1477 294 1183 80.1% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 1118 71 1047 93.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1571 641 930 59.2% Uninet S.A. de C.V. AS10620 1030 143 887 86.1% TV Cable S.A. AS4755 1277 420 857 67.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS19262 1044 236 808 77.4% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8452 1044 284 760 72.8% TEDATA TEDATA AS18101 983 336 647 65.8% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS6478 1312 671 641 48.9% ATT-INTERNET3 - AT&T WorldNet Services AS18566 1059 444 615 58.1% COVAD - Covad Communications Co. AS3356 1222 628 594 48.6% LEVEL3 Level 3 Communications AS4808 763 195 568 74.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7303 662 96 566 85.5% Telecom Argentina S.A. AS4804 635 72 563 88.7% MPX-AS Microplex PTY LTD AS7018 1588 1041 547 34.4% ATT-INTERNET4 - AT&T WorldNet Services AS22047 546 18 528 96.7% VTR BANDA ANCHA S.A. AS11492 1145 654 491 42.9% CABLEONE - CABLE ONE, INC. AS9498 651 183 468 71.9% BBIL-AP BHARTI Airtel Ltd. AS9443 531 80 451 84.9% INTERNETPRIMUS-AS-AP Primus Telecommunications AS17676 565 129 436 77.2% GIGAINFRA Softbank BB Corp. AS855 619 187 432 69.8% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS4780 567 149 418 73.7% SEEDNET Digital United Inc. AS5668 786 371 415 52.8% AS-5668 - CenturyTel Internet Holdings, Inc. AS7011 1036 627 409 39.5% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS7738 430 29 401 93.3% Telecomunicacoes da Bahia S.A. AS14117 437 44 393 89.9% Telefonica del Sur S.A. Total 36364 11252 25112 69.1% Top 30 total Possible Bogus Routes 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 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 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 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-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 89.248.71.0/24 AS11730 CIL-ASN - Circle Internet LTD 95.215.108.0/22 AS48924 VOLSBUD-NET BMP VolsBud Ltd 96.8.64.0/18 AS19166 ACRONOC - ACRONOC INC 96.8.127.0/24 AS19166 ACRONOC - ACRONOC INC 117.103.72.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.10.0/24 AS38236 121.50.13.0/24 AS38236 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.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.77.128.0/24 AS4323 TWTC - tw telecom holdings, inc. 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 X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 193.24.196.0/22 AS6714 ATOMNET ATOM SA 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom s.r.l. 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.207.128.0/20 AS26452 BRING-AS - BringCom, Inc. 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc. 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc. 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 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - 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 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 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.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.9.115.0/24 AS10292 CWJ-1 - Cable & Wireless Jamaica 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet 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.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 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.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.143.56.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 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.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.86.96.0/19 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 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/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.108.96.0/19 AS577 BACOM - Bell Canada 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.189.62.0/23 AS7132 SBIS-AS - AT&T Internet Services 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.88.0/21 AS36835 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.224.0/24 AS36835 208.77.225.0/24 AS36835 208.77.226.0/24 AS36835 208.77.227.0/24 AS36835 208.77.228.0/24 AS36835 208.77.229.0/24 AS36835 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.77.230.0/24 AS36835 208.77.231.0/24 AS36835 208.87.152.0/21 AS25973 MZIMA - Mzima Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 213.181.70.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.80.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.81.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.83.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.84.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.85.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.86.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.87.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.88.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.89.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.90.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.91.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.92.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.93.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.94.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.95.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, 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.251.207.0/24 AS1239 SPRINTLINK - Sprint 218.185.240.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 222.0.0.0/8 AS9484 MOBINET-AS-MN Mobicom Company. AS Mobinet Internet Service Provider 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 kohn.jack at gmail.com Fri Nov 13 18:22:51 2009 From: kohn.jack at gmail.com (Jack Kohn) Date: Sat, 14 Nov 2009 05:52:51 +0530 Subject: AH is pretty useless and perhaps should be deprecated Message-ID: Hi, Interesting discussion on the utility of Authentication Header (AH) in IPSecME WG. http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html Post explaining that AH even though protecting the source and destination IP addresses is really not good enough. http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html What do folks feel? Do they see themselves using AH in the future? IMO, ESP and WESP are good enough and we dont need to support AH any more .. Jack From owen at delong.com Fri Nov 13 18:49:40 2009 From: owen at delong.com (Owen DeLong) Date: Fri, 13 Nov 2009 16:49:40 -0800 Subject: AH is pretty useless and perhaps should be deprecated In-Reply-To: References: Message-ID: I've never seen anyone use AH vs. ESP. I've always used ESP and so has every other IPSEC implementation I've seen anyone do. Owen On Nov 13, 2009, at 4:22 PM, Jack Kohn wrote: > Hi, > > Interesting discussion on the utility of Authentication Header (AH) in > IPSecME WG. > > http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html > > Post explaining that AH even though protecting the source and > destination IP addresses is really not good enough. > > http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html > > What do folks feel? Do they see themselves using AH in the future? > IMO, ESP and WESP are good enough and we dont need to support AH any > more .. > > Jack From jason at i6ix.com Fri Nov 13 19:02:19 2009 From: jason at i6ix.com (Jason Bertoch) Date: Fri, 13 Nov 2009 20:02:19 -0500 Subject: ESPN360 Access In-Reply-To: <4AFC5394.7040200@uplogon.com> References: <4AFC5394.7040200@uplogon.com> Message-ID: <4AFE019B.8060401@i6ix.com> Chris Gotstein wrote: > We've been getting more and more requests for ESPN360 from our > customers. From what i understand, ESPN requires that the ISP > "subscribe" to their content and pay a fee to do so. I have been unable > to find much information on what it takes to subscribe and what the fees > are to do so. Does anyone have more info on ESPN360? Thanks. > > +1 I attempted contact and was treated like and end user even though I clearly specified I was an ISP seeking connection info. From kohn.jack at gmail.com Fri Nov 13 20:27:25 2009 From: kohn.jack at gmail.com (Jack Kohn) Date: Sat, 14 Nov 2009 07:57:25 +0530 Subject: AH is pretty useless and perhaps should be deprecated In-Reply-To: References: Message-ID: So who uses AH and why? Jack On Sat, Nov 14, 2009 at 6:19 AM, Owen DeLong wrote: > I've never seen anyone use AH vs. ESP. I've always used ESP and so has > every other IPSEC implementation I've seen anyone do. > > Owen > > On Nov 13, 2009, at 4:22 PM, Jack Kohn wrote: > >> Hi, >> >> Interesting discussion on the utility of Authentication Header (AH) in >> IPSecME WG. >> >> http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html >> >> Post explaining that AH even though protecting the source and >> destination IP addresses is really not good enough. >> >> http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html >> >> What do folks feel? Do they see themselves using AH in the future? >> IMO, ESP and WESP are good enough and we dont need to support AH any >> more .. >> >> Jack > > From sfouant at shortestpathfirst.net Fri Nov 13 21:09:18 2009 From: sfouant at shortestpathfirst.net (sfouant at shortestpathfirst.net) Date: Sat, 14 Nov 2009 03:09:18 +0000 Subject: AH is pretty useless and perhaps should be deprecated Message-ID: <185296339-1258168066-cardhu_decombobulator_blackberry.rim.net-399891495-@bda772.bisx.prod.on.blackberry> I've seen some vendor implementations in which ESP actually outperformed AH during performance testing... go figure... Stefan Fouant ------Original Message------ From: Jack Kohn To: nanog at nanog.org Subject: AH is pretty useless and perhaps should be deprecated Sent: Nov 13, 2009 7:22 PM Hi, Interesting discussion on the utility of Authentication Header (AH) in IPSecME WG. http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html Post explaining that AH even though protecting the source and destination IP addresses is really not good enough. http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html What do folks feel? Do they see themselves using AH in the future? IMO, ESP and WESP are good enough and we dont need to support AH any more .. Jack Sent from my Verizon Wireless BlackBerry From kaeo at merike.com Fri Nov 13 23:09:42 2009 From: kaeo at merike.com (Merike Kaeo) Date: Fri, 13 Nov 2009 21:09:42 -0800 Subject: AH is pretty useless and perhaps should be deprecated In-Reply-To: <185296339-1258168066-cardhu_decombobulator_blackberry.rim.net-399891495-@bda772.bisx.prod.on.blackberry> References: <185296339-1258168066-cardhu_decombobulator_blackberry.rim.net-399891495-@bda772.bisx.prod.on.blackberry> Message-ID: <0237939E-1DE8-427E-9517-195BE796DBF8@merike.com> If I recall correctly what an implementor once told me, the work involved in taking the fields that are immutable, then hashing packet, then sticking those immutable fields back in is actually more work than encrypting. Surprised me at the time but seems to be the case. - merike On Nov 13, 2009, at 7:09 PM, sfouant at shortestpathfirst.net wrote: > I've seen some vendor implementations in which ESP actually > outperformed AH during performance testing... go figure... > > Stefan Fouant > ------Original Message------ > From: Jack Kohn > To: nanog at nanog.org > Subject: AH is pretty useless and perhaps should be deprecated > Sent: Nov 13, 2009 7:22 PM > > Hi, > > Interesting discussion on the utility of Authentication Header (AH) in > IPSecME WG. > > http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html > > Post explaining that AH even though protecting the source and > destination IP addresses is really not good enough. > > http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html > > What do folks feel? Do they see themselves using AH in the future? > IMO, ESP and WESP are good enough and we dont need to support AH any > more .. > > Jack > > > > Sent from my Verizon Wireless BlackBerry > From bit.gossip at chello.nl Sat Nov 14 01:37:26 2009 From: bit.gossip at chello.nl (Luca Tosolini) Date: Sat, 14 Nov 2009 08:37:26 +0100 Subject: AH is pretty useless and perhaps should be deprecated In-Reply-To: References: Message-ID: <1258184246.2404.2.camel@nlws481253> Junos VRRP with md5 authentication does..... On Sat, 2009-11-14 at 07:57 +0530, Jack Kohn wrote: > So who uses AH and why? > > Jack > > On Sat, Nov 14, 2009 at 6:19 AM, Owen DeLong wrote: > > I've never seen anyone use AH vs. ESP. I've always used ESP and so has > > every other IPSEC implementation I've seen anyone do. > > > > Owen > > > > On Nov 13, 2009, at 4:22 PM, Jack Kohn wrote: > > > >> Hi, > >> > >> Interesting discussion on the utility of Authentication Header (AH) in > >> IPSecME WG. > >> > >> http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html > >> > >> Post explaining that AH even though protecting the source and > >> destination IP addresses is really not good enough. > >> > >> http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html > >> > >> What do folks feel? Do they see themselves using AH in the future? > >> IMO, ESP and WESP are good enough and we dont need to support AH any > >> more .. > >> > >> Jack > > > > > From jim at reptiles.org Sat Nov 14 09:09:45 2009 From: jim at reptiles.org (Jim Mercer) Date: Sat, 14 Nov 2009 10:09:45 -0500 Subject: kaspersky anti-virus tech, with a clue? Message-ID: <20091114150945.GA23933@reptiles.org> it seems that kaspersky anti-virus is "detecting" our hotspot captive portal login as a "Trojan-Downloader.Script.Generic". my googling on this seems to indicate that it isn't finding so much a signature, but something in the url that is "suspicious". unfortunately, this is causing some fairly unhappy, panicing calls to our support people from customers. can anyone point me at a Kaspersky tech with a clue? maybe we can re-craft our login url to not offend the Kaspersky suite. note: this hotspot suite has been in operation for 4+ years, and is based on the chillispot portal. note: these reports only started recently, so i suspect something was added to Kaspersky's virus database recently that kicked this off. -- Jim Mercer jim at reptiles.org +92 336 520-4504 "I'm Prime Minister of Canada, I live here and I'm going to take a leak." - Lester Pearson in 1967, during a meeting between himself and President Lyndon Johnson, whose Secret Service detail had taken over Pearson's cottage retreat. At one point, a Johnson guard asked Pearson, "Who are you and where are you going?" From ge at linuxbox.org Sat Nov 14 09:20:48 2009 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 14 Nov 2009 17:20:48 +0200 Subject: kaspersky anti-virus tech, with a clue? In-Reply-To: <20091114150945.GA23933@reptiles.org> References: <20091114150945.GA23933@reptiles.org> Message-ID: <4AFECAD0.80203@linuxbox.org> Jim Mercer wrote: > can anyone point me at a Kaspersky tech with a clue? maybe we can re-craft > our login url to not offend the Kaspersky suite. > Forwarding. Gadi. -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From tmaufer at gmail.com Sat Nov 14 12:59:57 2009 From: tmaufer at gmail.com (Thomas Maufer) Date: Sat, 14 Nov 2009 10:59:57 -0800 Subject: AH is pretty useless and perhaps should be deprecated In-Reply-To: References: Message-ID: I prefer letting the market deprecate things. If no one uses AH, someday the IETF can mark it as "Historic," but long before that there will come a time when no one is interested in doing any more work on it. I was at the IETF IPsec WG meeting (in Los Angeles in the mid-90s) when AH would have died except once Microsoft strongly endorsed it, everyone else took the anti-MSFT viewpoint. Also, don't confuse "almost no one uses" for "no one uses" -- if AH is useful for someone, there is no harm in having a spec that tells them how to do it, and hopefully that spec is well written such that they can interoperate with other implementations. AH is less efficient than ESP because you have to buffer a whole packet prior to calculating the Integrity Check Value that goes in the AH [header], which goes at the front. The calculations you have to do involve parts of the packet that are both before and after the AH [header], including the packet's payload. Once you calculate the Integrity Check Value (ICV) you then stuff it in the appropriate part of the AH and send the packet. ESP's cryptographic goodness is appended at the end (and the packet is encrypted up until that point), and you can be doing a running cryptographic algorithm as the packet is streamed out (encrypted after the IP header and ESP header), then append the right amount of padding and the ESP "trailer" at the end. This site has some nice graphical depictions of AH and ESP (including the tunnel-mode vs. transport-mode that I didn't touch on: http://unixwiz.net/techtips/iguide-ipsec.html) Cheers, ~tom On Fri, Nov 13, 2009 at 18:27, Jack Kohn wrote: > So who uses AH and why? > > Jack > > On Sat, Nov 14, 2009 at 6:19 AM, Owen DeLong wrote: > > I've never seen anyone use AH vs. ESP. I've always used ESP and so has > > every other IPSEC implementation I've seen anyone do. > > > > Owen > > > > On Nov 13, 2009, at 4:22 PM, Jack Kohn wrote: > > > >> Hi, > >> > >> Interesting discussion on the utility of Authentication Header (AH) in > >> IPSecME WG. > >> > >> http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html > >> > >> Post explaining that AH even though protecting the source and > >> destination IP addresses is really not good enough. > >> > >> http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html > >> > >> What do folks feel? Do they see themselves using AH in the future? > >> IMO, ESP and WESP are good enough and we dont need to support AH any > >> more .. > >> > >> Jack > > > > > > From stasinia at msoe.edu Sat Nov 14 13:46:09 2009 From: stasinia at msoe.edu (Adam Stasiniewicz) Date: Sat, 14 Nov 2009 13:46:09 -0600 Subject: AH is pretty useless and perhaps should be deprecated In-Reply-To: References: Message-ID: <000a01ca6563$1db96f20$592c4d60$@edu> I have see AH used in network segmentation. I.e. systems is group A are configured with rules to require all communication be over AH. Systems in group B (which have no AH and no appropriate certificates configured) can't chat with group A. The benefit of using AH vs. ESP in this case is twofold. First, AH is less CPU intensive, and when one considers enabling it on all/many workstations and servers in a company, that can add up to a lot of CPU cycles. Second, since AH only signs, not encrypts, products like network analyzers, IDS/IPS, etc can still perform their functions. Outside of some manual deployments, the only commercial product I know that offers AH based network segmentation is Microsoft's NAP: http://www.microsoft.com/nap Regards, Adam Stasiniewicz -----Original Message----- From: Jack Kohn [mailto:kohn.jack at gmail.com] Sent: Friday, November 13, 2009 6:23 PM To: nanog at nanog.org Subject: AH is pretty useless and perhaps should be deprecated Hi, Interesting discussion on the utility of Authentication Header (AH) in IPSecME WG. http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html Post explaining that AH even though protecting the source and destination IP addresses is really not good enough. http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html What do folks feel? Do they see themselves using AH in the future? IMO, ESP and WESP are good enough and we dont need to support AH any more .. Jack From smb at cs.columbia.edu Sat Nov 14 17:12:24 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sat, 14 Nov 2009 18:12:24 -0500 Subject: AH is pretty useless and perhaps should be deprecated In-Reply-To: <000a01ca6563$1db96f20$592c4d60$@edu> References: <000a01ca6563$1db96f20$592c4d60$@edu> Message-ID: On Nov 14, 2009, at 2:46 PM, Adam Stasiniewicz wrote: > I have see AH used in network segmentation. I.e. systems is group A are > configured with rules to require all communication be over AH. Systems in > group B (which have no AH and no appropriate certificates configured) can't > chat with group A. The benefit of using AH vs. ESP in this case is twofold. > First, AH is less CPU intensive, and when one considers enabling it on > all/many workstations and servers in a company, that can add up to a lot of > CPU cycles. Second, since AH only signs, not encrypts, products like > network analyzers, IDS/IPS, etc can still perform their functions. ESP with NULL encryption only authenticates (not "signs") also. However, one can't tell in a context-free way that NULL is in use. If you're using it, though, I can't see how AH could be less expensive. AH has been controversial for years. I've been asking folks to delete it since 1995. I've never succeeded... At least RFC 4301 deprecated it to a MAY instead of a MUST for IPsec implementors. > > Outside of some manual deployments, the only commercial product I know that > offers AH based network segmentation is Microsoft's NAP: > http://www.microsoft.com/nap > > Regards, > Adam Stasiniewicz > > -----Original Message----- > From: Jack Kohn [mailto:kohn.jack at gmail.com] > Sent: Friday, November 13, 2009 6:23 PM > To: nanog at nanog.org > Subject: AH is pretty useless and perhaps should be deprecated > > Hi, > > Interesting discussion on the utility of Authentication Header (AH) in > IPSecME WG. > > http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html > > Post explaining that AH even though protecting the source and > destination IP addresses is really not good enough. > > http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html > > What do folks feel? Do they see themselves using AH in the future? > IMO, ESP and WESP are good enough and we dont need to support AH any > more .. > > Jack > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb From thegameiam at yahoo.com Sat Nov 14 19:28:20 2009 From: thegameiam at yahoo.com (David Barak) Date: Sat, 14 Nov 2009 17:28:20 -0800 (PST) Subject: AH is pretty useless and perhaps should be deprecated In-Reply-To: References: <000a01ca6563$1db96f20$592c4d60$@edu> Message-ID: <107749.71985.qm@web31814.mail.mud.yahoo.com> I've seen AH used as a "prove that this hasn't been through a NAT" mechanism.??In this context, it's pretty much perfect. However, what I don't understand is where the dislike for it?originates: if you don't like it, don't run it.??It is useful in certain cases,?and it's already in all of the production IPSec implementations.? Why the hate? David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From smb at cs.columbia.edu Sat Nov 14 20:58:41 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sat, 14 Nov 2009 21:58:41 -0500 Subject: AH is pretty useless and perhaps should be deprecated In-Reply-To: <107749.71985.qm@web31814.mail.mud.yahoo.com> References: <000a01ca6563$1db96f20$592c4d60$@edu> <107749.71985.qm@web31814.mail.mud.yahoo.com> Message-ID: <093B72CA-7F7D-4FBB-836E-E082D931705F@cs.columbia.edu> On Nov 14, 2009, at 8:28 PM, David Barak wrote: > I've seen AH used as a "prove that this hasn't been through a NAT" mechanism. In this context, it's pretty much perfect. > > However, what I don't understand is where the dislike for it originates: if you don't like it, don't run it. It is useful in certain cases, and it's already in all of the production IPSec implementations. Why the hate? There are two reasons. First, it's difficult to implement cleanly, since it violates layering: you have to know the contents of the surrounding IP header to calculate the AH field. Back when I was security AD, I had implementors, especially implementors of on-NIC IPsec, beg me to get rid of it. Second, it's redundant; if (as I believe), ESP with NULL encryption does everything useful that AH does, why have two mechanisms? --Steve Bellovin, http://www.cs.columbia.edu/~smb From mohacsi at niif.hu Sun Nov 15 00:58:24 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Sun, 15 Nov 2009 07:58:24 +0100 (CET) Subject: AH is pretty useless and perhaps should be deprecated In-Reply-To: References: Message-ID: On Sat, 14 Nov 2009, Jack Kohn wrote: > Hi, > > Interesting discussion on the utility of Authentication Header (AH) in > IPSecME WG. > > http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html > > Post explaining that AH even though protecting the source and > destination IP addresses is really not good enough. > > http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html > > What do folks feel? Do they see themselves using AH in the future? > IMO, ESP and WESP are good enough and we dont need to support AH any > more .. They are planning to make OSPFv3 IPSec authentication useless? Best Regards, Janos Mohacsi From gordslater at ieee.org Sun Nov 15 01:59:04 2009 From: gordslater at ieee.org (gordon b slater) Date: Sun, 15 Nov 2009 07:59:04 +0000 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <4AFD1C84.2020408@linpro.no> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> <4AFC6DD8.5050502@rollernet.us> <4AFC7917.5040002@davidcoulson.net> <1258060985-sup-4132@sfo.thejof.com> <4AFD1C84.2020408@linpro.no> Message-ID: <1258271944.24078.11.camel@ub-g-d2> On Fri, 2009-11-13 at 09:44 +0100, Tore Anderson wrote: > * Jonathan Lassoff > > > Are there any applications that absolutely *have* to sit on the same > > LAN/broadcast domain and can't be configured to use unicast or multicast > > IP? > > FCoE comes to mind. > ....and in a similar vein, ATAoE ; either Coraid stuff or the the free one in the Linux kernel. Its heavily used in some shops that use virtual farms with SANS as it's cheap/free and works over existing hardware but only at layer 2. I even run it at home (!) - and it's a surprisingly easy way to have a shelf of storage hanging off the back of a server, with 4GB of cache for each set of 4 disks per box. Stand too close can feel the wind from it, especially if RAIDed. Depends if there's much call for VM-ing in your shop in the future? Gord -- NNNN -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3161 bytes Desc: not available URL: From tme at americafree.tv Sun Nov 15 03:12:19 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Sun, 15 Nov 2009 04:12:19 -0500 Subject: AH is pretty useless and perhaps should be deprecated In-Reply-To: <093B72CA-7F7D-4FBB-836E-E082D931705F@cs.columbia.edu> References: <000a01ca6563$1db96f20$592c4d60$@edu> <107749.71985.qm@web31814.mail.mud.yahoo.com> <093B72CA-7F7D-4FBB-836E-E082D931705F@cs.columbia.edu> Message-ID: <8F2A42C1-53FC-48F1-8276-A96899A5CB04@americafree.tv> On Nov 14, 2009, at 9:58 PM, Steven Bellovin wrote: > > On Nov 14, 2009, at 8:28 PM, David Barak wrote: > >> I've seen AH used as a "prove that this hasn't been through a NAT" >> mechanism. In this context, it's pretty much perfect. >> >> However, what I don't understand is where the dislike for it >> originates: if you don't like it, don't run it. It is useful in >> certain cases, and it's already in all of the production IPSec >> implementations. Why the hate? > > There are two reasons. First, it's difficult to implement cleanly, > since it violates layering: you have to know the contents of the > surrounding IP header to calculate the AH field. Back when I was > security AD, I had implementors, especially implementors of on-NIC > IPsec, beg me to get rid of it. Second, it's redundant; if (as I > believe), ESP with NULL encryption does everything useful that AH > does, why have two mechanisms? > Maybe someone should push through a "IPSEC-lite" in the same way we are pushing through IGMPv3-lite. > > --Steve Bellovin, http://www.cs.columbia.edu/~smb Regards Marshall > > > > > > > From kaeo at merike.com Sun Nov 15 03:23:31 2009 From: kaeo at merike.com (Merike Kaeo) Date: Sun, 15 Nov 2009 01:23:31 -0800 Subject: AH is pretty useless and perhaps should be deprecated In-Reply-To: References: Message-ID: No - if you read the below pointers carefully it does specify that ESP-Null is a MUST for OSPFv3 authentication protocol while AH is a MAY. AH is mostly superfluous and complicates implementations. Someone on the IPsec mailing list stated that at least two implementations he was aware of used ESP-Null for OSPFv3 where one did not even have any support for AH. And I know I'm probably violating some posting etiquette here but to answer an earlier comment on same thread where someone asked why the hate for AH and what's problem if it's already in all of the production IPsec implementations.......I can firsthand state that for many IPsec interoperability tests AH is hardly if ever tested. I have been a part of some of them as an interested 3rd party (i.e. non vendor) so have seen what gets tested. AH is always last from what I've seen and rarely does anyone ever get to it. [caveat - my experience comes from multivendor consortium type tests and not what vendors may do privately amongst themselves] And FWIW.....I've been doing skunskwork IPsec for past 10 years and right now there's yet another effort to come up with interoperable defaults which is being lead by the aviation industry and is looking at IETF defined profiles, NSA related recommendations, NIST recommendations and ICSA IPsec consortium recommendations. There was a meeting in Seattle last week and many vendors as well as NIST, DoD and other parties participated. If you are at all running IPsec in a major way and care about interoperable defaults and consistent terminology, contact me offline and I'll get you connected to the group. Vendors will only 'fix' their implementations if there's cohesion from customer base. - merike On Nov 14, 2009, at 10:58 PM, Mohacsi Janos wrote: > > > > On Sat, 14 Nov 2009, Jack Kohn wrote: > >> Hi, >> >> Interesting discussion on the utility of Authentication Header >> (AH) in >> IPSecME WG. >> >> http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html >> >> Post explaining that AH even though protecting the source and >> destination IP addresses is really not good enough. >> >> http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html >> >> What do folks feel? Do they see themselves using AH in the future? >> IMO, ESP and WESP are good enough and we dont need to support AH any >> more .. > > > They are planning to make OSPFv3 IPSec authentication useless? > Best Regards, > Janos Mohacsi > > From simon.leinen at switch.ch Sun Nov 15 07:17:35 2009 From: simon.leinen at switch.ch (Simon Leinen) Date: Sun, 15 Nov 2009 14:17:35 +0100 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <4AFD1C84.2020408@linpro.no> (Tore Anderson's message of "Fri, 13 Nov 2009 09:44:52 +0100") References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> <4AFC6DD8.5050502@rollernet.us> <4AFC7917.5040002@davidcoulson.net> <1258060985-sup-4132@sfo.thejof.com> <4AFD1C84.2020408@linpro.no> Message-ID: Tore Anderson writes: > * Jonathan Lassoff >> Are there any applications that absolutely *have* to sit on the same >> LAN/broadcast domain and can't be configured to use unicast or multicast >> IP? > FCoE comes to mind. Doesn't FCoE need even more than that, i.e. "lossless" Ethernet with end-to-end flow control, such as IEEE DCB? As far as I understand, traditional switched Ethernets don't fit the bill anyway. On the other hand iSCSI should be fine with routed IP paths; though Malte's mail suggests that there are (broken?) implementations that aren't. -- Simon. From simon at darkmere.gen.nz Sun Nov 15 19:14:01 2009 From: simon at darkmere.gen.nz (NANOG Mail List Committee) Date: Mon, 16 Nov 2009 14:14:01 +1300 Subject: ADMIN: List FAQ/Monthly Post. Message-ID: This 100-line document contains 62% of what you need to know to avoid annoying 10,000 people in your email to the NANOG list. It also contains pointers to another 23%. Please take 5 minutes to read it before you post [again]. General Information =================== About NANOG: http://www.nanog.org/about/ NANOG News: http://www.nanog.org/ NANOG lists and AUP: http://www.nanog.org/mailinglist/ NANOG List FAQ: http://www.nanog.org/mailinglist/listfaqs/ To Subscribe or Unsubscribe from the list: http://mailman.nanog.org/mailman/listinfo/nanog To contact the list's admins: admins at nanog.org Posting Policy ============== The NANOG list has over 10,000 subscribers so it is very easy for a thread to have scores of posts while being off-topic and only of interest to only a small proportion of subscribers. Please consider before each post if your email will be of interest to the majority of members or might alternatively be emailed directly the people of interest or posted to another forum. Please read the FAQ and AUP policy before posting for more details. Especially the following are discouraged: * Is a certain site down? Other Outages not affecting half the Internet. Please use http://downforeveryoneorjustme.com/ or a similar site. Please post to the Outages mailing list: http://wiki.outages.org * Spam Please use SPAM-L - http://spam-l.com/mailman/listinfo * Contacting People * http://puck.nether.net/netops/ * http://www.peeringdb.com * Please try other methods of contacting sites before you post to NANOG. Saying something like "I tried calling 213-555-3333 but no answer" shows you _have_ tried alternative methods first. * Political Issues * Topics such as ICANN policy, Government Policy or Law changes that do not have short term Operational impact should be avoided. * Operation topics with more specific lists * DNS - http://lists.oarci.net/mailman/listinfo/dns-operations * Email - http://www.mailop.org/ * NANOG Mailing list policy Please use the nanog-futures list or contact admins at nanog.org Please also avoid ================= * Sending posts to the list relevant to only one or two people on this list, such as tests or traceroutes in response to another post for comparison to those originally posted. * Jokes, Puns, amusing observations, spelling corrections. Other NANOG related lists ========================= * NANOG-futures - for discussion of the evolution of NANOG, including organizational structure, policies and procedures, and agendas for NANOG meetings. Such topics aren't appropriate for the main NANOG mailing list. http://mailman.nanog.org/mailman/listinfo/nanog-futures * nanog-attendee - For discussion of venue-specific issues relevant to attendees of the current NANOG physical meeting. http://mailman.nanog.org/mailman/listinfo/nanog-attendee * nanog-announce - For announcements of NANOG meetings an other Important NANOG related announcements. Low traffic and all posts are also sent to main list. http://mailman.nanog.org/mailman/listinfo/nanog-announce Other Mailing Lists =================== Information about related lists: http://www.nanog.org/mailinglist/listfaqs/otherlists.php From joelja at bogus.com Sun Nov 15 22:48:47 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 16 Nov 2009 13:48:47 +0900 Subject: AH is pretty useless and perhaps should be deprecated In-Reply-To: References: Message-ID: <4B00D9AF.8020202@bogus.com> Owen DeLong wrote: > I've never seen anyone use AH vs. ESP. OSPFv3? > I've always used ESP and so has > every other IPSEC implementation I've seen anyone do. > > Owen > > On Nov 13, 2009, at 4:22 PM, Jack Kohn wrote: > >> Hi, >> >> Interesting discussion on the utility of Authentication Header (AH) in >> IPSecME WG. >> >> http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html >> >> Post explaining that AH even though protecting the source and >> destination IP addresses is really not good enough. >> >> http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html >> >> What do folks feel? Do they see themselves using AH in the future? >> IMO, ESP and WESP are good enough and we dont need to support AH any >> more .. >> >> Jack > > From sethm at rollernet.us Sun Nov 15 23:28:48 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 15 Nov 2009 21:28:48 -0800 Subject: Alternatives to Cisco SFP-GE-S? Message-ID: <4B00E310.3040609@rollernet.us> Does anyone have any practical long term experience with third party alternatives to the (must be made from solid gold) Cisco SFP-GE-S module that they'd like to share with me? I suppose I could just use compatible GLC-SX-MM instead, but I kind of want to have DOM support. ~Seth From lists at billfehring.com Sun Nov 15 23:29:58 2009 From: lists at billfehring.com (Bill Fehring) Date: Sun, 15 Nov 2009 21:29:58 -0800 Subject: AH is pretty useless and perhaps should be deprecated In-Reply-To: <4B00D9AF.8020202@bogus.com> References: <4B00D9AF.8020202@bogus.com> Message-ID: On Sun, Nov 15, 2009 at 20:48, Joel Jaeggli wrote: > Owen DeLong wrote: >> I've never seen anyone use AH vs. ESP. > > OSPFv3? Maybe I'm asking a dumb question, but why would one prefer AH over ESP for OSPFv3? RFC4552: "In order to provide authentication to OSPFv3, implementations MUST support ESP and MAY support AH." -Bill From joelja at bogus.com Mon Nov 16 00:17:29 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 16 Nov 2009 15:17:29 +0900 Subject: AH is pretty useless and perhaps should be deprecated In-Reply-To: References: <4B00D9AF.8020202@bogus.com> Message-ID: <4B00EE79.701@bogus.com> Bill Fehring wrote: > On Sun, Nov 15, 2009 at 20:48, Joel Jaeggli wrote: >> Owen DeLong wrote: >>> I've never seen anyone use AH vs. ESP. >> OSPFv3? > > Maybe I'm asking a dumb question, but why would one prefer AH over ESP > for OSPFv3? Header protection... still doesn't provide replay protection, your mileage may vary http://tools.ietf.org/html/draft-ietf-opsec-routing-protocols-crypto-issues-02 > RFC4552: > "In order to provide authentication to OSPFv3, implementations MUST > support ESP and MAY support AH." > > -Bill > From sthaug at nethelp.no Mon Nov 16 01:00:39 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Mon, 16 Nov 2009 08:00:39 +0100 (CET) Subject: Alternatives to Cisco SFP-GE-S? In-Reply-To: <4B00E310.3040609@rollernet.us> References: <4B00E310.3040609@rollernet.us> Message-ID: <20091116.080039.74696513.sthaug@nethelp.no> > Does anyone have any practical long term experience with third party > alternatives to the (must be made from solid gold) Cisco SFP-GE-S module > that they'd like to share with me? I suppose I could just use compatible > GLC-SX-MM instead, but I kind of want to have DOM support. There are plenty of vendors which can sell you SFPs which are "Cisco coded" (i.e. the Cisco switches don't complain), have DOM support and are much more reasonably priced than Cisco. We have had good experience with Zycko. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From net-ops at monolith-networks.net Mon Nov 16 09:54:02 2009 From: net-ops at monolith-networks.net (Gary Mackenzie) Date: Mon, 16 Nov 2009 15:54:02 -0000 (GMT) Subject: Juniper M120 Alternatives Message-ID: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> Having slightly lost track of what everybody is using for peering routers these days, what is the consensus about the best alternative to Juniper M series routers? I'm asking as the prices to upgrade to 10Gbit capable Juniper units (ie. an M120) seem prohibitively high so I'm looking to get a feel for the alternatives. The other obvious platform would appear to be a Cisco XR 12404 (or similar depending on line card requirements) but is anything else in common use as a peering platform? Cheers for any input. Rgds Gary From dwcarder at wisc.edu Mon Nov 16 10:04:35 2009 From: dwcarder at wisc.edu (Dale W. Carder) Date: Mon, 16 Nov 2009 10:04:35 -0600 Subject: Juniper M120 Alternatives In-Reply-To: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> References: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> Message-ID: On Nov 16, 2009, at 9:54 AM, Gary Mackenzie wrote: > Having slightly lost track of what everybody is using for peering routers > these days, what is the consensus about the best alternative to Juniper M > series routers? have you looked at the MX series? Dale From cgrundemann at gmail.com Mon Nov 16 10:08:27 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 16 Nov 2009 09:08:27 -0700 Subject: Juniper M120 Alternatives In-Reply-To: References: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> Message-ID: <443de7ad0911160808oee8f9cfo70e3391f36b054f2@mail.gmail.com> On Mon, Nov 16, 2009 at 09:04, Dale W. Carder wrote: > > On Nov 16, 2009, at 9:54 AM, Gary Mackenzie wrote: > >> Having slightly lost track of what everybody is using for peering routers >> these days, what is the consensus about the best alternative to Juniper M >> series routers? > > have you looked at the MX series? +1 ~Chris > > Dale > > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From sthaug at nethelp.no Mon Nov 16 10:10:14 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Mon, 16 Nov 2009 17:10:14 +0100 (CET) Subject: Juniper M120 Alternatives In-Reply-To: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> References: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> Message-ID: <20091116.171014.74676447.sthaug@nethelp.no> > Having slightly lost track of what everybody is using for peering routers > these days, what is the consensus about the best alternative to Juniper M > series routers? Juniper MX series? Works great for us. Much nicer 10G prices than M120. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From bdfleming at kanren.net Mon Nov 16 10:14:34 2009 From: bdfleming at kanren.net (Brad Fleming) Date: Mon, 16 Nov 2009 10:14:34 -0600 Subject: Juniper M120 Alternatives In-Reply-To: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> References: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> Message-ID: I'd think the Juniper MX series might fit, as well as the Brocade NetIron XMR. And of course the Cisco you already mentioned. -brad On Nov 16, 2009, at 9:54 AM, Gary Mackenzie wrote: > Having slightly lost track of what everybody is using for peering > routers > these days, what is the consensus about the best alternative to > Juniper M > series routers? > > I'm asking as the prices to upgrade to 10Gbit capable Juniper units > (ie. > an M120) seem prohibitively high so I'm looking to get a feel for the > alternatives. The other obvious platform would appear to be a Cisco XR > 12404 (or similar depending on line card requirements) but is anything > else in common use as a peering platform? > > Cheers for any input. > > Rgds > > Gary > > > From net-ops at monolith-networks.net Mon Nov 16 10:14:52 2009 From: net-ops at monolith-networks.net (Gary Mackenzie) Date: Mon, 16 Nov 2009 16:14:52 -0000 (GMT) Subject: Juniper M120 Alternatives In-Reply-To: <443de7ad0911160808oee8f9cfo70e3391f36b054f2@mail.gmail.com> References: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> <443de7ad0911160808oee8f9cfo70e3391f36b054f2@mail.gmail.com> Message-ID: <29152.82.132.136.147.1258388092.squirrel@webmail-vh.tagadab.com> > On Mon, Nov 16, 2009 at 09:04, Dale W. Carder wrote: >> >> On Nov 16, 2009, at 9:54 AM, Gary Mackenzie wrote: >> >>> Having slightly lost track of what everybody is using for peering >>> routers >>> these days, what is the consensus about the best alternative to Juniper >>> M >>> series routers? >> >> have you looked at the MX series? > > +1 > ~Chris > >> >> Dale >> I had looked briefly, does anybody here actually use them as peering routers? I've seen a few implementations using them in the MPLS P and PE router roles but never as border routers. If there is some precedent for using them in this role that's good to hear and I'll take another look, I was loath to move away from Juniper as our current boxes are been the model of reliability. Cheers Gary From sthaug at nethelp.no Mon Nov 16 10:37:42 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Mon, 16 Nov 2009 17:37:42 +0100 (CET) Subject: Juniper M120 Alternatives In-Reply-To: <29152.82.132.136.147.1258388092.squirrel@webmail-vh.tagadab.com> References: <443de7ad0911160808oee8f9cfo70e3391f36b054f2@mail.gmail.com> <29152.82.132.136.147.1258388092.squirrel@webmail-vh.tagadab.com> Message-ID: <20091116.173742.41703039.sthaug@nethelp.no> > I had looked briefly, does anybody here actually use them as peering > routers? I've seen a few implementations using them in the MPLS P and PE > router roles but never as border routers. We use MX series as peering routers. They work very well. Steinar Haug, AS 2116 From jason at lixfeld.ca Mon Nov 16 10:55:14 2009 From: jason at lixfeld.ca (Jason Lixfeld) Date: Mon, 16 Nov 2009 11:55:14 -0500 Subject: Juniper M120 Alternatives In-Reply-To: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> References: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> Message-ID: <0CCE589F-D86F-4644-BF56-6FCD90F4C0F9@lixfeld.ca> Cisco's ASR9000 is supposed to be in-line with the Juniper MX offering (price-wise and feature-wise); more so than as 124xx, I hear. On 2009-11-16, at 10:54 AM, "Gary Mackenzie" wrote: > Having slightly lost track of what everybody is using for peering > routers > these days, what is the consensus about the best alternative to > Juniper M > series routers? > > I'm asking as the prices to upgrade to 10Gbit capable Juniper units > (ie. > an M120) seem prohibitively high so I'm looking to get a feel for the > alternatives. The other obvious platform would appear to be a Cisco XR > 12404 (or similar depending on line card requirements) but is anything > else in common use as a peering platform? > > Cheers for any input. > > Rgds > > Gary > > From tore at linpro.no Mon Nov 16 11:04:46 2009 From: tore at linpro.no (Tore Anderson) Date: Mon, 16 Nov 2009 18:04:46 +0100 Subject: Juniper M120 Alternatives In-Reply-To: <29152.82.132.136.147.1258388092.squirrel@webmail-vh.tagadab.com> References: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> <443de7ad0911160808oee8f9cfo70e3391f36b054f2@mail.gmail.com> <29152.82.132.136.147.1258388092.squirrel@webmail-vh.tagadab.com> Message-ID: <4B01862E.8090101@linpro.no> * Gary Mackenzie > I had looked briefly, does anybody here actually use them as peering > routers? I've seen a few implementations using them in the MPLS P and > PE router roles but never as border routers. We've been using the MX-es as border routers for some time now. It's a role that suits them very well in my opinion, no problems at all so far. I'll be very surprised if we don't end up using MX-es in our next PoP as well. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From j.varaillon at cosmoline.com Mon Nov 16 11:05:08 2009 From: j.varaillon at cosmoline.com (Varaillon Jean Christophe) Date: Mon, 16 Nov 2009 19:05:08 +0200 Subject: Fiber Cut in Italy In-Reply-To: <0CCE589F-D86F-4644-BF56-6FCD90F4C0F9@lixfeld.ca> References: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> <0CCE589F-D86F-4644-BF56-6FCD90F4C0F9@lixfeld.ca> Message-ID: <012c01ca66de$f41e26b0$dc5a7410$%varaillon@cosmoline.com> Hi, It seems that there is a major fiber cut in Italy (not really near nanog, so just in case...) I was just wondering if anybody has heard of any possible recovery time - as there is none official one yet. Thank you, Jean-Christophe VARAILLON ------------------------- Data Network Engineer Cosmoline - www.cosmoline.com 40th km Attiki Odos Rest Area Mesogea 190 02 Peania,?Greece my: phone???? +30 212 212 2211 my: cell??????+30 694 556 4826 my: fax2mail? +30 212 212 9905 my: e-mail? ??j.varaillon at cosmoline.com ?????????? ?????????: ?? ??????????? ??? ??????????????? ??? ????? ????? ????????????? ??? ???????????? ???????????? ???? ??? ????????? ??? ?????????? ????????. ??? ?? ?????? ??? ????????? ??? ??????????? ??? ???, ??? ?????????? ??? ??? ?????????? ??? ????? ???????? ?? ?? ??????????, ???????????, ?????????? ? ??????????????? ?? ??????????? ?????. ??? ??????????? ????? ?? ???????????? ?????? ??? ????????? ???? ?????????? ??????? ??? ?????????? ? ?? ?????????? e-mail ??? ?? ???????????? ?? ?????????. IMPORTANT NOTICE: This email and any of its attachments are intended only for the recipient(s) named above and are confidential and/or contain trade secrets. Any unauthorized use, e.g. review, printing, copying or distribution by other persons,is prohibited and may constitute a criminal offence. If you have received this email in error, please notify the sender immediately and delete the original message. __________ Information from ESET Smart Security, version of virus signature database 4611 (20091116) __________ The message was checked by ESET Smart Security. http://www.eset.com From oberman at es.net Mon Nov 16 11:18:03 2009 From: oberman at es.net (Kevin Oberman) Date: Mon, 16 Nov 2009 09:18:03 -0800 Subject: Juniper M120 Alternatives In-Reply-To: Your message of "Mon, 16 Nov 2009 16:14:52 GMT." <29152.82.132.136.147.1258388092.squirrel@webmail-vh.tagadab.com> Message-ID: <20091116171803.555DD1CC37@ptavv.es.net> > Date: Mon, 16 Nov 2009 16:14:52 -0000 (GMT) > From: "Gary Mackenzie" > > > On Mon, Nov 16, 2009 at 09:04, Dale W. Carder wrote: > >> > >> On Nov 16, 2009, at 9:54 AM, Gary Mackenzie wrote: > >> > >>> Having slightly lost track of what everybody is using for peering > >>> routers > >>> these days, what is the consensus about the best alternative to Juniper > >>> M > >>> series routers? > >> > >> have you looked at the MX series? > > > > +1 > > ~Chris > > > >> > >> Dale > >> > > I had looked briefly, does anybody here actually use them as peering > routers? I've seen a few implementations using them in the MPLS P and PE > router roles but never as border routers. > > If there is some precedent for using them in this role that's good to hear > and I'll take another look, I was loath to move away from Juniper as our > current boxes are been the model of reliability. We use them as peering routers and are in the process of upgrading all of our peering routers to MX boxes. -- 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 hank at efes.iucc.ac.il Mon Nov 16 11:55:04 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 16 Nov 2009 19:55:04 +0200 (IST) Subject: Fiber Cut in Italy In-Reply-To: <012c01ca66de$f41e26b0$dc5a7410$%varaillon@cosmoline.com> References: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> <0CCE589F-D86F-4644-BF56-6FCD90F4C0F9@lixfeld.ca> <012c01ca66de$f41e26b0$dc5a7410$%varaillon@cosmoline.com> Message-ID: On Mon, 16 Nov 2009, Varaillon Jean Christophe wrote: Yup - even Israel is affected. Started at 16:35 (gmt+2) and the cut is inside Telecom Italia. No ETA. -Hank > Hi, > > It seems that there is a major fiber cut in Italy (not really near nanog, so > just in case...) > > I was just wondering if anybody has heard of any possible recovery time - as > there is none official one yet. > > Thank you, > > Jean-Christophe VARAILLON > ------------------------- > Data Network Engineer > Cosmoline - www.cosmoline.com > 40th km Attiki Odos > Rest Area Mesogea > 190 02 Peania,?Greece > my: phone???? +30 212 212 2211 > my: cell??????+30 694 556 4826 > my: fax2mail? +30 212 212 9905 > my: e-mail? ??j.varaillon at cosmoline.com > > > ?????????? ?????????: ?? ??????????? ??? ??????????????? ??? ????? ????? > ????????????? ??? ???????????? ???????????? ???? ??? ????????? ??? > ?????????? ????????. ??? ?? ?????? ??? ????????? ??? ??????????? ??? ???, > ??? ?????????? ??? ??? ?????????? ??? ????? ???????? ?? ?? ??????????, > ???????????, ?????????? ? ??????????????? ?? ??????????? ?????. ??? > ??????????? ????? ?? ???????????? ?????? ??? ????????? ???? ?????????? > ??????? ??? ?????????? ? ?? ?????????? e-mail ??? ?? ???????????? ?? > ?????????. > > > IMPORTANT NOTICE: This email and any of its attachments are intended only > for the recipient(s) named above and are confidential and/or contain trade > secrets. Any unauthorized use, e.g. review, printing, copying or > distribution by other persons,is prohibited and may constitute a criminal > offence. If you have received this email in error, please notify the sender > immediately and delete the original message. > > > > __________ Information from ESET Smart Security, version of virus signature > database 4611 (20091116) __________ > > The message was checked by ESET Smart Security. > > http://www.eset.com > > From net-ops at monolith-networks.net Mon Nov 16 13:00:45 2009 From: net-ops at monolith-networks.net (Gary Mackenzie) Date: Mon, 16 Nov 2009 19:00:45 -0000 (GMT) Subject: Juniper M120 Alternatives In-Reply-To: References: Message-ID: <11626.217.196.233.39.1258398045.squirrel@webmail-vh.tagadab.com> Thanks everybody for the feedback. I'll likely be getting a few quotes for MX series boxes I think, we're in the happy position of having a completely e-net infrastructure so we're not limited by interface options. Thanks again for recommendation, good to know other people are using them successfully. Cheers Gary > MX uses the I-Chip same as on M120/320 series. MX would be perfect for > any > location in the network P/PE if you are talking about E-Net services vs. > TDM. They would be a perfect peering box if you are using E-Net. > > > On 11/16/09 10:14 AM, "Gary Mackenzie" > wrote: > >>> On Mon, Nov 16, 2009 at 09:04, Dale W. Carder >>> wrote: >>>> >>>> On Nov 16, 2009, at 9:54 AM, Gary Mackenzie wrote: >>>> >>>>> Having slightly lost track of what everybody is using for peering >>>>> routers >>>>> these days, what is the consensus about the best alternative to >>>>> Juniper >>>>> M >>>>> series routers? >>>> >>>> have you looked at the MX series? >>> >>> +1 >>> ~Chris >>> >>>> >>>> Dale >>>> >> >> I had looked briefly, does anybody here actually use them as peering >> routers? I've seen a few implementations using them in the MPLS P and PE >> router roles but never as border routers. >> >> If there is some precedent for using them in this role that's good to >> hear >> and I'll take another look, I was loath to move away from Juniper as our >> current boxes are been the model of reliability. >> >> Cheers >> >> Gary >> >> > > > *************************************************************************************** > The information contained in this message, including attachments, may > contain > privileged or confidential information that is intended to be delivered > only to the > person identified above. If you are not the intended recipient, or the > person > responsible for delivering this message to the intended recipient, > Windstream requests > that you immediately notify the sender and asks that you do not read the > message or its > attachments, and that you delete them without copying or sending them to > anyone else. > From bpasdar at batblue.com Mon Nov 16 13:37:10 2009 From: bpasdar at batblue.com (Babak Pasdar) Date: Mon, 16 Nov 2009 14:37:10 -0500 Subject: Bandwidth Monitoring per AS Message-ID: <20091116193710.f7262880@concur.batblue.com> Could some of you share your recommendations on the best tools for monitoring per AS communications. I would like to track all source AS to Destination AS traffic utilization. Best Regards, Babak -- Babak Pasdar President & CEO | Certified Ethical Hacker Bat Blue Corporation | Integrity . Privacy . Availability (p) 212.461.3322 x3005 | (f) 212.584.9999 | (w) www.BatBlue.com Receive Bat Blue's Daily Security Intelligence Report Bat Blue's AS: 25885 | BGP Policy | Peering Policy Bat Blue's Legal Notice Reducing IT Security Budget, Burden & Risk - Video | Article From bbillon-ml at splio.fr Mon Nov 16 13:51:11 2009 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Mon, 16 Nov 2009 20:51:11 +0100 Subject: Bandwidth Monitoring per AS In-Reply-To: <20091116193710.f7262880@concur.batblue.com> References: <20091116193710.f7262880@concur.batblue.com> Message-ID: <4B01AD2F.70200@splio.fr> Depending on your needs: - https://neon1.net/as-stats/ (some patches here http://www.mail-archive.com/frnog at frnog.org/msg07257.html) - Arbor PeakflowSP - anything base on netflow Benjamin BILLON -- -- -- -- -- -- Splio eMarketing Services Babak Pasdar a ?crit : > Could some of you share your recommendations on the best tools for monitoring per AS communications. I would like to track all source AS to Destination AS traffic utilization. > > Best Regards, > > Babak > > > -- > Babak Pasdar > President & CEO | Certified Ethical Hacker > Bat Blue Corporation | Integrity . Privacy . Availability > (p) 212.461.3322 x3005 | (f) 212.584.9999 | (w) www.BatBlue.com > > Receive Bat Blue's Daily Security Intelligence Report > Bat Blue's AS: 25885 | BGP Policy | Peering Policy > Bat Blue's Legal Notice > > Reducing IT Security Budget, Burden & Risk - Video | Article > From mehmet at akcin.net Mon Nov 16 14:02:31 2009 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 16 Nov 2009 12:02:31 -0800 Subject: Juniper M120 Alternatives In-Reply-To: <11626.217.196.233.39.1258398045.squirrel@webmail-vh.tagadab.com> References: <11626.217.196.233.39.1258398045.squirrel@webmail-vh.tagadab.com> Message-ID: <18D6646E-9543-4CCF-9081-C41648857006@akcin.net> Remember to request some quotes for MX-80, not yet released , soon to be out "lower end" routers. and MX240 3Ds. http://www.juniper.net/us/en/products-services/routing/mx-series/mx240/ Normally Juniper sales guys don't quote you things that are coming out soon unless you specially ask for this. mehmet On Nov 16, 2009, at 11:00 AM, Gary Mackenzie wrote: > Thanks everybody for the feedback. I'll likely be getting a few quotes for > MX series boxes I think, we're in the happy position of having a > completely e-net infrastructure so we're not limited by interface options. > > Thanks again for recommendation, good to know other people are using them > successfully. > > Cheers > > Gary > >> MX uses the I-Chip same as on M120/320 series. MX would be perfect for >> any >> location in the network P/PE if you are talking about E-Net services vs. >> TDM. They would be a perfect peering box if you are using E-Net. >> >> >> On 11/16/09 10:14 AM, "Gary Mackenzie" >> wrote: >> >>>> On Mon, Nov 16, 2009 at 09:04, Dale W. Carder >>>> wrote: >>>>> >>>>> On Nov 16, 2009, at 9:54 AM, Gary Mackenzie wrote: >>>>> >>>>>> Having slightly lost track of what everybody is using for peering >>>>>> routers >>>>>> these days, what is the consensus about the best alternative to >>>>>> Juniper >>>>>> M >>>>>> series routers? >>>>> >>>>> have you looked at the MX series? >>>> >>>> +1 >>>> ~Chris >>>> >>>>> >>>>> Dale >>>>> >>> >>> I had looked briefly, does anybody here actually use them as peering >>> routers? I've seen a few implementations using them in the MPLS P and PE >>> router roles but never as border routers. >>> >>> If there is some precedent for using them in this role that's good to >>> hear >>> and I'll take another look, I was loath to move away from Juniper as our >>> current boxes are been the model of reliability. >>> >>> Cheers >>> >>> Gary >>> >>> >> >> >> *************************************************************************************** >> The information contained in this message, including attachments, may >> contain >> privileged or confidential information that is intended to be delivered >> only to the >> person identified above. If you are not the intended recipient, or the >> person >> responsible for delivering this message to the intended recipient, >> Windstream requests >> that you immediately notify the sender and asks that you do not read the >> message or its >> attachments, and that you delete them without copying or sending them to >> anyone else. >> > > > From sfouant at shortestpathfirst.net Mon Nov 16 14:04:57 2009 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Mon, 16 Nov 2009 15:04:57 -0500 Subject: Bandwidth Monitoring per AS In-Reply-To: <20091116193710.f7262880@concur.batblue.com> References: <20091116193710.f7262880@concur.batblue.com> Message-ID: <005401ca66f8$1281f5f0$3785e1d0$@net> > -----Original Message----- > From: Babak Pasdar [mailto:bpasdar at batblue.com] > Sent: Monday, November 16, 2009 2:37 PM > > Could some of you share your recommendations on the best tools for > monitoring per AS communications. I would like to track all source AS > to Destination AS traffic utilization. Depending on your price range, you might want to take a look at Arbor's Peakflow SP. There is some pretty top notch traffic and routing analysis tools in their package. Regards, Stefan Fouant GPG Key ID: 0xB5E3803D From pstewart at nexicomgroup.net Mon Nov 16 14:17:00 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Mon, 16 Nov 2009 15:17:00 -0500 Subject: Bandwidth Monitoring per AS In-Reply-To: <005401ca66f8$1281f5f0$3785e1d0$@net> References: <20091116193710.f7262880@concur.batblue.com> <005401ca66f8$1281f5f0$3785e1d0$@net> Message-ID: Yes, we use Arbor here and *really* like it... powerful system - not cheap but worth every penny...;) Paul -----Original Message----- From: Stefan Fouant [mailto:sfouant at shortestpathfirst.net] Sent: Monday, November 16, 2009 3:05 PM To: 'Babak Pasdar'; nanog at nanog.org Subject: RE: Bandwidth Monitoring per AS > -----Original Message----- > From: Babak Pasdar [mailto:bpasdar at batblue.com] > Sent: Monday, November 16, 2009 2:37 PM > > Could some of you share your recommendations on the best tools for > monitoring per AS communications. I would like to track all source AS > to Destination AS traffic utilization. Depending on your price range, you might want to take a look at Arbor's Peakflow SP. There is some pretty top notch traffic and routing analysis tools in their package. Regards, Stefan Fouant GPG Key ID: 0xB5E3803D ---------------------------------------------------------------------------- "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 leslie at craigslist.org Mon Nov 16 15:20:19 2009 From: leslie at craigslist.org (Leslie) Date: Mon, 16 Nov 2009 13:20:19 -0800 Subject: Juniper M120 Alternatives In-Reply-To: <4B01862E.8090101@linpro.no> References: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> <443de7ad0911160808oee8f9cfo70e3391f36b054f2@mail.gmail.com> <29152.82.132.136.147.1258388092.squirrel@webmail-vh.tagadab.com> <4B01862E.8090101@linpro.no> Message-ID: <4B01C213.7060609@craigslist.org> Tore Anderson wrote: > * Gary Mackenzie > >> I had looked briefly, does anybody here actually use them as peering >> routers? I've seen a few implementations using them in the MPLS P and >> PE router roles but never as border routers. > > We've been using the MX-es as border routers for some time now. It's a > role that suits them very well in my opinion, no problems at all so far. > I'll be very surprised if we don't end up using MX-es in our next PoP > as well. > > Best regards, We're using them as border routers and love them. As long as you don't need sonet, i think it's a great choice. Leslie From rduman at colohouse.com Mon Nov 16 15:24:11 2009 From: rduman at colohouse.com (Duman, Richard) Date: Mon, 16 Nov 2009 16:24:11 -0500 Subject: Bandwidth Monitoring per AS In-Reply-To: <20091116193710.f7262880@concur.batblue.com> References: <20091116193710.f7262880@concur.batblue.com> Message-ID: Pretty Sure Arbor makes a good box. If you are looking for reporting and auto-tweaking of your traffic, you can look at the Internap Flow Control box as well. -----Original Message----- From: Babak Pasdar [mailto:bpasdar at batblue.com] Sent: Monday, November 16, 2009 2:37 PM To: nanog at nanog.org Subject: Bandwidth Monitoring per AS Could some of you share your recommendations on the best tools for monitoring per AS communications. I would like to track all source AS to Destination AS traffic utilization. Best Regards, Babak -- Babak Pasdar President & CEO | Certified Ethical Hacker Bat Blue Corporation | Integrity . Privacy . Availability (p) 212.461.3322 x3005 | (f) 212.584.9999 | (w) www.BatBlue.com Receive Bat Blue's Daily Security Intelligence Report Bat Blue's AS: 25885 | BGP Policy | Peering Policy Bat Blue's Legal Notice Reducing IT Security Budget, Burden & Risk - Video | Article From j.varaillon at cosmoline.com Mon Nov 16 15:48:15 2009 From: j.varaillon at cosmoline.com (Varaillon Jean Christophe) Date: Mon, 16 Nov 2009 23:48:15 +0200 Subject: Fiber Cut in Italy In-Reply-To: <012c01ca66de$f41e26b0$dc5a7410$%varaillon@cosmoline.com> References: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> <0CCE589F-D86F-4644-BF56-6FCD90F4C0F9@lixfeld.ca> <012c01ca66de$f41e26b0$dc5a7410$%varaillon@cosmoline.com> Message-ID: <009801ca6706$84380910$8ca81b30$%varaillon@cosmoline.com> This is still ongoing (more than 6 hours now...), and nobody can give any ETA. So if someone hear about something... Thank you Jean-Christophe -----Original Message----- From: Varaillon Jean Christophe [mailto:varaillon at cosmoline.com] Sent: Monday, November 16, 2009 7:05 PM To: nanog at nanog.org Subject: Fiber Cut in Italy Hi, It seems that there is a major fiber cut in Italy (not really near nanog, so just in case...) I was just wondering if anybody has heard of any possible recovery time - as there is none official one yet. Thank you, Jean-Christophe VARAILLON ------------------------- Data Network Engineer Cosmoline - www.cosmoline.com 40th km Attiki Odos Rest Area Mesogea 190 02 Peania,?Greece my: phone???? +30 212 212 2211 my: cell??????+30 694 556 4826 my: fax2mail? +30 212 212 9905 my: e-mail? ??j.varaillon at cosmoline.com ?????????? ?????????: ?? ??????????? ??? ??????????????? ??? ????? ????? ????????????? ??? ???????????? ???????????? ???? ??? ????????? ??? ?????????? ????????. ??? ?? ?????? ??? ????????? ??? ??????????? ??? ???, ??? ?????????? ??? ??? ?????????? ??? ????? ???????? ?? ?? ??????????, ???????????, ?????????? ? ??????????????? ?? ??????????? ?????. ??? ??????????? ????? ?? ???????????? ?????? ??? ????????? ???? ?????????? ??????? ??? ?????????? ? ?? ?????????? e-mail ??? ?? ???????????? ?? ?????????. IMPORTANT NOTICE: This email and any of its attachments are intended only for the recipient(s) named above and are confidential and/or contain trade secrets. Any unauthorized use, e.g. review, printing, copying or distribution by other persons,is prohibited and may constitute a criminal offence. If you have received this email in error, please notify the sender immediately and delete the original message. __________ Information from ESET Smart Security, version of virus signature database 4611 (20091116) __________ The message was checked by ESET Smart Security. http://www.eset.com __________ Information from ESET Smart Security, version of virus signature database 4611 (20091116) __________ The message was checked by ESET Smart Security. http://www.eset.com __________ Information from ESET Smart Security, version of virus signature database 4613 (20091116) __________ The message was checked by ESET Smart Security. http://www.eset.com From kohn.jack at gmail.com Mon Nov 16 18:23:39 2009 From: kohn.jack at gmail.com (Jack Kohn) Date: Tue, 17 Nov 2009 05:53:39 +0530 Subject: AH is pretty useless and perhaps should be deprecated In-Reply-To: <4B00EE79.701@bogus.com> References: <4B00D9AF.8020202@bogus.com> <4B00EE79.701@bogus.com> Message-ID: I read the draft and its very interesting. There were some issues that i had never imagined could exist and it does a wonderful job of brining them forth. However, i still dont understand why AH would be preferred over ESP-NULL in case of OSPFv3. The draft speaks of issues with replaying the OSPF packets. One could also do these things with AH. Am i missing something? Jack On Mon, Nov 16, 2009 at 11:47 AM, Joel Jaeggli wrote: > > > Bill Fehring wrote: >> On Sun, Nov 15, 2009 at 20:48, Joel Jaeggli wrote: >>> Owen DeLong wrote: >>>> I've never seen anyone use AH vs. ESP. >>> OSPFv3? >> >> Maybe I'm asking a dumb question, but why would one prefer AH over ESP >> for OSPFv3? > > Header protection... still doesn't provide replay protection, your > mileage may vary > > http://tools.ietf.org/html/draft-ietf-opsec-routing-protocols-crypto-issues-02 > >> RFC4552: >> "In order to provide authentication to OSPFv3, implementations MUST >> support ESP and MAY support AH." >> >> -Bill >> > > From dr at cluenet.de Mon Nov 16 18:28:06 2009 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 17 Nov 2009 01:28:06 +0100 Subject: Juniper M120 Alternatives In-Reply-To: <4B01862E.8090101@linpro.no> References: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> <443de7ad0911160808oee8f9cfo70e3391f36b054f2@mail.gmail.com> <29152.82.132.136.147.1258388092.squirrel@webmail-vh.tagadab.com> <4B01862E.8090101@linpro.no> Message-ID: <20091117002806.GA302@srv03.cluenet.de> On Mon, Nov 16, 2009 at 06:04:46PM +0100, Tore Anderson wrote: > We've been using the MX-es as border routers for some time now. It's a > role that suits them very well in my opinion, no problems at all so far. Caveat: no MAC accounting on LAGs (IEEE speak) / Aggregated Ethernet (Juniper speak) / Etherchannels (Cisco speak). Might or might not be important when using bundled links to public peering fabrics. Best regards, Daniel PS: and of course JUNOS still undeterministically resetting unrelated BGP sessions for no good reason when modifying BGP configuration - so one is well-advised to do ANY configuration changes in the area of BGP within a maint window as it might happen that you configure a peering session and whoops there goes your IBGP mesh... or all your other peerings, or, ... -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From w.d.clayton at gmail.com Mon Nov 16 19:25:55 2009 From: w.d.clayton at gmail.com (William C) Date: Mon, 16 Nov 2009 19:25:55 -0600 Subject: Bandwidth Monitoring per AS In-Reply-To: References: <20091116193710.f7262880@concur.batblue.com> Message-ID: <69069bc20911161725t68e1bcc0if241f7cd66866f0e@mail.gmail.com> Junipers let you configure multiple IP addresses on the same network as subinterfaces of a given physical interface. Seen a lot of this at places like GigExchange, making it easy to use simple things like MRTG to graph exactly this. On Mon, Nov 16, 2009 at 3:24 PM, Duman, Richard wrote: > Pretty Sure Arbor makes a good box. If you are looking for reporting and > auto-tweaking of your traffic, you can look at the Internap Flow Control box > as well. > > -----Original Message----- > From: Babak Pasdar [mailto:bpasdar at batblue.com] > Sent: Monday, November 16, 2009 2:37 PM > To: nanog at nanog.org > Subject: Bandwidth Monitoring per AS > > Could some of you share your recommendations on the best tools for > monitoring per AS communications. I would like to track all source AS to > Destination AS traffic utilization. > > Best Regards, > > Babak > > > -- > Babak Pasdar > President & CEO | Certified Ethical Hacker > Bat Blue Corporation | Integrity . Privacy . Availability > (p) 212.461.3322 x3005 | (f) 212.584.9999 | (w) www.BatBlue.com > > Receive Bat Blue's Daily Security Intelligence Report > Bat Blue's AS: 25885 | BGP Policy | Peering Policy > Bat Blue's Legal Notice > > Reducing IT Security Budget, Burden & Risk - Video | Article > > From leonardo.rizzi at gmail.com Mon Nov 16 19:47:22 2009 From: leonardo.rizzi at gmail.com (Leonardo Rizzi) Date: Tue, 17 Nov 2009 02:47:22 +0100 Subject: Fiber Cut in Italy In-Reply-To: <009801ca6706$84380910$8ca81b30$%varaillon@cosmoline.com> References: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> <0CCE589F-D86F-4644-BF56-6FCD90F4C0F9@lixfeld.ca> <012c01ca66de$f41e26b0$dc5a7410$%varaillon@cosmoline.com> <009801ca6706$84380910$8ca81b30$%varaillon@cosmoline.com> Message-ID: <4B0200AA.3010200@gmail.com> TI Sparkle just confirmed they are having a fault. Email from Telecom Italia Sparkle - Seabone NOC: Dear We have a big fault ( fiber cut) in france 2 cuts and one in milan. We are working to solve it asap. Regards ???????????????- Telecom Italia Sparkle SpA Customer Assistance/Assurance I? t Se at bone Network Operations Center Via M. Palocco, 223 ? Rome, IT Varaillon Jean Christophe wrote: > This is still ongoing (more than 6 hours now...), and nobody can give any > ETA. > > So if someone hear about something... > > Thank you > Jean-Christophe > -----Original Message----- > From: Varaillon Jean Christophe [mailto:varaillon at cosmoline.com] > Sent: Monday, November 16, 2009 7:05 PM > To: nanog at nanog.org > Subject: Fiber Cut in Italy > > Hi, > > It seems that there is a major fiber cut in Italy (not really near nanog, so > just in case...) > > I was just wondering if anybody has heard of any possible recovery time - as > there is none official one yet. > > Thank you, > > Jean-Christophe VARAILLON > ------------------------- > Data Network Engineer > Cosmoline - www.cosmoline.com > 40th km Attiki Odos > Rest Area Mesogea > 190 02 Peania, Greece > my: phone +30 212 212 2211 > my: cell +30 694 556 4826 > my: fax2mail +30 212 212 9905 > my: e-mail j.varaillon at cosmoline.com > > > ?????????? ?????????: ?? ??????????? ??? ??????????????? ??? ????? ????? > ????????????? ??? ???????????? ???????????? ???? ??? ????????? ??? > ?????????? ????????. ??? ?? ?????? ??? ????????? ??? ??????????? ??? ???, > ??? ?????????? ??? ??? ?????????? ??? ????? ???????? ?? ?? ??????????, > ???????????, ?????????? ? ??????????????? ?? ??????????? ?????. ??? > ??????????? ????? ?? ???????????? ?????? ??? ????????? ???? ?????????? > ??????? ??? ?????????? ? ?? ?????????? e-mail ??? ?? ???????????? ?? > ?????????. > > > IMPORTANT NOTICE: This email and any of its attachments are intended only > for the recipient(s) named above and are confidential and/or contain trade > secrets. Any unauthorized use, e.g. review, printing, copying or > distribution by other persons,is prohibited and may constitute a criminal > offence. If you have received this email in error, please notify the sender > immediately and delete the original message. > > > > __________ Information from ESET Smart Security, version of virus signature > database 4611 (20091116) __________ > > The message was checked by ESET Smart Security. > > http://www.eset.com > > > > __________ Information from ESET Smart Security, version of virus signature > database 4611 (20091116) __________ > > The message was checked by ESET Smart Security. > > http://www.eset.com > > > > __________ Information from ESET Smart Security, version of virus signature > database 4613 (20091116) __________ > > The message was checked by ESET Smart Security. > > http://www.eset.com > > From mysidia at gmail.com Mon Nov 16 20:07:31 2009 From: mysidia at gmail.com (James Hess) Date: Mon, 16 Nov 2009 20:07:31 -0600 Subject: AH is pretty useless and perhaps should be deprecated In-Reply-To: References: <4B00D9AF.8020202@bogus.com> <4B00EE79.701@bogus.com> Message-ID: <6eb799ab0911161807v152f964cre87fc28943bb07b@mail.gmail.com> On Mon, Nov 16, 2009 at 6:23 PM, Jack Kohn wrote: > However, i still dont understand why AH would be preferred over > ESP-NULL in case of OSPFv3. The draft speaks of issues with replaying > the OSPF packets. One could also do these things with AH. > Am i missing something? Neither protects against replay without additional measures. However, AH is very close... consider using AH-authenticated packets with the timestamp option and clock synchronization between peers. Discard packets arriving that are more than 5 minutes old. In transport mode for security between LAN peers, ESP NULL verifies the integrity of only the data payload in the packet. AH secures the header, the IP header fields and options. Therefore changing the timestamp to replay would be detected. This evil act would not be detected if you are using ESP NULL, the attacker can potentially replay this packet, while the SPI is still good, and you'll never know. One of AH's most visible disadvantages (cannot be used with NAT) is a side-effect of the increased security coverage it provides. Many IPv4 networks require NAT, making AH impractical. However, matters could change for IPv6 networks with high security requirements, that need to validate authenticity of more than just packet contents... -- -J From gdt at gdt.id.au Mon Nov 16 20:31:41 2009 From: gdt at gdt.id.au (Glen Turner) Date: Tue, 17 Nov 2009 13:01:41 +1030 Subject: What DNS Is Not In-Reply-To: <4AF83515.8040404@brightok.net> References: <4AF748B3.7060606@evaristesys.com> <4AF83515.8040404@brightok.net> Message-ID: <4B020B0D.401@gdt.id.au> On 10/11/09 01:58, Jack Bates wrote: > And different CDN's behave differently, depending on how they deliver > content, support provider interconnects, etc. I'd hardly call many of > them DNS lies, as they do resolve you to the appropriate IP, and if that > IP disappears, try and quickly get you to another appropriate IP. It depends what you mean by "appropriate". It may not be "least cost" or "closest", and that can be a rude shock when the CDN traffic suddenly costs you A$5/GB (delivered from the US by undersea cable) rather than $0 (delivered from an in-country peer). DNS is the wrong answer, simply because there's no way for the user to express *their* policy. But since there no CDN support in HTTP..... -- Glen Turner From smb at cs.columbia.edu Mon Nov 16 20:34:49 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 16 Nov 2009 21:34:49 -0500 Subject: AH is pretty useless and perhaps should be deprecated In-Reply-To: <6eb799ab0911161807v152f964cre87fc28943bb07b@mail.gmail.com> References: <4B00D9AF.8020202@bogus.com> <4B00EE79.701@bogus.com> <6eb799ab0911161807v152f964cre87fc28943bb07b@mail.gmail.com> Message-ID: <669955EE-9CE8-4D26-A4D4-1B5A4A270F1A@cs.columbia.edu> On Nov 16, 2009, at 9:07 PM, James Hess wrote: > On Mon, Nov 16, 2009 at 6:23 PM, Jack Kohn wrote: >> However, i still dont understand why AH would be preferred over >> ESP-NULL in case of OSPFv3. The draft speaks of issues with replaying >> the OSPF packets. One could also do these things with AH. >> Am i missing something? > > Neither protects against replay without additional measures. > However, AH is very close... consider using AH-authenticated > packets with the timestamp option and clock synchronization between > peers. > Discard packets arriving that are more than 5 minutes old. > > In transport mode for security between LAN peers, ESP NULL verifies > the integrity of only the data payload in the packet. AH secures > the header, the IP header fields and options. > > Therefore changing the timestamp to replay would be detected. > This evil act would not be detected if you are using ESP NULL, the > attacker can potentially replay this packet, while the SPI is still > good, and you'll never know. > > > > One of AH's most visible disadvantages (cannot be used with NAT) is a > side-effect of the increased security coverage it provides. Many IPv4 > networks require NAT, making AH impractical. > > However, matters could change for IPv6 networks with high > security requirements, that need to validate authenticity of more > than just packet contents... > Except for multicast packets -- the case of interest for OSPFv3, and even there the spec arguably got it wrong -- you can check the source IP address against the SPD. That is, you can't replay my ESP packets in a unicast connection with a different source address because packets from your source address on my SPI will be rejected. ESP does have antireplay protection; admittedly, that's disabled if manual keying is used, but generally speaking, manual keying shouldn't be used, per RFC 4107. The interesting case is multicast. 4552 seems to assume symmetric keys, but that's a bad idea; it lets other members of the authorized group impersonate each other. What you really want is digitally signed packets, where each source has a key. I don't think that the IETF's multicast key management protocols are quite up to the job, though; they focus on single source multicast, which isn't what OSPF needs. (That said, 5374 seems to point in the proper direction, but I haven't been following this work.) It may be that the proper answer for OSPFv3 is its own strong multicast security. --Steve Bellovin, http://www.cs.columbia.edu/~smb From brandon.galbraith at gmail.com Mon Nov 16 20:46:09 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Mon, 16 Nov 2009 20:46:09 -0600 Subject: What DNS Is Not In-Reply-To: <4B020B0D.401@gdt.id.au> References: <4AF748B3.7060606@evaristesys.com> <4AF83515.8040404@brightok.net> <4B020B0D.401@gdt.id.au> Message-ID: <366100670911161846r4df5eb88j4db61c01ef653e69@mail.gmail.com> Maybe Google needs to incorporate some level of CDN support into their SPDY layer... Better than DNS I would think. -brandon On 11/16/09, Glen Turner wrote: > On 10/11/09 01:58, Jack Bates wrote: >> And different CDN's behave differently, depending on how they deliver >> content, support provider interconnects, etc. I'd hardly call many of >> them DNS lies, as they do resolve you to the appropriate IP, and if that >> IP disappears, try and quickly get you to another appropriate IP. > > It depends what you mean by "appropriate". It may not be "least cost" > or "closest", and that can be a rude shock when the CDN traffic suddenly > costs you A$5/GB (delivered from the US by undersea cable) rather than > $0 (delivered from an in-country peer). > > DNS is the wrong answer, simply because there's no way for the user to > express *their* policy. But since there no CDN support in HTTP..... > > -- > Glen Turner > > -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From thegameiam at yahoo.com Mon Nov 16 21:10:04 2009 From: thegameiam at yahoo.com (David Barak) Date: Mon, 16 Nov 2009 19:10:04 -0800 (PST) Subject: AH is pretty useless and perhaps should be deprecated In-Reply-To: <6eb799ab0911161807v152f964cre87fc28943bb07b@mail.gmail.com> Message-ID: <523622.60728.qm@web31804.mail.mud.yahoo.com> +1. I know of a network whose owners are far more worried about a replay attack than about data being revealed to the outside world. They need to verify the provenance of data (i. e. Make sure that it hasn't bee Natted), and AH is a simple way to do these precise things. -David Barak James Hess wrote: > On Mon, Nov 16, 2009 at 6:23 PM, Jack Kohn wrote: >> However, i still dont understand why AH would be preferred over >> ESP-NULL in case of OSPFv3. The draft speaks of issues with replaying >> the OSPF packets. One could also do these things with AH. >> Am i missing something? > Neither protects against replay without additional measures. > However, AH is very close... consider using AH-authenticated > packets with the timestamp option and clock synchronization between > peers. > Discard packets arriving that are more than 5 minutes old. > In transport mode for security between LAN peers, ESP NULL verifies > the integrity of only the data payload in the packet. AH secures > the header, the IP header fields and options. > Therefore changing the timestamp to replay would be detected. > This evil act would not be detected if you are using ESP NULL, the > attacker can potentially replay this packet, while the SPI is still > good, and you'll never know. > One of AH's most visible disadvantages (cannot be used with NAT) is a > side-effect of the increased security coverage it provides. Many IPv4 > networks require NAT, making AH impractical. > However, matters could change for IPv6 networks with high > security requirements, that need to validate authenticity of more > than just packet contents... > -- > -J From randy at psg.com Mon Nov 16 22:04:11 2009 From: randy at psg.com (Randy Bush) Date: Tue, 17 Nov 2009 13:04:11 +0900 Subject: Juniper M120 Alternatives In-Reply-To: <20091117002806.GA302@srv03.cluenet.de> References: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> <443de7ad0911160808oee8f9cfo70e3391f36b054f2@mail.gmail.com> <29152.82.132.136.147.1258388092.squirrel@webmail-vh.tagadab.com> <4B01862E.8090101@linpro.no> <20091117002806.GA302@srv03.cluenet.de> Message-ID: > PS: and of course JUNOS still undeterministically resetting unrelated BGP > sessions for no good reason when modifying BGP configuration cisco is deterministic. breathe on it and all sessions reset. randy From jbates at brightok.net Mon Nov 16 22:11:09 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 16 Nov 2009 22:11:09 -0600 Subject: What DNS Is Not In-Reply-To: <4B020B0D.401@gdt.id.au> References: <4AF748B3.7060606@evaristesys.com> <4AF83515.8040404@brightok.net> <4B020B0D.401@gdt.id.au> Message-ID: <4B02225D.9040904@brightok.net> Glen Turner wrote: > It depends what you mean by "appropriate". It may not be "least cost" > or "closest", and that can be a rude shock when the CDN traffic suddenly > costs you A$5/GB (delivered from the US by undersea cable) rather than > $0 (delivered from an in-country peer). > In some cases this may be true. However, many of the CDN's I've talked to will happily update which POP my network talks to. Is automatic detection perfect? Probably not. That is why they support manual correction. Their goal is to get you the best connectivity, and they usually don't have a problem, in my experience, working with a provider to ensure the right IP ranges go to the best POP. > DNS is the wrong answer, simply because there's no way for the user to > express *their* policy. But since there no CDN support in HTTP..... > See above. It appears I have no problem expressing my policy to CDN's. Corporate world often uses views to express external and internal policy. Unfortunately, it's not that easy for the CDN, so they do the best that they can, and they correct when it's important enough for a provider to say "hey, this pop isn't the best for my network!" Jack From ddunkin at netos.net Mon Nov 16 22:27:38 2009 From: ddunkin at netos.net (Darryl Dunkin) Date: Mon, 16 Nov 2009 20:27:38 -0800 Subject: Bandwidth Monitoring per AS In-Reply-To: <005401ca66f8$1281f5f0$3785e1d0$@net> References: <20091116193710.f7262880@concur.batblue.com> <005401ca66f8$1281f5f0$3785e1d0$@net> Message-ID: <56F5BC5F404CF84896C447397A1AAF2001670312@MAIL.nosi.netos.com> A free Netflow option is CUFlow, you can graph via AS/network/protocol. http://www.columbia.edu/acis/networks/advanced/CUFlow It is a bit outdated, but gets the job done here, as these details are not mission critical for me. -----Original Message----- From: Stefan Fouant [mailto:sfouant at shortestpathfirst.net] Sent: Monday, November 16, 2009 12:05 To: 'Babak Pasdar'; nanog at nanog.org Subject: RE: Bandwidth Monitoring per AS > -----Original Message----- > From: Babak Pasdar [mailto:bpasdar at batblue.com] > Sent: Monday, November 16, 2009 2:37 PM > > Could some of you share your recommendations on the best tools for > monitoring per AS communications. I would like to track all source AS > to Destination AS traffic utilization. Depending on your price range, you might want to take a look at Arbor's Peakflow SP. There is some pretty top notch traffic and routing analysis tools in their package. Regards, Stefan Fouant GPG Key ID: 0xB5E3803D From ras at e-gerbil.net Mon Nov 16 22:46:24 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Mon, 16 Nov 2009 22:46:24 -0600 Subject: Juniper M120 Alternatives In-Reply-To: <20091117002806.GA302@srv03.cluenet.de> References: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> <443de7ad0911160808oee8f9cfo70e3391f36b054f2@mail.gmail.com> <29152.82.132.136.147.1258388092.squirrel@webmail-vh.tagadab.com> <4B01862E.8090101@linpro.no> <20091117002806.GA302@srv03.cluenet.de> Message-ID: <20091117044624.GB51443@gerbil.cluepon.net> On Tue, Nov 17, 2009 at 01:28:06AM +0100, Daniel Roesen wrote: > PS: and of course JUNOS still undeterministically resetting unrelated > BGP sessions for no good reason when modifying BGP configuration - so > one is well-advised to do ANY configuration changes in the area of BGP > within a maint window as it might happen that you configure a peering > session and whoops there goes your IBGP mesh... or all your other > peerings, or, ... Well to be fair, the session resetting on config change behavior is actually quite deterministic (being EASY to determine is not part of the requirements, technically speaking :P), and most of the resets really do have perfectly good reasons. I'll certainly go with "really annoying and often a giant pain in the @#$%^&*" though. They've definitely been improving it over the years though, so much that I almost never trigger a session reset on me unintentionally any more. The things to watch out for are: a) any time you change the update replication by moving a neighbor between groups, renaming groups, or significantly changing the export policy chain. b) any time you change a major part of the underlying interface configuration for an eBGP session, such as mtu or vlan tagging config. c) any time you change something about the bgp session which really does require a session reset to take effect, such as a new ASN, new endpoint address, new mbgp family configuration, new md5 password, new tcp mss, etc. You can actually safeguard yourself from a lot of the accidental reset behaviors while implementing other features at the same time by using commit scripts (i.e. as a side-effect of my scripts which exist for other reasons, I automatically protect myself against changes to the policy chain or family configuration which might cause unintended session flaps), though I'll certainly admit this is well into the category of "power user" and not appropriate for most people. They are making some progress though, you can actually turn NSR on and off now without flapping your sessions, which is certainly an improvement over the serious logic flaws in earlier versions (where you couldn't turn off NSR without flapping every session, but you also couldn't commit w/NSR enabled and the backup RE offline, effectively locking you out of config changes without a total box flap if you didn't have both RE's running). It would certainly be a lot more user friendly if they could tell you what sessions would be reset as part of a "commit check" process though. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From hank at efes.iucc.ac.il Mon Nov 16 23:25:09 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 17 Nov 2009 07:25:09 +0200 (IST) Subject: Fiber Cut in Italy In-Reply-To: <009801ca6706$84380910$8ca81b30$%varaillon@cosmoline.com> References: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> <0CCE589F-D86F-4644-BF56-6FCD90F4C0F9@lixfeld.ca> <012c01ca66de$f41e26b0$dc5a7410$%varaillon@cosmoline.com> <009801ca6706$84380910$8ca81b30$%varaillon@cosmoline.com> Message-ID: On Mon, 16 Nov 2009, Varaillon Jean Christophe wrote: We have observed restoration around 1:30am (gmt+2). About 9 hours of outage. -Hank > This is still ongoing (more than 6 hours now...), and nobody can give any > ETA. > > So if someone hear about something... > > Thank you > Jean-Christophe > -----Original Message----- > From: Varaillon Jean Christophe [mailto:varaillon at cosmoline.com] > Sent: Monday, November 16, 2009 7:05 PM > To: nanog at nanog.org > Subject: Fiber Cut in Italy > > Hi, > > It seems that there is a major fiber cut in Italy (not really near nanog, so > just in case...) > > I was just wondering if anybody has heard of any possible recovery time - as > there is none official one yet. > > Thank you, > > Jean-Christophe VARAILLON > ------------------------- > Data Network Engineer > Cosmoline - www.cosmoline.com > 40th km Attiki Odos > Rest Area Mesogea > 190 02 Peania,?Greece > my: phone???? +30 212 212 2211 > my: cell??????+30 694 556 4826 > my: fax2mail? +30 212 212 9905 > my: e-mail? ??j.varaillon at cosmoline.com > > > ?????????? ?????????: ?? ??????????? ??? ??????????????? ??? ????? ????? > ????????????? ??? ???????????? ???????????? ???? ??? ????????? ??? > ?????????? ????????. ??? ?? ?????? ??? ????????? ??? ??????????? ??? ???, > ??? ?????????? ??? ??? ?????????? ??? ????? ???????? ?? ?? ??????????, > ???????????, ?????????? ? ??????????????? ?? ??????????? ?????. ??? > ??????????? ????? ?? ???????????? ?????? ??? ????????? ???? ?????????? > ??????? ??? ?????????? ? ?? ?????????? e-mail ??? ?? ???????????? ?? > ?????????. > > > IMPORTANT NOTICE: This email and any of its attachments are intended only > for the recipient(s) named above and are confidential and/or contain trade > secrets. Any unauthorized use, e.g. review, printing, copying or > distribution by other persons,is prohibited and may constitute a criminal > offence. If you have received this email in error, please notify the sender > immediately and delete the original message. > > > > __________ Information from ESET Smart Security, version of virus signature > database 4611 (20091116) __________ > > The message was checked by ESET Smart Security. > > http://www.eset.com > > > > __________ Information from ESET Smart Security, version of virus signature > database 4611 (20091116) __________ > > The message was checked by ESET Smart Security. > > http://www.eset.com > > > > __________ Information from ESET Smart Security, version of virus signature > database 4613 (20091116) __________ > > The message was checked by ESET Smart Security. > > http://www.eset.com > > From jbates at brightok.net Tue Nov 17 09:24:24 2009 From: jbates at brightok.net (Jack Bates) Date: Tue, 17 Nov 2009 09:24:24 -0600 Subject: Juniper M120 Alternatives In-Reply-To: <20091117044624.GB51443@gerbil.cluepon.net> References: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> <443de7ad0911160808oee8f9cfo70e3391f36b054f2@mail.gmail.com> <29152.82.132.136.147.1258388092.squirrel@webmail-vh.tagadab.com> <4B01862E.8090101@linpro.no> <20091117002806.GA302@srv03.cluenet.de> <20091117044624.GB51443@gerbil.cluepon.net> Message-ID: <4B02C028.5060109@brightok.net> Richard A Steenbergen wrote: > They've definitely been improving it over the years though, so much that > I almost never trigger a session reset on me unintentionally any more. They must have. This was new to me and came as a shock. I don't think I've ever seen my m120 behave any different than my cisco when it comes to flapping BGP. Things have just worked as I expected them to. Not that I go screwing with underlying interface configs or changing a peer from one group to another or changing the asn; at least not on a live session. These things would seem to indicate that the session might be subject to reset. Perhaps it just behaves for normal users and not power users. :) Jack From jloiacon at csc.com Tue Nov 17 09:27:14 2009 From: jloiacon at csc.com (Joe Loiacono) Date: Tue, 17 Nov 2009 10:27:14 -0500 Subject: Bandwidth Monitoring per AS In-Reply-To: <20091116193710.f7262880@concur.batblue.com> References: <20091116193710.f7262880@concur.batblue.com> Message-ID: "Babak Pasdar" wrote on 11/16/2009 02:37:10 PM: > Could some of you share your recommendations on the best tools for > monitoring per AS communications. I would like to track all source > AS to Destination AS traffic utilization. Another netflow open-source solution is flow-tools/FlowViewer. Here you can track traffic to or from an individual, or combination of ASes, over time via RRDtool graphs. Other fine-tune filtering is available as well. http://ensight.eos.nasa.gov/FlowViewer Joe From pl+list at pmacct.net Tue Nov 17 10:10:29 2009 From: pl+list at pmacct.net (Paolo Lucente) Date: Tue, 17 Nov 2009 16:10:29 +0000 Subject: Juniper M120 Alternatives In-Reply-To: <20091117002806.GA302@srv03.cluenet.de> References: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> <443de7ad0911160808oee8f9cfo70e3391f36b054f2@mail.gmail.com> <29152.82.132.136.147.1258388092.squirrel@webmail-vh.tagadab.com> <4B01862E.8090101@linpro.no> <20091117002806.GA302@srv03.cluenet.de> Message-ID: <20091117161029.GA18002@moussaka.pmacct.net> On Tue, Nov 17, 2009 at 01:28:06AM +0100, Daniel Roesen wrote: > Caveat: no MAC accounting on LAGs (IEEE speak) / Aggregated Ethernet (Juniper > speak) / Etherchannels (Cisco speak). > > Might or might not be important when using bundled links to public > peering fabrics. Or for the very same goal, vendors can maybe think at making support for L2 primitives via NetFlow v9 exports somewhat more implemented. Cheers, Paolo From maxsec at gmail.com Tue Nov 17 10:30:48 2009 From: maxsec at gmail.com (Martin Hepworth) Date: Tue, 17 Nov 2009 16:30:48 +0000 Subject: edgedirector.com Message-ID: <72cf361e0911170830j359652f7k93103d5b91e59374@mail.gmail.com> Any one got any comments about edgedirector.com's service(s), esp wrt to load balancing, geo-ip stuff etc. They seem to be way way cheaper than ultradns, esp when you adding in geo-ip load sharing and such. So is there wnay reason WHY its cheaper? -- Martin Hepworth Oxford, UK From jeffrey.lyon at blacklotus.net Tue Nov 17 11:23:33 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 17 Nov 2009 12:23:33 -0500 Subject: edgedirector.com In-Reply-To: <72cf361e0911170830j359652f7k93103d5b91e59374@mail.gmail.com> References: <72cf361e0911170830j359652f7k93103d5b91e59374@mail.gmail.com> Message-ID: <16720fe00911170923x2d81de68o9905ddb7ce662ffe@mail.gmail.com> You really can't compare EdgeDirector's network to UltraDNS which is much larger and more resilient by leaps and bounds. I've spoke with the owner of ED before and decided against using the service. Right now we're using Afilias and the price isn't much worse, the GUI is much nicer, and the network is much larger and more redundant. We recently walked out on an UltraDNS contract due to deceptive billing practices. They're a corrupt company, imho. Jeff On Tue, Nov 17, 2009 at 11:30 AM, Martin Hepworth wrote: > Any one got any comments about edgedirector.com's service(s), esp wrt to > load balancing, geo-ip stuff etc. > > They seem to be way way cheaper than ultradns, esp when you adding in geo-ip > load sharing and such. So is there wnay reason WHY its cheaper? > > -- > Martin Hepworth > Oxford, UK > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From ras at e-gerbil.net Tue Nov 17 11:32:47 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Tue, 17 Nov 2009 11:32:47 -0600 Subject: Juniper M120 Alternatives In-Reply-To: <4B02C028.5060109@brightok.net> References: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> <443de7ad0911160808oee8f9cfo70e3391f36b054f2@mail.gmail.com> <29152.82.132.136.147.1258388092.squirrel@webmail-vh.tagadab.com> <4B01862E.8090101@linpro.no> <20091117002806.GA302@srv03.cluenet.de> <20091117044624.GB51443@gerbil.cluepon.net> <4B02C028.5060109@brightok.net> Message-ID: <20091117173246.GE51443@gerbil.cluepon.net> On Tue, Nov 17, 2009 at 09:24:24AM -0600, Jack Bates wrote: > Richard A Steenbergen wrote: > >They've definitely been improving it over the years though, so much that > >I almost never trigger a session reset on me unintentionally any more. > > They must have. This was new to me and came as a shock. I don't think > I've ever seen my m120 behave any different than my cisco when it comes > to flapping BGP. Things have just worked as I expected them to. Not that > I go screwing with underlying interface configs or changing a peer from > one group to another or changing the asn; at least not on a live > session. These things would seem to indicate that the session might be > subject to reset. > > Perhaps it just behaves for normal users and not power users. :) But those things won't trigger session resets on Cisco, so it often comes as a shock. Also, one might very well expect that changing the peer-as on a neighbor is going to cause a reset, but if you didn't know from experience you might not expect that renaming a group or changing an underlying interface MTU would do it too. The issue is that there is a fundamental design difference between Cisco and Juniper. Cisco lets you configure anything you want in a line by line basis, but it doesn't immediately apply those changes until you command it to do so. Juniper's philosophy is that you make a bunch of changes to a candiate configuration, "commit" to apply those changes, and then you can expect those changes to take effect (or at least begin trying to take effect) immediately. Personally I think the Juniper design philosophy is "better". Besides the obvious stuff like being able to rollback your config, think about how non-deterministic it is when you update a route-map but forget to soft clear the BGP session. The routes that have been exchanged so far will retain their old policy, while any new updates you receive after the route-map change will receive the new policy, leaving the session in an inconsistent state that will slowly and unpredictably change over time as routing updates come in. The trade-off is that you lose the ability to do non-impacting changes, where you make a change but know that it hasn't actually taken effect yet, and won't until the next time the session bounces. What Juniper is trying to do really is a good thing, I just wish it could tell me before I commit what is and isn't going to flap. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From Mauricio.Rodriguez at fpl.com Tue Nov 17 12:07:44 2009 From: Mauricio.Rodriguez at fpl.com (Rodriguez, Mauricio) Date: Tue, 17 Nov 2009 13:07:44 -0500 Subject: Bandwidth Monitoring per AS Message-ID: <611085D375448C4D99BAF870659DEAC403C7A4D4EB@GOXEXVS03.fplu.fpl.com> Sure, Rick. Maybe they can buy ours off of us!! ;-) Regards, Mauricio Rodriguez Manager of IP/Data Engineering, FPL FiberNet Email: Mauricio.Rodriguez at fpl.com Office: 305-552-3418 Mobile: 786-236-2665 Pager: 786-236-2665 From Mauricio.Rodriguez at fpl.com Tue Nov 17 12:22:50 2009 From: Mauricio.Rodriguez at fpl.com (Rodriguez, Mauricio) Date: Tue, 17 Nov 2009 13:22:50 -0500 Subject: Bandwidth Monitoring per AS In-Reply-To: <108B09B7A61C02459F37D1A54E824A026A889B4CDB@GOXEXVS03.fplu.fpl.com> References: <108B09B7A61C02459F37D1A54E824A026A889B4CDB@GOXEXVS03.fplu.fpl.com> Message-ID: <611085D375448C4D99BAF870659DEAC403C7A4D4F7@GOXEXVS03.fplu.fpl.com> Apologies -- That was supposed to be addressed to Rick only... However, the truth is that we have outgrown our FCP. YMMV with the product... From: Rodriguez, Mauricio Sent: Tuesday, November 17, 2009 1:08 PM To: nanog at nanog.org Subject: Bandwidth Monitoring per AS Sure, Rick. Maybe they can buy ours off of us!! ;-) Regards, Mauricio Rodriguez Manager of IP/Data Engineering, FPL FiberNet Email: Mauricio.Rodriguez at fpl.com Office: 305-552-3418 Mobile: 786-236-2665 Pager: 786-236-2665 From jeffrey.lyon at blacklotus.net Tue Nov 17 12:32:50 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 17 Nov 2009 13:32:50 -0500 Subject: Mauricio's FCP (was: Bandwidth Monitoring per AS) Message-ID: <16720fe00911171032kb58aafdy1eb809318ff0199a@mail.gmail.com> > However, the truth is that we have outgrown our FCP. ?YMMV with the product... Why is that? What particular problems did you run into? -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From peter.hicks at poggs.co.uk Tue Nov 17 13:09:22 2009 From: peter.hicks at poggs.co.uk (Peter Hicks) Date: Tue, 17 Nov 2009 19:09:22 +0000 Subject: What happened to Quick Eagle? Message-ID: <4B02F4E2.6000100@poggs.co.uk> All, I have a Quick Eagle DL087E here, but Quick Eagle's website has fallen off the planet: pwh at angel:~$ host -t any www.quickeagle.com Host www.quickeagle.com not found: 3(NXDOMAIN) Can anyone help me out with a firmware update and/or PDF manuals? It's been a little while since I had to use one of these. Cheers Peter From Mauricio.Rodriguez at fpl.com Tue Nov 17 13:28:11 2009 From: Mauricio.Rodriguez at fpl.com (Rodriguez, Mauricio) Date: Tue, 17 Nov 2009 14:28:11 -0500 Subject: Mauricio's FCP (was: Bandwidth Monitoring per AS) In-Reply-To: <16720fe00911171032kb58aafdy1eb809318ff0199a@mail.gmail.com> References: <16720fe00911171032kb58aafdy1eb809318ff0199a@mail.gmail.com> Message-ID: <611085D375448C4D99BAF870659DEAC403C7A4D515@GOXEXVS03.fplu.fpl.com> Since I've opened the can of worms... The FCP integration requires direct capturing of traffic off of your network. This would either be a off of a port mirror or off of network taps. We had some challenges, basically because of our architecture, implementing the solution at first. We had a rather collapsed network with service access and peering in the same router in some cases. Also, our routers were not capable of mirroring traffic at L2. Including any geographically diverse peering sites may be challenging. Options include another FCP, an FCR (remote packet capture device), or transporting the mirrored/tapped traffic back to the FCP location. I believe sampled flow data may have been an option, but was not a recommended approach. The preferred method of enabling communication between the FCP and peering routers for routing manipulation is to create GRE tunnels between those. Our routers did not support GRE as a base option or at all (multiple vendors/models). Other options are available that we did not explore fully. We have since "cleaned up" our architecture, but are also growing to a much larger number of ports and to 10Gbps. Also, we'd like to have more insight into traffic between our various service PoPs and not just at our transit/private peering edges. Significant hardware investment would be required to scale to this level. All that being said, the Internap Implementation team was very helpful and patient throughout. If you do go with this solution, you'll have a good set of allies at Internap helping you throughout the project. Regards, Mauricio Rodriguez Manager of IP/Data Engineering, FPL FiberNet Email: Mauricio.Rodriguez at fpl.com -----Original Message----- From: jeffrey.lyon at gmail.com [mailto:jeffrey.lyon at gmail.com] On Behalf Of Jeffrey Lyon Sent: Tuesday, November 17, 2009 1:33 PM To: Rodriguez, Mauricio Cc: nanog at nanog.org Subject: Mauricio's FCP (was: Bandwidth Monitoring per AS) > However, the truth is that we have outgrown our FCP. ?YMMV with the product... Why is that? What particular problems did you run into? -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From msa at latt.net Tue Nov 17 13:49:47 2009 From: msa at latt.net (Majdi S. Abbas) Date: Tue, 17 Nov 2009 12:49:47 -0700 Subject: What happened to Quick Eagle? In-Reply-To: <4B02F4E2.6000100@poggs.co.uk> References: <4B02F4E2.6000100@poggs.co.uk> Message-ID: <20091117194947.GA33131@puck.nether.net> On Tue, Nov 17, 2009 at 07:09:22PM +0000, Peter Hicks wrote: > I have a Quick Eagle DL087E here, but Quick Eagle's website has > fallen off the planet: > > pwh at angel:~$ host -t any www.quickeagle.com > Host www.quickeagle.com not found: 3(NXDOMAIN) Their phones go to a reorder too. I'm guessing the T1 DSU market is not as robust as it used to be. > Can anyone help me out with a firmware update and/or PDF manuals? While they did have an update mechanism, I don't remember ever really having to update the code on a DL08x. Once configured, they tended to just work. I did manage to find these: http://cliffbrooks.com/Samples/soloselectt1_qwk.pdf http://www.interlinkweb.com/quickeagle/manuals%5CPrelude-T1-Quick-Start-Guide.pdf (Your best bet is probably looking for DL087, followed by DL080 or "Digital Link" on Google, with the filetype:pdf modifier.) > It's been a little while since I had to use one of these. The menued interface is really easy to deal with, so just get consoled into it and go -- odds are you don't even need the docs. DIP switch guide used to be on a decal on the bottom -- if not, it's on page 19 of the first PDF I linked above. I used to have a very large quantity of these in service, so if you have any questions, fire me an email off-list and I'll see if I can remember the answer. --msa From leslien at arin.net Tue Nov 17 15:53:15 2009 From: leslien at arin.net (Leslie Nobile) Date: Tue, 17 Nov 2009 16:53:15 -0500 Subject: APNIC to issue from 175 /8 and 182 /8 soon Message-ID: Forwarding at the request of APNIC... From: Secretariat Reply-To: "secretariat at apnic.net" , Secretariat Date: Sun, 15 Nov 2009 23:31:42 -0500 To: APNIC-announce Subject: [Apnic-announce] APNIC to make allocations from 175/8 and 182/8 soon _______________________________________________________________________ APNIC to make allocations from 175/8 and 182/8 soon _______________________________________________________________________ Dear colleagues, In August 2009, APNIC received two IPv4 address blocks from IANA. These were: - 175/8 - 182/8 Reachability and routability testing is now complete and exceeds 96% for all prefixes. APNIC will soon be allocating from these prefixes. Please update your routing filters and network configurations accordingly. Please also double-check and release any blacklisted IP addresses from the above ranges, as they now represent fresh /8 blocks. Thank you for your cooperation. If you have any questions, please contact the APNIC helpdesk: helpdesk at apnic.net Sincerely, -- APNIC Helpdesk helpdesk at apnic.net Asia Pacific Network Information Centre (APNIC) Tel: +61 7 3858 3188 PO Box 2131 Milton, QLD 4064 Australia Fax: +61 7 3858 3199 Level 1, 33 Park Road, Milton, QLD http://www.apnic.net ________________________________________________________________________ * Sent by email to save paper. Print only if necessary. _______________________________________________ Apnic-announce mailing list Apnic-announce at lists.apnic.net http://mailman.apnic.net/mailman/listinfo/apnic-announce From brwatters at absfoc.com Tue Nov 17 19:50:11 2009 From: brwatters at absfoc.com (brwatters at absfoc.com) Date: Tue, 17 Nov 2009 17:50:11 -0800 (PST) Subject: APNIC to issue from 175 /8 and 182 /8 soon Message-ID: <27316649.537.1258509011641.JavaMail.root@mail.absfoc.com> The following is a new meeting request: Subject: APNIC to issue from 175 /8 and 182 /8 soon Organizer: "Brian R. Watters" Time: Thursday, November 19, 2009, 11:00:00 AM - 12:00:00 PM GMT -08:00 US/Canada Pacific Invitees: "Leslie Nobile" ; "nanog" *~*~*~*~*~*~*~*~*~* Forwarding at the request of APNIC... From: Secretariat Reply-To: "secretariat at apnic.net" , Secretariat Date: Sun, 15 Nov 2009 23:31:42 -0500 To: APNIC-announce Subject: [Apnic-announce] APNIC to make allocations from 175/8 and 182/8 soon _______________________________________________________________________ APNIC to make allocations from 175/8 and 182/8 soon _______________________________________________________________________ Dear colleagues, In August 2009, APNIC received two IPv4 address blocks from IANA. These were: - 175/8 - 182/8 Reachability and routability testing is now complete and exceeds 96% for all prefixes. APNIC will soon be allocating from these prefixes. Please update your routing filters and network configurations accordingly. Please also double-check and release any blacklisted IP addresses from the above ranges, as they now represent fresh /8 blocks. Thank you for your cooperation. If you have any questions, please contact the APNIC helpdesk: helpdesk at apnic.net Sincerely, -- APNIC Helpdesk helpdesk at apnic.net Asia Pacific Network Information Centre (APNIC) Tel: +61 7 3858 3188 PO Box 2131 Milton, QLD 4064 Australia Fax: +61 7 3858 3199 Level 1, 33 Park Road, Milton, QLD http://www.apnic.net ________________________________________________________________________ * Sent by email to save paper. Print only if necessary. _______________________________________________ Apnic-announce mailing list Apnic-announce at lists.apnic.net http://mailman.apnic.net/mailman/listinfo/apnic-announce From joe at via.net Tue Nov 17 20:59:00 2009 From: joe at via.net (joe mcguckin) Date: Tue, 17 Nov 2009 18:59:00 -0800 Subject: What happened to Quick Eagle? In-Reply-To: <20091117194947.GA33131@puck.nether.net> References: <4B02F4E2.6000100@poggs.co.uk> <20091117194947.GA33131@puck.nether.net> Message-ID: The last time I drove by their office, it looked deserted - like they had closed down. Joe McGuckin ViaNet Communications joe at via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax On Nov 17, 2009, at 11:49 AM, Majdi S. Abbas wrote: > On Tue, Nov 17, 2009 at 07:09:22PM +0000, Peter Hicks wrote: >> I have a Quick Eagle DL087E here, but Quick Eagle's website has >> fallen off the planet: >> >> pwh at angel:~$ host -t any www.quickeagle.com >> Host www.quickeagle.com not found: 3(NXDOMAIN) > > Their phones go to a reorder too. I'm guessing the T1 DSU > market is not as robust as it used to be. > >> Can anyone help me out with a firmware update and/or PDF manuals? > > While they did have an update mechanism, I don't remember > ever really having to update the code on a DL08x. Once configured, > they tended to just work. > > I did manage to find these: > > http://cliffbrooks.com/Samples/soloselectt1_qwk.pdf > http://www.interlinkweb.com/quickeagle/manuals%5CPrelude-T1-Quick-Start-Guide.pdf > > (Your best bet is probably looking for DL087, followed by DL080 or > "Digital Link" on Google, with the filetype:pdf modifier.) > >> It's been a little while since I had to use one of these. > > The menued interface is really easy to deal with, so just get > consoled into it and go -- odds are you don't even need the docs. DIP > switch guide used to be on a decal on the bottom -- if not, it's on > page > 19 of the first PDF I linked above. > > I used to have a very large quantity of these in service, so if > you have any questions, fire me an email off-list and I'll see if I > can > remember the answer. > > --msa From skirk at godaddy.com Tue Nov 17 22:24:54 2009 From: skirk at godaddy.com (Stuart Kirk) Date: Tue, 17 Nov 2009 21:24:54 -0700 Subject: SBC/AT&T Contact Message-ID: <20091117212454.793bd257d3564d371c65df57e70810a7.bf94eb89b3.wbe@email.secureserver.net> Is anybody experiencing any issues with customer traffic originating from either of these carriers? If anybody from SBC or AT&T can contact me off-list I would appreciate it. Thank you. --Stuart From frnkblk at iname.com Tue Nov 17 22:28:17 2009 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 17 Nov 2009 22:28:17 -0600 Subject: SBC/AT&T Contact In-Reply-To: <20091117212454.793bd257d3564d371c65df57e70810a7.bf94eb89b3.wbe@email.secureserver.net> References: <20091117212454.793bd257d3564d371c65df57e70810a7.bf94eb89b3.wbe@email.secureserver.net> Message-ID: Not personally, but it's being documented here: http://www.internetpulse.net/ Frank -----Original Message----- From: Stuart Kirk [mailto:skirk at godaddy.com] Sent: Tuesday, November 17, 2009 10:25 PM To: nanog at nanog.org Subject: SBC/AT&T Contact Is anybody experiencing any issues with customer traffic originating from either of these carriers? If anybody from SBC or AT&T can contact me off-list I would appreciate it. Thank you. --Stuart From martin at theicelandguy.com Tue Nov 17 22:54:24 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Tue, 17 Nov 2009 23:54:24 -0500 Subject: APNIC to issue from 175 /8 and 182 /8 soon In-Reply-To: <27316649.537.1258509011641.JavaMail.root@mail.absfoc.com> References: <27316649.537.1258509011641.JavaMail.root@mail.absfoc.com> Message-ID: I'm available, but you didn't put a bridge number in. Best, -M< On Tue, Nov 17, 2009 at 8:50 PM, wrote: > The following is a new meeting request: > > Subject: APNIC to issue from 175 /8 and 182 /8 soon > Organizer: "Brian R. Watters" > > Time: Thursday, November 19, 2009, 11:00:00 AM - 12:00:00 PM GMT -08:00 > US/Canada Pacific > > Invitees: "Leslie Nobile" ; "nanog" > > *~*~*~*~*~*~*~*~*~* > > Forwarding at the request of APNIC... > > > From: Secretariat > Reply-To: "secretariat at apnic.net" , Secretariat < > apnic-no-reply at apnic.net> > Date: Sun, 15 Nov 2009 23:31:42 -0500 > To: APNIC-announce > Subject: [Apnic-announce] APNIC to make allocations from 175/8 and 182/8 > soon > > _______________________________________________________________________ > > APNIC to make allocations from 175/8 and 182/8 soon > _______________________________________________________________________ > > > Dear colleagues, > > In August 2009, APNIC received two IPv4 address blocks from IANA. These > were: > > - 175/8 > - 182/8 > > Reachability and routability testing is now complete and exceeds 96% for > all prefixes. > > APNIC will soon be allocating from these prefixes. > > Please update your routing filters and network configurations > accordingly. > > Please also double-check and release any blacklisted IP addresses from > the above ranges, as they now represent fresh /8 blocks. > > Thank you for your cooperation. If you have any questions, please > contact the APNIC helpdesk: > > helpdesk at apnic.net > > Sincerely, > > -- > APNIC Helpdesk helpdesk at apnic.net > Asia Pacific Network Information Centre (APNIC) Tel: +61 7 3858 3188 > PO Box 2131 Milton, QLD 4064 Australia Fax: +61 7 3858 3199 > Level 1, 33 Park Road, Milton, QLD http://www.apnic.net > ________________________________________________________________________ > * Sent by email to save paper. Print only if necessary. > _______________________________________________ > Apnic-announce mailing list > Apnic-announce at lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/apnic-announce > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From aaronh at bind.com Tue Nov 17 23:00:28 2009 From: aaronh at bind.com (Aaron Hughes) Date: Tue, 17 Nov 2009 21:00:28 -0800 Subject: SBC/AT&T Contact In-Reply-To: References: <20091117212454.793bd257d3564d371c65df57e70810a7.bf94eb89b3.wbe@email.secureserver.net> Message-ID: <20091118050028.GD91582@trace.bind.com> I can confirm serious problems reaching at&t DSL customers. The majority seem to be in the Pacbell regions. Cheers, Aaron On Tue, Nov 17, 2009 at 10:28:17PM -0600, Frank Bulk wrote: > Not personally, but it's being documented here: > http://www.internetpulse.net/ > > Frank > > -----Original Message----- > From: Stuart Kirk [mailto:skirk at godaddy.com] > Sent: Tuesday, November 17, 2009 10:25 PM > To: nanog at nanog.org > Subject: SBC/AT&T Contact > > Is anybody experiencing any issues with customer traffic originating > from either of these carriers? If anybody from SBC or AT&T can contact > me off-list I would appreciate it. Thank you. > > --Stuart > > > > -- Aaron Hughes aaronh at bind.com +1-831-824-4161 Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 http://www.bind.com/ From william.mccall at gmail.com Tue Nov 17 23:07:50 2009 From: william.mccall at gmail.com (William McCall) Date: Tue, 17 Nov 2009 23:07:50 -0600 Subject: SBC/AT&T Contact In-Reply-To: <20091118050028.GD91582@trace.bind.com> References: <20091117212454.793bd257d3564d371c65df57e70810a7.bf94eb89b3.wbe@email.secureserver.net> <20091118050028.GD91582@trace.bind.com> Message-ID: No issues out of Dallas area for what its worth. On Tue, Nov 17, 2009 at 11:00 PM, Aaron Hughes wrote: > I can confirm serious problems reaching at&t DSL customers. The majority seem to be in the Pacbell regions. > > Cheers, > Aaron > > On Tue, Nov 17, 2009 at 10:28:17PM -0600, Frank Bulk wrote: >> Not personally, but it's being documented here: >> http://www.internetpulse.net/ >> >> Frank >> >> -----Original Message----- >> From: Stuart Kirk [mailto:skirk at godaddy.com] >> Sent: Tuesday, November 17, 2009 10:25 PM >> To: nanog at nanog.org >> Subject: SBC/AT&T Contact >> >> Is anybody experiencing any issues with customer traffic originating >> from either of these carriers? ?If anybody from SBC or AT&T can contact >> me off-list I would appreciate it. ?Thank you. >> >> --Stuart >> >> >> >> > > -- > > Aaron Hughes > aaronh at bind.com > +1-831-824-4161 > Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 > http://www.bind.com/ > > -- William McCall, CCIE #25044 From mehmet at akcin.net Wed Nov 18 01:52:35 2009 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 17 Nov 2009 23:52:35 -0800 Subject: SBC/AT&T Contact In-Reply-To: References: <20091117212454.793bd257d3564d371c65df57e70810a7.bf94eb89b3.wbe@email.secureserver.net> <20091118050028.GD91582@trace.bind.com> Message-ID: Stuart, ..Confirmed , packet loss , latency when connecting to several destinations from at&t, Orange County Uverse client. mehmet On Nov 17, 2009, at 9:07 PM, William McCall wrote: > No issues out of Dallas area for what its worth. > > On Tue, Nov 17, 2009 at 11:00 PM, Aaron Hughes wrote: >> I can confirm serious problems reaching at&t DSL customers. The majority seem to be in the Pacbell regions. >> >> Cheers, >> Aaron >> >> On Tue, Nov 17, 2009 at 10:28:17PM -0600, Frank Bulk wrote: >>> Not personally, but it's being documented here: >>> http://www.internetpulse.net/ >>> >>> Frank >>> >>> -----Original Message----- >>> From: Stuart Kirk [mailto:skirk at godaddy.com] >>> Sent: Tuesday, November 17, 2009 10:25 PM >>> To: nanog at nanog.org >>> Subject: SBC/AT&T Contact >>> >>> Is anybody experiencing any issues with customer traffic originating >>> from either of these carriers? If anybody from SBC or AT&T can contact >>> me off-list I would appreciate it. Thank you. >>> >>> --Stuart >>> >>> >>> >>> >> >> -- >> >> Aaron Hughes >> aaronh at bind.com >> +1-831-824-4161 >> Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 >> http://www.bind.com/ >> >> > > > > -- > William McCall, CCIE #25044 > From paul.cosgrove.nanog at gmail.com Wed Nov 18 08:04:17 2009 From: paul.cosgrove.nanog at gmail.com (Paul Cosgrove) Date: Wed, 18 Nov 2009 14:04:17 +0000 Subject: Juniper M120 Alternatives In-Reply-To: <20091117173246.GE51443@gerbil.cluepon.net> References: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> <443de7ad0911160808oee8f9cfo70e3391f36b054f2@mail.gmail.com> <29152.82.132.136.147.1258388092.squirrel@webmail-vh.tagadab.com> <4B01862E.8090101@linpro.no> <20091117002806.GA302@srv03.cluenet.de> <20091117044624.GB51443@gerbil.cluepon.net> <4B02C028.5060109@brightok.net> <20091117173246.GE51443@gerbil.cluepon.net> Message-ID: <1a9450c80911180604u461875f4pab847d905c688d73@mail.gmail.com> On Tue, Nov 17, 2009 at 5:32 PM, Richard A Steenbergen wrote: > On Tue, Nov 17, 2009 at 09:24:24AM -0600, Jack Bates wrote: > > Richard A Steenbergen wrote: > > >They've definitely been improving it over the years though, so much that > > >I almost never trigger a session reset on me unintentionally any more. > > > > They must have. This was new to me and came as a shock. I don't think > > I've ever seen my m120 behave any different than my cisco when it comes > > to flapping BGP. Things have just worked as I expected them to. Not that > > I go screwing with underlying interface configs or changing a peer from > > one group to another or changing the asn; at least not on a live > > session. These things would seem to indicate that the session might be > > subject to reset. > > > > Perhaps it just behaves for normal users and not power users. :) > > But those things won't trigger session resets on Cisco, so it often comes > as a shock. Also, one might very well expect that changing the peer-as on > a neighbor is going to cause a reset, but if you didn't know from > experience you might not expect that renaming a group or changing an > underlying interface MTU would do it too. > > The issue is that there is a fundamental design difference between Cisco > and Juniper. Cisco lets you configure anything you want in a line by line > basis, but it doesn't immediately apply those changes until you command > it to do so. Juniper's philosophy is that you make a bunch of changes to > a candiate configuration, "commit" to apply those changes, and then you > can expect those changes to take effect (or at least begin trying to take > effect) immediately. > > Personally I think the Juniper design philosophy is "better". Besides the > obvious stuff like being able to rollback your config, think about how > non-deterministic it is when you update a route-map but forget to soft > clear the BGP session. The routes that have been exchanged so far will > retain their old policy, while any new updates you receive after the > route-map change will receive the new policy, leaving the session in an > inconsistent state that will slowly and unpredictably change over time as > routing updates come in. The trade-off is that you lose the ability to do > non-impacting changes, where you make a change but know that it hasn't > actually taken effect yet, and won't until the next time the session > bounces. What Juniper is trying to do really is a good thing, I just wish > it could tell me before I commit what is and isn't going to flap. :) > > > The design differences you describe there relate more to traditional IOS vs JUNOS, rather than IOS XR vs JUNOS. IOS XR uses candidate configurations, commit, rollback etc. Paul. From gkinkie at gmail.com Wed Nov 18 08:04:28 2009 From: gkinkie at gmail.com (Kinkie) Date: Wed, 18 Nov 2009 15:04:28 +0100 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <550031AE4E25FE40BCD5D6894BC95DD5013F17DC@DCPWMF303.polk.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> <4AFC6DD8.5050502@rollernet.us> <550031AE4E25FE40BCD5D6894BC95DD5013F17DC@DCPWMF303.polk.com> Message-ID: On Thu, Nov 12, 2009 at 9:40 PM, Bulger, Tim wrote: > If you use stackable switches, you can stack across cabinets (up to 3 with 1 meter Cisco 3750 Stackwise), and uplink on the ends. ?It's a pretty solid layout if you plan your port needs properly based on NIC density and cabinet size, plus you can cable cleanly to an adjacent cabinet's switch if necessary. Juniper claims their switches can do clustering using ethernet cabling, yet a cluster behaves as a single-system-image configuration-wise. Should allow for very flexible cabling and operations-wise for TOR switches. I have never tried it however. /Kinkie From eugen at imacandi.net Wed Nov 18 08:34:11 2009 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Wed, 18 Nov 2009 16:34:11 +0200 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> <4AFC6DD8.5050502@rollernet.us> <550031AE4E25FE40BCD5D6894BC95DD5013F17DC@DCPWMF303.polk.com> Message-ID: <89ca25070911180634h34e8fef7y5c18fb127078fffb@mail.gmail.com> On Wed, Nov 18, 2009 at 4:04 PM, Kinkie wrote: > On Thu, Nov 12, 2009 at 9:40 PM, Bulger, Tim wrote: >> If you use stackable switches, you can stack across cabinets (up to 3 with 1 meter Cisco 3750 Stackwise), and uplink on the ends. ?It's a pretty solid layout if you plan your port needs properly based on NIC density and cabinet size, plus you can cable cleanly to an adjacent cabinet's switch if necessary. > > > > Juniper claims their switches can do clustering using ethernet > cabling, yet a cluster behaves as a single-system-image > configuration-wise. Should allow for very flexible cabling and > operations-wise for TOR switches. I have never tried it however. > The Ex4200 can be stacked by the ethernet expansion ports, either 4 x 1G or 2 x 10G. And yes, it behaves as single switch with multiple line cards. From jerry at jdixon.com Wed Nov 18 08:39:48 2009 From: jerry at jdixon.com (Jerry Dixon) Date: Wed, 18 Nov 2009 09:39:48 -0500 Subject: Policy News Message-ID: If you can make it they can tax it :/ Article in today's Wall Street Journal: "WASHINGTON -- Federal regulators are considering whether the government should take greater control of the Internet and ask consumers to pay higher phone charges in order to provide all Americans with cheaper access to broadband Internet service. The Federal Communications Commission Wednesday will lay out the case for expanding broadband Internet service, outlining current obstacles to making it widely available. The agency is considering whether to force Internet providers to share their networks with rivals and raise fees charged on consumer phone bills to pay for the broader access." Schatz, A. *Feds mull rules, fees to spur net access - WSJ.com.* Retrieved 11/18/2009, 2009, from http://online.wsj.com/article/SB125850641299752981.html -Jerry -- jerry at jdixon.com From jared at puck.nether.net Wed Nov 18 08:50:41 2009 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 18 Nov 2009 09:50:41 -0500 Subject: Policy News In-Reply-To: References: Message-ID: <8690D0B3-A23E-4BF3-BBA6-99773788D49A@puck.nether.net> How about just mandating that it's illegal to build anything but fiber/gpon for services. If something fails, it needs to be replaced with modern technology. I know here they replaced copper cable in the middle of the winter last year, it would have made more sense to just use the conduit they were replacing and put fiber in. But the fiber union guys != copper union guys so that is harder to do. Oh well, stuck in the 70's with my ISDN. - Jared On Nov 18, 2009, at 9:39 AM, Jerry Dixon wrote: > If you can make it they can tax it :/ > > Article in today's Wall Street Journal: > > "WASHINGTON -- Federal regulators are considering whether the government > should take greater control of the Internet and ask consumers to pay higher > phone charges in order to provide all Americans with cheaper access to > broadband Internet service. > > The Federal Communications Commission Wednesday will lay out the case for > expanding broadband Internet service, outlining current obstacles to making > it widely available. The agency is considering whether to force Internet > providers to share their networks with rivals and raise fees charged on > consumer phone bills to pay for the broader access." > > Schatz, A. *Feds mull rules, fees to spur net access - WSJ.com.* Retrieved > 11/18/2009, 2009, from > http://online.wsj.com/article/SB125850641299752981.html > > -Jerry > -- > jerry at jdixon.com From streiner at cluebyfour.org Wed Nov 18 09:00:49 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 18 Nov 2009 10:00:49 -0500 (EST) Subject: Policy News In-Reply-To: References: Message-ID: On Wed, 18 Nov 2009, Jerry Dixon wrote: > The Federal Communications Commission Wednesday will lay out the case for > expanding broadband Internet service, outlining current obstacles to making > it widely available. The agency is considering whether to force Internet > providers to share their networks with rivals and raise fees charged on > consumer phone bills to pay for the broader access." The telcos are asking for more taxpayer-funded goodie--er... incentives to expand broadband coverage. Given that the incentives (entry into additional markets, additional fees tacked onto customer bills, reduction/elimination of various other regulatory hurdles, etc) that have been handed to them over the past 10+ years have largely failed to produce that expanded coverage and improved service, doing more of the same is pretty much throwing good money after bad. jms From jerry at jdixon.com Wed Nov 18 08:57:09 2009 From: jerry at jdixon.com (Jerry Dixon) Date: Wed, 18 Nov 2009 09:57:09 -0500 Subject: Policy News In-Reply-To: <8690D0B3-A23E-4BF3-BBA6-99773788D49A@puck.nether.net> References: <8690D0B3-A23E-4BF3-BBA6-99773788D49A@puck.nether.net> Message-ID: While we're at it why not charge taxes for having security bolted on too....I'm waiting for my Internet EZ-Pass to come in the mail to mount on my cable modem :-O I'm wondering where they come up with these schemes...I didn't see any mention of tax breaks to encourage the roll out. Just more charges. Jerry On Wed, Nov 18, 2009 at 9:50 AM, Jared Mauch wrote: > How about just mandating that it's illegal to build anything but fiber/gpon > for services. If something fails, it needs to be replaced with modern > technology. > > I know here they replaced copper cable in the middle of the winter last > year, it would have made more sense to just use the conduit they were > replacing and put fiber in. > > But the fiber union guys != copper union guys so that is harder to do. > > Oh well, stuck in the 70's with my ISDN. > > - Jared > > On Nov 18, 2009, at 9:39 AM, Jerry Dixon wrote: > > > If you can make it they can tax it :/ > > > > Article in today's Wall Street Journal: > > > > "WASHINGTON -- Federal regulators are considering whether the government > > should take greater control of the Internet and ask consumers to pay > higher > > phone charges in order to provide all Americans with cheaper access to > > broadband Internet service. > > > > The Federal Communications Commission Wednesday will lay out the case for > > expanding broadband Internet service, outlining current obstacles to > making > > it widely available. The agency is considering whether to force Internet > > providers to share their networks with rivals and raise fees charged on > > consumer phone bills to pay for the broader access." > > > > Schatz, A. *Feds mull rules, fees to spur net access - WSJ.com.* > Retrieved > > 11/18/2009, 2009, from > > http://online.wsj.com/article/SB125850641299752981.html > > > > -Jerry > > -- > > jerry at jdixon.com > > -- jerry at jdixon.com (443) 295-3779 From bclark at spectraaccess.com Wed Nov 18 09:41:06 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Wed, 18 Nov 2009 10:41:06 -0500 Subject: Policy News In-Reply-To: References: Message-ID: <1258558866.5216.16.camel@Acer-Linux> Yeah...because when the economy is sucking wind why not raise fees to the consumer?!?! Want to get broadband out to people, then deal with duopolies that many of the regions in the country have...such as Verizon & Comcast! They are the main barriers that cause grief in deployment, giving a chance there are any number of small businesses that could respond to a broadband deployment faster, quicker and cheaper! Talk with any CLEC and they have countless stories regarding the horrors of dealing with an ILEC. Bret On Wed, 2009-11-18 at 10:00 -0500, Justin M. Streiner wrote: > > > The Federal Communications Commission Wednesday will lay out the > case for > > expanding broadband Internet service, outlining current obstacles to > making > > it widely available. The agency is considering whether to force > Internet > > providers to share their networks with rivals and raise fees charged > on > > consumer phone bills to pay for the broader access." From cra at WPI.EDU Wed Nov 18 09:43:49 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 18 Nov 2009 10:43:49 -0500 Subject: Layer 2 vs. Layer 3 to TOR In-Reply-To: <89ca25070911180634h34e8fef7y5c18fb127078fffb@mail.gmail.com> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4E63E3DB@BLV11EXVS01.corp.dm.local> <3144163E-F6D4-4AF4-8B81-E2653D2AF8B8@twincreeks.net> <4AFC6DD8.5050502@rollernet.us> <550031AE4E25FE40BCD5D6894BC95DD5013F17DC@DCPWMF303.polk.com> <89ca25070911180634h34e8fef7y5c18fb127078fffb@mail.gmail.com> Message-ID: <20091118154349.GI12115@angus.ind.WPI.EDU> On Wed, Nov 18, 2009 at 04:34:11PM +0200, Eugeniu Patrascu wrote: > On Wed, Nov 18, 2009 at 4:04 PM, Kinkie wrote: > > On Thu, Nov 12, 2009 at 9:40 PM, Bulger, Tim wrote: > >> If you use stackable switches, you can stack across cabinets (up to 3 with 1 meter Cisco 3750 Stackwise), and uplink on the ends. ?It's a pretty solid layout if you plan your port needs properly based on NIC density and cabinet size, plus you can cable cleanly to an adjacent cabinet's switch if necessary. > > > > > > > > Juniper claims their switches can do clustering using ethernet > > cabling, yet a cluster behaves as a single-system-image > > configuration-wise. Should allow for very flexible cabling and > > operations-wise for TOR switches. I have never tried it however. > > > > The Ex4200 can be stacked by the ethernet expansion ports, either 4 x > 1G or 2 x 10G. > And yes, it behaves as single switch with multiple line cards. Yes, up to 10 EX4200 switches can be interconnected into a "Virtual Chassis" using either the rear Virtual Chassis Ports (32 Gbps ingress + 32 Gbps egress for each of the 2 ports) with up to 5-meter VCP cables, or using SFP, XFP or SFP+ fiber links (not sure if it works with copper SFP, but might). You can mix/match each type of interconnection within the same VC. From streiner at cluebyfour.org Wed Nov 18 09:55:40 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 18 Nov 2009 10:55:40 -0500 (EST) Subject: Policy News In-Reply-To: <1258558866.5216.16.camel@Acer-Linux> References: <1258558866.5216.16.camel@Acer-Linux> Message-ID: On Wed, 18 Nov 2009, Bret Clark wrote: > Yeah...because when the economy is sucking wind why not raise fees to > the consumer?!?! And one of the points of my original response was that consumers in large part have not received any additional value out of the fees they've paying (directly or indirectly) for the past several years. Throwing yet more cash into the hog trough doesn't make much sense. > Want to get broadband out to people, then deal with duopolies that many > of the regions in the country have...such as Verizon & Comcast! They are > the main barriers that cause grief in deployment, giving a chance there > are any number of small businesses that could respond to a broadband > deployment faster, quicker and cheaper! Talk with any CLEC and they have > countless stories regarding the horrors of dealing with an ILEC. Having worked much more closely with many ILECs in a previous life than I do now, I have plenty of horror stories of my own. jms From mike-nanog at tiedyenetworks.com Wed Nov 18 10:36:11 2009 From: mike-nanog at tiedyenetworks.com (Mike) Date: Wed, 18 Nov 2009 08:36:11 -0800 Subject: [mild flamage] Re: Policy News In-Reply-To: <8690D0B3-A23E-4BF3-BBA6-99773788D49A@puck.nether.net> References: <8690D0B3-A23E-4BF3-BBA6-99773788D49A@puck.nether.net> Message-ID: <4B04227B.6050001@tiedyenetworks.com> Jared Mauch wrote: > How about just mandating that it's illegal to build anything but fiber/gpon for services. I would expand on this and say we should make it illegal for any telecom carrier to refuse to put their assets into service wherever they may be, and going forward we should force conditions on all telecom carriers to sell to all at any technical feasible point to all comers, and further to require planned points of interconnection for competitors and rules about how much overbuild is required (minimum fiber counts that should be reserved for 'the public interest') and so forth. We saw how the telecoms gamed the 96 telecom act, so now we know and we can do better and design in indefeasble rules that take away the game playing and replace it with service that actually gets to people who need it. I happen to be an operator in a rural area and the realities are that prices are waaayyyy high (over $100/mbps), where you can get any sort of bigname telco service at all. At the same time however, there is plenty of fiber in the ground, on the poles and passing thru regeneration huts all thru the area that is doing absolutely no good for the local populations. There are plenty of already existing possible points of interconnection, but there's no requirement that they be forced to sell to you at these points. An example in my area is Level3 communications, who has an international fiber route running thru my county and 2 regeneration huts and at least one of these confirmed as having all necessary gear to sell ethernet/tdm handoff services. I have a competitor who was able to get into this one before l3 bought it (former Wiltel sites) and enjoys $20/mbps but since then although there's been plenty of discussion the bottom line is l3 simply isn't _interested_ in selling _us_ service, leaving us (and our county) at the mercy of att for all connectivity, making att a single point of failure, empowering att to charge outlandish prices for connectivity services since everything has to go at least 100 miles away (triggering those 'loop charges' we're all so fond of, since they won't dare put in opteman or other advanced distance insensitive options, oh heavens no you need those old expensive copper tdm services and anything you want to connect to is gonna be a long, long ways away....) What really burns me up is that L3 had the odacity to apply for federal BTOP dollars for creating exactly the problem they are proposing to resolve. Gee what an original idea - get federal grant money to sell a service that we're already sellling at a zero cost! Ok Im don't spewing now, thanks for letting me vent. From smb at cs.columbia.edu Wed Nov 18 10:43:28 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 18 Nov 2009 11:43:28 -0500 Subject: Policy News In-Reply-To: <4B04227B.6050001@tiedyenetworks.com> References: <8690D0B3-A23E-4BF3-BBA6-99773788D49A@puck.nether.net> <4B04227B.6050001@tiedyenetworks.com> Message-ID: Does anyone know an easy way to do "kill thread" in MacOS's Mail.App? It's getting increasingly hard to read the NANOG list on my Mac without such a capability. (Yes, the question is serious on its own, apart from any other meanings you may choose to read into it.) From ge at linuxbox.org Wed Nov 18 11:08:31 2009 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 18 Nov 2009 19:08:31 +0200 Subject: Announcement: Critical Internet Infrastructure WG is now open to public participation Message-ID: <4B042A0F.4010603@linuxbox.org> ISOTF Critical Internet Infrastructure WG is now open to public participation. The group holds top experts on internet technology, critical infrastructure, and internet governance, from around the globe. Together, we discuss definitions, problems, challenges and solutions in securing and assuring the reliability of the global internet infrastructure, which is critical infrastructure for a growing number of nations, corporations and indeed, individuals -- world wide. The group started as a closed and private forum, to discuss technical and operational risks, as other venues limited discussion of critical internet resources to politically charged subjects such ascontrol of ICANN and ARIN, thus overshadowing other important aspects. As of November 18th 2009, the list is open for public access, to advance public awareness of the issues, and bring new talent on board. The group is hosted by the ISOTF, but is governed by members. Note: SCADA, network operations, and other related issues should be discussed in the appropriate forums, elsewhere. This group deals with the internet. To subscribe: http://isotf.org/mailman/listinfo/cii Gadi Evron for ISOTF-CII-WG. From simon at slimey.org Wed Nov 18 11:12:39 2009 From: simon at slimey.org (Simon Lockhart) Date: Wed, 18 Nov 2009 17:12:39 +0000 Subject: Announcement: Critical Internet Infrastructure WG is now open to public participation In-Reply-To: <4B042A0F.4010603@linuxbox.org> References: <4B042A0F.4010603@linuxbox.org> Message-ID: <20091118171239.GC23204@virtual.bogons.net> On Wed Nov 18, 2009 at 07:08:31PM +0200, Gadi Evron wrote: > ISOTF Critical Internet Infrastructure WG is now open to public > participation. Sorry, who is ISOTF? I tried looking on the website, but the "About ISOTF" page is blank... http://www.isotf.org/?page_value=0 Simon From ge at linuxbox.org Wed Nov 18 11:29:44 2009 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 18 Nov 2009 19:29:44 +0200 Subject: Announcement: Critical Internet Infrastructure WG is now open to public participation In-Reply-To: <20091118171239.GC23204@virtual.bogons.net> References: <4B042A0F.4010603@linuxbox.org> <20091118171239.GC23204@virtual.bogons.net> Message-ID: <4B042F08.2080501@linuxbox.org> Simon Lockhart wrote: > On Wed Nov 18, 2009 at 07:08:31PM +0200, Gadi Evron wrote: >> ISOTF Critical Internet Infrastructure WG is now open to public >> participation. > > Sorry, who is ISOTF? > > I tried looking on the website, but the "About ISOTF" page is blank... > > http://www.isotf.org/?page_value=0 It's the blanket name we use to host meetings, publish papers, or give a home on the web for task forces of volunteers for global incident response and similar matters. We don't like the idea of formalizing it, and thus not much data is available on the official web page. Perhaps that needs to be fixed. Thanks for bringing it to our attention. Gadi. > > Simon > -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From youssef.ghorbal at gmail.com Wed Nov 18 12:24:54 2009 From: youssef.ghorbal at gmail.com (Youssef Ghorbal) Date: Wed, 18 Nov 2009 19:24:54 +0100 Subject: Announcement: Critical Internet Infrastructure WG is now open to public participation In-Reply-To: <4B042F08.2080501@linuxbox.org> References: <4B042A0F.4010603@linuxbox.org> <20091118171239.GC23204@virtual.bogons.net> <4B042F08.2080501@linuxbox.org> Message-ID: Off topic, but are you serious about the "Admin Interface" Link (http://www.isotf.org/?page_value=13223) or is it just a joke ? -------------------- On Wed, Nov 18, 2009 at 6:29 PM, Gadi Evron wrote: > Simon Lockhart wrote: >> >> On Wed Nov 18, 2009 at 07:08:31PM +0200, Gadi Evron wrote: >>> >>> ISOTF Critical Internet Infrastructure WG is now open to public >>> participation. >> >> Sorry, who is ISOTF? >> >> I tried looking on the website, but the "About ISOTF" page is blank... >> >> ? ? ? ?http://www.isotf.org/?page_value=0 > > It's the blanket name we use to host meetings, publish papers, or give a > home on the web for task forces of volunteers for global incident response > and similar matters. > > We don't like the idea of formalizing it, and thus not much data is > available on the official web page. Perhaps that needs to be fixed. > > Thanks for bringing it to our attention. > > ? ? ? ?Gadi. > > >> >> Simon >> > > > -- > Gadi Evron, > ge at linuxbox.org. > > Blog: http://gevron.livejournal.com/ > > From cmeidinger at sendmail.com Wed Nov 18 13:01:17 2009 From: cmeidinger at sendmail.com (Chris Meidinger) Date: Wed, 18 Nov 2009 20:01:17 +0100 Subject: Policy News In-Reply-To: References: <8690D0B3-A23E-4BF3-BBA6-99773788D49A@puck.nether.net> <4B04227B.6050001@tiedyenetworks.com> Message-ID: <623F7659-E0B7-4699-8934-FE79C2D9814C@sendmail.com> Command+0 for the activity viewer - then click on the stop sign Sent from my iPhone. Please execute spelling errors. On 18.11.2009, at 17:43, Steven Bellovin wrote: > Does anyone know an easy way to do "kill thread" in MacOS's > Mail.App? It's getting increasingly hard to read the NANOG list on > my Mac without such a capability. (Yes, the question is serious on > its own, apart from any other meanings you may choose to read into > it.) From mdodd at doddserver.com Wed Nov 18 13:13:27 2009 From: mdodd at doddserver.com (Matthew Dodd) Date: Wed, 18 Nov 2009 14:13:27 -0500 Subject: Policy News In-Reply-To: <623F7659-E0B7-4699-8934-FE79C2D9814C@sendmail.com> References: <8690D0B3-A23E-4BF3-BBA6-99773788D49A@puck.nether.net> <4B04227B.6050001@tiedyenetworks.com> <623F7659-E0B7-4699-8934-FE79C2D9814C@sendmail.com> Message-ID: <23728B67-E85B-4F54-B6D6-9ADBA38C2429@doddserver.com> I think he meant being able to easily delete an entire thread of emails, like you might be able to if you were using Gmail. Sadly I don't know of any feature that does this in Mail.app, but you can always make a Smart Mailbox with the rule Any Recipient : Contains : "nanog at merit.edu" and delete things within that mailbox. Best, -Matt Dodd On Nov 18, 2009, at 2:01 PM, Chris Meidinger wrote: > Command+0 for the activity viewer - then click on the stop sign > > Sent from my iPhone. Please execute spelling errors. > > On 18.11.2009, at 17:43, Steven Bellovin wrote: > >> Does anyone know an easy way to do "kill thread" in MacOS's Mail.App? It's getting increasingly hard to read the NANOG list on my Mac without such a capability. (Yes, the question is serious on its own, apart from any other meanings you may choose to read into it.) > From hrlinneweh at sbcglobal.net Wed Nov 18 13:26:49 2009 From: hrlinneweh at sbcglobal.net (Henry Linneweh) Date: Wed, 18 Nov 2009 11:26:49 -0800 (PST) Subject: Policy News In-Reply-To: <23728B67-E85B-4F54-B6D6-9ADBA38C2429@doddserver.com> References: <8690D0B3-A23E-4BF3-BBA6-99773788D49A@puck.nether.net> <4B04227B.6050001@tiedyenetworks.com> <623F7659-E0B7-4699-8934-FE79C2D9814C@sendmail.com> <23728B67-E85B-4F54-B6D6-9ADBA38C2429@doddserver.com> Message-ID: <512733.51630.qm@web180309.mail.gq1.yahoo.com> Well, I was reading this https://mozillalabs.com/raindrop? and it could have the potential to solve these problems for non gmail users and policy issues surrounding email itself. This is not intended to rain on anyones parade. -henry ________________________________ From: Matthew Dodd To: Chris Meidinger Cc: Nanog Sent: Wed, November 18, 2009 11:13:27 AM Subject: Re: Policy News I think he meant being able to easily delete an entire thread of emails, like you might be able to if you were using Gmail. Sadly I don't know of any feature that does this in Mail.app, but you can always make a Smart Mailbox with the rule Any Recipient : Contains : "nanog at merit.edu" and delete things within that mailbox. Best, -Matt Dodd On Nov 18, 2009, at 2:01 PM, Chris Meidinger wrote: > Command+0 for the activity viewer - then click on the stop sign > > Sent from my iPhone. Please execute spelling errors. > > On 18.11.2009, at 17:43, Steven Bellovin wrote: > >> Does anyone know an easy way to do "kill thread" in MacOS's Mail.App?? It's getting increasingly hard to read the NANOG list on my Mac without such a capability.? (Yes, the question is serious on its own, apart from any other meanings you may choose to read into it.) > From smb at cs.columbia.edu Wed Nov 18 13:27:46 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 18 Nov 2009 14:27:46 -0500 Subject: Policy News In-Reply-To: <23728B67-E85B-4F54-B6D6-9ADBA38C2429@doddserver.com> References: <8690D0B3-A23E-4BF3-BBA6-99773788D49A@puck.nether.net> <4B04227B.6050001@tiedyenetworks.com> <623F7659-E0B7-4699-8934-FE79C2D9814C@sendmail.com> <23728B67-E85B-4F54-B6D6-9ADBA38C2429@doddserver.com> Message-ID: On Nov 18, 2009, at 2:13 PM, Matthew Dodd wrote: > I think he meant being able to easily delete an entire thread of emails, like you might be able to if you were using Gmail. Yup, precisely. > Sadly I don't know of any feature that does this in Mail.app, but you can always make a Smart Mailbox with the rule Any Recipient : Contains : "nanog at merit.edu" and delete things within that mailbox. Or a rule to at least mark the messages as read. I can do that -- I do do that, for threads that have gotten too annoying for too long, but it takes many mouse clicks to add each new offending subject line. --Steve Bellovin, http://www.cs.columbia.edu/~smb From charles at thewybles.com Wed Nov 18 13:18:53 2009 From: charles at thewybles.com (Charles Wyble) Date: Wed, 18 Nov 2009 11:18:53 -0800 Subject: Policy News In-Reply-To: <23728B67-E85B-4F54-B6D6-9ADBA38C2429@doddserver.com> References: <8690D0B3-A23E-4BF3-BBA6-99773788D49A@puck.nether.net> <4B04227B.6050001@tiedyenetworks.com> <623F7659-E0B7-4699-8934-FE79C2D9814C@sendmail.com> <23728B67-E85B-4F54-B6D6-9ADBA38C2429@doddserver.com> Message-ID: <7B651D14-23CD-43FB-8E15-1264DF7C8708@thewybles.com> View -> Organize by thread. Then just hit the little circle, which selects all messages. Then delete. On Nov 18, 2009, at 11:13 AM, Matthew Dodd wrote: > I think he meant being able to easily delete an entire thread of > emails, like you might be able to if you were using Gmail. Sadly I > don't know of any feature that does this in Mail.app, but you can > always make a Smart Mailbox with the rule Any Recipient : Contains : > "nanog at merit.edu" and delete things within that mailbox. > > Best, > > -Matt Dodd > > On Nov 18, 2009, at 2:01 PM, Chris Meidinger wrote: > >> Command+0 for the activity viewer - then click on the stop sign >> >> Sent from my iPhone. Please execute spelling errors. >> >> On 18.11.2009, at 17:43, Steven Bellovin wrote: >> >>> Does anyone know an easy way to do "kill thread" in MacOS's >>> Mail.App? It's getting increasingly hard to read the NANOG list >>> on my Mac without such a capability. (Yes, the question is >>> serious on its own, apart from any other meanings you may choose >>> to read into it.) >> > > From rdobbins at arbor.net Wed Nov 18 13:52:02 2009 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 18 Nov 2009 19:52:02 +0000 Subject: Mail.app threading (was Re: Policy News) In-Reply-To: <23728B67-E85B-4F54-B6D6-9ADBA38C2429@doddserver.com> References: <8690D0B3-A23E-4BF3-BBA6-99773788D49A@puck.nether.net> <4B04227B.6050001@tiedyenetworks.com> <623F7659-E0B7-4699-8934-FE79C2D9814C@sendmail.com> <23728B67-E85B-4F54-B6D6-9ADBA38C2429@doddserver.com> Message-ID: <981CD29A-5EF4-4F50-A47A-64E8CE027844@arbor.net> On Nov 19, 2009, at 2:13 AM, Matthew Dodd wrote: > Sadly I don't know of any feature that does this in Mail.app, b If you set the Mail.app GUI to use 'threaded view', it's easy to zap a whole thread. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From owen at delong.com Wed Nov 18 14:03:27 2009 From: owen at delong.com (Owen DeLong) Date: Wed, 18 Nov 2009 12:03:27 -0800 Subject: Policy News In-Reply-To: <23728B67-E85B-4F54-B6D6-9ADBA38C2429@doddserver.com> References: <8690D0B3-A23E-4BF3-BBA6-99773788D49A@puck.nether.net> <4B04227B.6050001@tiedyenetworks.com> <623F7659-E0B7-4699-8934-FE79C2D9814C@sendmail.com> <23728B67-E85B-4F54-B6D6-9ADBA38C2429@doddserver.com> Message-ID: <5B10A733-7551-43D8-A958-BDD494E75670@delong.com> There isn't a thread-kill per se, but, you can create a rule and add the threads you want to it fairly easily... MAIL->Preferences, then go to the "Rules" tab. Owen On Nov 18, 2009, at 11:13 AM, Matthew Dodd wrote: > I think he meant being able to easily delete an entire thread of > emails, like you might be able to if you were using Gmail. Sadly I > don't know of any feature that does this in Mail.app, but you can > always make a Smart Mailbox with the rule Any Recipient : Contains : > "nanog at merit.edu" and delete things within that mailbox. > > Best, > > -Matt Dodd > > On Nov 18, 2009, at 2:01 PM, Chris Meidinger wrote: > >> Command+0 for the activity viewer - then click on the stop sign >> >> Sent from my iPhone. Please execute spelling errors. >> >> On 18.11.2009, at 17:43, Steven Bellovin wrote: >> >>> Does anyone know an easy way to do "kill thread" in MacOS's >>> Mail.App? It's getting increasingly hard to read the NANOG list >>> on my Mac without such a capability. (Yes, the question is >>> serious on its own, apart from any other meanings you may choose >>> to read into it.) >> > From dga at cs.cmu.edu Wed Nov 18 14:12:51 2009 From: dga at cs.cmu.edu (David Andersen) Date: Wed, 18 Nov 2009 15:12:51 -0500 Subject: Mail.app threading (was Re: Policy News) In-Reply-To: <981CD29A-5EF4-4F50-A47A-64E8CE027844@arbor.net> References: <8690D0B3-A23E-4BF3-BBA6-99773788D49A@puck.nether.net> <4B04227B.6050001@tiedyenetworks.com> <623F7659-E0B7-4699-8934-FE79C2D9814C@sendmail.com> <23728B67-E85B-4F54-B6D6-9ADBA38C2429@doddserver.com> <981CD29A-5EF4-4F50-A47A-64E8CE027844@arbor.net> Message-ID: <73748011-DDCC-4C88-9C30-AFBF1606B559@cs.cmu.edu> On Nov 18, 2009, at 2:52 PM, Dobbins, Roland wrote: > > On Nov 19, 2009, at 2:13 AM, Matthew Dodd wrote: > >> Sadly I don't know of any feature that does this in Mail.app, b > > If you set the Mail.app GUI to use 'threaded view', it's easy to zap > a whole thread. I believe that Steve's desire was to kill *future* messages in the same thread. e.g., a rule that says 'delete all mail from nanog with the subject line 'Policy News' until December 1, 2010'. This would be a marvelous feature indeed. Sadly, I don't know how to do it in Mail.app. :) -Dave From phil.pierotti at gmail.com Wed Nov 18 15:08:04 2009 From: phil.pierotti at gmail.com (Phil Pierotti) Date: Thu, 19 Nov 2009 08:08:04 +1100 Subject: Juniper M120 Alternatives In-Reply-To: <1a9450c80911180604u461875f4pab847d905c688d73@mail.gmail.com> References: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> <443de7ad0911160808oee8f9cfo70e3391f36b054f2@mail.gmail.com> <29152.82.132.136.147.1258388092.squirrel@webmail-vh.tagadab.com> <4B01862E.8090101@linpro.no> <20091117002806.GA302@srv03.cluenet.de> <20091117044624.GB51443@gerbil.cluepon.net> <4B02C028.5060109@brightok.net> <20091117173246.GE51443@gerbil.cluepon.net> <1a9450c80911180604u461875f4pab847d905c688d73@mail.gmail.com> Message-ID: <5574b2240911181308y762e702btc43dec7367fa4ad1@mail.gmail.com> That's excellent news - any word on when Cisco will be back-porting these truly useful features from XR to that platform which so many of us are still running on (ie "traditional IOS")? Phil P On Thu, Nov 19, 2009 at 1:04 AM, Paul Cosgrove < paul.cosgrove.nanog at gmail.com> wrote: > On Tue, Nov 17, 2009 at 5:32 PM, Richard A Steenbergen >wrote: > The design differences you describe there relate more to traditional IOS vs > JUNOS, rather than IOS XR vs JUNOS. IOS XR uses candidate configurations, > commit, rollback etc. > > Paul. > From cmeidinger at sendmail.com Wed Nov 18 15:21:46 2009 From: cmeidinger at sendmail.com (Chris Meidinger) Date: Wed, 18 Nov 2009 22:21:46 +0100 Subject: Policy News In-Reply-To: <025FCD02-AE17-4FB5-8049-8DF7E19EA736@briworks.com> References: <8690D0B3-A23E-4BF3-BBA6-99773788D49A@puck.nether.net> <4B04227B.6050001@tiedyenetworks.com> <623F7659-E0B7-4699-8934-FE79C2D9814C@sendmail.com> <025FCD02-AE17-4FB5-8049-8DF7E19EA736@briworks.com> Message-ID: <97F158D2-19EE-4A50-BD3E-25632D2D16B6@sendmail.com> On 18.11.2009, at 20:08, Jeff Saxe wrote: > I don't think Steve meant a way to stop the CPU / process thread of retrieving email if it is hung talking to an email server, although thank you for that. I believe Steve meant "I want to keep reading the NANOG mailing list in general, but this particular message thread has zero interest to me, so as any new emails come in that are replies to replies to replies to this thread, just suppress them so I don't have to even hit Delete.". Something like that. Ah, I thought you meant threads were blocking Mail.app from processing messages in other mailboxes. I subscribe to several imap boxes with over half a million messages in them, so I use activity monitor to kill sync all the time. Mail.app seems to not process anything else on the same account as long as it's busy processing a subscription for a particular mailbox, which can take forever in some cases. As to the actual question, I use Mail.app in threaded mode anyway. When I'm not interested in a thread, I just let it collect messages and mark it as read every couple of days. I'm not aware of any way to tell Mail.app to quit showing messages from a particular thread. Chris From sthaug at nethelp.no Wed Nov 18 15:32:25 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 18 Nov 2009 22:32:25 +0100 (CET) Subject: Juniper M120 Alternatives In-Reply-To: <5574b2240911181308y762e702btc43dec7367fa4ad1@mail.gmail.com> References: <20091117173246.GE51443@gerbil.cluepon.net> <1a9450c80911180604u461875f4pab847d905c688d73@mail.gmail.com> <5574b2240911181308y762e702btc43dec7367fa4ad1@mail.gmail.com> Message-ID: <20091118.223225.74674714.sthaug@nethelp.no> > That's excellent news - any word on when Cisco will be back-porting these > truly useful features from XR to that platform which so many of us are still > running on (ie "traditional IOS")? Obviously not speaking for Cisco here - but as a significant customer we have had no indication that this will happen, ever. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From ge at linuxbox.org Wed Nov 18 15:32:39 2009 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 18 Nov 2009 23:32:39 +0200 Subject: Announcement: Critical Internet Infrastructure WG is now open to public participation In-Reply-To: References: <4B042A0F.4010603@linuxbox.org> <20091118171239.GC23204@virtual.bogons.net> <4B042F08.2080501@linuxbox.org> Message-ID: <4B0467F7.9010906@linuxbox.org> Youssef Ghorbal wrote: > Off topic, but are you serious about the "Admin Interface" Link > (http://www.isotf.org/?page_value=13223) or is it just a joke ? > hehe, thanks for noticing. I'm sure Randy Vaughn gets excited every single time someone does. Reddit had fun with our admin interface a while back: http://www.reddit.com/r/reddit.com/comments/6a32u/please_enter_the_first_1178_digits_of_pi_wait/ As to if it's a joke... one way to find out. :) Gadi. -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From shon at unwiredbb.com Wed Nov 18 16:31:40 2009 From: shon at unwiredbb.com (Shon Elliott) Date: Wed, 18 Nov 2009 14:31:40 -0800 Subject: AT&T BGP Setup Message-ID: <43BAB891D6D01742AFDEA3D62DCE9E5D5441E3@uwbb-cat2.unwiredbb.local> Hey everyone. I didn't really want to ask this out here, but wasn't sure who else I could ask, but does anyone here have BGP setup with AT&T as well as to other providers? Could you give me a phone number for a rep? Our AT&T reps are telling us they won't allow us to announce IP we get from AT&T and our own IP out our other connections, and vice versa where we cannot announce our IP address and IP addresses we have from AT&T out to through their circuit via like an Optiman setup. So basically, if you have a rep that some answers, could you forward me their phone number off-list? Thanks! -S From tvarriale at comcast.net Wed Nov 18 18:01:11 2009 From: tvarriale at comcast.net (Tony Varriale) Date: Wed, 18 Nov 2009 18:01:11 -0600 Subject: Juniper M120 Alternatives References: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com><443de7ad0911160808oee8f9cfo70e3391f36b054f2@mail.gmail.com><29152.82.132.136.147.1258388092.squirrel@webmail-vh.tagadab.com><4B01862E.8090101@linpro.no> <20091117002806.GA302@srv03.cluenet.de><20091117044624.GB51443@gerbil.cluepon.net><4B02C028.5060109@brightok.net><20091117173246.GE51443@gerbil.cluepon.net> <1a9450c80911180604u461875f4pab847d905c688d73@mail.gmail.com> Message-ID: <73B72EF86A054269B2070B51DD4F85B7@flamdt01> As a side note that many may be aware of, there are other Cisco products/code bases that have these nice features. tv ----- Original Message ----- From: "Paul Cosgrove" To: "Richard A Steenbergen" Cc: Sent: Wednesday, November 18, 2009 8:04 AM Subject: Re: Juniper M120 Alternatives > The design differences you describe there relate more to traditional IOS > vs > JUNOS, rather than IOS XR vs JUNOS. IOS XR uses candidate configurations, > commit, rollback etc. > > Paul. From zeusdadog at gmail.com Wed Nov 18 21:56:39 2009 From: zeusdadog at gmail.com (Jay Nakamura) Date: Wed, 18 Nov 2009 22:56:39 -0500 Subject: Password repository Message-ID: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> Quick question, does anyone have software/combination of tools they recommend on centrally store various passwords securely? Thanks. From jmamodio at gmail.com Wed Nov 18 22:25:06 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 18 Nov 2009 22:25:06 -0600 Subject: Announcement: Critical Internet Infrastructure WG is now open to public participation In-Reply-To: <4B0467F7.9010906@linuxbox.org> References: <4B042A0F.4010603@linuxbox.org> <20091118171239.GC23204@virtual.bogons.net> <4B042F08.2080501@linuxbox.org> <4B0467F7.9010906@linuxbox.org> Message-ID: <202705b0911182025y4aca6491t69651ef1aa2bf581@mail.gmail.com> Still you didn't answer the question. What ISOTF stands for and who are "we" ? What papers the "we" published ? where ? Regards Jorge From dstorandt at teljet.com Wed Nov 18 22:33:22 2009 From: dstorandt at teljet.com (David Storandt) Date: Wed, 18 Nov 2009 23:33:22 -0500 Subject: Password repository In-Reply-To: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> References: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> Message-ID: On a small scale, PasswordSafe from Sourceforge. On Wed, Nov 18, 2009 at 10:56 PM, Jay Nakamura wrote: > Quick question, does anyone have software/combination of tools they > recommend on centrally store various passwords securely? > > Thanks. > > -- -- David Storandt CTO TelJet Longhaul LLC 802-922-9503 (new DID) 802-264-3003 (fax) dstorandt at teljet.com From smeuse at mara.org Wed Nov 18 22:36:25 2009 From: smeuse at mara.org (Steve Meuse) Date: Wed, 18 Nov 2009 23:36:25 -0500 Subject: Policy News In-Reply-To: <1258558866.5216.16.camel@Acer-Linux> References: <1258558866.5216.16.camel@Acer-Linux> Message-ID: <20091119043625.GA5758@mara.org> Bret Clark expunged (bclark at spectraaccess.com): > Want to get broadband out to people, then deal with duopolies that many > of the regions in the country have...such as Verizon & Comcast WRT to Comcast ... There is nothing preventing *any* company from building a cable network in any existing MSO territory. Each license is negotiated town-by-town, county-by-county, there aren't any exclusivity agreements, which allow companies like RCN to compete. The reason why there isn't more local competition is, well, it's kinda seriously captial inte$ive. You ever notice why RCN doesn't overbuild in East Nowheresville, MI (where Jared lives apparently :)??? Because it's not profitable! -Steve (Comcast employee, speaking on my own behalf) From darren at bolding.org Wed Nov 18 22:49:34 2009 From: darren at bolding.org (Darren Bolding) Date: Wed, 18 Nov 2009 20:49:34 -0800 Subject: Password repository In-Reply-To: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> References: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> Message-ID: <5a318d410911182049u5a54945ase318a53b3a8a5035@mail.gmail.com> Pwman On 11/18/09, Jay Nakamura wrote: > Quick question, does anyone have software/combination of tools they > recommend on centrally store various passwords securely? > > Thanks. > > -- Sent from my mobile device -- Darren Bolding -- -- darren at bolding.org -- From ddunkin at netos.net Thu Nov 19 00:12:22 2009 From: ddunkin at netos.net (Darryl Dunkin) Date: Wed, 18 Nov 2009 22:12:22 -0800 Subject: Password repository In-Reply-To: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> References: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> Message-ID: <56F5BC5F404CF84896C447397A1AAF200167052C@MAIL.nosi.netos.com> http://keepass.info Works great in a multi-user environment. -----Original Message----- From: Jay Nakamura [mailto:zeusdadog at gmail.com] Sent: Wednesday, November 18, 2009 19:57 To: NANOG Subject: Password repository Quick question, does anyone have software/combination of tools they recommend on centrally store various passwords securely? Thanks. From randy at psg.com Thu Nov 19 00:34:30 2009 From: randy at psg.com (Randy Bush) Date: Thu, 19 Nov 2009 15:34:30 +0900 Subject: Password repository In-Reply-To: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> References: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> Message-ID: > Quick question, does anyone have software/combination of tools they > recommend on centrally store various passwords securely? ascii text file, gpg encrypted, only opened with emacs crypt++.el randy From dwhite at olp.net Thu Nov 19 01:11:59 2009 From: dwhite at olp.net (Dan White) Date: Thu, 19 Nov 2009 01:11:59 -0600 Subject: Password repository In-Reply-To: References: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> Message-ID: <20091119071158.GA5691@dan.olp.net> On 19/11/09?15:34?+0900, Randy Bush wrote: >> Quick question, does anyone have software/combination of tools they >> recommend on centrally store various passwords securely? > > > >ascii text file, gpg encrypted, only opened with emacs crypt++.el From the network administrator perspective, we prefer to use a 3rd party/central authentication system where feasible, to reduce the number of passwords entries in our network from Users*Systems to Users*Security_Domains, and keep a gpg encrypted file (and a physical copy) in a safe location of rarely used admin/root passwords that we only need in an emergency (e.g. when RADIUS goes down). -- Dan White From ge at linuxbox.org Thu Nov 19 01:27:39 2009 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 19 Nov 2009 09:27:39 +0200 Subject: Announcement: Critical Internet Infrastructure WG is now open to public participation In-Reply-To: <202705b0911182025y4aca6491t69651ef1aa2bf581@mail.gmail.com> References: <4B042A0F.4010603@linuxbox.org> <20091118171239.GC23204@virtual.bogons.net> <4B042F08.2080501@linuxbox.org> <4B0467F7.9010906@linuxbox.org> <202705b0911182025y4aca6491t69651ef1aa2bf581@mail.gmail.com> Message-ID: <4B04F36B.700@linuxbox.org> Jorge Amodio wrote: > Still you didn't answer the question. > > What ISOTF stands for and who are "we" ? > > What papers the "we" published ? where ? This is off-topic, so while we give some thought as to what to put on the public web page in the future, here is a quick answer. Future responses, please off-list. ISOTF stands for Internet Security Operations Task Force. It's a loosely affiliated group of people who respond to Internet-wide incident response, and sometimes, need an umbrella name. I can share personal examples of past uses relating to NANOG, which are public. I realize you need a blurb-like answer rather than answer by example. Public is new for us, so give us time: I can share personal examples of past uses relating to NANOG, which are public: 1. Monthly botnet C&C's report, posted for a while from c2reports at isotf.org by Randy Vaughn and myself. 2. We also use it to host some papers such as I did the original DNS Amplification Attacks, which was released prior to being able to get academic credit or decent editing, due to operational needs of major attacks in the wild, with very little information known at the time by operators. 3. ISOI stands for Internet Security Operations and Intelligence. It is a non-profit and closed workshop for vetted and trusted individuals in communities such as MWP, NSP-SEC, MAAWG, and in government, law enforcement, industry and academia in North America and world-wide. In it sensitive subjects relating to the security of the Internet infrastructure, combating cyber crime, phishing, botnets and fraud are being discussed. ISOI 1 was hosted by Cisco and supported by the ISC. http://isotf.org/isoi.html ISOI 2 was hosted by Microsoft and supported by Trend Micro. http://isotf.org/isoi2.html ISOI 3 was hosted by ICANN, ISOC and Afilias, and supported by Sunbelt Software. http://isotf.org/isoi3.html ISOI 4 was hosted by Yahoo! and supported by various local SF-bay companies. http://isotf.org/isoi4.html ISOI 5 was hosted by the Estonian CERT and supported by Norman. http://isotf.org/isoi5.html ISOI 6 was hosted by the University of Texas, Dallas, and supported by Baylor University. http://isotf.org/isoi6.html ISOI 7 was hosted by Websense and ESET, and supported by Facebook and Softlayer: http://isotf.org/isoi7.html Gadi. > > Regards > Jorge > -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From ge at linuxbox.org Thu Nov 19 01:36:18 2009 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 19 Nov 2009 09:36:18 +0200 Subject: Announcement: Critical Internet Infrastructure WG is now open to public participation In-Reply-To: <4B04F36B.700@linuxbox.org> References: <4B042A0F.4010603@linuxbox.org> <20091118171239.GC23204@virtual.bogons.net> <4B042F08.2080501@linuxbox.org> <4B0467F7.9010906@linuxbox.org> <202705b0911182025y4aca6491t69651ef1aa2bf581@mail.gmail.com> <4B04F36B.700@linuxbox.org> Message-ID: <4B04F572.6080403@linuxbox.org> Gadi Evron wrote: > I can share personal examples of past uses relating to NANOG, which are > public: > Oh, duh! The outages mailing list is part of the ISOTF, although clearly its own entity. Gadi. From greg at bestnet.kharkov.ua Thu Nov 19 02:03:22 2009 From: greg at bestnet.kharkov.ua (Gregory Edigarov) Date: Thu, 19 Nov 2009 10:03:22 +0200 Subject: APEWS.ORG Message-ID: <20091119100322.48babc36@greg.bestnet.kharkov.ua> Hello Everybody, Somebody from apews, could you please contact me off list? Thank you. -- With best regards, Gregory Edigarov From regnauld at nsrc.org Thu Nov 19 02:38:52 2009 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 19 Nov 2009 09:38:52 +0100 Subject: Password repository In-Reply-To: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> References: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> Message-ID: <20091119083847.GA23832@macbook.catpipe.net> Jay Nakamura (zeusdadog) writes: > Quick question, does anyone have software/combination of tools they > recommend on centrally store various passwords securely? Home built app with GELI (FreeBSD) encrypted disk image and automated versioning of documents/secure stuff wih a VCS. Works fine in a multi user context, but only one user can access it at a time. From bpfankuch at cpgreeley.com Thu Nov 19 07:19:03 2009 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Thu, 19 Nov 2009 06:19:03 -0700 Subject: Password repository In-Reply-To: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> References: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> Message-ID: <01759D50DC387C45A018FE1817CE27D757895CFF94@CPExchange1.cpgreeley.com> We have used Password Manager XP for quite some time. It supports different user roles, allows security to be set per folder, the encryption levels it supports are insane, and it allows for a "database password" and then user level authentication (which can be tied to NT authentication from the workstation). They also have a client for windows mobile devices. The client also runs in wine exceptionally well. You can configure it to do form filling, and you can define password expiration dates and it will remind you that passwords need changed. Also supports the ability to define a database log, so that all changes can be sent off to a log server. You can also add pretty detailed descriptions to the entry, and you can tie files into the entry as well. Works great for attaching a private key for access to servers via SSH. All of the displayed fields inside of each folder are completely customizable and quite easy to change. It supports multiple users pretty well, however we have had to restore the database from backups once when a user was writing to the database over SSLVPN and the connection dropped. We have used it with a max of about 20 people and it worked great for that number, however as your database gets larger and larger it does take a while to make some changes. -----Original Message----- From: Jay Nakamura [mailto:zeusdadog at gmail.com] Sent: Wednesday, November 18, 2009 8:57 PM To: NANOG Subject: Password repository Quick question, does anyone have software/combination of tools they recommend on centrally store various passwords securely? Thanks. From gordslater at ieee.org Thu Nov 19 08:07:13 2009 From: gordslater at ieee.org (gordon b slater) Date: Thu, 19 Nov 2009 14:07:13 +0000 Subject: Password repository In-Reply-To: <5a318d410911182049u5a54945ase318a53b3a8a5035@mail.gmail.com> References: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> <5a318d410911182049u5a54945ase318a53b3a8a5035@mail.gmail.com> Message-ID: <1258639633.13750.77.camel@ub-g-d2> On Wed, 2009-11-18 at 20:49 -0800, Darren Bolding wrote: > Pwman ...which has the HUGE advantage of being CLI (so useable over SSH sessions from network devices) and has tagging for searching large databases of passes. pwman3 is current version. For most OSs. I've even used it looped through a multitude of nested VTY+SSH+screen sessions - one of which was a Dropbear sshd and client on a 20$ plastic CPE - to save my sorry *ss For GUIs:- Keepassx for most OSs, and Keepass2.x on MS Windows Password Gorilla is a nice one for end-users, most OSs Bruce's Passwordsafe format is a somewhat de-facto standard for import/export. Keepass can do a lot of conversion for you. Some shops use rsync top distribute the masters and set them readonly at filesystem - level though this tends to preclude regular rotation and updating. Beware that some of the commercial offerings are trivially broken or otherwise borked for "work" use. ymmv Whatever you use dump the file to a flat file (crypted of course) and save a statically linked version of the app for those "wow - what password app did we use way back in 2001?" moments. Print a copy every month or so and store securely offsite too - all the usual caveats apply. Once you have a super-duper app for them you tend to crank the pw complexity up to a level where no-one can remember anything nor even recognise regular ones; it's mainly cut and paste, especially if you use X. Unless of course, the OP meant RADIUS pulling on LDAP, PAM, etc ? Gord -- rommon 3 > You have reached the gateway of last resort. Abandon hope all ye who press enter here -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3161 bytes Desc: not available URL: From jbates at brightok.net Thu Nov 19 08:19:25 2009 From: jbates at brightok.net (Jack Bates) Date: Thu, 19 Nov 2009 08:19:25 -0600 Subject: Juniper M120 Alternatives In-Reply-To: <5574b2240911181308y762e702btc43dec7367fa4ad1@mail.gmail.com> References: <28807.82.132.136.147.1258386842.squirrel@webmail-vh.tagadab.com> <443de7ad0911160808oee8f9cfo70e3391f36b054f2@mail.gmail.com> <29152.82.132.136.147.1258388092.squirrel@webmail-vh.tagadab.com> <4B01862E.8090101@linpro.no> <20091117002806.GA302@srv03.cluenet.de> <20091117044624.GB51443@gerbil.cluepon.net> <4B02C028.5060109@brightok.net> <20091117173246.GE51443@gerbil.cluepon.net> <1a9450c80911180604u461875f4pab847d905c688d73@mail.gmail.com> <5574b2240911181308y762e702btc43dec7367fa4ad1@mail.gmail.com> Message-ID: <4B0553ED.4030303@brightok.net> Phil Pierotti wrote: > That's excellent news - any word on when Cisco will be back-porting these > truly useful features from XR to that platform which so many of us are still > running on (ie "traditional IOS")? > The general feeling is that XR won't be ported to a lot of existing hardware, and traditional IOS is just royally screwed (see 12.3T EOL'd and 12.4 bloated and full of bugs, and everything older missing critical PE functionality for unnumbered vlans). Jack (disliking all vendors when it comes to the edge right now) From bclark at spectraaccess.com Thu Nov 19 08:25:41 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Thu, 19 Nov 2009 09:25:41 -0500 Subject: Password repository In-Reply-To: <1258639633.13750.77.camel@ub-g-d2> References: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> <5a318d410911182049u5a54945ase318a53b3a8a5035@mail.gmail.com> <1258639633.13750.77.camel@ub-g-d2> Message-ID: <1258640741.2592.34.camel@Acer-Linux> Don't recall if it was mention but we use a nice little app called MyPMS http://lvoware.com/. Put it on an internal system and then people have to access via a VPN connection to browse into it. That way if a person is no longer with the company, then their VPN has been turned off and they don't have access to it anymore. The reason I like the app is it's OS agnostic for the end user and keeps the data in an SQL DB. On Thu, 2009-11-19 at 14:07 +0000, gordon b slater wrote: > On Wed, 2009-11-18 at 20:49 -0800, Darren Bolding wrote: > > Pwman > > ...which has the HUGE advantage of being CLI (so useable over SSH > sessions from network devices) and has tagging for searching large > databases of passes. pwman3 is current version. For most OSs. > I've even used it looped through a multitude of nested VTY+SSH+screen > sessions - one of which was a Dropbear sshd and client on a 20$ plastic > CPE - to save my sorry *ss > > For GUIs:- > Keepassx for most OSs, and Keepass2.x on MS Windows > Password Gorilla is a nice one for end-users, most OSs > > Bruce's Passwordsafe format is a somewhat de-facto standard for > import/export. Keepass can do a lot of conversion for you. > Some shops use rsync top distribute the masters and set them readonly at > filesystem - level though this tends to preclude regular rotation and > updating. > > Beware that some of the commercial offerings are trivially broken or > otherwise borked for "work" use. ymmv > > Whatever you use dump the file to a flat file (crypted of course) and > save a statically linked version of the app for those "wow - what > password app did we use way back in 2001?" moments. > > Print a copy every month or so and store securely offsite too - all the > usual caveats apply. Once you have a super-duper app for them you tend > to crank the pw complexity up to a level where no-one can remember > anything nor even recognise regular ones; it's mainly cut and paste, > especially if you use X. > > > Unless of course, the OP meant RADIUS pulling on LDAP, PAM, etc ? > > Gord > > -- > rommon 3 > You have reached the gateway of last resort. Abandon hope all > ye who press enter here > > > From rsk at gsp.org Thu Nov 19 08:40:19 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 19 Nov 2009 09:40:19 -0500 Subject: APEWS.ORG In-Reply-To: <20091119100322.48babc36@greg.bestnet.kharkov.ua> References: <20091119100322.48babc36@greg.bestnet.kharkov.ua> Message-ID: <20091119144019.GA5507@gsp.org> On Thu, Nov 19, 2009 at 10:03:22AM +0200, Gregory Edigarov wrote: > Somebody from apews, could you please contact me off list? (a) unlikely to happen (b) probably doesn't matter anyway, apews isn't widely used (c) better directed to the spam-l mailing list ---Rsk From lorell at hathcock.org Thu Nov 19 08:41:53 2009 From: lorell at hathcock.org (Lorell Hathcock) Date: Thu, 19 Nov 2009 08:41:53 -0600 Subject: Recommend DSLAM for Apartment Bldg Message-ID: <00d201ca6926$6fe25ca0$4fa715e0$@org> All: I've got access to the copper pairs in an apartment building of approximately 800 units. I'd like to get a modest, functional, scalable, affordable DSLAM. My WAN connection is an ethernet handoff. I've been looking at the Adtran 1100F and 1200F with 1148 modules. http://www.adtran.com/web/page/portal/Adtran/group/3451 http://www.adtran.com/web/page/portal/Adtran/group/3453 Once I reach the top capacity of these (4 x 48 = 192) , I could just start again with another 1100 or 1200 shelf and go on up from there. Any recommendations? Also, can anyone recommend an outsourced tech support group that speaks Korean and Chinese? Sincerely, Lorell Hathcock OfficeConnect.net | 832-665-3400 x101 (o) | 713-992-2343 (f) | lorell at officeconnect.net Texas State Security Contractor License | ONSSI Certified Channel Partner Axis Communications Channel Partner | BICSI Corporate Member Leviton Authorized Installer From linford at spamhaus.org Thu Nov 19 08:46:16 2009 From: linford at spamhaus.org (Steve Linford) Date: Thu, 19 Nov 2009 14:46:16 +0000 Subject: APEWS.ORG In-Reply-To: <20091119100322.48babc36@greg.bestnet.kharkov.ua> References: <20091119100322.48babc36@greg.bestnet.kharkov.ua> Message-ID: On 19 Nov 2009, at 09:03, Gregory Edigarov wrote: > Hello Everybody, > > Somebody from apews, could you please contact me off list? > Thank you. That's a bit like requesting contact from someone on Mars. APEWS (and *PEWS variations) are 'home-brew DNSBLs' run by a handful of kids from bedrooms and attics, with no clue or care. More than half the world is listed by these tiny DNSBLs and normally nobody ever notices, because nobody uses *PEWS lists except the odd guy running a home mail server for him, the wife and 4 cats. You only noticed because someone told you to go and look, right? There is not a single ISP or production mail server anywhere in the world using APEWS. If you're 'listed' in any *PEWS list, its having no effect on your mail at all. Ignore it. Steve Linford The Spamhaus Project http://www.spamhaus.org From greg at bestnet.kharkov.ua Thu Nov 19 08:52:53 2009 From: greg at bestnet.kharkov.ua (Gregory Edigarov) Date: Thu, 19 Nov 2009 16:52:53 +0200 Subject: APEWS.ORG In-Reply-To: <20091119144019.GA5507@gsp.org> References: <20091119100322.48babc36@greg.bestnet.kharkov.ua> <20091119144019.GA5507@gsp.org> Message-ID: <20091119165253.49b2a4be@greg.bestnet.kharkov.ua> On Thu, 19 Nov 2009 09:40:19 -0500 Rich Kulawiec wrote: > On Thu, Nov 19, 2009 at 10:03:22AM +0200, Gregory Edigarov wrote: > > Somebody from apews, could you please contact me off list? > > (a) unlikely to happen > (b) probably doesn't matter anyway, apews isn't widely used > (c) better directed to the spam-l mailing list the matter was about two bugs i have found while trying to apply their list for my needs. but since you're saying "unlikely to happen" - let bugs sit there for long long time. I wash my hands :-) -- With best regards, Gregory Edigarov From zeusdadog at gmail.com Thu Nov 19 10:21:25 2009 From: zeusdadog at gmail.com (Jay Nakamura) Date: Thu, 19 Nov 2009 11:21:25 -0500 Subject: Password repository In-Reply-To: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> References: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> Message-ID: <9418aca70911190821w3436e74o5e8c227ea7f907cf@mail.gmail.com> All, I wasn't expecting the number of suggestions I got! Thanks all. It looks like keepass is the popular choice by many. We are looking into that. And those that suggested RADIUS, yes, I am moving towards that direction for what can be moved to the RADIUS direction. However, we also managed so many customer's equipment/web site contents/application/networks as well that we can't use RADIUS in those instances. Again, I appreciate having this list to get ideas on various issues I face everyday. On Wed, Nov 18, 2009 at 10:56 PM, Jay Nakamura wrote: > Quick question, does anyone have software/combination of tools they > recommend on centrally store various passwords securely? > > Thanks. > From jg at slash128.com Thu Nov 19 10:31:00 2009 From: jg at slash128.com (Jason Granat) Date: Thu, 19 Nov 2009 08:31:00 -0800 Subject: Password repository In-Reply-To: <9418aca70911190821w3436e74o5e8c227ea7f907cf@mail.gmail.com> References: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> <9418aca70911190821w3436e74o5e8c227ea7f907cf@mail.gmail.com> Message-ID: <4B7C6FA1C76F2E45B236701F379AD4AD01E0F1B6E783@mx2.lab.local> I offer a free service: Send me all your passwords via encrypted email and I promise to keep them safe for you :-) Ok, kidding aside we also use KeePass... On Wed, Nov 18, 2009 at 10:56 PM, Jay Nakamura wrote: > Quick question, does anyone have software/combination of tools they > recommend on centrally store various passwords securely? > > Thanks. > http://slash128.com From leetcheese at gmail.com Thu Nov 19 10:43:54 2009 From: leetcheese at gmail.com (Adam Gray) Date: Thu, 19 Nov 2009 11:43:54 -0500 Subject: No subject Message-ID: From jnegro at billtrust.com Thu Nov 19 10:56:50 2009 From: jnegro at billtrust.com (Jeffrey Negro) Date: Thu, 19 Nov 2009 11:56:50 -0500 Subject: Password repository In-Reply-To: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> References: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> Message-ID: <3C5B084431653D4A9C469A22AFCDB5B9041B4004@LOGAN.billtrust.local> I've used phpchain in the past. It's a freeware you can get off of sourceforge. It runs on a PHP server and stores the passwords per user, blowfish encrypted. It hasn't been updated in a while, but I found it simple, rather helpful, and easy to install and manage. Jeff -----Original Message----- From: Jay Nakamura [mailto:zeusdadog at gmail.com] Sent: Wednesday, November 18, 2009 10:57 PM To: NANOG Subject: Password repository Quick question, does anyone have software/combination of tools they recommend on centrally store various passwords securely? Thanks. From dyoung at mesd.k12.or.us Thu Nov 19 11:53:55 2009 From: dyoung at mesd.k12.or.us (Dan Young) Date: Thu, 19 Nov 2009 09:53:55 -0800 Subject: Password repository In-Reply-To: References: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> Message-ID: <994441ae0911190953p4576de24rb34c6c03bc7be0a2@mail.gmail.com> On Wed, Nov 18, 2009 at 10:34 PM, Randy Bush wrote: >> Quick question, does anyone have software/combination of tools they >> recommend on centrally store various passwords securely? > > > > ascii text file, gpg encrypted, only opened with emacs crypt++.el Or if you prefer vim there is the gnupg.vim plugin: http://www.vim.org/scripts/script.php?script_id=661 :-P -- Dan Young Multnomah ESD - Technology Services 503-257-1562 From blewis at hottopic.com Thu Nov 19 13:00:57 2009 From: blewis at hottopic.com (Bill Lewis) Date: Thu, 19 Nov 2009 13:00:57 -0600 Subject: Wan acceleration Message-ID: <26CF6BC367161D4BAFC39B6ED6F885F301D6115B@TNEXPRD.hottopic.com> Anyone in the group using hardware based wan acceleration and have suggestions? If so, anyone using it over a static IPSEC Cisco VPN link (or other vendor)? I've seen a demo of Cisco WAAS and why they think it's best of breed. Spoke to F5, theirs is still in beta so they suggested Riverbed. I've been told that Riverbed (unlike Cisco) reverse engineers protocols to allow for pass-through though, which worries me in case of failure. Cisco on the other hand licenses the protocols from the various vendors. Other vendors I'm looking at as possibilities are RocketConnect, RadWare, BlueCoat, and Juniper. My connectivity is a tier 2 Metro E at one site (policed at 90Mbps), Tier 1 OC3 at other. Reply to post, or off list. Cheers, Bill Lewis From Jacob.Maynard at citrix.com Thu Nov 19 13:04:53 2009 From: Jacob.Maynard at citrix.com (Jacob Maynard) Date: Thu, 19 Nov 2009 14:04:53 -0500 Subject: Wan acceleration In-Reply-To: <26CF6BC367161D4BAFC39B6ED6F885F301D6115B@TNEXPRD.hottopic.com> References: <26CF6BC367161D4BAFC39B6ED6F885F301D6115B@TNEXPRD.hottopic.com> Message-ID: May want to look into Citrix WanScaler. I wouldn't personally be the most knowledgeable on the product, but I can put you in touch with someone who is if you would like. Thanks, Jacob?Maynard Mobile 954-560-8729 Office?954-689-1319 (ext: 24319) Sr. Escalation Engineer?. Escalation,?Americas Netscaler Support . Citrix Systems, Inc. . jacob.maynard at citrix.com Customer Satisfaction is our goal. If you have feedback regarding my performance, please feel free to contact my Manager? ted.vukelich at citrix.com Are you Satisfied with Citrix Support? Do you need help?? Let me know at http://www.twitter.com/citrixsupport CONFIDENTIALITY NOTICE This e-mail message and all documents which accompany it are intended only for the use of the individual or entity to which addressed, and may contain privileged or confidential information. Any unauthorized disclosure or distribution of this e-mail message is prohibited. Any private files or utilities that are included in this e-mail are intended only for the use of the individual or entity to which this is addressed and distribution of these files or utilities is prohibited. If you have received this e-mail message in error, please notify me immediately. Thank you. -----Original Message----- From: Bill Lewis [mailto:blewis at hottopic.com] Sent: Thursday, November 19, 2009 2:01 PM To: nanog at nanog.org Subject: Wan acceleration Anyone in the group using hardware based wan acceleration and have suggestions? If so, anyone using it over a static IPSEC Cisco VPN link (or other vendor)? I've seen a demo of Cisco WAAS and why they think it's best of breed. Spoke to F5, theirs is still in beta so they suggested Riverbed. I've been told that Riverbed (unlike Cisco) reverse engineers protocols to allow for pass-through though, which worries me in case of failure. Cisco on the other hand licenses the protocols from the various vendors. Other vendors I'm looking at as possibilities are RocketConnect, RadWare, BlueCoat, and Juniper. My connectivity is a tier 2 Metro E at one site (policed at 90Mbps), Tier 1 OC3 at other. Reply to post, or off list. Cheers, Bill Lewis From emccaleb at gmail.com Thu Nov 19 13:25:13 2009 From: emccaleb at gmail.com (Ernest McCaleb) Date: Thu, 19 Nov 2009 14:25:13 -0500 Subject: Wan acceleration In-Reply-To: <26CF6BC367161D4BAFC39B6ED6F885F301D6115B@TNEXPRD.hottopic.com> References: <26CF6BC367161D4BAFC39B6ED6F885F301D6115B@TNEXPRD.hottopic.com> Message-ID: I would certainly look at Riverbed. In my experience they make a product that is just sensational. I could really go on and on about their product but I'd come off sounding like an advertisement. Juniper's WX is a good product also and worth a look. In my experience people tend to go with the WAAS because it can be really cheap with the right bundle. Ernest. On Thu, Nov 19, 2009 at 2:00 PM, Bill Lewis wrote: > Anyone in the group using hardware based wan acceleration and have > suggestions? > > If so, anyone using it over a static IPSEC Cisco VPN link (or other > vendor)? > I've seen a demo of Cisco WAAS and why they think it's best of breed. > Spoke to F5, theirs is still in beta so they suggested Riverbed. I've > been told that Riverbed (unlike Cisco) reverse engineers protocols to > allow for pass-through though, which worries me in case of failure. > Cisco on the other hand licenses the protocols from the various vendors. > > Other vendors I'm looking at as possibilities are RocketConnect, > RadWare, BlueCoat, and Juniper. > > My connectivity is a tier 2 Metro E at one site (policed at 90Mbps), > Tier 1 OC3 at other. > > Reply to post, or off list. > > Cheers, > Bill Lewis > > > -- Ernest McCaleb From canepa at lmi.net Thu Nov 19 13:43:24 2009 From: canepa at lmi.net (Ricardo Canepa) Date: Thu, 19 Nov 2009 11:43:24 -0800 (PST) Subject: Wan acceleration In-Reply-To: References: <26CF6BC367161D4BAFC39B6ED6F885F301D6115B@TNEXPRD.hottopic.com> Message-ID: <20091119114001.K42912@shell.lmi.net> I use WAN acceleration appliances to optimize traffic over satellite links. Initially we used Blue Coats but due to some issues they have, or had, with satellite links we replaced them with Riverbeds and now we have over 100 of them deployed. The Riverbed units have done a much better job and if there is a power failure they fail open, as they use the fail-through NICs which have always worked so far. Regards, --ricardo On Thu, 19 Nov 2009, Ernest McCaleb wrote: > I would certainly look at Riverbed. In my experience they make a product > that is just sensational. I could really go on and on about their product > but I'd come off sounding like an advertisement. > > Juniper's WX is a good product also and worth a look. In my experience > people tend to go with the WAAS because it can be really cheap with the > right bundle. > > Ernest. > > On Thu, Nov 19, 2009 at 2:00 PM, Bill Lewis wrote: > > > Anyone in the group using hardware based wan acceleration and have > > suggestions? > > > > If so, anyone using it over a static IPSEC Cisco VPN link (or other > > vendor)? > > I've seen a demo of Cisco WAAS and why they think it's best of breed. > > Spoke to F5, theirs is still in beta so they suggested Riverbed. I've > > been told that Riverbed (unlike Cisco) reverse engineers protocols to > > allow for pass-through though, which worries me in case of failure. > > Cisco on the other hand licenses the protocols from the various vendors. > > > > Other vendors I'm looking at as possibilities are RocketConnect, > > RadWare, BlueCoat, and Juniper. > > > > My connectivity is a tier 2 Metro E at one site (policed at 90Mbps), > > Tier 1 OC3 at other. > > > > Reply to post, or off list. > > > > Cheers, > > Bill Lewis > > > > > > > > > -- > Ernest McCaleb > From andrey.gordon at gmail.com Thu Nov 19 14:18:03 2009 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Thu, 19 Nov 2009 15:18:03 -0500 Subject: Wan acceleration In-Reply-To: <20091119114001.K42912@shell.lmi.net> References: <26CF6BC367161D4BAFC39B6ED6F885F301D6115B@TNEXPRD.hottopic.com> <20091119114001.K42912@shell.lmi.net> Message-ID: <90ccfc90911191218y4abcc44fi4f995cf94e4b7d98@mail.gmail.com> I don't have much to add to already said, other than, when I looked at Cisco vs. Riverbed vs. BlueCoat - Riverbed came out as a winner for a few major reasons. Can't recall all of them anymore, but the one I think still stands today is that Cisco and BlueCoat optimize protocols and, I believe, mainly CIFS and HTTP. Maybe some exchange stuff, and a few major ones. RIverbed claimed (and seemed to be true when we deployed them) that they don't optimize protocols. They optimize bit streams, which allows them to optimize a far greater number of protocols than Cisco or BlueCoat. At that company, we had a lot of home grown network apps, so that mattered. We deployed them in a few sites that suffered the most, most of them metro area, but one was in Europe (when HQs are in US). Complains stopped. Also, I can't recall if we tested the failure at the time (I think we did and it worked beautifully to open), but today I work for a different company and we have WAAS. Recent failure showed that they don't quite fail the right way. We had it respond to configuration changes, but somehow, it would mess packets up. Only a restart saved the day. So in short, I'd recommend Riverbed. ----- Andrey Gordon [andrey.gordon at gmail.com] On Thu, Nov 19, 2009 at 2:43 PM, Ricardo Canepa wrote: > I use WAN acceleration appliances to optimize traffic over satellite > links. Initially we used Blue Coats but due to some issues they have, or > had, with satellite links we replaced them with Riverbeds and now we have > over 100 of them deployed. > > The Riverbed units have done a much better job and if there is a power > failure they fail open, as they use the fail-through NICs which have > always worked so far. > > Regards, > > > --ricardo > > On Thu, 19 Nov 2009, Ernest McCaleb wrote: > > > I would certainly look at Riverbed. In my experience they make a product > > that is just sensational. I could really go on and on about their product > > but I'd come off sounding like an advertisement. > > > > Juniper's WX is a good product also and worth a look. In my experience > > people tend to go with the WAAS because it can be really cheap with the > > right bundle. > > > > Ernest. > > > > On Thu, Nov 19, 2009 at 2:00 PM, Bill Lewis wrote: > > > > > Anyone in the group using hardware based wan acceleration and have > > > suggestions? > > > > > > If so, anyone using it over a static IPSEC Cisco VPN link (or other > > > vendor)? > > > I've seen a demo of Cisco WAAS and why they think it's best of breed. > > > Spoke to F5, theirs is still in beta so they suggested Riverbed. I've > > > been told that Riverbed (unlike Cisco) reverse engineers protocols to > > > allow for pass-through though, which worries me in case of failure. > > > Cisco on the other hand licenses the protocols from the various > vendors. > > > > > > Other vendors I'm looking at as possibilities are RocketConnect, > > > RadWare, BlueCoat, and Juniper. > > > > > > My connectivity is a tier 2 Metro E at one site (policed at 90Mbps), > > > Tier 1 OC3 at other. > > > > > > Reply to post, or off list. > > > > > > Cheers, > > > Bill Lewis > > > > > > > > > > > > > > > -- > > Ernest McCaleb > > > > From andrew at accessplus.com.au Thu Nov 19 17:19:14 2009 From: andrew at accessplus.com.au (Andrew Cox) Date: Fri, 20 Nov 2009 09:49:14 +1030 Subject: What DNS Is Not In-Reply-To: <4B02225D.9040904@brightok.net> References: <4AF748B3.7060606@evaristesys.com> <4AF83515.8040404@brightok.net> <4B020B0D.401@gdt.id.au> <4B02225D.9040904@brightok.net> Message-ID: <4B05D272.9020900@accessplus.com.au> As a follow up to this, one of the large Australian ISP's has just introduced a DNS redirection "service" for all home customers. "/The BigPond-branded landing page provides BigPond customers with organic search results, sponsored links, display advertisements and intelligent recommendations, all derived from the invalid domain input - much more helpful and friendly than a nasty 404 page error./" http://www.crn.com.au/News/160923,bigpond-redirects-typos-to-unethical-branded-search-page.aspx From randy at psg.com Thu Nov 19 17:38:19 2009 From: randy at psg.com (Randy Bush) Date: Fri, 20 Nov 2009 08:38:19 +0900 Subject: What DNS Is Not In-Reply-To: <4B05D272.9020900@accessplus.com.au> References: <4AF748B3.7060606@evaristesys.com> <4AF83515.8040404@brightok.net> <4B020B0D.401@gdt.id.au> <4B02225D.9040904@brightok.net> <4B05D272.9020900@accessplus.com.au> Message-ID: > "/The BigPond-branded landing page provides BigPond customers with > organic search results with high ecoli From surfer at mauigateway.com Thu Nov 19 19:31:53 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 19 Nov 2009 17:31:53 -0800 Subject: What DNS Is Not Message-ID: <20091119173153.F342645@resin18.mta.everyone.net> --- andrew at accessplus.com.au wrote: From: Andrew Cox As a follow up to this, one of the large Australian ISP's has just introduced a DNS redirection "service" for all home customers. "/The BigPond-branded landing page provides BigPond customers with organic search results, sponsored links, display advertisements and intelligent recommendations, all derived from the invalid domain input - much more helpful and friendly than a nasty 404 page error./" http://www.crn.com.au/News/160923,bigpond-redirects-typos-to-unethical-branded-search-page.aspx ------------------------------------------------------------------------------ >From AUSNOG: On Thu, Nov 19, 2009 at 2:08 PM, Paul Foote wrote: All that's left for them to complete the "404" strategy is to put transparent proxies in place that redirect on real 404's :P Did nobody learn the lessons from when Verisign did this with .com ? baah. In fairness (and I use that term loosly) to BigPond, this is probably a little different to what Verisign did. I haven't seen the BigPond details, but I have seen what Comcast are doing on my US cable connection, and I presume BigPond is doing something similar. The major differences between the two are : * Only responds for "www" addresses. a lookup for "non-existantdomain.com" will still return an NXDOMAIN, but "www.non-existantdomain.com" returns their search page. This means that (the majority of) things like RBL/anti-spam/etc things which broke under Verisign's redirection no longer break. * It's only home users. Business plans/etc are not redirected. Obviously this is different to Verisign where everyone was hit. * You can turn it off, and the page you end up on even gives you the details on how to turn it off. Also despite claims to the contrary, Comcast are not actually "intercepting" DNS traffic - or at least they aren't for me. They are only doing this for traffic sent directly to their DNS servers, and pointing to another DNS server works as expected, as does running your own resolver. I'm still not saying that it's a good thing for them to be doing, but it's not quite as bad or destructive as Verisign's move was... From esuarez at fcaglp.fcaglp.unlp.edu.ar Thu Nov 19 19:50:05 2009 From: esuarez at fcaglp.fcaglp.unlp.edu.ar (Eduardo A. =?iso-8859-1?b?U3XhcmV6?=) Date: Thu, 19 Nov 2009 22:50:05 -0300 Subject: What DNS Is Not In-Reply-To: <20091119173153.F342645@resin18.mta.everyone.net> References: <20091119173153.F342645@resin18.mta.everyone.net> Message-ID: <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> Hi, Quoting Scott Weeks : >> From AUSNOG: > > > On Thu, Nov 19, 2009 at 2:08 PM, Paul Foote wrote: > > All that's left for them to complete the "404" strategy is to > put transparent proxies in place that redirect on real 404's :P > Telefonica is doing that here, and not onlw for www. hostnames... # nmap nonexist.merit.edu. Starting Nmap 4.68 ( http://nmap.org ) at 2009-11-19 23:44 ARST Interesting ports on smartbrowsebr-mx.terra.com (208.70.188.15): Not shown: 1712 filtered ports PORT STATE SERVICE 80/tcp open http 554/tcp open rtsp 1755/tcp open wms Nmap done: 1 IP address (1 host up) scanned in 28.324 seconds Cheers, Eduardo.- -- Eduardo A. Suarez Facultad de Ciencias Astronomicas y Geofisicas Universidad Nacional de La Plata ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From marka at isc.org Thu Nov 19 20:03:13 2009 From: marka at isc.org (Mark Andrews) Date: Fri, 20 Nov 2009 13:03:13 +1100 Subject: What DNS Is Not In-Reply-To: Your message of "Thu, 19 Nov 2009 22:50:05 -0300." <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> Message-ID: <200911200203.nAK23DHI072927@drugs.dv.isc.org> In message <20091119225005.v3lcpv1k9kwok4oo at fcaglp.fcaglp.unlp.edu.ar>, "Eduardo A. =?iso-8859-1?b?U3XhcmV6?=" writes: > Hi, > > Quoting Scott Weeks : > > >> From AUSNOG: > > > > > > On Thu, Nov 19, 2009 at 2:08 PM, Paul Foote wrote: > > > > All that's left for them to complete the "404" strategy is to > > put transparent proxies in place that redirect on real 404's :P > > > > Telefonica is doing that here, and not onlw for www. hostnames... > > # nmap nonexist.merit.edu. It would be intersting to see what would happen if MERIT issued a cease and decist request for using their domain name without permission. > Starting Nmap 4.68 ( http://nmap.org ) at 2009-11-19 23:44 ARST > Interesting ports on smartbrowsebr-mx.terra.com (208.70.188.15): > Not shown: 1712 filtered ports > PORT STATE SERVICE > 80/tcp open http > 554/tcp open rtsp > 1755/tcp open wms > > Nmap done: 1 IP address (1 host up) scanned in 28.324 seconds > > Cheers, > Eduardo.- > > > -- > Eduardo A. Suarez > Facultad de Ciencias Astronomicas y Geofisicas > Universidad Nacional de La Plata > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From surfer at mauigateway.com Thu Nov 19 20:18:31 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 19 Nov 2009 18:18:31 -0800 Subject: What DNS Is Not Message-ID: <20091119181831.F51899F@resin18.mta.everyone.net> --- marka at isc.org wrote: From: Mark Andrews > Telefonica is doing that here, and not onlw for www. hostnames... > > # nmap nonexist.merit.edu. It would be intersting to see what would happen if MERIT issued a cease and decist request for using their domain name without permission. --------------------------------------------- I sure would like to have a front row seat for that! :-) scott From scott at doc.net.au Thu Nov 19 20:21:26 2009 From: scott at doc.net.au (Scott Howard) Date: Thu, 19 Nov 2009 18:21:26 -0800 Subject: What DNS Is Not In-Reply-To: <20091119173153.F342645@resin18.mta.everyone.net> References: <20091119173153.F342645@resin18.mta.everyone.net> Message-ID: Scott, If you're going to blatantly copy what others have written on another mailing list, please at least have the common decency to attribute it to the original author, and/or get the original authors permission first. Scott. On Thu, Nov 19, 2009 at 5:31 PM, Scott Weeks wrote: > > > >From AUSNOG: > > > On Thu, Nov 19, 2009 at 2:08 PM, Paul Foote wrote: > > All that's left for them to complete the "404" strategy is to put > transparent proxies in place that redirect on real 404's :P > > Did nobody learn the lessons from when Verisign did this with .com ? > baah. > > > In fairness (and I use that term loosly) to BigPond, this is probably a > little different to what Verisign did. > > I haven't seen the BigPond details, but I have seen what Comcast are doing > on my US cable connection, and I presume BigPond is doing something similar. > > The major differences between the two are : > * Only responds for "www" addresses. a lookup for "non-existantdomain.com" > will still return an NXDOMAIN, but "www.non-existantdomain.com" returns > their search page. This means that (the majority of) things like > RBL/anti-spam/etc things which broke under Verisign's redirection no longer > break. > * It's only home users. Business plans/etc are not redirected. Obviously > this is different to Verisign where everyone was hit. > * You can turn it off, and the page you end up on even gives you the > details on how to turn it off. > > Also despite claims to the contrary, Comcast are not actually > "intercepting" DNS traffic - or at least they aren't for me. They are only > doing this for traffic sent directly to their DNS servers, and pointing to > another DNS server works as expected, as does running your own resolver. > > > I'm still not saying that it's a good thing for them to be doing, but it's > not quite as bad or destructive as Verisign's move was... > > > > > > From jmamodio at gmail.com Thu Nov 19 20:30:17 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 19 Nov 2009 20:30:17 -0600 Subject: What DNS Is Not In-Reply-To: <200911200203.nAK23DHI072927@drugs.dv.isc.org> References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> Message-ID: <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> >> Telefonica is doing that here, and not onlw for www. hostnames... >> >> # nmap nonexist.merit.edu. > > It would be intersting to see what would happen if MERIT issued a > cease and decist request for using their domain name without > permission. That's really bad, because by doing that they could redirect things like hardcoreporn.merit.edu creating huge liability for the rightful admin of any domain name without them knowing. This will not stop until a big pocket corp sends the legal dogs for hunting. Regards Jorge From esuarez at fcaglp.fcaglp.unlp.edu.ar Thu Nov 19 20:36:50 2009 From: esuarez at fcaglp.fcaglp.unlp.edu.ar (Eduardo A. =?iso-8859-1?b?U3XhcmV6?=) Date: Thu, 19 Nov 2009 23:36:50 -0300 Subject: What DNS Is Not In-Reply-To: <200911200203.nAK23DHI072927@drugs.dv.isc.org> References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> Message-ID: <20091119233650.gdcoqf3xesosoccs@fcaglp.fcaglp.unlp.edu.ar> Quoting Mark Andrews : > It would be intersting to see what would happen if MERIT issued a > cease and decist request for using their domain name without > permission. well they can sue them in the US... # traceroute 208.70.188.15 traceroute to 208.70.188.15 (208.70.188.15), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 so-1-1-0-0-grtbueba2.red.telefonica-wholesale.net (213.140.51.73) 3.913 ms 3.911 ms 3.905 ms 14 Xe7-3-0-0-grtlurem4.red.telefonica-wholesale.net (213.140.49.18) 58.677 ms Xe8-0-0-0-grtlurem4.red.telefonica-wholesale.net (213.140.49.6) 59.780 ms Xe11-0-0-0-grtlurem4.red.telefonica-wholesale.net (213.140.36.150) 59.784 ms 15 Xe8-3-0-0-grtmiabr5.red.telefonica-wholesale.net.126.142.94.in-addr.arpa (94.142.126.113) 129.878 ms 129.878 ms Xe5-1-3-0-grtmiabr4.red.telefonica-wholesale.net (84.16.15.62) 130.615 ms 16 P9-0-0-0-gramiatc2.red.telefonica-wholesale.net (213.140.37.201) 131.945 ms 131.942 ms 131.936 ms 17 84.16.6.150 (84.16.6.150) 129.855 ms 129.850 ms 129.838 ms 18 tdcsdr11-vl-3.mia1.ustdata.net (66.119.65.19) 130.774 ms 130.761 ms 130.754 ms 19 terra-g-3-1-dsw01-mia.tc.terra.com (66.119.71.2) 130.724 ms 130.724 ms 130.719 ms 20 bsw01a-mia.tc.terra.com (208.70.191.245) 134.385 ms 135.200 ms 135.189 ms 21 bsw01a-mia.tc.terra.com (208.70.191.245) 127.450 ms 127.455 ms 127.451 ms Eduardo.- -- Eduardo A. Suarez Facultad de Ciencias Astronomicas y Geofisicas Universidad Nacional de La Plata ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From kgasso-lists at visp.net Thu Nov 19 23:09:21 2009 From: kgasso-lists at visp.net (Kameron Gasso) Date: Thu, 19 Nov 2009 21:09:21 -0800 Subject: Paging a Comcast mail admin... Message-ID: <4B062481.3010003@visp.net> Paging a Comcast mail admin... can you please contact me offlist about one of our mail servers being blocked? It appears your systems have blocklisted one of our outbound customer mail filters, 204.16.46.3, most likely due phishing email originating from a customer account that was compromised (and locked down) 2 days ago. I've tried the request form located at http://www.comcastsupport.com/Forms/NET/blockedprovider.asp, but it's not accepting my input (timing out). I've also tried a couple of phone contacts, but that lead to them telling me that I "need to talk to [my] ISP". Any help would be appreciated. Thanks, -- Kameron Gasso | Senior Systems Administrator | visp.net Direct: 541-955-6903 | Fax: 541-471-0821 From accesss801 at gmail.com Fri Nov 20 00:31:57 2009 From: accesss801 at gmail.com (Dan Bellazetin) Date: Thu, 19 Nov 2009 23:31:57 -0700 Subject: Password repository In-Reply-To: <994441ae0911190953p4576de24rb34c6c03bc7be0a2@mail.gmail.com> References: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> <994441ae0911190953p4576de24rb34c6c03bc7be0a2@mail.gmail.com> Message-ID: <951E1855-DF6D-458F-818C-EB705C2B31BD@gmail.com> I'm not sure if your only considering free software, but if not take a look at password manager pro. http://www.manageengine.com/products/passwordmanagerpro/download.html Dan On Nov 19, 2009, at 10:53 AM, Dan Young wrote: > On Wed, Nov 18, 2009 at 10:34 PM, Randy Bush wrote: >>> Quick question, does anyone have software/combination of tools they >>> recommend on centrally store various passwords securely? >> >> >> >> ascii text file, gpg encrypted, only opened with emacs crypt++.el > > Or if you prefer vim there is the gnupg.vim plugin: > http://www.vim.org/scripts/script.php?script_id=661 > > :-P > > -- > Dan Young > Multnomah ESD - Technology Services > 503-257-1562 > From ssrigha at gmail.com Fri Nov 20 01:11:02 2009 From: ssrigha at gmail.com (shake righa) Date: Fri, 20 Nov 2009 10:11:02 +0300 Subject: Testing Internet Speeds and Capacity Message-ID: <73439e5a0911192311j13e370eboe3e44c1621a3ee17@mail.gmail.com> Hi, how does one truly test internet speeds provided by your provider. Speed test sits give different results that one provided by the provider. Regards, Shake From brandon.galbraith at gmail.com Fri Nov 20 01:15:20 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Fri, 20 Nov 2009 01:15:20 -0600 Subject: Testing Internet Speeds and Capacity In-Reply-To: <73439e5a0911192311j13e370eboe3e44c1621a3ee17@mail.gmail.com> References: <73439e5a0911192311j13e370eboe3e44c1621a3ee17@mail.gmail.com> Message-ID: <366100670911192315s1d22e3dfl4aef0163b1edb19@mail.gmail.com> Speedtest sites (speedtest.net, ndt.anl.gov, etc) or your own tests: http://www.google.com/search?q=nanog+iperf On Fri, Nov 20, 2009 at 1:11 AM, shake righa wrote: > Hi, > > how does one truly test internet speeds provided by your provider. > > Speed test sits give different results that one provided by the provider. > > Regards, > Shake > > -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From andrew at accessplus.com.au Fri Nov 20 01:16:27 2009 From: andrew at accessplus.com.au (Andrew Cox) Date: Fri, 20 Nov 2009 17:46:27 +1030 Subject: Testing Internet Speeds and Capacity In-Reply-To: <73439e5a0911192311j13e370eboe3e44c1621a3ee17@mail.gmail.com> References: <73439e5a0911192311j13e370eboe3e44c1621a3ee17@mail.gmail.com> Message-ID: <4B06424B.6010702@accessplus.com.au> There was a thread on speed testing a little while back. http://www.merit.edu/mail.archives/nanog/msg01842.html Regards, Andrew Cox AccessPlus HNA shake righa wrote: > Hi, > > how does one truly test internet speeds provided by your provider. > > Speed test sits give different results that one provided by the provider. > > Regards, > Shake > > From nanog at maunier.org Fri Nov 20 01:36:48 2009 From: nanog at maunier.org (Pierre-Yves Maunier) Date: Fri, 20 Nov 2009 08:36:48 +0100 Subject: Password repository In-Reply-To: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> References: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> Message-ID: <4B064710.5010206@maunier.org> Jay Nakamura wrote: > Quick question, does anyone have software/combination of tools they > recommend on centrally store various passwords securely? > > Thanks. > > I use opensource, multiplatforms softwares : Keepass password file in a truecrypt container and it works as heaven and securely. Keepass for Windows : http://www.keepass.info/ Keepass for Linux/Mac OS : http://www.keepassx.org/ Truecrypt (all platforms) : http://www.truecrypt.org/ Pierre-Yves Maunier From jna at retina.net Fri Nov 20 01:48:51 2009 From: jna at retina.net (John Adams) Date: Thu, 19 Nov 2009 23:48:51 -0800 Subject: Password repository In-Reply-To: <4B064710.5010206@maunier.org> References: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> <4B064710.5010206@maunier.org> Message-ID: <0AA1B707-377C-45BF-A2A1-DBBF32F2EA3F@retina.net> I'm a big fan of 1password, but I'm on mac and iPhone. Sent from my iPhone On Nov 19, 2009, at 23:36, Pierre-Yves Maunier wrote: > Jay Nakamura wrote: >> Quick question, does anyone have software/combination of tools they >> recommend on centrally store various passwords securely? >> >> Thanks. >> >> > I use opensource, multiplatforms softwares : > > Keepass password file in a truecrypt container and it works as > heaven and securely. > > Keepass for Windows : http://www.keepass.info/ > Keepass for Linux/Mac OS : http://www.keepassx.org/ > > Truecrypt (all platforms) : http://www.truecrypt.org/ > > > Pierre-Yves Maunier > > From kbroder at accretive-networks.net Fri Nov 20 01:58:57 2009 From: kbroder at accretive-networks.net (Kevin Broderick) Date: Thu, 19 Nov 2009 23:58:57 -0800 Subject: Password repository Message-ID: Pierre-Yves Maunier wrote: >Jay Nakamura wrote: >> Quick question, does anyone have software/combination of tools they >> recommend on centrally store various passwords securely? >> >> Thanks. >> >> >I use opensource, multiplatforms softwares : > >Keepass password file in a truecrypt container and it works as heaven >and securely. > >Keepass for Windows : http://www.keepass.info/ >Keepass for Linux/Mac OS : http://www.keepassx.org/ > >Truecrypt (all platforms) : http://www.truecrypt.org/ > > >Pierre-Yves Maunier > > From jwbensley at gmail.com Fri Nov 20 03:18:13 2009 From: jwbensley at gmail.com (James Bensley) Date: Fri, 20 Nov 2009 09:18:13 +0000 Subject: Testing Internet Speeds and Capacity In-Reply-To: <366100670911192315s1d22e3dfl4aef0163b1edb19@mail.gmail.com> References: <73439e5a0911192311j13e370eboe3e44c1621a3ee17@mail.gmail.com> <366100670911192315s1d22e3dfl4aef0163b1edb19@mail.gmail.com> Message-ID: <3c857e1c0911200118y35ef6951q430ea20b9f994a3e@mail.gmail.com> 2009/11/20 Brandon Galbraith > Speedtest sites (speedtest.net, ndt.anl.gov, etc) or your own tests: > > http://www.google.com/search?q=nanog+iperf Speedtest.net now have their mini speedtest which you can download and put on your servers and then test their speed via your browser. -- Regards, James ;) Samuel Goldwyn - "I'm willing to admit that I may not always be right, but I am never wrong." From maxsec at gmail.com Fri Nov 20 03:30:24 2009 From: maxsec at gmail.com (Martin Hepworth) Date: Fri, 20 Nov 2009 09:30:24 +0000 Subject: edgedirector.com In-Reply-To: <16720fe00911170923x2d81de68o9905ddb7ce662ffe@mail.gmail.com> References: <72cf361e0911170830j359652f7k93103d5b91e59374@mail.gmail.com> <16720fe00911170923x2d81de68o9905ddb7ce662ffe@mail.gmail.com> Message-ID: <72cf361e0911200130j78bd616fpc4391413528ffa78@mail.gmail.com> 2009/11/17 Jeffrey Lyon > You really can't compare EdgeDirector's network to UltraDNS which is > much larger and more resilient by leaps and bounds. I've spoke with > the owner of ED before and decided against using the service. Right > now we're using Afilias and the price isn't much worse, the GUI is > much nicer, and the network is much larger and more redundant. > > We recently walked out on an UltraDNS contract due to deceptive > billing practices. They're a corrupt company, imho. > > Jeff > > > On Tue, Nov 17, 2009 at 11:30 AM, Martin Hepworth > wrote: > > Any one got any comments about edgedirector.com's service(s), esp wrt to > > load balancing, geo-ip stuff etc. > > > > They seem to be way way cheaper than ultradns, esp when you adding in > geo-ip > > load sharing and such. So is there wnay reason WHY its cheaper? > > > > -- > > Martin Hepworth > > Oxford, UK > > > > > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications of The IRC Company, Inc. > > Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - > 21 to find out how to "protect your booty." > Jeffrey can't see any info on the Afilias web site on them doing stuff with GNS type solutions - maybe I should do something odd like talk to them ;-) -- Martin Hepworth Oxford, UK From tony at lava.net Fri Nov 20 05:59:47 2009 From: tony at lava.net (Antonio Querubin) Date: Fri, 20 Nov 2009 01:59:47 -1000 (HST) Subject: backupdns.com down? Message-ID: Anyone else having trouble reaching backupdns.com or their nameservers? Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From jwbensley at gmail.com Fri Nov 20 06:09:08 2009 From: jwbensley at gmail.com (James Bensley) Date: Fri, 20 Nov 2009 12:09:08 +0000 Subject: backupdns.com down? In-Reply-To: References: Message-ID: <3c857e1c0911200409x4afc3135qb6e2220ea9551419@mail.gmail.com> Not working for me. -- Regards, James ;) Joan Crawford - "I, Joan Crawford, I believe in the dollar. Everything I earn, I spend." From jared at puck.nether.net Fri Nov 20 07:26:23 2009 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 20 Nov 2009 08:26:23 -0500 Subject: backupdns.com down? In-Reply-To: <3c857e1c0911200409x4afc3135qb6e2220ea9551419@mail.gmail.com> References: <3c857e1c0911200409x4afc3135qb6e2220ea9551419@mail.gmail.com> Message-ID: <35649EC0-8320-4C0A-A0C6-83B8FE77EB0B@puck.nether.net> A plug for the secondary dns service I run (free!) http://puck.nether.net/dns/ Jared Mauch On Nov 20, 2009, at 7:09 AM, James Bensley wrote: > Not working for me. > > > -- > Regards, > James ;) > > Joan Crawford > > - "I, Joan Crawford, I believe in the dollar. Everything I earn, I > spend." From mpalmer at hezmatt.org Fri Nov 20 08:40:40 2009 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sat, 21 Nov 2009 01:40:40 +1100 Subject: What DNS Is Not In-Reply-To: <4B05D272.9020900@accessplus.com.au> References: <4AF748B3.7060606@evaristesys.com> <4AF83515.8040404@brightok.net> <4B020B0D.401@gdt.id.au> <4B02225D.9040904@brightok.net> <4B05D272.9020900@accessplus.com.au> Message-ID: <20091120144040.GQ25450@hezmatt.org> On Fri, Nov 20, 2009 at 09:49:14AM +1030, Andrew Cox wrote: > As a follow up to this, one of the large Australian ISP's has just > introduced a DNS redirection "service" for all home customers. > > "/The BigPond-branded landing page provides BigPond customers with > organic search results, sponsored links, display advertisements and > intelligent recommendations, all derived from the invalid domain input - > much more helpful and friendly than a nasty 404 page error./" *Facepalm* Maybe my browser's just doing something wrong, but when was the last time you got a "nasty 404 page error" for an NXDOMAIN response? - Matt *mumblemumble*journalists*mumblemumble* From jeffshultz at wvi.com Fri Nov 20 09:56:41 2009 From: jeffshultz at wvi.com (Jeff Shultz) Date: Fri, 20 Nov 2009 07:56:41 -0800 Subject: Testing Internet Speeds and Capacity In-Reply-To: <73439e5a0911192311j13e370eboe3e44c1621a3ee17@mail.gmail.com> References: <73439e5a0911192311j13e370eboe3e44c1621a3ee17@mail.gmail.com> Message-ID: <4B06BC39.8060105@wvi.com> shake righa wrote: > Hi, > > how does one truly test internet speeds provided by your provider. > > Speed test sits give different results that one provided by the provider. > > Regards, > Shake > Nice ISP's will put speed test software on their backbone so you can test the speed of your circuit to the backbone. Remember that the speed your provider quotes you is probably the full throughput of the circuit. Some circuits, such as DSL ones, will read up to 15% slower due to ATM circuit overhead. -- Jeff Shultz From beckman at angryox.com Fri Nov 20 10:34:39 2009 From: beckman at angryox.com (Peter Beckman) Date: Fri, 20 Nov 2009 11:34:39 -0500 Subject: Password repository In-Reply-To: <0AA1B707-377C-45BF-A2A1-DBBF32F2EA3F@retina.net> References: <9418aca70911181956l387bc17ar539615dacfdc2c05@mail.gmail.com> <4B064710.5010206@maunier.org> <0AA1B707-377C-45BF-A2A1-DBBF32F2EA3F@retina.net> Message-ID: On Thu, 19 Nov 2009, John Adams wrote: > I'm a big fan of 1password, but I'm on mac and iPhone. I'll second that. 1Password truly is fabulous, though it's strength is the Auto-website login feature with a hotkey. When in your browser, Command+Option+\, type some characters of the site or description, hit enter, and it opens your default browser, goes to the site and logs you in. Integrates on all browsers: Safari, Firefox, Opera and others. Supports secure notes, has a well designed strong password generator, can be synced over the network to multiple other computers via Dropbox (or whatever you want to use, rsync works too), and has great integration with the iPhone as well as a browser-based client for use on non-Mac computers. If you are not using a Mac, or are using a mixed bag of operating systems, 1Password is probably not best. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From cscora at apnic.net Fri Nov 20 13:07:42 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 21 Nov 2009 05:07:42 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200911201907.nAKJ7g1K010291@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 21 Nov, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 303515 Prefixes after maximum aggregation: 141876 Deaggregation factor: 2.14 Unique aggregates announced to Internet: 149990 Total ASes present in the Internet Routing Table: 32755 Prefixes per ASN: 9.27 Origin-only ASes present in the Internet Routing Table: 28465 Origin ASes announcing only one prefix: 13890 Transit ASes present in the Internet Routing Table: 4290 Transit-only ASes present in the Internet Routing Table: 101 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 39 Max AS path prepend of ASN (22394) 36 Prefixes from unregistered ASNs in the Routing Table: 641 Unregistered ASNs in the Routing Table: 131 Number of 32-bit ASNs allocated by the RIRs: 325 Prefixes from 32-bit ASNs in the Routing Table: 268 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 178 Number of addresses announced to Internet: 2135526784 Equivalent to 127 /8s, 73 /16s and 141 /24s Percentage of available address space announced: 57.6 Percentage of allocated address space announced: 65.3 Percentage of available address space allocated: 88.2 Percentage of address space in use by end-sites: 80.1 Total number of prefixes smaller than registry allocations: 145792 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 72525 Total APNIC prefixes after maximum aggregation: 25316 APNIC Deaggregation factor: 2.86 Prefixes being announced from the APNIC address blocks: 69057 Unique aggregates announced from the APNIC address blocks: 30639 APNIC Region origin ASes present in the Internet Routing Table: 3873 APNIC Prefixes per ASN: 17.83 APNIC Region origin ASes announcing only one prefix: 1056 APNIC Region transit ASes present in the Internet Routing Table: 595 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 22 Number of APNIC addresses announced to Internet: 471116320 Equivalent to 28 /8s, 20 /16s and 170 /24s Percentage of available APNIC address space announced: 80.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 43/8, 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, 175/8, 180/8, 182/8, 183/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: 128091 Total ARIN prefixes after maximum aggregation: 67322 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 102319 Unique aggregates announced from the ARIN address blocks: 38824 ARIN Region origin ASes present in the Internet Routing Table: 13364 ARIN Prefixes per ASN: 7.66 ARIN Region origin ASes announcing only one prefix: 5178 ARIN Region transit ASes present in the Internet Routing Table: 1320 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 39 Number of ARIN addresses announced to Internet: 731512352 Equivalent to 43 /8s, 153 /16s and 254 /24s Percentage of available ARIN address space announced: 64.1 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 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/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, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 70128 Total RIPE prefixes after maximum aggregation: 40973 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 63332 Unique aggregates announced from the RIPE address blocks: 42329 RIPE Region origin ASes present in the Internet Routing Table: 13789 RIPE Prefixes per ASN: 4.59 RIPE Region origin ASes announcing only one prefix: 7170 RIPE Region transit ASes present in the Internet Routing Table: 2068 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 20 Number of RIPE addresses announced to Internet: 405095104 Equivalent to 24 /8s, 37 /16s and 66 /24s Percentage of available RIPE address space announced: 75.5 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-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 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, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 26381 Total LACNIC prefixes after maximum aggregation: 6416 LACNIC Deaggregation factor: 4.11 Prefixes being announced from the LACNIC address blocks: 24694 Unique aggregates announced from the LACNIC address blocks: 13655 LACNIC Region origin ASes present in the Internet Routing Table: 1209 LACNIC Prefixes per ASN: 20.43 LACNIC Region origin ASes announcing only one prefix: 389 LACNIC Region transit ASes present in the Internet Routing Table: 200 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 23 Number of LACNIC addresses announced to Internet: 68308480 Equivalent to 4 /8s, 18 /16s and 78 /24s Percentage of available LACNIC address space announced: 67.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 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: 5891 Total AfriNIC prefixes after maximum aggregation: 1545 AfriNIC Deaggregation factor: 3.81 Prefixes being announced from the AfriNIC address blocks: 4280 Unique aggregates announced from the AfriNIC address blocks: 1382 AfriNIC Region origin ASes present in the Internet Routing Table: 332 AfriNIC Prefixes per ASN: 12.89 AfriNIC Region origin ASes announcing only one prefix: 97 AfriNIC Region transit ASes present in the Internet Routing Table: 69 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 16 Number of AfriNIC addresses announced to Internet: 13490176 Equivalent to 0 /8s, 205 /16s and 216 /24s Percentage of available AfriNIC address space announced: 40.2 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1775 7507 461 Korea Telecom (KIX) 17488 1443 143 134 Hathway IP Over Cable Interne 4755 1277 292 148 TATA Communications formerly 4134 1011 19183 392 CHINANET-BACKBONE 9583 994 73 491 Sify Limited 18101 983 204 34 Reliance Infocom Ltd Internet 7545 905 199 100 TPG Internet Pty Ltd 17974 866 265 61 PT TELEKOMUNIKASI INDONESIA 9829 846 663 23 BSNL National Internet Backbo 24560 802 293 174 Bharti Airtel Ltd., Telemedia 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 4248 3879 312 bellsouth.net, inc. 4323 3739 1054 399 Time Warner Telecom 1785 1778 714 136 PaeTec Communications, Inc. 7018 1582 5838 1034 AT&T WorldNet Services 20115 1518 1483 665 Charter Communications 2386 1296 632 932 AT&T Data Communications Serv 6478 1280 267 368 AT&T Worldnet Services 3356 1227 10967 448 Level 3 Communications, LLC 11492 1142 222 14 Cable One 22773 1121 2600 66 Cox Communications, Inc. 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 30890 514 98 207 Evolva Telecom 3292 446 1906 391 TDC Tele Danmark 35805 445 40 5 United Telecom of Georgia 702 418 1822 336 UUNET - Commercial IP service 9198 417 138 12 Kazakhtelecom Data Network Ad 8551 377 354 41 Bezeq International 8866 367 110 23 Bulgarian Telecommunication C 3320 357 7067 304 Deutsche Telekom AG 3215 349 3144 111 France Telecom Transpac 3301 348 1412 303 TeliaNet Sweden 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 1580 2899 232 UniNet S.A. de C.V. 10620 1017 226 110 TVCABLE BOGOTA 28573 811 665 87 NET Servicos de Comunicao S.A 7303 663 349 95 Telecom Argentina Stet-France 22047 546 302 14 VTR PUNTO NET S.A. 11830 473 308 59 Instituto Costarricense de El 11172 445 99 70 Servicios Alestra S.A de C.V 14117 437 29 11 Telefonica del Sur S.A. 7738 429 858 29 Telecomunicacoes da Bahia S.A 6471 423 96 31 ENTEL CHILE 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 8452 1045 188 7 TEDATA 24863 756 130 46 LINKdotNET AS number 3741 274 857 234 The Internet Solution 2018 190 188 118 Tertiary Education Network 6713 176 167 12 Itissalat Al-MAGHRIB 29571 132 15 8 Ci Telecom Autonomous system 33776 124 7 11 Starcomms Nigeria Limited 29975 122 506 15 Vodacom 5536 121 8 18 Internet Egypt Network 5713 116 508 67 Telkom SA Ltd 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 4248 3879 312 bellsouth.net, inc. 4323 3739 1054 399 Time Warner Telecom 1785 1778 714 136 PaeTec Communications, Inc. 4766 1775 7507 461 Korea Telecom (KIX) 7018 1582 5838 1034 AT&T WorldNet Services 8151 1580 2899 232 UniNet S.A. de C.V. 20115 1518 1483 665 Charter Communications 17488 1443 143 134 Hathway IP Over Cable Interne 2386 1296 632 932 AT&T Data Communications Serv 6478 1280 267 368 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 4323 3739 3340 Time Warner Telecom 1785 1778 1642 PaeTec Communications, Inc. 8151 1580 1348 UniNet S.A. de C.V. 4766 1775 1314 Korea Telecom (KIX) 17488 1443 1309 Hathway IP Over Cable Interne 4755 1277 1129 TATA Communications formerly 11492 1142 1128 Cable One 22773 1121 1055 Cox Communications, Inc. 18566 1059 1049 Covad Communications 8452 1045 1038 TEDATA 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 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 46.0.0.0/16 12654 RIPE NCC RIS Project 46.1.0.0/21 12654 RIPE NCC RIS Project 46.1.24.0/24 12654 RIPE NCC RIS Project 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 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:10 /10:25 /11:65 /12:178 /13:361 /14:640 /15:1224 /16:10751 /17:4981 /18:8536 /19:17597 /20:21414 /21:21258 /22:27471 /23:27405 /24:158697 /25:934 /26:1126 /27:566 /28:229 /29:11 /30:8 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2779 4248 bellsouth.net, inc. 4323 2359 3739 Time Warner Telecom 4766 1440 1775 Korea Telecom (KIX) 1785 1245 1778 PaeTec Communications, Inc. 17488 1219 1443 Hathway IP Over Cable Interne 11492 1064 1142 Cable One 18566 1040 1059 Covad Communications 7018 946 1582 AT&T WorldNet Services 8452 945 1045 TEDATA 10620 922 1017 TVCABLE BOGOTA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 2:1 4:14 8:233 12:2104 13:8 15:22 16:3 17:5 20:36 24:1266 32:49 34:2 38:619 40:99 41:1803 43:1 44:2 46:1 47:21 52:6 55:2 56:2 57:23 58:632 59:610 60:444 61:978 62:949 63:1999 64:3686 65:2365 66:4077 67:1767 68:1001 69:2799 70:615 71:156 72:1752 73:2 74:2000 75:188 76:353 77:840 78:576 79:383 80:943 81:813 82:472 83:440 84:542 85:1023 86:382 87:693 88:424 89:1506 90:56 91:2644 92:427 93:1163 94:1300 95:822 96:201 97:273 98:417 99:30 109:164 110:285 111:456 112:147 113:174 114:291 115:357 116:1085 117:589 118:361 119:800 120:133 121:700 122:1302 123:780 124:1056 125:1352 128:222 129:204 130:135 131:442 132:82 133:16 134:187 135:43 136:232 137:166 138:236 139:84 140:458 141:122 142:385 143:343 144:383 145:52 146:394 147:173 148:557 149:193 150:148 151:171 152:219 153:160 154:2 155:274 156:166 157:313 158:95 159:361 160:294 161:174 162:276 163:163 164:278 165:468 166:490 167:392 168:751 169:160 170:555 171:43 172:1 173:397 174:397 180:184 183:134 184:1 186:176 187:179 188:1340 189:647 190:3244 192:5739 193:4305 194:3351 195:2749 196:1171 198:3575 199:3380 200:5221 201:1396 202:7913 203:8287 204:3960 205:2154 206:2407 207:3027 208:3979 209:3430 210:2529 211:1149 212:1635 213:1619 214:244 215:57 216:4432 217:1348 218:474 219:419 220:1137 221:451 222:300 End of report From cidr-report at potaroo.net Fri Nov 20 16:00:01 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 20 Nov 2009 22:00:01 GMT Subject: BGP Update Report Message-ID: <200911202200.nAKM01vt010615@wattle.apnic.net> BGP Update Report Interval: 12-Nov-09 -to- 19-Nov-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS19108 79808 2.9% 31.5 -- SUDDENLINK-COMMUNICATIONS - Suddenlink Communications 2 - AS4134 40779 1.5% 40.3 -- CHINANET-BACKBONE No.31,Jin-rong Street 3 - AS26610 34289 1.2% 1904.9 -- Universidad Tecnica Federico Santa Maria 4 - AS4323 27280 1.0% 6.2 -- TWTC - tw telecom holdings, inc. 5 - AS1785 19881 0.7% 11.1 -- AS-PAETEC-NET - PaeTec Communications, Inc. 6 - AS8452 19080 0.7% 18.2 -- TEDATA TEDATA 7 - AS17974 17511 0.6% 20.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 8 - AS20115 15125 0.5% 8.8 -- CHARTER-NET-HKY-NC - Charter Communications 9 - AS4766 14167 0.5% 7.5 -- KIXS-AS-KR Korea Telecom 10 - AS6389 13475 0.5% 3.2 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 11 - AS18566 13261 0.5% 12.5 -- COVAD - Covad Communications Co. 12 - AS3356 13139 0.5% 10.7 -- LEVEL3 Level 3 Communications 13 - AS7643 12797 0.5% 22.1 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 14 - AS8151 11707 0.4% 7.4 -- Uninet S.A. de C.V. 15 - AS5668 10435 0.4% 13.1 -- AS-5668 - CenturyTel Internet Holdings, Inc. 16 - AS9829 9911 0.4% 11.6 -- BSNL-NIB National Internet Backbone 17 - AS24863 9669 0.3% 10.1 -- LINKdotNET-AS 18 - AS11492 9082 0.3% 7.9 -- CABLEONE - CABLE ONE, INC. 19 - AS7018 8538 0.3% 5.4 -- ATT-INTERNET4 - AT&T WorldNet Services 20 - AS17488 8501 0.3% 5.8 -- HATHWAY-NET-AP Hathway IP Over Cable Internet TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS48754 4481 0.2% 4481.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 2 - AS36239 2430 0.1% 2430.0 -- EXIGEN-CANADA - Exigen Canada 3 - AS26610 34289 1.2% 1904.9 -- Universidad Tecnica Federico Santa Maria 4 - AS31529 2379 0.1% 1189.5 -- DENIC-ANYCAST-AS DENIC eG 5 - AS45782 1060 0.0% 1060.0 -- PHILIPPINEAIRLINES-PH-AP Philippine Airlines Inc. 6 - AS28690 1514 0.1% 757.0 -- ING-DIRECT-UK ING DIRECT UK N.V. 7 - AS42182 659 0.0% 659.0 -- KFMC-ASN AS Number for King Fahd Medical City 8 - AS24758 600 0.0% 600.0 -- MICROEL-AS OOO Microelectronika ISP AS 9 - AS26516 580 0.0% 580.0 -- TMDAS - TMD FRICTION,INC 10 - AS31699 3421 0.1% 570.2 -- BANK-AL-JAZIRA-AS bank al jazira aut.name 11 - AS39803 1032 0.0% 516.0 -- UTI-AS SC UTI COMMUNICATIONS SYSTEMS SRL 12 - AS32738 3113 0.1% 444.7 -- ASPCCCINC - PCC Communications Inc. 13 - AS48434 425 0.0% 425.0 -- TEBYAN Tebyan Cultural and Informative Institute 14 - AS49680 407 0.0% 407.0 -- DCI Armaghan Rahe Talaie 15 - AS38159 799 0.0% 399.5 -- JJNET-AS-ID PT Jivan Jaya Makmur Telecom 16 - AS20637 326 0.0% 326.0 -- EMAZE E*MAZE Communications S.p.A. 17 - AS24933 326 0.0% 326.0 -- MINXS-AS MINXS 18 - AS39386 4205 0.1% 323.5 -- STC-IGW-AS Saudi Telecom Company 19 - AS44208 319 0.0% 319.0 -- FARAHOOSH Farahoosh Dena 20 - AS44618 921 0.0% 307.0 -- GIGABIT-AS Gigabit Ltd. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 91.212.23.0/24 4481 0.1% AS48754 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 2 - 203.162.118.128/ 3779 0.1% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 3 - 200.1.16.0/20 2819 0.1% AS26610 -- Universidad Tecnica Federico Santa Maria 4 - 149.117.190.0/24 2783 0.1% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 5 - 192.12.120.0/24 2582 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 6 - 72.28.75.0/24 2430 0.1% AS36239 -- EXIGEN-CANADA - Exigen Canada 7 - 194.246.96.0/24 2371 0.1% AS31529 -- DENIC-ANYCAST-AS DENIC eG 8 - 92.255.241.0/24 2283 0.1% AS12768 -- ER-TELECOM-AS ER-Telecom Autonomous System AS41661 -- ERTH-CHEL-AS CJSC "Company "ER-Telecom" Chelyabinsk 9 - 200.1.28.0/24 1853 0.1% AS26610 -- Universidad Tecnica Federico Santa Maria 10 - 200.1.16.0/24 1853 0.1% AS26610 -- Universidad Tecnica Federico Santa Maria 11 - 200.1.26.0/24 1853 0.1% AS26610 -- Universidad Tecnica Federico Santa Maria 12 - 200.1.30.0/24 1852 0.1% AS26610 -- Universidad Tecnica Federico Santa Maria 13 - 204.87.169.0/24 1852 0.1% AS26610 -- Universidad Tecnica Federico Santa Maria 14 - 200.1.25.0/24 1852 0.1% AS26610 -- Universidad Tecnica Federico Santa Maria 15 - 200.1.29.0/24 1852 0.1% AS26610 -- Universidad Tecnica Federico Santa Maria 16 - 200.1.20.0/24 1851 0.1% AS26610 -- Universidad Tecnica Federico Santa Maria 17 - 200.1.21.0/24 1851 0.1% AS26610 -- Universidad Tecnica Federico Santa Maria 18 - 200.1.18.0/24 1851 0.1% AS26610 -- Universidad Tecnica Federico Santa Maria 19 - 200.1.23.0/24 1851 0.1% AS26610 -- Universidad Tecnica Federico Santa Maria 20 - 200.1.22.0/24 1850 0.1% AS26610 -- Universidad Tecnica Federico Santa Maria 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 Nov 20 16:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 20 Nov 2009 22:00:00 GMT Subject: The Cidr Report Message-ID: <200911202200.nAKM00Y3010608@wattle.apnic.net> This report has been generated at Fri Nov 20 21:11:45 2009 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 13-11-09 307775 190788 14-11-09 308005 191179 15-11-09 308009 191125 16-11-09 307855 191403 17-11-09 308425 190506 18-11-09 308809 190394 19-11-09 309066 190565 20-11-09 308769 190686 AS Summary 32926 Number of ASes in routing system 14007 Number of ASes announcing only one prefix 4342 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 91477952 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 20Nov09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 308928 190609 118319 38.3% All ASes AS6389 4248 319 3929 92.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4342 1938 2404 55.4% TWTC - tw telecom holdings, inc. AS1785 1778 320 1458 82.0% AS-PAETEC-NET - PaeTec Communications, Inc. AS4766 1892 586 1306 69.0% KIXS-AS-KR Korea Telecom AS17488 1443 282 1161 80.5% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 1121 71 1050 93.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1579 657 922 58.4% Uninet S.A. de C.V. AS4755 1277 395 882 69.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS19262 1045 237 808 77.3% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8452 1045 287 758 72.5% TEDATA TEDATA AS10620 1017 294 723 71.1% TV Cable S.A. AS18101 983 328 655 66.6% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS6478 1280 633 647 50.5% ATT-INTERNET3 - AT&T WorldNet Services AS18566 1059 444 615 58.1% COVAD - Covad Communications Co. AS3356 1229 641 588 47.8% LEVEL3 Level 3 Communications AS9498 653 80 573 87.7% BBIL-AP BHARTI Airtel Ltd. AS4808 764 198 566 74.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4804 635 72 563 88.7% MPX-AS Microplex PTY LTD AS7303 663 102 561 84.6% Telecom Argentina S.A. AS7018 1583 1036 547 34.6% ATT-INTERNET4 - AT&T WorldNet Services AS22047 546 37 509 93.2% VTR BANDA ANCHA S.A. AS7545 920 417 503 54.7% TPG-INTERNET-AP TPG Internet Pty Ltd AS11492 1142 650 492 43.1% CABLEONE - CABLE ONE, INC. AS9443 531 80 451 84.9% INTERNETPRIMUS-AS-AP Primus Telecommunications AS855 624 188 436 69.9% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS17676 565 129 436 77.2% GIGAINFRA Softbank BB Corp. AS4780 564 146 418 74.1% SEEDNET Digital United Inc. AS5668 788 372 416 52.8% AS-5668 - CenturyTel Internet Holdings, Inc. AS28573 811 395 416 51.3% NET Servicos de Comunicao S.A. AS7011 1038 629 409 39.4% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. Total 37165 11963 25202 67.8% Top 30 total Possible Bogus Routes 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 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 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 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-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 91.221.238.0/24 AS49555 ATR Avions de Transport Regional 95.215.108.0/22 AS48924 VOLSBUD-NET BMP VolsBud Ltd 96.8.64.0/18 AS19166 ACRONOC - ACRONOC INC 96.8.127.0/24 AS19166 ACRONOC - ACRONOC INC 109.71.96.0/21 AS49983 MIRONET-AS MiroNet GmbH 117.103.72.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.10.0/24 AS38236 121.50.13.0/24 AS38236 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 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.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 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 193.24.196.0/22 AS6714 ATOMNET ATOM SA 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom s.r.l. 193.104.149.0/24 AS48102 PETERSERVICE ZAO "Peter-Service" 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.207.128.0/20 AS26452 BRING-AS - BringCom, Inc. 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.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc. 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc. 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 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - 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 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 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.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet 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.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 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.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.143.56.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 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.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.86.96.0/19 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 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/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.108.96.0/19 AS577 BACOM - Bell Canada 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.189.62.0/23 AS7132 SBIS-AS - AT&T Internet Services 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.88.0/21 AS36835 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.224.0/24 AS36835 208.77.225.0/24 AS36835 208.77.226.0/24 AS36835 208.77.227.0/24 AS36835 208.77.228.0/24 AS36835 208.77.229.0/24 AS36835 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.77.230.0/24 AS36835 208.77.231.0/24 AS36835 208.87.152.0/21 AS25973 MZIMA - Mzima Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 213.181.70.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.80.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.81.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.83.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.84.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.85.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.86.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.87.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.88.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.89.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.90.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.91.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.92.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.93.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.94.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.95.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, 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.251.207.0/24 AS1239 SPRINTLINK - Sprint 222.0.0.0/8 AS9484 MOBINET-AS-MN Mobicom Company. AS Mobinet Internet Service Provider 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 morrowc.lists at gmail.com Fri Nov 20 16:43:42 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 20 Nov 2009 17:43:42 -0500 Subject: backupdns.com down? In-Reply-To: <35649EC0-8320-4C0A-A0C6-83B8FE77EB0B@puck.nether.net> References: <3c857e1c0911200409x4afc3135qb6e2220ea9551419@mail.gmail.com> <35649EC0-8320-4C0A-A0C6-83B8FE77EB0B@puck.nether.net> Message-ID: <75cb24520911201443s43f3fb4eufce5c7313b1ca209@mail.gmail.com> On Fri, Nov 20, 2009 at 8:26 AM, Jared Mauch wrote: > A plug for the secondary dns service I run (free!) > +9 it's also v6 enabled (if that matters to you) and pretty simple to setup/use. Thanks Jared! -Chris > http://puck.nether.net/dns/ > > Jared Mauch > > On Nov 20, 2009, at 7:09 AM, James Bensley wrote: > >> Not working for me. >> >> >> -- Regards, >> James ;) >> >> Joan >> Crawford >> - "I, Joan Crawford, I believe in the dollar. Everything I earn, I >> spend." > > From sethm at rollernet.us Fri Nov 20 16:46:06 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 20 Nov 2009 14:46:06 -0800 Subject: backupdns.com down? In-Reply-To: <75cb24520911201443s43f3fb4eufce5c7313b1ca209@mail.gmail.com> References: <3c857e1c0911200409x4afc3135qb6e2220ea9551419@mail.gmail.com> <35649EC0-8320-4C0A-A0C6-83B8FE77EB0B@puck.nether.net> <75cb24520911201443s43f3fb4eufce5c7313b1ca209@mail.gmail.com> Message-ID: <4B071C2E.1040101@rollernet.us> Christopher Morrow wrote: > On Fri, Nov 20, 2009 at 8:26 AM, Jared Mauch wrote: >> A plug for the secondary dns service I run (free!) >> > > +9 > > it's also v6 enabled (if that matters to you) and pretty simple to setup/use. > Someone should probably update the FAQ if that's true. Q: Do you support IPv6? A: The nameserver software supports IPv6 records, but we currently can not respond to IPv6 transport requests, nor can we perform zone transfers from IPv6 addresses. ~Seth From morrowc.lists at gmail.com Fri Nov 20 17:00:24 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 20 Nov 2009 18:00:24 -0500 Subject: backupdns.com down? In-Reply-To: <4B071C2E.1040101@rollernet.us> References: <3c857e1c0911200409x4afc3135qb6e2220ea9551419@mail.gmail.com> <35649EC0-8320-4C0A-A0C6-83B8FE77EB0B@puck.nether.net> <75cb24520911201443s43f3fb4eufce5c7313b1ca209@mail.gmail.com> <4B071C2E.1040101@rollernet.us> Message-ID: <75cb24520911201500n5944e7b5s619f7d98a730971d@mail.gmail.com> On Fri, Nov 20, 2009 at 5:46 PM, Seth Mattinen wrote: > Christopher Morrow wrote: >> >> On Fri, Nov 20, 2009 at 8:26 AM, Jared Mauch >> wrote: >>> >>> A plug for the secondary dns service I run (free!) >>> >> >> +9 >> >> it's also v6 enabled (if that matters to you) and pretty simple to >> setup/use. >> > > Someone should probably update the FAQ if that's true. > > Q: Do you support IPv6? > A: The nameserver software supports IPv6 records, but we currently can not > respond to IPv6 transport requests, nor can we perform zone transfers from > IPv6 addresses. huh?? (dig over ipv6, seemingly working for me) ;; ANSWER SECTION: rarc.net. 21600 IN NS ns03.ops-netman.net. rarc.net. 21600 IN NS ns02.ops-netman.net. rarc.net. 21600 IN NS ns01.ops-netman.net. rarc.net. 21600 IN NS puck.nether.net. ;; ADDITIONAL SECTION: ns01.ops-netman.net. 1800 IN A 71.246.230.124 ns02.ops-netman.net. 21600 IN A 71.246.230.124 ns03.ops-netman.net. 21600 IN A 64.151.66.228 puck.nether.net. 86400 IN A 204.42.254.5 puck.nether.net. 86400 IN AAAA 2001:418:3f4::5 ;; Query time: 72 msec ;; SERVER: 2001:418:3f4::5#53(2001:418:3f4 axfr's seem to also work: > dig AXFR rarc.net @2001:470:e03a:246:230::2 ; <<>> DiG 9.7.0b1 <<>> AXFR rarc.net @2001:470:e03a:246:230::2 ;; global options: +cmd rarc.net. 3600 IN SOA rarc.net. hostmaster.rarc.net. 16 10800 3600 604800 3600 methinks your v6 pathings are foobar?? -Chris From jared at puck.nether.net Fri Nov 20 17:31:53 2009 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 20 Nov 2009 18:31:53 -0500 Subject: backupdns.com down? In-Reply-To: <4B071C2E.1040101@rollernet.us> References: <3c857e1c0911200409x4afc3135qb6e2220ea9551419@mail.gmail.com> <35649EC0-8320-4C0A-A0C6-83B8FE77EB0B@puck.nether.net> <75cb24520911201443s43f3fb4eufce5c7313b1ca209@mail.gmail.com> <4B071C2E.1040101@rollernet.us> Message-ID: <8AB913EF-B98D-47B1-A432-E53687AECCCB@puck.nether.net> I will correct this later. Jared Mauch On Nov 20, 2009, at 5:46 PM, Seth Mattinen wrote: > Christopher Morrow wrote: >> On Fri, Nov 20, 2009 at 8:26 AM, Jared Mauch >> wrote: >>> A plug for the secondary dns service I run (free!) >>> >> +9 >> it's also v6 enabled (if that matters to you) and pretty simple to >> setup/use. > > Someone should probably update the FAQ if that's true. > > Q: Do you support IPv6? > A: The nameserver software supports IPv6 records, but we currently > can not respond to IPv6 transport requests, nor can we perform zone > transfers from IPv6 addresses. > > ~Seth From sean at donelan.com Fri Nov 20 17:42:37 2009 From: sean at donelan.com (Sean Donelan) Date: Fri, 20 Nov 2009 18:42:37 -0500 (EST) Subject: Smartcard and non-password methods (was Re: Password repository) Message-ID: <200911201830220.32BF5B92.12974@clifden.donelan.com> Are any network providers supporting smartcards or other non-password based authentication methods? Passwords always end up blaming the user for choosing/not remembering good passwords instead of blaming the technology for choosing/not doing things so the user isn't forced to work around its flaws. I know about the DOD Common Access Card. One-time code-generator tokens seem more widely used by single enterprises. But inter-operable credentials still seem to be one of those great unsolved problems for compter security. Are passwords still the only lowest-common-denominator? From sethm at rollernet.us Fri Nov 20 17:46:36 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 20 Nov 2009 15:46:36 -0800 Subject: backupdns.com down? In-Reply-To: <75cb24520911201500n5944e7b5s619f7d98a730971d@mail.gmail.com> References: <3c857e1c0911200409x4afc3135qb6e2220ea9551419@mail.gmail.com> <35649EC0-8320-4C0A-A0C6-83B8FE77EB0B@puck.nether.net> <75cb24520911201443s43f3fb4eufce5c7313b1ca209@mail.gmail.com> <4B071C2E.1040101@rollernet.us> <75cb24520911201500n5944e7b5s619f7d98a730971d@mail.gmail.com> Message-ID: <4B072A5C.6030302@rollernet.us> Christopher Morrow wrote: > > > methinks your v6 pathings are foobar?? > My v6 is fine, I didn't write this: https://puck.nether.net/dns/static/faq.html ~Seth From andy at nosignal.org Fri Nov 20 19:45:03 2009 From: andy at nosignal.org (Andy Davidson) Date: Sat, 21 Nov 2009 01:45:03 +0000 Subject: Strip AS in BGP peer In-Reply-To: References: Message-ID: <4B07461F.5010703@nosignal.org> Sherwin Ang wrote: > well here it goes. we'll soon form a new internet exchange and i > would like to suggest a model in the route-server wherein the > route-server would strip out it's own AS and give the neighbors/peers > the AS's of the members. I have seen this in Any2IX but i have no > idea on how to implement it as if i am the Any2 route-server. Hi, Sherwin Sorry for the late reply. We (LONAP, London UK) have deployed our route-servers using BIRD and OpenBGPd on unix servers, rather than traditional big iron hardware for the following reasons : - Availability of the 'stripped asn' feature as you describe. - Multiple RIBs per BGP instance, so that route-server participants who filter (on the route-server) can do so without causing shadowing of prefixes. - Don't need the high-capacity forwarding - the route-servers swap prefixes, not traffic. As other posters in this thread have described, it's also possible to do this with the Quagga software, but the current codebase appears to creak (and then croak !) with scale, when multiple-ribs are enabled. This email is pretty brief; the exchange community have been discussing this and publishing talks on the subject since the beginning of the year, as our understanding of the problems of running the common open-source so I can point you to some resources that you may find interesting : Our decisions and introduction to the LONAP service : http://www.uknof.org.uk/uknof13/Davidson-LONAP_routeservers.pdf INEX (Dublin, IE) describe the per-peer RIB problem and Quagga problems : http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Hilliard-Why_use_Quagga_for_Route_Servers.pdf LINX (London, UK) also describe the per-peer RIB problem and explain their efforts to solve the Quagga problems : http://www.uknof.org.uk/uknof13/Hughes-IXP_routeservers.pdf EuroIX route server activity report from October : http://www.ripe.net/ripe/meetings/ripe-59/presentations/hiliard-euroix-update.pdf (Situation is more evolved now, but I don't know if more recent slides are public) The situation is likely to move quickly by the middle of next year, if there is interest it sounds like a good operational BOF for N'49. Andy From jared at puck.nether.net Fri Nov 20 19:52:06 2009 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 20 Nov 2009 20:52:06 -0500 Subject: backupdns.com down? In-Reply-To: <4B072A5C.6030302@rollernet.us> References: <3c857e1c0911200409x4afc3135qb6e2220ea9551419@mail.gmail.com> <35649EC0-8320-4C0A-A0C6-83B8FE77EB0B@puck.nether.net> <75cb24520911201443s43f3fb4eufce5c7313b1ca209@mail.gmail.com> <4B071C2E.1040101@rollernet.us> <75cb24520911201500n5944e7b5s619f7d98a730971d@mail.gmail.com> <4B072A5C.6030302@rollernet.us> Message-ID: On Nov 20, 2009, at 6:46 PM, Seth Mattinen wrote: > Christopher Morrow wrote: >> methinks your v6 pathings are foobar?? > > My v6 is fine, I didn't write this: > > https://puck.nether.net/dns/static/faq.html > > ~Seth I've added a bit more text to this page, constructive comments and feedback are welcome regarding the service. - Jared From johnl at iecc.com Sat Nov 21 08:38:32 2009 From: johnl at iecc.com (John Levine) Date: 21 Nov 2009 14:38:32 -0000 Subject: Smartcard and non-password methods (was Re: Password repository) In-Reply-To: <200911201830220.32BF5B92.12974@clifden.donelan.com> Message-ID: <20091121143832.56867.qmail@simone.iecc.com> > Are passwords still the only lowest-common-denominator? There's OpenID, where a provider can use any verification process it wants, but all the OpenID providers I know use ordinary passwords. R's, John From jbates at brightok.net Sat Nov 21 08:57:55 2009 From: jbates at brightok.net (Jack Bates) Date: Sat, 21 Nov 2009 08:57:55 -0600 Subject: Smartcard and non-password methods (was Re: Password repository) In-Reply-To: <20091121143832.56867.qmail@simone.iecc.com> References: <20091121143832.56867.qmail@simone.iecc.com> Message-ID: <4B07FFF3.5070006@brightok.net> John Levine wrote: >> Are passwords still the only lowest-common-denominator? > > There's OpenID, where a provider can use any verification process it > wants, but all the OpenID providers I know use ordinary passwords. > Yeah, and every ISP would probably use key authentication, except there's not a simple distribution method for the multitude of ways clients might connect and handling temporary issues such as a customer connecting from a public site via webmail. So if a customer needs a password to retrieve or unlock a cert, they see no reason for a cert. This shows in the limited support for client certificates in standard software. Due to the limited support and increased overhead in supporting getting a client cert installed, they end up not being used. The same could be said for other protocols, though. Kerberos rocks, even does good with M$ networks, but there is no click and have fun kerberos support that I've seen for ISP networks. On the other hand, even with a very hands free implementation, I'm sure people would complain "but I want to let my son authenticate to this with my username/password, but not have access to this." Obviously, such a problem is best solved with "son" having his own auth, which may have different resources than the parent's, which is easily maintained and billable based on the resources actually required (see any number of Profile setups on fee based services; ie, netflix). Jack (off topic, and annoyed with the way we do things today) From mpalmer at hezmatt.org Sat Nov 21 11:31:55 2009 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sun, 22 Nov 2009 04:31:55 +1100 Subject: Smartcard and non-password methods (was Re: Password repository) In-Reply-To: <20091121143832.56867.qmail@simone.iecc.com> References: <200911201830220.32BF5B92.12974@clifden.donelan.com> <20091121143832.56867.qmail@simone.iecc.com> Message-ID: <20091121173155.GY25450@hezmatt.org> On Sat, Nov 21, 2009 at 02:38:32PM -0000, John Levine wrote: > > Are passwords still the only lowest-common-denominator? > > There's OpenID, where a provider can use any verification process it > wants, but all the OpenID providers I know use ordinary passwords. myvidoop.com does OpenID auth based on pictures. It's... interesting to use. - Matt From stasinia at msoe.edu Sat Nov 21 12:40:26 2009 From: stasinia at msoe.edu (Adam Stasiniewicz) Date: Sat, 21 Nov 2009 12:40:26 -0600 Subject: Smartcard and non-password methods (was Re: Password repository) In-Reply-To: <200911201830220.32BF5B92.12974@clifden.donelan.com> References: <200911201830220.32BF5B92.12974@clifden.donelan.com> Message-ID: <001601ca6ada$1895dd90$49c198b0$@edu> Sadly, passwords are the least common denominator. The biggest problems with 2 factor devices (smart cards, OTPs, etc) is having to buy, configure, and distribute them; plus get them to work with all the myriad of applications. Certificates that are issued to computers/web browsers suffer from a lack of portability (i.e. by design, the user shouldn't be able to export and share the certificate with anyone they want). Plus with any solution using certificates (client or smart card) a substantial reconfiguration is required to support websites/applications being able to process certificate logons. IMHO, even though OTPs are the less secure of the two types of two-factor products, I see them growing faster than any other method. From an end-user perspective, they are small/portable, don't require a reader, and don't require any special OS, web browser, or software. For an infrastructure perspective, it is easier to convert a website to support OTPs (simply change the function that runs the password validation; instead of having to install and configure a special module/component that would handle the mutual auth required by certificates). Also, many of the OTP vendors are working on making their products function more easily cross platform (while with smart cards, you are basically stuck with either the Microsoft's corporate/non-service provider friendly solution, or have to code your own). My $0.02, Adam Stasiniewicz -----Original Message----- From: Sean Donelan [mailto:sean at donelan.com] Sent: Friday, November 20, 2009 5:43 PM To: nanog at nanog.org Subject: Smartcard and non-password methods (was Re: Password repository) Are any network providers supporting smartcards or other non-password based authentication methods? Passwords always end up blaming the user for choosing/not remembering good passwords instead of blaming the technology for choosing/not doing things so the user isn't forced to work around its flaws. I know about the DOD Common Access Card. One-time code-generator tokens seem more widely used by single enterprises. But inter-operable credentials still seem to be one of those great unsolved problems for compter security. Are passwords still the only lowest-common-denominator? From netfortius at gmail.com Sat Nov 21 14:45:42 2009 From: netfortius at gmail.com (Stefan) Date: Sat, 21 Nov 2009 14:45:42 -0600 Subject: Smartcard and non-password methods (was Re: Password repository) In-Reply-To: <001601ca6ada$1895dd90$49c198b0$@edu> References: <200911201830220.32BF5B92.12974@clifden.donelan.com> <001601ca6ada$1895dd90$49c198b0$@edu> Message-ID: [Sightly off-topic - solution specific] Some European countries have long figured out logistics of smartcard distribution and management in their healthcare systems - some being at the second generation, already. In fact this is a subject "dear" to my heart, as I've researched and attempted a proposal for such systems for a few disparate businesses (with possible extension into eHR), based on a model similar to the one of SSL certificates authority (i.e third party management of authentication, with some very neat federated solution), but nobody seems to care.... Moral? It's been done and it works. Good luck with selling such. Stefan On 11/21/09, Adam Stasiniewicz wrote: > Sadly, passwords are the least common denominator. The biggest problems > with 2 factor devices (smart cards, OTPs, etc) is having to buy, configure, > and distribute them; plus get them to work with all the myriad of > applications. > > Certificates that are issued to computers/web browsers suffer from a lack of > portability (i.e. by design, the user shouldn't be able to export and share > the certificate with anyone they want). Plus with any solution using > certificates (client or smart card) a substantial reconfiguration is > required to support websites/applications being able to process certificate > logons. > > IMHO, even though OTPs are the less secure of the two types of two-factor > products, I see them growing faster than any other method. From an end-user > perspective, they are small/portable, don't require a reader, and don't > require any special OS, web browser, or software. For an infrastructure > perspective, it is easier to convert a website to support OTPs (simply > change the function that runs the password validation; instead of having to > install and configure a special module/component that would handle the > mutual auth required by certificates). Also, many of the OTP vendors are > working on making their products function more easily cross platform (while > with smart cards, you are basically stuck with either the Microsoft's > corporate/non-service provider friendly solution, or have to code your own). > > > My $0.02, > Adam Stasiniewicz > > > -----Original Message----- > From: Sean Donelan [mailto:sean at donelan.com] > Sent: Friday, November 20, 2009 5:43 PM > To: nanog at nanog.org > Subject: Smartcard and non-password methods (was Re: Password repository) > > > Are any network providers supporting smartcards or other non-password > based authentication methods? Passwords always end up blaming the > user for choosing/not remembering good passwords instead of blaming the > technology for choosing/not doing things so the user isn't forced to > work around its flaws. > > I know about the DOD Common Access Card. One-time code-generator tokens > seem more widely used by single enterprises. But inter-operable > credentials still seem to be one of those great unsolved problems for > compter security. Are passwords still the only lowest-common-denominator? > > > > -- Sent from my mobile device ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius From jeffrey.lyon at blacklotus.net Sat Nov 21 15:06:48 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 21 Nov 2009 16:06:48 -0500 Subject: Smartcard and non-password methods (was Re: Password repository) In-Reply-To: <20091121173155.GY25450@hezmatt.org> References: <200911201830220.32BF5B92.12974@clifden.donelan.com> <20091121143832.56867.qmail@simone.iecc.com> <20091121173155.GY25450@hezmatt.org> Message-ID: <16720fe00911211306j4bb51f25o1281c2536c300ef6@mail.gmail.com> I was pretty excited about this post until I found out that myvidoop only works on older version of FF. Jeff On Sat, Nov 21, 2009 at 12:31 PM, Matthew Palmer wrote: > On Sat, Nov 21, 2009 at 02:38:32PM -0000, John Levine wrote: >> > Are passwords still the only lowest-common-denominator? >> >> There's OpenID, where a provider can use any verification process it >> wants, but all the OpenID providers I know use ordinary passwords. > > myvidoop.com does OpenID auth based on pictures. ?It's... interesting to > use. > > - Matt > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From mpalmer at hezmatt.org Sat Nov 21 15:55:43 2009 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sun, 22 Nov 2009 08:55:43 +1100 Subject: Smartcard and non-password methods (was Re: Password repository) In-Reply-To: <16720fe00911211306j4bb51f25o1281c2536c300ef6@mail.gmail.com> References: <200911201830220.32BF5B92.12974@clifden.donelan.com> <20091121143832.56867.qmail@simone.iecc.com> <20091121173155.GY25450@hezmatt.org> <16720fe00911211306j4bb51f25o1281c2536c300ef6@mail.gmail.com> Message-ID: <20091121215543.GC25450@hezmatt.org> On Sat, Nov 21, 2009 at 04:06:48PM -0500, Jeffrey Lyon wrote: > I was pretty excited about this post until I found out that myvidoop > only works on older version of FF. I can only find something about the plugin not working on FF 3.5, but I don't use the plugin since I only use it as an OpenID endpoint. I can't imagine how the main site wouldn't work in FF 3.5 -- it's just a bit of javascripty fluff. - Matt From jeffrey.lyon at blacklotus.net Sat Nov 21 15:58:27 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 21 Nov 2009 16:58:27 -0500 Subject: Smartcard and non-password methods (was Re: Password repository) In-Reply-To: <20091121215543.GC25450@hezmatt.org> References: <200911201830220.32BF5B92.12974@clifden.donelan.com> <20091121143832.56867.qmail@simone.iecc.com> <20091121173155.GY25450@hezmatt.org> <16720fe00911211306j4bb51f25o1281c2536c300ef6@mail.gmail.com> <20091121215543.GC25450@hezmatt.org> Message-ID: <16720fe00911211358g5b4be024sddf6685c681757fd@mail.gmail.com> So it works as a standalone password vault also? Jeff On Sat, Nov 21, 2009 at 4:55 PM, Matthew Palmer wrote: > On Sat, Nov 21, 2009 at 04:06:48PM -0500, Jeffrey Lyon wrote: >> I was pretty excited about this post until I found out that myvidoop >> only works on older version of FF. > > I can only find something about the plugin not working on FF 3.5, but I > don't use the plugin since I only use it as an OpenID endpoint. ?I can't > imagine how the main site wouldn't work in FF 3.5 -- it's just a bit of > javascripty fluff. > > - Matt > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From mpalmer at hezmatt.org Sat Nov 21 16:28:17 2009 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sun, 22 Nov 2009 09:28:17 +1100 Subject: Smartcard and non-password methods (was Re: Password repository) In-Reply-To: <16720fe00911211358g5b4be024sddf6685c681757fd@mail.gmail.com> References: <200911201830220.32BF5B92.12974@clifden.donelan.com> <20091121143832.56867.qmail@simone.iecc.com> <20091121173155.GY25450@hezmatt.org> <16720fe00911211306j4bb51f25o1281c2536c300ef6@mail.gmail.com> <20091121215543.GC25450@hezmatt.org> <16720fe00911211358g5b4be024sddf6685c681757fd@mail.gmail.com> Message-ID: <20091121222817.GE25450@hezmatt.org> On Sat, Nov 21, 2009 at 04:58:27PM -0500, Jeffrey Lyon wrote: > So it works as a standalone password vault also? I don't know. My only experience with it has been as an OpenID endpoint/provider/whatever, and it was on that basis that I replied originally. - Matt From thomh at smx.co.nz Sat Nov 21 17:01:54 2009 From: thomh at smx.co.nz (Thom Hooker) Date: Sun, 22 Nov 2009 12:01:54 +1300 Subject: Any Yahoo! mail admins? Message-ID: <4B087162.9070405@smx.co.nz> Hi Could a Yahoo! mail admin contact me off-list please? We have been getting "421 Temporarily deferred" messages from Yahoo! for the past 48 hours with no signs of any improvement (despite filling out their forms) and an ever growing outbound queue. Thanks Thom SMX Ltd http://smxemail.com ______________________________________________________________________________ This email has been scrubbed for your protection by SMX. For more information visit http://smx.co.nz ______________________________________________________________________________ From bigwavedave at gmail.com Sat Nov 21 18:32:42 2009 From: bigwavedave at gmail.com (Big Wave Dave) Date: Sat, 21 Nov 2009 16:32:42 -0800 Subject: Any Yahoo! mail admins? In-Reply-To: <4B087162.9070405@smx.co.nz> References: <4B087162.9070405@smx.co.nz> Message-ID: <8e124f160911211632l47ea5a31re697a313750523d5@mail.gmail.com> On Sat, Nov 21, 2009 at 3:01 PM, Thom Hooker wrote: > Hi > > Could a Yahoo! mail admin contact me off-list please? > > We have been getting "421 Temporarily deferred" messages from Yahoo! for > the past 48 hours with no signs of any improvement (despite filling out > their forms) and an ever growing outbound queue. > > Thanks > Thom > SMX Ltd > http://smxemail.com I've heard a lot of reports of similar problems from different ISPs and mail providers. Most seem to indicate the recent association with Lashback: http://emailmarketingvoodoo.com/blog/post/lashback-yahoo-team-up/ Dave From vandry at TZoNE.ORG Sat Nov 21 19:54:37 2009 From: vandry at TZoNE.ORG (Phil Vandry) Date: Sat, 21 Nov 2009 20:54:37 -0500 Subject: backupdns.com down? In-Reply-To: <8AB913EF-B98D-47B1-A432-E53687AECCCB@puck.nether.net> References: <3c857e1c0911200409x4afc3135qb6e2220ea9551419@mail.gmail.com> <35649EC0-8320-4C0A-A0C6-83B8FE77EB0B@puck.nether.net> <75cb24520911201443s43f3fb4eufce5c7313b1ca209@mail.gmail.com> <4B071C2E.1040101@rollernet.us> <8AB913EF-B98D-47B1-A432-E53687AECCCB@puck.nether.net> Message-ID: <20091121205437.0fb5c7cf.vandry@TZoNE.ORG> On Fri, 20 Nov 2009 18:31:53 -0500, Jared Mauch wrote: > I will correct this later. I saw that the FAQ is updated but maybe there is one small thing left to correct? When I add a zone and give an IPv6 address as the master IP it just says "Unable to axfr that domain from that IP." and no connection attempt is logged on my side. Thanks for the service. Have you thought about making it reciprocal? If you are prepared to secondary for me then I am prepared to secondary for you :-) -Phil From scott at doc.net.au Sat Nov 21 21:45:06 2009 From: scott at doc.net.au (Scott Howard) Date: Sat, 21 Nov 2009 19:45:06 -0800 Subject: Smartcard and non-password methods (was Re: Password repository) In-Reply-To: <20091121143832.56867.qmail@simone.iecc.com> References: <200911201830220.32BF5B92.12974@clifden.donelan.com> <20091121143832.56867.qmail@simone.iecc.com> Message-ID: On Sat, Nov 21, 2009 at 6:38 AM, John Levine wrote: > > Are passwords still the only lowest-common-denominator? > > There's OpenID, where a provider can use any verification process it > wants, but all the OpenID providers I know use ordinary passwords. > http://yubico.com/developers/openid/ I'm currently trialing Yubico's for access to a number of Unix systems (via PAM), and they seem to work very well. Haven't played around with the OpenID support, so I can't comment on if/how well it works. Scott. From randy at psg.com Sat Nov 21 21:58:36 2009 From: randy at psg.com (Randy Bush) Date: Sun, 22 Nov 2009 12:58:36 +0900 Subject: Smartcard and non-password methods (was Re: Password repository) In-Reply-To: References: <200911201830220.32BF5B92.12974@clifden.donelan.com> <20091121143832.56867.qmail@simone.iecc.com> Message-ID: is there a freebsd pam tacacs+ hack? randy From joelja at bogus.com Sat Nov 21 22:24:04 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 21 Nov 2009 20:24:04 -0800 Subject: Smartcard and non-password methods (was Re: Password repository) In-Reply-To: <200911201830220.32BF5B92.12974@clifden.donelan.com> References: <200911201830220.32BF5B92.12974@clifden.donelan.com> Message-ID: <4B08BCE4.6060105@bogus.com> cards and tokens are a proxy for the use of a certificate authentication system... You can in fact do certificate auth without the use of cards or tokens or mix and match physical tokens and other private key storage depending on need with the same authentication backend (typically ldap). Since this plays nicely with eap-tls, 802.1x. ike, ssl/tls, and s/mime it seems like a shoe-in, once you have a uniform authentication system one is inclined to use it for everything. obviously being involved in several of these with with multiple ca's is something of a pain in the ass if it involves juggling 2 or more tokens instead of passwords. (which are already a problem if you have to trach quite a few non-overlapping ones. Typically tokens continue to require passwords or some other method to unlock them for use, effectively making them two factor (secret+physical possession) Sean Donelan wrote: > > Are any network providers supporting smartcards or other non-password > based authentication methods? Passwords always end up blaming the user > for choosing/not remembering good passwords instead of blaming the > technology for choosing/not doing things so the user isn't forced to > work around its flaws. > > I know about the DOD Common Access Card. One-time code-generator tokens > seem more widely used by single enterprises. But inter-operable > credentials still seem to be one of those great unsolved problems for > compter security. Are passwords still the only lowest-common-denominator? > > From jeffrey.lyon at blacklotus.net Sun Nov 22 01:17:11 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sun, 22 Nov 2009 02:17:11 -0500 Subject: Partial outage at Peer1 Los Angeles (600 W. 7th) Message-ID: <16720fe00911212317s1b72cb87ob3f809797b03e33b@mail.gmail.com> We lost a cabinet in this about 25 minutes ago, anyone else effected? -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From jared at puck.nether.net Sun Nov 22 07:06:06 2009 From: jared at puck.nether.net (Jared Mauch) Date: Sun, 22 Nov 2009 08:06:06 -0500 Subject: backupdns.com down? In-Reply-To: <20091121205437.0fb5c7cf.vandry@TZoNE.ORG> References: <3c857e1c0911200409x4afc3135qb6e2220ea9551419@mail.gmail.com> <35649EC0-8320-4C0A-A0C6-83B8FE77EB0B@puck.nether.net> <75cb24520911201443s43f3fb4eufce5c7313b1ca209@mail.gmail.com> <4B071C2E.1040101@rollernet.us> <8AB913EF-B98D-47B1-A432-E53687AECCCB@puck.nether.net> <20091121205437.0fb5c7cf.vandry@TZoNE.ORG> Message-ID: <59289424-9DBC-415D-8BD3-F3CC9D2ABD34@puck.nether.net> On Nov 21, 2009, at 8:54 PM, Phil Vandry wrote: > On Fri, 20 Nov 2009 18:31:53 -0500, Jared Mauch wrote: >> I will correct this later. > > I saw that the FAQ is updated but maybe there is one small thing left > to correct? When I add a zone and give an IPv6 address as the master > IP it just says "Unable to axfr that domain from that IP." and no > connection attempt is logged on my side. > > Thanks for the service. Have you thought about making it reciprocal? > If you are prepared to secondary for me then I am prepared to > secondary for you :-) Can you please check again? I found something that was causing AXFR to not work for IPv6. If not, we should take this off-list. Thanks for all the bug reports and feedback. - Jared From Brian.Dickson at concertia.com Sun Nov 22 09:26:48 2009 From: Brian.Dickson at concertia.com (Brian Dickson) Date: Sun, 22 Nov 2009 11:26:48 -0400 Subject: backupdns.com down? In-Reply-To: <75cb24520911201443s43f3fb4eufce5c7313b1ca209@mail.gmail.com> References: <3c857e1c0911200409x4afc3135qb6e2220ea9551419@mail.gmail.com> <35649EC0-8320-4C0A-A0C6-83B8FE77EB0B@puck.nether.net>, <75cb24520911201443s43f3fb4eufce5c7313b1ca209@mail.gmail.com> Message-ID: <21D41A38B8859B4A97B1AE2313922B8A8209DC2A40@concertiabl02.concertia.com> Ditto (puck.nether.net +9). Thanks on behalf of everyone, Jared. For those wanting further diversity, I also recommend using any or all of: everydns.net twisted4life.com afraid.org Also easy to use and set-up, IMHO. YMMV. Brian Dickson ________________________________________ From: Christopher Morrow [morrowc.lists at gmail.com] Sent: Friday, November 20, 2009 6:43 PM To: Jared Mauch Cc: nanog at nanog.org Subject: Re: backupdns.com down? On Fri, Nov 20, 2009 at 8:26 AM, Jared Mauch wrote: > A plug for the secondary dns service I run (free!) > +9 it's also v6 enabled (if that matters to you) and pretty simple to setup/use. Thanks Jared! -Chris > http://puck.nether.net/dns/ > > Jared Mauch > > On Nov 20, 2009, at 7:09 AM, James Bensley wrote: > >> Not working for me. >> >> >> -- Regards, >> James ;) >> >> Joan >> Crawford >> - "I, Joan Crawford, I believe in the dollar. Everything I earn, I >> spend." > > From sean at donelan.com Sun Nov 22 12:55:31 2009 From: sean at donelan.com (Sean Donelan) Date: Sun, 22 Nov 2009 13:55:31 -0500 (EST) Subject: Smartcard and non-password methods (was Re: Password repository) In-Reply-To: <4B08BCE4.6060105@bogus.com> References: <200911201830220.32BF5B92.12974@clifden.donelan.com> <4B08BCE4.6060105@bogus.com> Message-ID: <200911221320480.32BF5B92.17275@clifden.donelan.com> On Sat, 21 Nov 2009, Joel Jaeggli wrote: > Since this plays nicely with eap-tls, 802.1x. ike, ssl/tls, and s/mime > it seems like a shoe-in, once you have a uniform authentication system > one is inclined to use it for everything. obviously being involved in > several of these with with multiple ca's is something of a pain in the > ass if it involves juggling 2 or more tokens instead of passwords. > (which are already a problem if you have to trach quite a few > non-overlapping ones. Yep, there are lots of potential technologies out there. I've also implemented several on your list. I'm trying to stay neutral about the technology, as long as it works. I suppose my question was more about market share/mind share. Figure out where everyone else is already go, and then get in front of that :-). So where is the market going beyond passwords? From morrowc.lists at gmail.com Sun Nov 22 22:52:36 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 22 Nov 2009 23:52:36 -0500 Subject: Smartcard and non-password methods (was Re: Password repository) In-Reply-To: References: <200911201830220.32BF5B92.12974@clifden.donelan.com> <20091121143832.56867.qmail@simone.iecc.com> Message-ID: <75cb24520911222052l5bcb31bcyb573812307d8c95f@mail.gmail.com> On Sat, Nov 21, 2009 at 10:45 PM, Scott Howard wrote: > On Sat, Nov 21, 2009 at 6:38 AM, John Levine wrote: > >> > Are passwords still the only lowest-common-denominator? >> >> There's OpenID, where a provider can use any verification process it >> wants, but all the OpenID providers I know use ordinary passwords. >> > > http://yubico.com/developers/openid/ > > I'm currently trialing Yubico's for access to a number of Unix systems (via > PAM), and they seem to work very well. ?Haven't played around with the +1 for yubico's simplicity to setup/use. They also support a 'run your own auth server' model, so if you've got a closed system you don't have to find a way to sneak out http/s links to yubico-land. > OpenID support, so I can't comment on if/how well it works. I have not used their openid support either... but it looks promising. -Chris From drew.weaver at thenap.com Mon Nov 23 08:02:48 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Mon, 23 Nov 2009 09:02:48 -0500 Subject: Anyone from Global Crossing on-list? Message-ID: Hi, I'm seeking someone at GLBX who can assist me with an issue we've been having, all attempts at resolution via customer service/trouble tickets (ucommand) have failed. thanks, -Drew From bortzmeyer at nic.fr Mon Nov 23 09:10:43 2009 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 23 Nov 2009 16:10:43 +0100 Subject: Who has AS 1712? Message-ID: <20091123151043.GA11349@nic.fr> % whois -h whois.ripe.net AS1712 aut-num: AS1712 as-name: FR-RENATER-ENST descr: Ecole Nationale Superieure des Telecommunications, descr: Paris, France. descr: FR % whois -h whois.arin.net AS1712 OrgName: Twilight Communications City: Wallis StateProv: TX Country: US And, yes, AS 1712 is actually used by both and announced :-( From jeffrey.lyon at blacklotus.net Mon Nov 23 09:13:58 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 23 Nov 2009 10:13:58 -0500 Subject: Who has AS 1712? In-Reply-To: <20091123151043.GA11349@nic.fr> References: <20091123151043.GA11349@nic.fr> Message-ID: <16720fe00911230713n798841c0oddd8084f304fbde8@mail.gmail.com> Looks like FR-RENATER-ENST is in the wrong: 1708-1728 Assigned by ARIN whois.arin.net (source: http://www.iana.org/assignments/as-numbers/ ) Jeff On Mon, Nov 23, 2009 at 10:10 AM, Stephane Bortzmeyer wrote: > % whois -h whois.ripe.net AS1712 > > aut-num: ? ? ? ?AS1712 > as-name: ? ? ? ?FR-RENATER-ENST > descr: ? ? ? ? ?Ecole Nationale Superieure des Telecommunications, > descr: ? ? ? ? ?Paris, France. > descr: ? ? ? ? ?FR > > % whois -h whois.arin.net AS1712 > > OrgName: ? ?Twilight Communications > City: ? ? ? Wallis > StateProv: ?TX > Country: ? ?US > > And, yes, AS 1712 is actually used by both and announced :-( > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From bortzmeyer at nic.fr Mon Nov 23 09:18:23 2009 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 23 Nov 2009 16:18:23 +0100 Subject: Who has AS 1712? In-Reply-To: <16720fe00911230713n798841c0oddd8084f304fbde8@mail.gmail.com> References: <20091123151043.GA11349@nic.fr> <16720fe00911230713n798841c0oddd8084f304fbde8@mail.gmail.com> Message-ID: <20091123151823.GA13268@nic.fr> On Mon, Nov 23, 2009 at 10:13:58AM -0500, Jeffrey Lyon wrote a message of 42 lines which said: > Looks like FR-RENATER-ENST is in the wrong: You mean RIPE-NCC is wrong? Because this AS is used by ENST for many years and is registered in the RIPE database... From fweimer at bfk.de Mon Nov 23 09:19:33 2009 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 23 Nov 2009 15:19:33 +0000 Subject: Who has AS 1712? In-Reply-To: <16720fe00911230713n798841c0oddd8084f304fbde8@mail.gmail.com> (Jeffrey Lyon's message of "Mon\, 23 Nov 2009 10\:13\:58 -0500") References: <20091123151043.GA11349@nic.fr> <16720fe00911230713n798841c0oddd8084f304fbde8@mail.gmail.com> Message-ID: <827hthclq2.fsf@mid.bfk.de> * Jeffrey Lyon: > Looks like FR-RENATER-ENST is in the wrong: > > 1708-1728 Assigned by ARIN whois.arin.net > (source: http://www.iana.org/assignments/as-numbers/ ) It could have been ERXed (or whatever the process is called for AS numbers). -- 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 woody at pch.net Mon Nov 23 09:41:34 2009 From: woody at pch.net (Bill Woodcock) Date: Mon, 23 Nov 2009 07:41:34 -0800 (PST) Subject: Who has AS 1712? In-Reply-To: <20091123151043.GA11349@nic.fr> References: <20091123151043.GA11349@nic.fr> Message-ID: On Mon, 23 Nov 2009, Stephane Bortzmeyer wrote: > % whois -h whois.ripe.net AS1712 > as-name: FR-RENATER-ENST > > % whois -h whois.arin.net AS1712 > OrgName: Twilight Communications That would be ARIN, rather than RIPE: http://www.iana.org/assignments/as-numbers/as-numbers.xml "1708-1728 Assigned by ARIN whois.arin.net" > And, yes, AS 1712 is actually used by both and announced :-( Ouch, that's unfortunate. -Bill From ljb at merit.edu Mon Nov 23 10:06:31 2009 From: ljb at merit.edu (Larry Blunk) Date: Mon, 23 Nov 2009 11:06:31 -0500 Subject: Who has AS 1712? In-Reply-To: References: <20091123151043.GA11349@nic.fr> Message-ID: <4B0AB307.9070400@merit.edu> Bill Woodcock wrote: > On Mon, 23 Nov 2009, Stephane Bortzmeyer wrote: > > % whois -h whois.ripe.net AS1712 > > as-name: FR-RENATER-ENST > > > > % whois -h whois.arin.net AS1712 > > OrgName: Twilight Communications > > That would be ARIN, rather than RIPE: > > http://www.iana.org/assignments/as-numbers/as-numbers.xml > "1708-1728 Assigned by ARIN whois.arin.net" > > > And, yes, AS 1712 is actually used by both and announced :-( > > Ouch, that's unfortunate. > > -Bill > > > It's not just AS1712. AS1707 - AS1726 appear to all have been allocated to Renater. AS1707 was ERX'd to RIPE on Sep 9, 2002, but it appears that AS1708-AS1726 were missed and have subsequently been reallocated by ARIN (between Aug 18 and Aug 21, 2009) -Larry From bbillon-ml at splio.fr Mon Nov 23 10:29:59 2009 From: bbillon-ml at splio.fr (Benjamin BILLON) Date: Mon, 23 Nov 2009 17:29:59 +0100 Subject: Who has AS 1712? In-Reply-To: <20091123151043.GA11349@nic.fr> References: <20091123151043.GA11349@nic.fr> Message-ID: <4B0AB887.5090607@splio.fr> The RENATER I'm peering with is AS2200. From my PoV, AS1712 is announced by as174 and as701, with all the respect do to them I doubt their announcing RENATER. From what I receive from as2200: * 137.194.0.0 194.68.129.102 0 2200 2200 2422 1712 i And from bgp table (sniped): sh ip bgp path 1712$ Address Hash Refcount Metric Path 0x52D8F878 352 2 1001 174 1712 i 0x575A9088 1320 1 0 6453 174 1712 i 0x2274494C 1849 2 0 6453 701 1712 ? 0x52CF7AD0 1986 1 0 2200 2200 2422 1712 i 0x66B90AD0 3421 1 0 2200 2422 1712 i Indeed: WTF. Stephane Bortzmeyer a ?crit : > % whois -h whois.ripe.net AS1712 > > aut-num: AS1712 > as-name: FR-RENATER-ENST > descr: Ecole Nationale Superieure des Telecommunications, > descr: Paris, France. > descr: FR > > % whois -h whois.arin.net AS1712 > > OrgName: Twilight Communications > City: Wallis > StateProv: TX > Country: US > > And, yes, AS 1712 is actually used by both and announced :-( > From frederic at placenet.org Mon Nov 23 10:31:01 2009 From: frederic at placenet.org (=?ISO-8859-1?Q?Fr=E9d=E9ric?=) Date: Mon, 23 Nov 2009 17:31:01 +0100 Subject: Who has AS 1712? In-Reply-To: <20091123151043.GA11349@nic.fr> References: <20091123151043.GA11349@nic.fr> Message-ID: <1258993861.8263.10.camel@home> Arin CREATE DATE: 2009-08-19 RIPE CREATE DATE: 1999-10-14 well, we all know the serious of these compagny.... @+ Le lundi 23 novembre 2009 ? 16:10 +0100, Stephane Bortzmeyer a ?crit : > % whois -h whois.ripe.net AS1712 > > aut-num: AS1712 > as-name: FR-RENATER-ENST > descr: Ecole Nationale Superieure des Telecommunications, > descr: Paris, France. > descr: FR > > % whois -h whois.arin.net AS1712 > > OrgName: Twilight Communications > City: Wallis > StateProv: TX > Country: US > > And, yes, AS 1712 is actually used by both and announced :-( > > From bortzmeyer at nic.fr Mon Nov 23 10:36:10 2009 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 23 Nov 2009 17:36:10 +0100 Subject: Who has AS 1712? In-Reply-To: <4B0AB887.5090607@splio.fr> References: <20091123151043.GA11349@nic.fr> <4B0AB887.5090607@splio.fr> Message-ID: <20091123163610.GB24203@nic.fr> On Mon, Nov 23, 2009 at 05:29:59PM +0100, Benjamin BILLON wrote a message of 36 lines which said: > The RENATER I'm peering with is AS2200. The AS number was allocated (ten years ago, as noticed by Fr?d?ric) through the LIR Renater to the customer ENST (now T?l?com Paris Tech). It does not mean it is today announced by Renater. From bortzmeyer at nic.fr Mon Nov 23 10:37:47 2009 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 23 Nov 2009 17:37:47 +0100 Subject: Who has AS 1712? In-Reply-To: <4B0AB307.9070400@merit.edu> References: <20091123151043.GA11349@nic.fr> <4B0AB307.9070400@merit.edu> Message-ID: <20091123163747.GC24203@nic.fr> On Mon, Nov 23, 2009 at 11:06:31AM -0500, Larry Blunk wrote a message of 29 lines which said: > it appears that AS1708-AS1726 were missed and have subsequently been > reallocated by ARIN (between Aug 18 and Aug 21, 2009) Now, interesting question: what can we do to solve the problem? Who should act? I am quite surprised that it is possible to have the same AS number in two different RIRs, to different organizations :-( IP resources certificates will be difficult to deploy here. From morrowc.lists at gmail.com Mon Nov 23 10:46:31 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 23 Nov 2009 11:46:31 -0500 Subject: Who has AS 1712? In-Reply-To: <20091123163747.GC24203@nic.fr> References: <20091123151043.GA11349@nic.fr> <4B0AB307.9070400@merit.edu> <20091123163747.GC24203@nic.fr> Message-ID: <75cb24520911230846h74a37585o86f9589edff66188@mail.gmail.com> On Mon, Nov 23, 2009 at 11:37 AM, Stephane Bortzmeyer wrote: > On Mon, Nov 23, 2009 at 11:06:31AM -0500, > ?Larry Blunk wrote > ?a message of 29 lines which said: > >> it appears that AS1708-AS1726 were missed and have subsequently been >> reallocated by ARIN (between Aug 18 and Aug 21, 2009) > > Now, interesting question: what can we do to solve the problem? Who > should act? > > I am quite surprised that it is possible to have the same AS number in > two different RIRs, to different organizations :-( IP resources > certificates will be difficult to deploy here. oh! we can test out that 'transfer' policy now! :) lookie it's the ip-resources grey market arriving early (or on-time, depending upon which of Geoff's presentations you read over the years) -Chris From morrowc.lists at gmail.com Mon Nov 23 09:50:03 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 23 Nov 2009 10:50:03 -0500 Subject: Who has AS 1712? In-Reply-To: References: <20091123151043.GA11349@nic.fr> Message-ID: <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> On Mon, Nov 23, 2009 at 10:41 AM, Bill Woodcock wrote: > ? ? ?On Mon, 23 Nov 2009, Stephane Bortzmeyer wrote: > ? ?> % whois -h whois.ripe.net AS1712 > ? ?> as-name: ? ? ? ?FR-RENATER-ENST > ? ?> > ? ?> % whois -h whois.arin.net AS1712 > ? ?> OrgName: ? ?Twilight Communications > > That would be ARIN, rather than RIPE: > > http://www.iana.org/assignments/as-numbers/as-numbers.xml > "1708-1728 ? Assigned by ARIN ? whois.arin.net" > > ? ?> And, yes, AS 1712 is actually used by both and announced :-( > > Ouch, that's unfortunate. at least they are protected from eachother... In all seriousness though, how does this get fixed? and... who has to renumber? :) From smb at cs.columbia.edu Mon Nov 23 11:27:24 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 23 Nov 2009 12:27:24 -0500 Subject: Who has AS 1712? In-Reply-To: <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> References: <20091123151043.GA11349@nic.fr> <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> Message-ID: <5F974CF2-33EA-4E85-88C0-06D5A9B092A2@cs.columbia.edu> On Nov 23, 2009, at 10:50 03AM, Christopher Morrow wrote: > On Mon, Nov 23, 2009 at 10:41 AM, Bill Woodcock wrote: >> On Mon, 23 Nov 2009, Stephane Bortzmeyer wrote: >> > % whois -h whois.ripe.net AS1712 >> > as-name: FR-RENATER-ENST >> > >> > % whois -h whois.arin.net AS1712 >> > OrgName: Twilight Communications >> >> That would be ARIN, rather than RIPE: >> >> http://www.iana.org/assignments/as-numbers/as-numbers.xml >> "1708-1728 Assigned by ARIN whois.arin.net" >> >> > And, yes, AS 1712 is actually used by both and announced :-( >> >> Ouch, that's unfortunate. > > at least they are protected from eachother... So much so that they probably can't even email each other to discuss it... --Steve Bellovin, http://www.cs.columbia.edu/~smb From dhetzel at gmail.com Mon Nov 23 11:31:13 2009 From: dhetzel at gmail.com (Dorn Hetzel) Date: Mon, 23 Nov 2009 12:31:13 -0500 Subject: Who has AS 1712? In-Reply-To: <5F974CF2-33EA-4E85-88C0-06D5A9B092A2@cs.columbia.edu> References: <20091123151043.GA11349@nic.fr> <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> <5F974CF2-33EA-4E85-88C0-06D5A9B092A2@cs.columbia.edu> Message-ID: <7db2dcf90911230931n210ba4a3l2631207d97089468@mail.gmail.com> > > >> Ouch, that's unfortunate. > > > > at least they are protected from eachother... > > So much so that they probably can't even email each other to discuss it... > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > > Well, unless they have default routes... :) From carlos at race.com Mon Nov 23 12:26:31 2009 From: carlos at race.com (Carlos Alcantar) Date: Mon, 23 Nov 2009 10:26:31 -0800 Subject: earthlink sorbs Message-ID: <859604546CD1FF488BDB6EA94C896AFBAC30D5@racexchange.race.local> Did earthlink just get put on sorbs over the weekend? We have gotten 4 tickets in today about users not getting email from earthlink/mindspring users and looking thru the logs they are getting blocked for being listed on sorbs. Carlos Alcantar Race Telecommunications, Inc. 101 Haskins Way South San Francisco, CA 94080 From chaim.rieger at gmail.com Mon Nov 23 12:29:14 2009 From: chaim.rieger at gmail.com (chaim.rieger at gmail.com) Date: Mon, 23 Nov 2009 18:29:14 +0000 Subject: earthlink sorbs Message-ID: <892673829-1259000964-cardhu_decombobulator_blackberry.rim.net-176094541-@bda630.bisx.prod.on.blackberry> Same here Many bounces, started this weekend. Sent via BlackBerry from T-Mobile From bclark at spectraaccess.com Mon Nov 23 13:13:52 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Mon, 23 Nov 2009 14:13:52 -0500 Subject: earthlink sorbs In-Reply-To: <892673829-1259000964-cardhu_decombobulator_blackberry.rim.net-176094541-@bda630.bisx.prod.on.blackberry> References: <892673829-1259000964-cardhu_decombobulator_blackberry.rim.net-176094541-@bda630.bisx.prod.on.blackberry> Message-ID: <1259003632.3001.4.camel@acer> Doesn't really say much, but blacklisted would certainly cause those problems rather then just having server problems http://www.dslreports.com/shownews/Earthlink-Suffers-From-Major-Email-Outage-105607 On Mon, 2009-11-23 at 18:29 +0000, chaim.rieger at gmail.com wrote: > Same here > > Many bounces, started this weekend. > > > Sent via BlackBerry from T-Mobile > From mc at hack.org Mon Nov 23 12:42:33 2009 From: mc at hack.org (Michael Widerkrantz) Date: Mon, 23 Nov 2009 19:42:33 +0100 Subject: IPv6 Deployment for the LAN References: <7a6830090910171755q563d081fs7324a2f7d875bc9a@mail.gmail.com> <0B699A91-F45F-45C8-8BC4-61C086FF62A3@nosignal.org> <82B547ED-9637-4435-9F53-253551299555@muada.com> <811292ED-81AD-4F0F-B36A-E6EDF5EE7B94@delong.com> <923D6971-6DEB-4EAE-AB37-8B69FB9A787B@muada.com> <4AE07444.2000905@kl.net> <64539E93-986E-4CA0-A89A-B4A2CA22E0DC@muada.com> <1256238211.4101.13.camel@shrike.home.ludost.net> Message-ID: <868wdxrskm.fsf@brain.hack.org> Vasil Kolev , 2009-10-22 21:03 (+0200): > how should we provide DNS and other useful information for the V6 only > people? What Router Advertisment server did you use? The radvd server supports RFC 5006, an extension to vanilla RA that gives an address to a resolving DNS server (RDNSS). Granted, the client support is still rather poor. I only know of my own radns: http://hack.org/mc/hacks/radns/ and rdnssd: http://rdnssd.linkfanel.net/ The latter is included in some Linux distributions, at least Debian and Ubuntu. -- M.C. Widerkrantz, http://hack.org/mc/ Plain text e-mail, please. OpenPGP welcome. From ssrigha at gmail.com Mon Nov 23 13:36:37 2009 From: ssrigha at gmail.com (shake righa) Date: Mon, 23 Nov 2009 22:36:37 +0300 Subject: Testing Internet Speeds and Capacity In-Reply-To: <4B06BC39.8060105@wvi.com> References: <73439e5a0911192311j13e370eboe3e44c1621a3ee17@mail.gmail.com> <4B06BC39.8060105@wvi.com> Message-ID: <73439e5a0911231136o7110e1a5sddae8c8a3f4c426b@mail.gmail.com> The tools such as iperf need some level of expertise to use. some end users lack this level of expertise. are there any tools simply for end users to use that can accomplish the same task?\ Regards, Shake Righa On Fri, Nov 20, 2009 at 6:56 PM, Jeff Shultz wrote: > shake righa wrote: > >> Hi, >> >> how does one truly test internet speeds provided by your provider. >> >> Speed test sits give different results that one provided by the provider. >> >> Regards, >> Shake >> >> > Nice ISP's will put speed test software on their backbone so you can test > the speed of your circuit to the backbone. > > Remember that the speed your provider quotes you is probably the full > throughput of the circuit. Some circuits, such as DSL ones, will read up to > 15% slower due to ATM circuit overhead. > > -- > Jeff Shultz > From pfunix at gmail.com Mon Nov 23 13:47:03 2009 From: pfunix at gmail.com (Beavis) Date: Mon, 23 Nov 2009 13:47:03 -0600 Subject: ip capacity provider Message-ID: All, I know this is a long shot, but can anyone help me out on getting in touch with carriers in Miami FL. one that can pass ip traffic into latin america?. any help would be greatly appreciated. thanks, -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From sfouant at shortestpathfirst.net Mon Nov 23 14:01:23 2009 From: sfouant at shortestpathfirst.net (sfouant at shortestpathfirst.net) Date: Mon, 23 Nov 2009 20:01:23 +0000 Subject: ip capacity provider Message-ID: <1714806603-1259006475-cardhu_decombobulator_blackberry.rim.net-1611490425-@bda772.bisx.prod.on.blackberry> AS 701 Verizon Business (formerly UUNet) has a POP in Miami I believe, and they connect directly into their AS in LatAm. Regards, Stefan Fouant www.shortestpathfirst.net ------Original Message------ From: Beavis To: nanog at nanog.org Subject: ip capacity provider Sent: Nov 23, 2009 2:47 PM All, I know this is a long shot, but can anyone help me out on getting in touch with carriers in Miami FL. one that can pass ip traffic into latin america?. any help would be greatly appreciated. thanks, -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Sent from my Verizon Wireless BlackBerry From darren at bolding.org Mon Nov 23 14:10:47 2009 From: darren at bolding.org (Darren Bolding) Date: Mon, 23 Nov 2009 12:10:47 -0800 Subject: Recomended data cabling contractors in Bay Area/Peninsula? Message-ID: <5a318d410911231210v423a48ffi38d5ca69e98e784e@mail.gmail.com> Hello, I need to identify a quality data cabling contractor in the Bay Area (Peninsula/Palo-Alto/Redwood City) area, and most of the folks I've worked with before are not available or are doing different things these days. Does anyone have a recommended contractor in this area? This is basic Cat5E/Patch Panel work. Thanks for any suggestions! --D -- -- Darren Bolding -- -- darren at bolding.org -- From bdfleming at kanren.net Mon Nov 23 14:25:07 2009 From: bdfleming at kanren.net (Brad Fleming) Date: Mon, 23 Nov 2009 14:25:07 -0600 Subject: Ethernet over DS3 Converters Message-ID: <0F968957-1FE5-40EE-A572-6C8F1356EDCB@kanren.net> Hello all, My company is searching for some Ethernet over DS3 converters / adaptors for a specific installation. I see several options from Adtran, RAD-Direct, and a couple other (smaller) vendors and was wondering if anyone out there has suggestions or insights. Our needs are pretty simple: We'll need to pass multiple VLANs unless that's simply not possible. We'll need copper 10/100 interfaces on each side. Here are the two main products we're currently eyeing.... Adtran Product: http://www.adtran.com/web/page/portal/Adtran/group/3024 RAD-Direct Product: http://www.rad.com/10/Fast_Ethernet_over_T3_NTU/2480/ Thanks very much for any suggestions. -- Brad Fleming Network Engineer Kansas Research and Education Network Office: 785-856-9800 x.222 Moblie: 785-865-7231 NOC: 866-984-3662 From bking at inline.com Mon Nov 23 14:42:58 2009 From: bking at inline.com (Bryan King) Date: Mon, 23 Nov 2009 14:42:58 -0600 Subject: Ethernet over DS3 Converters In-Reply-To: <0F968957-1FE5-40EE-A572-6C8F1356EDCB@kanren.net> References: <0F968957-1FE5-40EE-A572-6C8F1356EDCB@kanren.net> Message-ID: <4B0AF3D2.9000608@inline.com> Brad Fleming wrote: > Hello all, > > My company is searching for some Ethernet over DS3 converters / adaptors > for a specific installation. I see several options from Adtran, > RAD-Direct, and a couple other (smaller) vendors and was wondering if > anyone out there has suggestions or insights. > > Our needs are pretty simple: > We'll need to pass multiple VLANs unless that's simply not possible. > We'll need copper 10/100 interfaces on each side. > > > Here are the two main products we're currently eyeing.... > > Adtran Product: > http://www.adtran.com/web/page/portal/Adtran/group/3024 > > RAD-Direct Product: > http://www.rad.com/10/Fast_Ethernet_over_T3_NTU/2480/ > > Thanks very much for any suggestions. > -- > Brad Fleming > Network Engineer > Kansas Research and Education Network > Office: 785-856-9800 x.222 > Moblie: 785-865-7231 > NOC: 866-984-3662 > > We currently use Overture Networks for Ethernet over DS3: http://www.overturenetworks.com/products/name/ISG34-45.html You can use them as a simple Ethernet bridge if that is all you need/want, but they also will handle VLAN tagging, tag-in-tag, VLAN switching, rate-limiting, CoS, etc. Some people don't like them because there is no CLI for management only a web-based GUI and SNMP. From vincetolo at gmail.com Mon Nov 23 14:59:07 2009 From: vincetolo at gmail.com (Vincent Tolorraerto) Date: Mon, 23 Nov 2009 15:59:07 -0500 Subject: Ethernet over DS3 Converters In-Reply-To: <0F968957-1FE5-40EE-A572-6C8F1356EDCB@kanren.net> References: <0F968957-1FE5-40EE-A572-6C8F1356EDCB@kanren.net> Message-ID: I like the Overture Networks products. Take a look at the link provided by Bryan. Vince On Mon, Nov 23, 2009 at 3:25 PM, Brad Fleming wrote: > Hello all, > > My company is searching for some Ethernet over DS3 converters / adaptors > for a specific installation. I see several options from Adtran, RAD-Direct, > and a couple other (smaller) vendors and was wondering if anyone out there > has suggestions or insights. > > Our needs are pretty simple: > We'll need to pass multiple VLANs unless that's simply not possible. > We'll need copper 10/100 interfaces on each side. > > > Here are the two main products we're currently eyeing.... > > Adtran Product: > http://www.adtran.com/web/page/portal/Adtran/group/3024 > > RAD-Direct Product: > http://www.rad.com/10/Fast_Ethernet_over_T3_NTU/2480/ > > Thanks very much for any suggestions. > -- > Brad Fleming > Network Engineer > Kansas Research and Education Network > Office: 785-856-9800 x.222 > Moblie: 785-865-7231 > NOC: 866-984-3662 > > > From tme at americafree.tv Mon Nov 23 16:40:14 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Mon, 23 Nov 2009 17:40:14 -0500 Subject: Testing Internet Speeds and Capacity In-Reply-To: <73439e5a0911192311j13e370eboe3e44c1621a3ee17@mail.gmail.com> References: <73439e5a0911192311j13e370eboe3e44c1621a3ee17@mail.gmail.com> Message-ID: <034920EA-012D-4116-9768-7BEF78E690CE@americafree.tv> On Nov 20, 2009, at 2:11 AM, shake righa wrote: > Hi, > > how does one truly test internet speeds provided by your provider. > I am going to go back to your original question and ask, for what purpose ? > Speed test sits give different results that one provided by the > provider. > Could well be. Speed tests for one purpose (say, TCP web) may be largely irrelevant for other purposes (say, UDP video). If it really matters - i.e., if you have an application or use case or customer where speed is crucial, then test it using that application, or find a test that mimics that application. If you care about interpreting your tests, you might start here http://shlang.com/writing/tcp-perf.html Regards Marshall > Regards, > Shake > > From randy at psg.com Mon Nov 23 16:58:00 2009 From: randy at psg.com (Randy Bush) Date: Tue, 24 Nov 2009 07:58:00 +0900 Subject: Who has AS 1712? In-Reply-To: <4B0AB307.9070400@merit.edu> References: <20091123151043.GA11349@nic.fr> <4B0AB307.9070400@merit.edu> Message-ID: > It's not just AS1712. AS1707 - AS1726 appear to all have been > allocated to Renater. AS1707 was ERX'd to RIPE on Sep 9, 2002, but it > appears that AS1708-AS1726 were missed and have subsequently been > reallocated by ARIN (between Aug 18 and Aug 21, 2009) this failure is one of the joys of per-rir trust anchors randy From randy at psg.com Mon Nov 23 18:25:56 2009 From: randy at psg.com (Randy Bush) Date: Tue, 24 Nov 2009 09:25:56 +0900 Subject: Who has AS 1712? In-Reply-To: <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> References: <20091123151043.GA11349@nic.fr> <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> Message-ID: > In all seriousness though, how does this get fixed? and... who has to > renumber? :) luckily, it's not a renumber in the ip address sense. but some router jock[ette]s are gonna be even more overworked than usual. how to detect if there are more instances? how to prevent new instances, both asn and ip? randy From alain_durand at cable.comcast.com Mon Nov 23 18:42:34 2009 From: alain_durand at cable.comcast.com (Durand, Alain) Date: Mon, 23 Nov 2009 19:42:34 -0500 Subject: Who has AS 1712? In-Reply-To: Message-ID: On 11/23/09 7:25 PM, "Randy Bush" wrote: > how to prevent new instances, both asn and ip? > The whole value of the RIR is to guarantee this uniqueness. This problem should not have happened. The fact that it has is troublesome. I?ll make a guess that this is a result of a clerical error somewhere in the chain... The answer to the above question seems to be stricter process. - Alain. From randy at psg.com Mon Nov 23 19:03:12 2009 From: randy at psg.com (Randy Bush) Date: Tue, 24 Nov 2009 10:03:12 +0900 Subject: Who has AS 1712? In-Reply-To: References: Message-ID: > The answer to the above question seems to be stricter process. mops schmops. formal rigor and tools, please. randy From jared at puck.nether.net Mon Nov 23 19:11:29 2009 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 23 Nov 2009 20:11:29 -0500 Subject: Who has AS 1712? In-Reply-To: References: <20091123151043.GA11349@nic.fr> <4B0AB307.9070400@merit.edu> Message-ID: <20091124011129.GA60839@puck.nether.net> On Tue, Nov 24, 2009 at 07:58:00AM +0900, Randy Bush wrote: > > It's not just AS1712. AS1707 - AS1726 appear to all have been > > allocated to Renater. AS1707 was ERX'd to RIPE on Sep 9, 2002, but it > > appears that AS1708-AS1726 were missed and have subsequently been > > reallocated by ARIN (between Aug 18 and Aug 21, 2009) > > this failure is one of the joys of per-rir trust anchors I don't see operators jumping at the idea of central trust anchor myself, no more than I see everyone ready to sign the root zone. I see some gTLD and ccTLD operators ready, but not all gTLD and ccTLD operators want it signed. There is perhaps the same issue here. Then again, ARIN doesn't say that an allocated resource is actually usable, they've specifically ducked that one in the past with address space on blacklists or bogon filters... I am curious to see their response now. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From mpetach at netflight.com Mon Nov 23 19:22:54 2009 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 23 Nov 2009 17:22:54 -0800 Subject: Ethernet over DS3 Converters In-Reply-To: <0F968957-1FE5-40EE-A572-6C8F1356EDCB@kanren.net> References: <0F968957-1FE5-40EE-A572-6C8F1356EDCB@kanren.net> Message-ID: <63ac96a50911231722t7f512802l76e972abbc58435e@mail.gmail.com> On Mon, Nov 23, 2009 at 12:25 PM, Brad Fleming wrote: > Hello all, > > My company is searching for some Ethernet over DS3 converters / adaptors for > a specific installation. I see several options from Adtran, RAD-Direct, and > a couple other (smaller) vendors and was wondering if anyone out there has > suggestions or insights. /me wonders how many ISPs still have old NetEdge boxes leftover from mae-east/mae-west extensions lurking in dark cabinets and hidden corners of colos in the san jose and vienna areas they would be more than happy to give away... ^_^; (for those who missed out on that flavour of joy 15 years ago... http://www.networkworld.com/archive/1994/94-01-24rout.html http://web.archive.org/web/19961112045539/www.netedge.com/pages/edge40_datasheet.html OK...that was a frightening bit of reminiscing. ^_^;; *goes back into power-lurking mode again* Matt From jlewis at lewis.org Mon Nov 23 19:25:33 2009 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 23 Nov 2009 20:25:33 -0500 (EST) Subject: Who has AS 1712? In-Reply-To: References: Message-ID: On Mon, 23 Nov 2009, Durand, Alain wrote: > On 11/23/09 7:25 PM, "Randy Bush" wrote: > >> how to prevent new instances, both asn and ip? >> > The whole value of the RIR is to guarantee this uniqueness. This problem > should not have happened. > The fact that it has is troublesome. I?ll make a guess that this is a result > of a clerical error somewhere in the chain... > The answer to the above question seems to be stricter process. Even after that clerical error happened, the subsequent error of assigning an ASN that's already assigned should never have happened. It seems someone (probably multiple someones) never considered this possibility. When assigning a subnet of our IP space to a customer or internal network, first I look for a suitably sized block marked as "open" in our IP space. Then I check our IGP to make sure that block isn't currently routed somewhere. It's a little disappointing that I ever find it is...but it happens. It just happened yesterday in fact. A customer who had some servers turned down had their subnet marked as available for re-use, but it looks like they still have a few servers online in that VLAN and the space obviously isn't ready for re-use. Is it too much to ask that the RIRs query each other's whois servers for an ASN before assigning that ASN?...just to make sure an ASN they think they're responsible for and about to assign hasn't already been assigned by another RIR? That should have been an item on the RIR ASN assignment checklist from the beginning. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From brunner at nic-naa.net Mon Nov 23 20:03:45 2009 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 23 Nov 2009 21:03:45 -0500 Subject: Who has AS 1712? In-Reply-To: <20091124011129.GA60839@puck.nether.net> References: <20091123151043.GA11349@nic.fr> <4B0AB307.9070400@merit.edu> <20091124011129.GA60839@puck.nether.net> Message-ID: <4B0B3F01.10006@nic-naa.net> Jared Mauch wrote: > On Tue, Nov 24, 2009 at 07:58:00AM +0900, Randy Bush wrote: > >>> It's not just AS1712. AS1707 - AS1726 appear to all have been >>> allocated to Renater. AS1707 was ERX'd to RIPE on Sep 9, 2002, but it >>> appears that AS1708-AS1726 were missed and have subsequently been >>> reallocated by ARIN (between Aug 18 and Aug 21, 2009) >>> >> this failure is one of the joys of per-rir trust anchors >> > > I don't see operators jumping at the idea of central trust anchor > myself, no more than I see everyone ready to sign the root zone. > Not everyone gets to sign the IANA root zone. > I see some gTLD and ccTLD operators ready, but not all gTLD and ccTLD > operators want it signed. There is perhaps the same issue here. > I'm looking at the registry service requests for .museum, .org, .com/.net/.name, .biz, and writing .cat's. What gTLD operators are you looking at? What ccTLD operators are you looking at? > Then again, ARIN doesn't say that an allocated resource is actually > usable, they've specifically ducked that one in the past with address > space on blacklists or bogon filters... I am curious to see their response > now. > > - Jared > > From morrowc.lists at gmail.com Mon Nov 23 22:33:01 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 23 Nov 2009 23:33:01 -0500 Subject: Who has AS 1712? In-Reply-To: References: <20091123151043.GA11349@nic.fr> <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> Message-ID: <75cb24520911232033x24bacf13xa3bb9d32599f45ea@mail.gmail.com> On Mon, Nov 23, 2009 at 7:25 PM, Randy Bush wrote: >> In all seriousness though, how does this get fixed? and... who has to >> renumber? :) > > luckily, it's not a renumber in the ip address sense. ?but some router > jock[ette]s are gonna be even more overworked than usual. hope for their sake it's just 1 router :) and 2 transits ... if they have internal bgp setup (more than one router in their peering/transit edge) it's going to cause them some pain :( (at least with only 1 router and 2 bgp peers you could hope to static route around the maintenance event) > how to detect if there are more instances? o Should some form of 'scrape routeviews before assignment' happen at the RIR? (if you don't like o RV, pick another 2-3 sources of data) o How do you make sure each RIR does this act? o Should the customer check public data sources before acceptance? o Is there a 30 day revoke/return dance for Number Resources? > how to prevent new instances, both asn and ip? See above ... It seems sensible to check existing data sources, if that can be automated easily enough? -chris From xaixili at live.com Mon Nov 23 23:02:08 2009 From: xaixili at live.com (Xai Xi) Date: Tue, 24 Nov 2009 05:02:08 +0000 Subject: Testing Internet Speeds and Capacity Message-ID: As mentioned, there is a limitation to TCP-based speed tests - TCP throughput is very sensitive to packet losses, particularly during slow-start, in addition to requiring end-host tuning (as an exercise, try running speedtest.net on a high bandwidth connection). You could use something called "available bandwidth", which is kind of like the "leftover capacity" on your path - I've been using this tool called pathload2: http://www.measurementlab.net/measurement-lab-tools#pathload2 _________________________________________________________________ Keep your friends updated?even when you?re not signed in. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010 From jlewis at lewis.org Mon Nov 23 23:32:55 2009 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 24 Nov 2009 00:32:55 -0500 (EST) Subject: Who has AS 1712? In-Reply-To: <75cb24520911232033x24bacf13xa3bb9d32599f45ea@mail.gmail.com> References: <20091123151043.GA11349@nic.fr> <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> <75cb24520911232033x24bacf13xa3bb9d32599f45ea@mail.gmail.com> Message-ID: On Mon, 23 Nov 2009, Christopher Morrow wrote: >> how to detect if there are more instances? > > o Should some form of 'scrape routeviews before assignment' happen at > the RIR? (if you don't like o RV, pick another 2-3 sources of data) > o How do you make sure each RIR does this act? > o Should the customer check public data sources before acceptance? > o Is there a 30 day revoke/return dance for Number Resources? Checking "global BGP" only works if the ASN is being announced at that instant. That ought to be one of the due diligence steps, but so should checking the various RIR whois servers. Lots of ASNs have been assigned but aren't visible in the global table. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From morrowc.lists at gmail.com Mon Nov 23 23:43:33 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 24 Nov 2009 00:43:33 -0500 Subject: Who has AS 1712? In-Reply-To: References: <20091123151043.GA11349@nic.fr> <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> <75cb24520911232033x24bacf13xa3bb9d32599f45ea@mail.gmail.com> Message-ID: <75cb24520911232143o2603cf85n2108f0a5c7ddb8e6@mail.gmail.com> On Tue, Nov 24, 2009 at 12:32 AM, Jon Lewis wrote: > On Mon, 23 Nov 2009, Christopher Morrow wrote: > >>> how to detect if there are more instances? >> >> o Should some form of 'scrape routeviews before assignment' happen at >> the RIR? (if you don't like o RV, pick another 2-3 sources of data) >> o How do you make sure each RIR does this act? >> o Should the customer check public data sources before acceptance? >> o Is there a 30 day revoke/return dance for Number Resources? > > Checking "global BGP" only works if the ASN is being announced at that > instant. ?That ought to be one of the due diligence steps, but so should > checking the various RIR whois servers. ?Lots of ASNs have been assigned but > aren't visible in the global table. > sure, pick 2-3 ways to check was my point... I ain't writin' RIR policy in nanog maillist traffic :) I presume also there's some '80% check is good enough' standard that's applied along the way because I doubt you'll ever get 100% certainty in this sort of thing, sadly. -Chris > ---------------------------------------------------------------------- > ?Jon Lewis ? ? ? ? ? ? ? ? ? | ?I route > ?Senior Network Engineer ? ? | ?therefore you are > ?Atlantic Net ? ? ? ? ? ? ? ?| > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From swmike at swm.pp.se Tue Nov 24 00:35:50 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 24 Nov 2009 07:35:50 +0100 (CET) Subject: Ethernet over DS3 Converters In-Reply-To: <4B0AF3D2.9000608@inline.com> References: <0F968957-1FE5-40EE-A572-6C8F1356EDCB@kanren.net> <4B0AF3D2.9000608@inline.com> Message-ID: On Mon, 23 Nov 2009, Bryan King wrote: > You can use them as a simple Ethernet bridge if that is all you need/want, > but they also will handle VLAN tagging, tag-in-tag, VLAN switching, > rate-limiting, CoS, etc. Some people don't like them because there is no CLI > for management only a web-based GUI and SNMP. I used some RAD T3-FE media converters from 8 years back or so. They had really small buffers (just a few ms) so if power usage is not a problem, I'd definitely recommend a used 7200 (non-vxr) with NPE-225 and IO-FE and a PA-T3. It probably uses 10x more power than the T3-FE converter, but it does a much better job of getting the traffic thru in a nice friendly manner (fair-queue is really nice). -- Mikael Abrahamsson email: swmike at swm.pp.se From ssrigha at gmail.com Tue Nov 24 00:44:46 2009 From: ssrigha at gmail.com (shake righa) Date: Tue, 24 Nov 2009 09:44:46 +0300 Subject: Testing Internet Speeds and Capacity In-Reply-To: References: Message-ID: <73439e5a0911232244l6d51c11epb0b364c0c13ecaee@mail.gmail.com> At the moment the market is competitive and clients are getting various different offers from different competitors.Thus you find them enquiring about speeds hence need to check on the speeds. onsite engineers too need to be able to test and provide accurate results.thus need for a tool that can provide accurate results. Regards, Shake Righa On 11/24/09, Xai Xi wrote: > > As mentioned, there is a limitation to TCP-based speed tests - TCP > throughput is very sensitive to packet losses, particularly during > slow-start, in addition to requiring end-host tuning (as an exercise, try > running speedtest.net on a high bandwidth connection). You could use > something called "available bandwidth", which is kind of like the "leftover > capacity" on your path - I've been using this tool called pathload2: > http://www.measurementlab.net/measurement-lab-tools#pathload2 > > > _________________________________________________________________ > Keep your friends updated?even when you?re not signed in. > http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010 From leland at taranta.discpro.org Tue Nov 24 00:51:29 2009 From: leland at taranta.discpro.org (Leland Vandervort) Date: Tue, 24 Nov 2009 07:51:29 +0100 Subject: OT: VSS + MEC - port-channel dynamically cloned? Message-ID: <1259045489.12138.5.camel@leland-gandi> Hi all.. this one seems to have stumped even the community forums on CCO ;) Anyone else seen this behaviour? (It's not actually a problem as such since the MEC port-channels are actually working fine, just unexpected the way that it has done it...) We have a few paris of VSS running, and having brought the down-stream access-switches online using MEC we note that the active port-channel that they bind under isn't actually the one configured, but rather a CLONE of the configured one which appears to be dynamically generated. In our case, all ports and port-channel configurations are set to dot1q encapsulation and trunk mode active. For example, we have about 20 3560s MEC'd to the VSS: the MEC comes up, but under a slightly different port-channel identifier: Here's the 3560 side: interface status: Gi0/49 connected trunk a-full a-1000 1000BaseSX SFP Gi0/50 connected trunk a-full a-1000 1000BaseSX SFP Gi0/51 connected trunk a-full a-1000 1000BaseSX SFP Gi0/52 connected trunk a-full a-1000 1000BaseSX SFP #sh int po1 | i Member Members in this channel: Gi0/49 Gi0/50 Gi0/51 Gi0/52 Here's the VSS side: Interface status: Po11 CISCO C3560 A01 notconnect 1 auto auto Po11A connected trunk a-full a-1000 ^^^^ Po11A is not actually configured, but appears to be cloned from Po11 #sh int po11A | i Member Members in this channel: Gi1/1/33 Gi1/1/34 Gi2/1/41 Gi2/1/42 #sh cdp nei | i hacc01-d hacc01-d Gig 2/1/42 140 S I WS-C3560G Gig 0/50 hacc01-d Gig 2/1/41 140 S I WS-C3560G Gig 0/49 hacc01-d Gig 1/1/34 161 S I WS-C3560G Gig 0/52 hacc01-d Gig 1/1/33 161 S | WS-C3560G Gig 0/51 Essentially, for all of the MEC connections, the VSS has created a clone of the configured port-channel to bind the actual physical connections, rather than binding them under the configured port-channel (and suffixed the port-channel number with A or B depending on which chassis was first to bind). Config for port-channel and interfaces all match: VSS SIDE: interface Port-channel11 description CISCO C3560 A01 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 40-48,51,400 switchport mode trunk mtu 9216 end Physical ports are the same config, with channel-group 11 mode active (and repeated for 20 different port-channels each with 4 ports) ACCESS Side: interface Port-channel1 description DIST-VSS-EQX1 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 40-48,51,400 switchport mode trunk mtu 9216 end Similarly, physical ports are the same with channel-group 1 mode active I'm not overly worried about it since the MEC is working with the dynamically generated port-channel, and traffic is flowing correctly... just curious as to why it uses a clone of the configured port-channel, rather than the actual configured port-channel itself. Just find that a bit strange. Thanks, Leland From randy at psg.com Tue Nov 24 00:58:41 2009 From: randy at psg.com (Randy Bush) Date: Tue, 24 Nov 2009 15:58:41 +0900 Subject: Who has AS 1712? In-Reply-To: <75cb24520911232033x24bacf13xa3bb9d32599f45ea@mail.gmail.com> References: <20091123151043.GA11349@nic.fr> <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> <75cb24520911232033x24bacf13xa3bb9d32599f45ea@mail.gmail.com> Message-ID: >> how to detect if there are more instances? > > o Should some form of 'scrape routeviews before assignment' happen at > the RIR? (if you don't like o RV, pick another 2-3 sources of data) > o How do you make sure each RIR does this act? > o Should the customer check public data sources before acceptance? > o Is there a 30 day revoke/return dance for Number Resources? > >> how to prevent new instances, both asn and ip? > > See above ... It seems sensible to check existing data sources, if > that can be automated easily enough? owned resources may not be announced or visible universally. existing data sources deeply suck. rir source data are in different formats, owner identies are not even unique in one rir (how many names does goog have in arin?), let alone coordinated across rirs, much historical data is missing, ... dual ownership is needed for transfer. so i am thinking along the lines of an aged report of cert conflicts. maybe "bob and alice have both owned 42.666.0.0/15 for 77 days." of course this begs the issue of irs not having unique single IDs for bob and alice. randy From morrowc.lists at gmail.com Tue Nov 24 01:14:41 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 24 Nov 2009 02:14:41 -0500 Subject: Testing Internet Speeds and Capacity In-Reply-To: <73439e5a0911232244l6d51c11epb0b364c0c13ecaee@mail.gmail.com> References: <73439e5a0911232244l6d51c11epb0b364c0c13ecaee@mail.gmail.com> Message-ID: <75cb24520911232314p759eba9fmf0ebdffee844182f@mail.gmail.com> On Tue, Nov 24, 2009 at 1:44 AM, shake righa wrote: > At the moment the market is competitive and clients are getting > various different offers from different competitors.Thus you find them > enquiring about speeds hence need to check on the speeds. > > onsite engineers too need to be able to test and provide accurate > results.thus need for a tool that can provide accurate results. see a comment by me in the previously mentioned thread: "swedish isps do this for their customers, perhaps one/some of them could present at a *NOG as to how they do what they do?" -chris From bortzmeyer at nic.fr Tue Nov 24 01:34:20 2009 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 24 Nov 2009 08:34:20 +0100 Subject: Who has AS 1712? In-Reply-To: References: Message-ID: <20091124073420.GA18280@nic.fr> On Mon, Nov 23, 2009 at 07:42:34PM -0500, Durand, Alain wrote a message of 14 lines which said: > The whole value of the RIR is to guarantee this uniqueness. This > problem should not have happened. Indeed. It is a big blunder from the RIR system. I have reported it to RIPE-NCC (ticket NCC#2009116087) but not to ARIN (I'm not used to interact with them, if someone wants to relay the information...) From bortzmeyer at nic.fr Tue Nov 24 01:36:11 2009 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 24 Nov 2009 08:36:11 +0100 Subject: Who has AS 1712? In-Reply-To: References: Message-ID: <20091124073611.GB18280@nic.fr> On Mon, Nov 23, 2009 at 08:25:33PM -0500, Jon Lewis wrote a message of 44 lines which said: > Is it too much to ask that the RIRs query each other's whois servers > for an ASN before assigning that ASN?... Yes, very good idea. And to check the BGP public routing table also (belts and suspenders...) From daniel.karrenberg at ripe.net Tue Nov 24 01:48:17 2009 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 24 Nov 2009 08:48:17 +0100 Subject: Who has AS 1712? In-Reply-To: <20091123151043.GA11349@nic.fr> References: <20091123151043.GA11349@nic.fr> Message-ID: <20091124074817.GA6170@reiftel.karrenberg.net> RIS Routing History for AS1712 since 2001: AS From To avg #peers 12.196.66.0/23 AS1712 20091026 08:00Z 20091026 16:00Z 88 137.194.0.0/16 AS1712 20011220 16:00Z 20031231 16:00Z 39 20040101 00:00Z 20040312 16:00Z 54 20040315 08:00Z 20040402 16:00Z 44 20040405 08:00Z 20061231 16:00Z 63 20070101 00:00Z 20091122 00:00Z 101 74.118.148.0/22 AS1712 20091026 08:00Z 20091122 00:00Z 88 74.118.148.0/24 AS1712 20091018 00:00Z 20091026 00:00Z 83 74.118.149.0/24 AS1712 20091019 16:00Z 20091026 00:00Z 86 74.118.150.0/24 AS1712 20091020 00:00Z 20091026 00:00Z 87 74.118.151.0/24 AS1712 20091020 00:00Z 20091026 00:00Z 87 See also colorful graph attached. Interpretation: 137.194.0.0/16 is assigned to ENST and has been announced by AS1712 since 2001. See also: http://albatross.ripe.net/cgi-bin/rex.pl?type=all&res=137.194.0.0/16&stime=2001-01-01&etime=2009-11-23&page=routing&cf=1&af=1 Other announcements from AS1712 have appeared on 20091018 imost ceased on 20091026, about a month ago. 74.118.148.0/22 is still there and needs to be addressed. http://albatross.ripe.net/cgi-bin/rex.pl?res=74.118.148.0%2F22&type=all&stime=2008-11-23&etime=2009-11-23&cf=1&af=1&page=routing I am sure the RIRs concerned will learn from this and this thread already contains good suggestions about what/how to learn. Daniel PS: And yes we are going to make the REX tool for querying ASes available soon. Keep watching labs.ripe.net. -------------- next part -------------- A non-text attachment was scrubbed... Name: rex-enst-short.png Type: image/png Size: 5765 bytes Desc: not available URL: From brad at brad-x.com Tue Nov 24 02:54:59 2009 From: brad at brad-x.com (Brad Laue) Date: Tue, 24 Nov 2009 03:54:59 -0500 Subject: AT&T SMTP Admin contact? Message-ID: <9C081244-5E56-459B-9270-E0D10E65225C@brad-x.com> Hi all, Would I be able to get an AT&T mail administrator to contact me off-list? We've recently moved our mailservers to a new IP address range, and the standard CGI forms haven't produced any progress for us in over a week now. Unfortunately this affects dozens of hosted clients... The CGI form at http://wn.att.net/cgi-bin/block_admin.cgi has also got a dead link at the bottom, which shakes my confidence in its level of maintenance a little. Thanks in advance, -- Regards, Brad Laue Systems Administrator, Inftek Hosting 1-888-44-SYNCD http://www.getsyncd.com (888) 44-SYNCD (888-447-9623) x702 From daniel.karrenberg at ripe.net Tue Nov 24 02:56:56 2009 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 24 Nov 2009 09:56:56 +0100 Subject: Who has AS 1712? In-Reply-To: <20091124074817.GA6170@reiftel.karrenberg.net> References: <20091123151043.GA11349@nic.fr> <20091124074817.GA6170@reiftel.karrenberg.net> Message-ID: <20091124085656.GC6170@reiftel.karrenberg.net> On 24.11 08:48, Daniel Karrenberg wrote: > > RIS Routing History for AS1712 since 2001: > > ... > > PS: And yes we are going to make the REX tool for querying ASes available soon. > Keep watching labs.ripe.net. OK, by popular demand: Before we release the nicely presented version, here is a direct link to some of the RIS data which can be queried by AS: http://albatross.ripe.net/cgi-bin/inrdb-risribl.cgi?res=1712&rrc=aggr&match=x There are links at the bottom for explanations and a link at the top for asking different questions. Note again that this is not a production service, it is raw data that needs interpretation and a nicer presentation is coming soon. Daniel From randy at psg.com Tue Nov 24 03:29:12 2009 From: randy at psg.com (Randy Bush) Date: Tue, 24 Nov 2009 18:29:12 +0900 Subject: Who has AS 1712? In-Reply-To: <20091124074817.GA6170@reiftel.karrenberg.net> References: <20091123151043.GA11349@nic.fr> <20091124074817.GA6170@reiftel.karrenberg.net> Message-ID: > RIS Routing History for AS1712 since 2001: on what date was AS1712 assigned to the current RIPE holder? randy From hank at efes.iucc.ac.il Tue Nov 24 03:41:07 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 24 Nov 2009 11:41:07 +0200 Subject: Who has AS 1712? In-Reply-To: References: <20091124074817.GA6170@reiftel.karrenberg.net> <20091123151043.GA11349@nic.fr> <20091124074817.GA6170@reiftel.karrenberg.net> Message-ID: <5.1.0.14.2.20091124113919.00c47098@efes.iucc.ac.il> At 18:29 24/11/2009 +0900, Randy Bush wrote: > > RIS Routing History for AS1712 since 2001: > >on what date was AS1712 assigned to the current RIPE holder? Based on: ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest it doesn't show AS1712 ever being allocated to Renater (probably why the inter-RIR mistake happened) but the surrounding ASNs give you an idea of the timeframe: ripencc|IL|asn|1680|1|19930901|allocated ripencc|EU|asn|1707|1|19930901|allocated ripencc|EU|asn|1729|1|19930901|allocated ripencc|EU|asn|1732|1|19930901|allocated -Hank >randy From fweimer at bfk.de Tue Nov 24 03:56:25 2009 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 24 Nov 2009 09:56:25 +0000 Subject: Who has AS 1712? In-Reply-To: <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> (Christopher Morrow's message of "Mon\, 23 Nov 2009 10\:50\:03 -0500") References: <20091123151043.GA11349@nic.fr> <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> Message-ID: <82zl6c6yba.fsf@mid.bfk.de> * Christopher Morrow: > In all seriousness though, how does this get fixed? AS number translation, perhaps? But more seriously, in general, it is impossible to tell if a conflict between RIPE and ARIN is real, or is the result of lack of updates after mergers and acquisitions on one of the sides. A good example in this area is 53.0.0.0/8, which has a rather interesting history. Another one is AS702. -- 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 sronan at fattoc.com Tue Nov 24 06:26:21 2009 From: sronan at fattoc.com (Shane Ronan) Date: Tue, 24 Nov 2009 04:26:21 -0800 Subject: Ethernet over DS3 Converters In-Reply-To: <0F968957-1FE5-40EE-A572-6C8F1356EDCB@kanren.net> References: <0F968957-1FE5-40EE-A572-6C8F1356EDCB@kanren.net> Message-ID: I've been using the RAD products for years. The price is right and they are extremely reliable. On Nov 23, 2009, at 12:25 PM, Brad Fleming wrote: > Hello all, > > My company is searching for some Ethernet over DS3 converters / adaptors for a specific installation. I see several options from Adtran, RAD-Direct, and a couple other (smaller) vendors and was wondering if anyone out there has suggestions or insights. > > Our needs are pretty simple: > We'll need to pass multiple VLANs unless that's simply not possible. > We'll need copper 10/100 interfaces on each side. > > > Here are the two main products we're currently eyeing.... > > Adtran Product: > http://www.adtran.com/web/page/portal/Adtran/group/3024 > > RAD-Direct Product: > http://www.rad.com/10/Fast_Ethernet_over_T3_NTU/2480/ > > Thanks very much for any suggestions. > -- > Brad Fleming > Network Engineer > Kansas Research and Education Network > Office: 785-856-9800 x.222 > Moblie: 785-865-7231 > NOC: 866-984-3662 > > From jason.rowley.lists at gmail.com Tue Nov 24 06:31:33 2009 From: jason.rowley.lists at gmail.com (Jason Rowley) Date: Tue, 24 Nov 2009 07:31:33 -0500 Subject: Ethernet over DS3 Converters In-Reply-To: <0F968957-1FE5-40EE-A572-6C8F1356EDCB@kanren.net> References: <0F968957-1FE5-40EE-A572-6C8F1356EDCB@kanren.net> Message-ID: On Mon, Nov 23, 2009 at 3:25 PM, Brad Fleming wrote: > Hello all, > > My company is searching for some Ethernet over DS3 converters / adaptors for > a specific installation. I see several options from Adtran, RAD-Direct, and > a couple other (smaller) vendors and was wondering if anyone out there has > suggestions or insights. > > Our needs are pretty simple: > We'll need to pass multiple VLANs unless that's simply not possible. > We'll need copper 10/100 interfaces ?on each side. +1 for Overture. We have a pretty large deployment of 5100s and ISG45s. Be aware on the 5100 and lower, that if you run MPLS over it, it cannot currently put that traffic in the appropriate queues. They're working on that feature (fingers crossed for Q1). We work around that by setting ToS bits on outgoing interfaces and configuring the switch rule to look at that instead. The 5000/5100 and 6000 does have a CLI and SNMP, but lacks the queue details that the 45+ has. They just tell you something dropped, not which queue had the drop. The MPLS limitation also applies to bundling multiple DS3s (if you can't get GFP bonding to work due to differential delay limitations). That traffic gets stuffed onto one DS3. Non MPLS traffic appears to be hashed pretty evenly across multiple DS3s on the newer code. Also, the hash is dynamically sized based on # of DS3s in the bundle. Again, hopefully Q1 for MPLS capabilities. It is my understanding (haven't tested them for that purpose) that the 6000 can see into MPLS headers and properly queue today based off of DSCP markings. However, they are a bit pricier. Their TAC is also fantastic if you ever need them. jason From eksffa at freebsdbrasil.com.br Tue Nov 24 07:43:16 2009 From: eksffa at freebsdbrasil.com.br (Patrick Tracanelli) Date: Tue, 24 Nov 2009 11:43:16 -0200 Subject: Tucows vs Postini In-Reply-To: References: Message-ID: <4B0BE2F4.20201@freebsdbrasil.com.br> Paul Stewart escreveu: > Hi folks... > > > > Anyone have much experience with outsourcing antispam/antivirus to > Tucows? We use Postini today and are overall pleased. The Tucows > pricing seems to be MUCH lower so curious on any feedback... > > > > Thanks, > > > > Paul I personally run Postini, Tucows' and MailFoundry on the clowd (hosted) for some of my customers, so, its all about my very own personal experience. Tucows has a way better ROI rates, however they used to be very, very unstable, with really higher outages than any other of the mentioned players. Nowadays things just seems to be pretty much improved. However, when downtime is not a problem anymore with Tucows, sometimes messages just happen to take real longer to show up in the inbox. Seems like large mail queue or alike (information-less diagnostics, in other words just a feeling). Therefore performance is still lacking from Tucows compared to Postini and MailFoundry. I dont see any of those problems with Postini. Now, MailFoundry seems to be the most feature-rich option. Specially needed for companies with special security policy needs. Performance and availability is just as good as Postini. Ask your financial people to check out the pricing conditions for MailFoundry, if they believe it worths the TCO, I honestly suggest some attention on this SaaS provider. -- Patrick Tracanelli From Ed.Lewis at neustar.biz Tue Nov 24 07:51:33 2009 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 24 Nov 2009 08:51:33 -0500 Subject: Who has AS 1712? In-Reply-To: References: <20091123151043.GA11349@nic.fr> <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> <75cb24520911232033x24bacf13xa3bb9d32599f45ea@mail.gmail.com> Message-ID: At 0:32 -0500 11/24/09, Jon Lewis wrote: >Lots of ASNs have been assigned but aren't visible in the global table. And not all global networks (needing unique numbering) connect to the global "public" internet. At 8:36 +0100 11/24/09, Stephane Bortzmeyer wrote: >Yes, very good idea. And to check the BGP public routing table also >(belts and suspenders...) That's a good check, but not sufficient. When last we fixed an ASN registration, the check showed that other ASN's we had were not seen in that table. We just mentioned "they are used on another inter-network" and passed. Kinda like "belts and suspenders" but let's make sure the fly is shut too. ;) At 15:58 +0900 11/24/09, Randy Bush wrote: >owned resources may not be announced or visible universally. Right...or maybe in a different universe. >existing data sources deeply suck. rir source data are in different >formats, owner identies are not even unique in one rir (how many names >does goog have in arin?), let alone coordinated across rirs, much >historical data is missing, ... This is why an inter-registry database inspection tool is needed. The traditional one is WhoIs - which as Randy mentions is too vague in content. (The WhoIs spec only says something about TCP to port 43...and nothing about the query/response formats.) A tool like IRIS is on the shelf that could be a platform from which to build something better. Checking the global public internet tables is a good first step, but that's not all that is needed. Such a step only gives credence to uniqueness, but it doesn't guarantee it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. From eksffa at freebsdbrasil.com.br Tue Nov 24 07:51:48 2009 From: eksffa at freebsdbrasil.com.br (Patrick Tracanelli) Date: Tue, 24 Nov 2009 11:51:48 -0200 Subject: AT&T SMTP Admin contact? In-Reply-To: <9C081244-5E56-459B-9270-E0D10E65225C@brad-x.com> References: <9C081244-5E56-459B-9270-E0D10E65225C@brad-x.com> Message-ID: <4B0BE4F4.8080706@freebsdbrasil.com.br> Brad Laue escreveu: > Hi all, > > Would I be able to get an AT&T mail administrator to contact me off-list? We've recently moved our mailservers to a new IP address range, and the standard CGI forms haven't produced any progress for us in over a week now. Unfortunately this affects dozens of hosted clients... > > The CGI form at http://wn.att.net/cgi-bin/block_admin.cgi has also got a dead link at the bottom, which shakes my confidence in its level of maintenance a little. > > Thanks in advance, Any success? I have been trying to mail @bellsouth for a while now, and I am stuckd into this RBL. Filling the CGI form or mailing abuse@, postmaster, or this address: http://worldnet.att.net/global-images/general-info/abuse_mail.gif Never helped. My IP address, which has very good reputation on mail delivery on many other public RBLs, btw, is still blocked reason-less. -- Patrick Tracanelli From bclark at spectraaccess.com Tue Nov 24 09:10:58 2009 From: bclark at spectraaccess.com (Bret Clark) Date: Tue, 24 Nov 2009 10:10:58 -0500 Subject: Ethernet over DS3 Converters In-Reply-To: References: <0F968957-1FE5-40EE-A572-6C8F1356EDCB@kanren.net> Message-ID: <1259075458.5988.3.camel@acer> Long time ago I assited on consultation for this device. Probably provide what you are looking for: http://www.zhone.com/products/ETHX-2200-DS3/ On Tue, 2009-11-24 at 07:31 -0500, Jason Rowley wrote: > On Mon, Nov 23, 2009 at 3:25 PM, Brad Fleming > wrote: > > Hello all, > > > > My company is searching for some Ethernet over DS3 converters / > adaptors for > > a specific installation. I see several options from Adtran, > RAD-Direct, and > > a couple other (smaller) vendors and was wondering if anyone out > there has > > suggestions or insights. > > > > Our needs are pretty simple: > > We'll need to pass multiple VLANs unless that's simply not possible. > > We'll need copper 10/100 interfaces on each side. From uri.joskovitch at telrad.com Tue Nov 24 09:17:56 2009 From: uri.joskovitch at telrad.com (Uri Joskovitch) Date: Tue, 24 Nov 2009 17:17:56 +0200 Subject: Ethernet over DS3 Converters In-Reply-To: <1259075458.5988.3.camel@acer> References: <0F968957-1FE5-40EE-A572-6C8F1356EDCB@kanren.net> <1259075458.5988.3.camel@acer> Message-ID: <02755D474772E74E97471FC5BBE7641B02AC326D@TLRD-MAIL1.Telrad.co.il> Here is another product family that supports also GE over PDH. http://telrad.com/pages/products/eopdh-cpe.aspx Regards, Uri Joskovitch VP Product Management Telrad Products Division Telrad Networks Office: +972-73-2467-195 Fax: +972-73-2467-592 Assistant: +972-73-2467-750 Cell (IL): +972-52-2467195 Email: uri.joskovitch at telrad.com Website: www.telrad.com Check out our *NEW* website, www.telrad.com " Playing to Win..." -----Original Message----- From: Bret Clark [mailto:bclark at spectraaccess.com] Sent: Tuesday, November 24, 2009 5:11 PM To: nanog at nanog.org Subject: Re: Ethernet over DS3 Converters Long time ago I assited on consultation for this device. Probably provide what you are looking for: http://www.zhone.com/products/ETHX-2200-DS3/ On Tue, 2009-11-24 at 07:31 -0500, Jason Rowley wrote: > On Mon, Nov 23, 2009 at 3:25 PM, Brad Fleming > wrote: > > Hello all, > > > > My company is searching for some Ethernet over DS3 converters / > adaptors for > > a specific installation. I see several options from Adtran, > RAD-Direct, and > > a couple other (smaller) vendors and was wondering if anyone out > there has > > suggestions or insights. > > > > Our needs are pretty simple: > > We'll need to pass multiple VLANs unless that's simply not possible. > > We'll need copper 10/100 interfaces on each side. From mruiz at telwestservices.com Tue Nov 24 10:01:37 2009 From: mruiz at telwestservices.com (Michael Ruiz) Date: Tue, 24 Nov 2009 10:01:37 -0600 Subject: Having trouble trying to activate a GigE connection> Message-ID: <9F285BFE1D7757499D9FF095B4EE347D0490F9A6@tw-xchange01.TWC.local> Group, I am having an issue with activating a Gige interface between a Cisco 7206 VXR w/IO-1GE module to a 7606 w/sup720-3bxls connecting to a line module WS-X6416-GBIC. I have verified that the GBIC-MMF have good light reading and the MMF fiber jumper are not reversed. The GigE connection comes up briefly for about a few seconds, takes a burst of errors and goes down. I have tried to set the speed to nonegotiate on both ends, set one end to speed auto. No dice. Here is the copy of the configuration. On my 7606 I show that the GigE interface is up/up but on the 7206vxr I show down/down. Any help will be greatly appreciated. Thanks! This is the Cisco 7206VXR configuration. interface GIabitEthernet0/0 no ip address duplex full speed 1000 media-type gbic no negotiation auto This is the Cisco 7606 configuration. interface GigabitEthernet1/8 description AR4-DLLSTXHW-GE0/0 no ip address speed nonegotiate Michael Ruiz Network Engineer From bmah at kitchenlab.org Tue Nov 24 10:01:16 2009 From: bmah at kitchenlab.org (Bruce A. Mah) Date: Tue, 24 Nov 2009 08:01:16 -0800 Subject: Smartcard and non-password methods (was Re: Password repository) In-Reply-To: References: <200911201830220.32BF5B92.12974@clifden.donelan.com> <20091121143832.56867.qmail@simone.iecc.com> Message-ID: <4B0C034C.8090506@kitchenlab.org> If memory serves me right, Randy Bush wrote: > is there a freebsd pam tacacs+ hack? Yep. Haven't actually used it though. PAM_TACPLUS(8) FreeBSD System Manager's Manual PAM_TACPLUS(8) NAME pam_tacplus -- TACACS+ authentication PAM module Bruce. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature URL: From mksmith at adhost.com Tue Nov 24 10:25:25 2009 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 24 Nov 2009 08:25:25 -0800 Subject: Having trouble trying to activate a GigE connection> In-Reply-To: <9F285BFE1D7757499D9FF095B4EE347D0490F9A6@tw-xchange01.TWC.local> References: <9F285BFE1D7757499D9FF095B4EE347D0490F9A6@tw-xchange01.TWC.local> Message-ID: <17838240D9A5544AAA5FF95F8D520316071DE6C9@ad-exh01.adhost.lan> Hello Michael: > -----Original Message----- > From: Michael Ruiz [mailto:mruiz at telwestservices.com] > Sent: Tuesday, November 24, 2009 8:02 AM > To: nanog at nanog.org > Subject: Having trouble trying to activate a GigE connection> > > Group, > > > > I am having an issue with activating a Gige interface > between a Cisco 7206 VXR w/IO-1GE module to a 7606 w/sup720-3bxls > connecting to a line module WS-X6416-GBIC. I have verified that the > GBIC-MMF have good light reading and the MMF fiber jumper are not > reversed. The GigE connection comes up briefly for about a few > seconds, > takes a burst of errors and goes down. I have tried to set the speed > to > nonegotiate on both ends, set one end to speed auto. No dice. Here is > the copy of the configuration. On my 7606 I show that the GigE > interface is up/up but on the 7206vxr I show down/down. Any help will > be greatly appreciated. Thanks! > > > I don't think there is any reason to have hard-set speed and duplex, particularly between two Cisco's. Why not just set *both* sides (you can't set just one) to auto-negotation - 'no speed nonegotiate' on the 7606 side. Is this a straight shot, single fiber pair between the two or are there intermediate junctions or optics? It sounds like you have questionable fiber or optics in the path. It could be the fiber itself or the GBICs on either side. Regards, Mike From brad at brad-x.com Tue Nov 24 10:50:54 2009 From: brad at brad-x.com (Brad Laue) Date: Tue, 24 Nov 2009 11:50:54 -0500 Subject: AT&T SMTP Admin contact? In-Reply-To: <4B0BE4F4.8080706@freebsdbrasil.com.br> References: <9C081244-5E56-459B-9270-E0D10E65225C@brad-x.com> <4B0BE4F4.8080706@freebsdbrasil.com.br> Message-ID: <4B0C0EEE.50302@brad-x.com> Patrick Tracanelli wrote: > Brad Laue escreveu: > >> Hi all, >> >> Would I be able to get an AT&T mail administrator to contact me off-list? We've recently moved our mailservers to a new IP address range, and the standard CGI forms haven't produced any progress for us in over a week now. Unfortunately this affects dozens of hosted clients... >> >> The CGI form at http://wn.att.net/cgi-bin/block_admin.cgi has also got a dead link at the bottom, which shakes my confidence in its level of maintenance a little. >> >> Thanks in advance, >> > > Any success? > > I have been trying to mail @bellsouth for a while now, and I am stuckd > into this RBL. Filling the CGI form or mailing abuse@, postmaster, or > this address: > > http://worldnet.att.net/global-images/general-info/abuse_mail.gif > > Never helped. My IP address, which has very good reputation on mail > delivery on many other public RBLs, btw, is still blocked reason-less. > > No luck as yet. I've sent an e-mail to postmaster@ and abuse_rbl@, hopefully I'll receive a reply from these. Exclusionary blocklists are a great idea if they're constantly maintained. I'm unclear as to why mail administrators don't work more proactively with things like SenderID and SPF, as these seem to be far more maintainable in the long-run than an ever-growing list of IP address ranges. From scott at sberkman.net Tue Nov 24 10:52:02 2009 From: scott at sberkman.net (Scott Berkman) Date: Tue, 24 Nov 2009 11:52:02 -0500 Subject: Having trouble trying to activate a GigE connection> In-Reply-To: <17838240D9A5544AAA5FF95F8D520316071DE6C9@ad-exh01.adhost.lan> References: <9F285BFE1D7757499D9FF095B4EE347D0490F9A6@tw-xchange01.TWC.local> <17838240D9A5544AAA5FF95F8D520316071DE6C9@ad-exh01.adhost.lan> Message-ID: <042701ca6d26$741d42e0$5c57c8a0$@net> I actually have seen where you have to hard set to speed 1000 to get this type of link up, even Cisco to Cisco. -Scott -----Original Message----- From: Michael K. Smith - Adhost [mailto:mksmith at adhost.com] Sent: Tuesday, November 24, 2009 11:25 AM To: Michael Ruiz; nanog at nanog.org Subject: RE: Having trouble trying to activate a GigE connection> Hello Michael: > -----Original Message----- > From: Michael Ruiz [mailto:mruiz at telwestservices.com] > Sent: Tuesday, November 24, 2009 8:02 AM > To: nanog at nanog.org > Subject: Having trouble trying to activate a GigE connection> > > Group, > > > > I am having an issue with activating a Gige interface > between a Cisco 7206 VXR w/IO-1GE module to a 7606 w/sup720-3bxls > connecting to a line module WS-X6416-GBIC. I have verified that the > GBIC-MMF have good light reading and the MMF fiber jumper are not > reversed. The GigE connection comes up briefly for about a few > seconds, > takes a burst of errors and goes down. I have tried to set the speed > to > nonegotiate on both ends, set one end to speed auto. No dice. Here is > the copy of the configuration. On my 7606 I show that the GigE > interface is up/up but on the 7206vxr I show down/down. Any help will > be greatly appreciated. Thanks! > > > I don't think there is any reason to have hard-set speed and duplex, particularly between two Cisco's. Why not just set *both* sides (you can't set just one) to auto-negotation - 'no speed nonegotiate' on the 7606 side. Is this a straight shot, single fiber pair between the two or are there intermediate junctions or optics? It sounds like you have questionable fiber or optics in the path. It could be the fiber itself or the GBICs on either side. Regards, Mike From mruiz at telwestservices.com Tue Nov 24 11:04:32 2009 From: mruiz at telwestservices.com (Michael Ruiz) Date: Tue, 24 Nov 2009 11:04:32 -0600 Subject: Having trouble trying to activate a GigE connection> In-Reply-To: <17838240D9A5544AAA5FF95F8D520316071DE6C9@ad-exh01.adhost.lan> References: <9F285BFE1D7757499D9FF095B4EE347D0490F9A6@tw-xchange01.TWC.local> <17838240D9A5544AAA5FF95F8D520316071DE6C9@ad-exh01.adhost.lan> Message-ID: <9F285BFE1D7757499D9FF095B4EE347D0490FA5F@tw-xchange01.TWC.local> >I don't think there is any reason to have hard-set speed and duplex, >particularly between two Cisco's. Why not just set *both* sides (you >can't set just one) to auto-negotation - 'no speed nonegotiate' on the >7606 side. Is this a straight shot, single fiber pair between the two >or are there intermediate junctions or optics? It sounds like you have >questionable fiber or optics in the path. It could be the fiber itself >or the GBICs on either side. Mike, I tried setting the 7206 to auto, and the 7606 to nonnegtiate, however, no dice. We put light meter on both ends of the GBIC and light readings are at -20, which are applicable. Between the two routers are MMF and it is straight shot with no transport equipment in between. -----Original Message----- From: Michael K. Smith - Adhost [mailto:mksmith at adhost.com] Sent: Tuesday, November 24, 2009 10:25 AM To: Michael Ruiz; nanog at nanog.org Subject: RE: Having trouble trying to activate a GigE connection> Hello Michael: > -----Original Message----- > From: Michael Ruiz [mailto:mruiz at telwestservices.com] > Sent: Tuesday, November 24, 2009 8:02 AM > To: nanog at nanog.org > Subject: Having trouble trying to activate a GigE connection> > > Group, > > > > I am having an issue with activating a Gige interface > between a Cisco 7206 VXR w/IO-1GE module to a 7606 w/sup720-3bxls > connecting to a line module WS-X6416-GBIC. I have verified that the > GBIC-MMF have good light reading and the MMF fiber jumper are not > reversed. The GigE connection comes up briefly for about a few > seconds, > takes a burst of errors and goes down. I have tried to set the speed > to > nonegotiate on both ends, set one end to speed auto. No dice. Here is > the copy of the configuration. On my 7606 I show that the GigE > interface is up/up but on the 7206vxr I show down/down. Any help will > be greatly appreciated. Thanks! > > > I don't think there is any reason to have hard-set speed and duplex, particularly between two Cisco's. Why not just set *both* sides (you can't set just one) to auto-negotation - 'no speed nonegotiate' on the 7606 side. Is this a straight shot, single fiber pair between the two or are there intermediate junctions or optics? It sounds like you have questionable fiber or optics in the path. It could be the fiber itself or the GBICs on either side. Regards, Mike From Valdis.Kletnieks at vt.edu Tue Nov 24 12:10:38 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 24 Nov 2009 13:10:38 -0500 Subject: AT&T SMTP Admin contact? In-Reply-To: Your message of "Tue, 24 Nov 2009 11:50:54 EST." <4B0C0EEE.50302@brad-x.com> References: <9C081244-5E56-459B-9270-E0D10E65225C@brad-x.com> <4B0BE4F4.8080706@freebsdbrasil.com.br> <4B0C0EEE.50302@brad-x.com> Message-ID: <12522.1259086238@turing-police.cc.vt.edu> On Tue, 24 Nov 2009 11:50:54 EST, Brad Laue said: > maintained. I'm unclear as to why mail administrators don't work more > proactively with things like SenderID and SPF, as these seem to be far > more maintainable in the long-run than an ever-growing list of IP > address ranges. There's a difference between maintainable and usable. Yes, letting the remote end maintain their SenderID and SPF is more scalable, and both do at least a plausible job of answering "Is this mail claiming to be from foobar.com really from foobar.com?". However, there's like 140M+ .coms now, and neither of them actually tell you what you really want to know, which is "do I want e-mail from foobar.com or not?". Especially when the spammer is often in cahoots with the DNS admins... On the other hand, I can, by looking at my logs, develop a fairly good sense of "do I have any real non-spam traffic from that address range?". Yes, it's more work, but it's also more likely to actually answer the question that I wanted answered. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jcurran.bulk at me.com Tue Nov 24 12:19:51 2009 From: jcurran.bulk at me.com (John Curran) Date: Tue, 24 Nov 2009 13:19:51 -0500 Subject: Who has AS 1712? In-Reply-To: <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> References: <20091123151043.GA11349@nic.fr> <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> Message-ID: On Nov 23, 2009, at 10:50 AM, Christopher Morrow wrote: > In all seriousness though, how does this get fixed? It's being addressed now, but requires both RIPE and ARIN to work with the respective ASN holders. Standby for an update once that step has been completed. The more interesting question is how this could happen, and we're busy looking into that at present. The AS 1707 assignment goes back to Internic days (i.e. pre-1997) but the remainder of the ASN block (AS 1708 to AS 1728) is marked "assigned by ARIN" at the IANA but had not actually been assigned until very recently. (ARIN did a reconciliation in July 2009 of all ASNs marked as ?assigned by ARIN? with our own internal records to find out whether any holes existed, and began assigning such ASNs in August 2009, including AS numbers in the range 1708 thru 1726). We're working with RIPE to determine how these numbers were put into usage via the RIPE DB, and will come up with appropriate steps to prevent recurrence once we fully understand the root cause. /John John Curran President and CEO ARIN From dot at dotat.at Tue Nov 24 12:57:56 2009 From: dot at dotat.at (Tony Finch) Date: Tue, 24 Nov 2009 18:57:56 +0000 Subject: Who has AS 1712? In-Reply-To: <20091124011129.GA60839@puck.nether.net> References: <20091123151043.GA11349@nic.fr> <4B0AB307.9070400@merit.edu> <20091124011129.GA60839@puck.nether.net> Message-ID: On Mon, 23 Nov 2009, Jared Mauch wrote: > > I don't see operators jumping at the idea of central trust anchor > myself, no more than I see everyone ready to sign the root zone. You know the root zone is supposed to be signed next week? http://www.ripe.net/ripe/meetings/ripe-59/presentations/uploads//presentations/Tuesday/Plenary%2014:00/Abley-DNSSEC_for_the_Root_Zone.mId7.pdf Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From ross at kallisti.us Tue Nov 24 12:57:20 2009 From: ross at kallisti.us (Ross Vandegrift) Date: Tue, 24 Nov 2009 13:57:20 -0500 Subject: OT: VSS + MEC - port-channel dynamically cloned? In-Reply-To: <1259045489.12138.5.camel@leland-gandi> References: <1259045489.12138.5.camel@leland-gandi> Message-ID: <20091124185720.GA13704@kallisti.us> On Tue, Nov 24, 2009 at 07:51:29AM +0100, Leland Vandervort wrote: > Essentially, for all of the MEC connections, the VSS has created a clone > of the configured port-channel to bind the actual physical connections, > rather than binding them under the configured port-channel (and suffixed > the port-channel number with A or B depending on which chassis was first > to bind). IOS does this when ethernet channel members cannot join the bundle due to negotiation mismatch. If the currently active elements are incompatible with a new element, the A/B interfaces are created. These are called "secondary aggregators" in IOS-speak. http://www.cisco.com/en/US/tech/tk389/tk213/technologies_configuration_example09186a0080094470.shtml#po1a -- Ross Vandegrift ross at kallisti.us "If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher." --Woody Guthrie -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From jared at puck.nether.net Tue Nov 24 13:02:04 2009 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 24 Nov 2009 14:02:04 -0500 Subject: Who has AS 1712? In-Reply-To: References: <20091123151043.GA11349@nic.fr> <4B0AB307.9070400@merit.edu> <20091124011129.GA60839@puck.nether.net> Message-ID: On Nov 24, 2009, at 1:57 PM, Tony Finch wrote: > On Mon, 23 Nov 2009, Jared Mauch wrote: >> >> I don't see operators jumping at the idea of central trust anchor >> myself, no more than I see everyone ready to sign the root zone. > > You know the root zone is supposed to be signed next week? > > http://www.ripe.net/ripe/meetings/ripe-59/presentations/uploads//presentations/Tuesday/Plenary%2014:00/Abley-DNSSEC_for_the_Root_Zone.mId7.pdf Yes. I also saw the presentation at IETF in Hiroshima on this. The issue of zone signing is going to be interesting as some nation-states (ccTLD) have been known to speak-up about their issues with the signing of the zone. I'm not saying these things will never happen, just they won't happen on a timescale that some would prefer (or would have preferred, eg: last summer or earlier). - Jared From ljb at merit.edu Tue Nov 24 13:55:39 2009 From: ljb at merit.edu (Larry Blunk) Date: Tue, 24 Nov 2009 14:55:39 -0500 Subject: Who has AS 1712? In-Reply-To: References: <20091123151043.GA11349@nic.fr> <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> Message-ID: <4B0C3A3B.1010305@merit.edu> John Curran wrote: > On Nov 23, 2009, at 10:50 AM, Christopher Morrow wrote: > > >> In all seriousness though, how does this get fixed? >> > > It's being addressed now, but requires both RIPE and ARIN to work with the respective ASN holders. Standby for an update once that step has been completed. The more interesting question is how this could happen, and we're busy looking into that at present. > > The AS 1707 assignment goes back to Internic days (i.e. pre-1997) but the remainder of the ASN block (AS 1708 to AS 1728) is marked "assigned by ARIN" at the IANA but had not actually been assigned until very recently. (ARIN did a reconciliation in July 2009 of all ASNs marked as ?assigned by ARIN? with our own internal records to find out whether any holes existed, and began assigning such ASNs in August 2009, including AS numbers in the range 1708 thru 1726). > > We're working with RIPE to determine how these numbers were put into usage via the RIPE DB, and will come up with appropriate steps to prevent recurrence once we fully understand the root cause. > > /John > > John Curran > President and CEO > ARIN > > FWIW, I searched for any historical registrations from this block in the RADB and found a number of routes with an origin of AS1717. They date from 1995 and were registered for the Universit? Pierre et Marie Curie by Renater. They have long since been removed from the RADB. Here's an example -- route: 132.166.0.0/15 descr: RENATER_CIDR descr: Universite Pierre et Marie Curie descr: 4 place Jussieu 75252 PARIS CEDEX 05 descr: FRANCE origin: AS1717 advisory: AS690 1:1800 2:1239(144) 3:1133 4:1674 comm-list: COMM_NSFNET mnt-by: MAINT-AS1717 changed: rensvp at renater.fr 950510 source: RADB -Larry Blunk Merit From morrowc.lists at gmail.com Tue Nov 24 14:16:47 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 24 Nov 2009 15:16:47 -0500 Subject: ip capacity provider In-Reply-To: <1714806603-1259006475-cardhu_decombobulator_blackberry.rim.net-1611490425-@bda772.bisx.prod.on.blackberry> References: <1714806603-1259006475-cardhu_decombobulator_blackberry.rim.net-1611490425-@bda772.bisx.prod.on.blackberry> Message-ID: <75cb24520911241216v12fe9e3bq2cef83e8bbf34ec2@mail.gmail.com> On Mon, Nov 23, 2009 at 3:01 PM, wrote: > AS 701 Verizon Business (formerly UUNet) has a POP in Miami I believe, and they connect directly into their AS in LatAm. of course showing up at terramark's NoTA would also get you lots of options (and I think 701 has one pop at NoTA) > ------Original Message------ > From: Beavis > To: nanog at nanog.org > Subject: ip capacity provider > Sent: Nov 23, 2009 2:47 PM > > All, > > ?I know this is a long shot, but can anyone help me out on getting in > touch with carriers in Miami FL. one that can pass ip traffic into > latin america?. > > any help would be greatly appreciated. > > > > > thanks, > -- > () ?ascii ribbon campaign - against html e-mail > /\ ?www.asciiribbon.org ? - against proprietary attachments > > > > Sent from my Verizon Wireless BlackBerry > > From woody at pch.net Tue Nov 24 14:21:29 2009 From: woody at pch.net (Bill Woodcock) Date: Tue, 24 Nov 2009 12:21:29 -0800 (PST) Subject: Recomended data cabling contractors in Bay Area/Peninsula? In-Reply-To: <5a318d410911231210v423a48ffi38d5ca69e98e784e@mail.gmail.com> References: <5a318d410911231210v423a48ffi38d5ca69e98e784e@mail.gmail.com> Message-ID: On Mon, 23 Nov 2009, Darren Bolding wrote: > I need to identify a quality data cabling contractor in the Bay Area Kray Cabling. http://kraycablinginc.com/ -Bill From justin at justinshore.com Tue Nov 24 14:58:07 2009 From: justin at justinshore.com (Justin Shore) Date: Tue, 24 Nov 2009 14:58:07 -0600 Subject: Who has AS 1712? In-Reply-To: <5.1.0.14.2.20091124113919.00c47098@efes.iucc.ac.il> References: <20091124074817.GA6170@reiftel.karrenberg.net> <20091123151043.GA11349@nic.fr> <20091124074817.GA6170@reiftel.karrenberg.net> <5.1.0.14.2.20091124113919.00c47098@efes.iucc.ac.il> Message-ID: <4B0C48DF.1040806@justinshore.com> Hank Nussbacher wrote: > At 18:29 24/11/2009 +0900, Randy Bush wrote: >> > RIS Routing History for AS1712 since 2001: >> >> on what date was AS1712 assigned to the current RIPE holder? > > Based on: > ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest > it doesn't show AS1712 ever being allocated to Renater (probably why the > inter-RIR mistake happened) but the surrounding ASNs give you an idea of > the timeframe: > > ripencc|IL|asn|1680|1|19930901|allocated > ripencc|EU|asn|1707|1|19930901|allocated > ripencc|EU|asn|1729|1|19930901|allocated > ripencc|EU|asn|1732|1|19930901|allocated Since IANA says that the ASN is ARIN's to assign wouldn't that preclude another RIR from assigning it? http://www.iana.org/assignments/as-numbers/ Of course if it was already assigned when IANA said that (no dates on the link above) then maybe the fault is more IANA's for telling another RIR that they could allocate an ASN that another RIR already allocated. Who knows. It should be an interesting one to watch play out though. Justin From leland at taranta.discpro.org Tue Nov 24 15:19:33 2009 From: leland at taranta.discpro.org (Leland Vandervort) Date: Tue, 24 Nov 2009 22:19:33 +0100 Subject: OT: VSS + MEC - port-channel dynamically cloned? In-Reply-To: <20091124185720.GA13704@kallisti.us> References: <1259045489.12138.5.camel@leland-gandi> <20091124185720.GA13704@kallisti.us> Message-ID: <1259097573.5897.2.camel@leland-laptop> Thanks Ross, In this case, though I cannot see where the mismatch is given that the encapsulation, trunking (vlans allowed, etc.) and channel mode (LACP) are all configured identically across all ports and the channel itself. Just wondering if it's a left-over from before the VSS migration when the original trunks were two separate etherchannels and then migrated them "live" to MEC... L. On Tue, 2009-11-24 at 13:57 -0500, Ross Vandegrift wrote: > On Tue, Nov 24, 2009 at 07:51:29AM +0100, Leland Vandervort wrote: > > Essentially, for all of the MEC connections, the VSS has created a clone > > of the configured port-channel to bind the actual physical connections, > > rather than binding them under the configured port-channel (and suffixed > > the port-channel number with A or B depending on which chassis was first > > to bind). > > IOS does this when ethernet channel members cannot join the bundle due > to negotiation mismatch. If the currently active elements are > incompatible with a new element, the A/B interfaces are created. > These are called "secondary aggregators" in IOS-speak. > > http://www.cisco.com/en/US/tech/tk389/tk213/technologies_configuration_example09186a0080094470.shtml#po1a > From randy at psg.com Tue Nov 24 15:21:00 2009 From: randy at psg.com (Randy Bush) Date: Wed, 25 Nov 2009 06:21:00 +0900 Subject: Who has AS 1712? In-Reply-To: <4B0C48DF.1040806@justinshore.com> References: <20091124074817.GA6170@reiftel.karrenberg.net> <20091123151043.GA11349@nic.fr> <5.1.0.14.2.20091124113919.00c47098@efes.iucc.ac.il> <4B0C48DF.1040806@justinshore.com> Message-ID: > Of course if it was already assigned when IANA said that (no dates on > the link above) then maybe the fault is more IANA's for telling another > RIR that they could allocate an ASN that another RIR already allocated. i suspect that, in the erx project, there may have been more than one case of the iana saying "ok, X now manages this block, excpet of course for those pieces already allocated by Y and Z." and the latter were not always well defined or easily learnable, and were not registered directly with the iana, but other rirs. and the data are all buried in whois, which is not well-defined, stats files, which are not defined, etc. the rirs, in the thrall of nih (you did know that ripe/ncc invented the bicycle), spent decades not agreeing on common formats, protocols, or code. this is one result thereof. testosterone kills, and the community gets the collateral damage. randy From joelja at bogus.com Tue Nov 24 12:27:14 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 24 Nov 2009 10:27:14 -0800 Subject: AT&T SMTP Admin contact? In-Reply-To: <12522.1259086238@turing-police.cc.vt.edu> References: <9C081244-5E56-459B-9270-E0D10E65225C@brad-x.com> <4B0BE4F4.8080706@freebsdbrasil.com.br> <4B0C0EEE.50302@brad-x.com> <12522.1259086238@turing-police.cc.vt.edu> Message-ID: <4B0C2582.90805@bogus.com> Valdis.Kletnieks at vt.edu wrote: > On Tue, 24 Nov 2009 11:50:54 EST, Brad Laue said: >> maintained. I'm unclear as to why mail administrators don't work more >> proactively with things like SenderID and SPF, as these seem to be far >> more maintainable in the long-run than an ever-growing list of IP >> address ranges. > > There's a difference between maintainable and usable. Yes, letting the remote > end maintain their SenderID and SPF is more scalable, and both do at least a > plausible job of answering "Is this mail claiming to be from foobar.com really > from foobar.com?". However, there's like 140M+ .coms now, and neither of them > actually tell you what you really want to know, which is "do I want e-mail from > foobar.com or not?". Especially when the spammer is often in cahoots with the > DNS admins... identify framework with trust anchors and reputation management are not things that spf or pra actually solve. spammers can publish spf and senderid records and in fact arguably have more incentive to do so if it can be demonstrated that your mail is more likely to be accepted on the basis of their existence. > On the other hand, I can, by looking at my logs, develop a fairly good sense of > "do I have any real non-spam traffic from that address range?". Yes, it's more > work, but it's also more likely to actually answer the question that I wanted > answered. > From joelja at bogus.com Tue Nov 24 15:17:28 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 24 Nov 2009 13:17:28 -0800 Subject: Who has AS 1712? In-Reply-To: <4B0C48DF.1040806@justinshore.com> References: <20091124074817.GA6170@reiftel.karrenberg.net> <20091123151043.GA11349@nic.fr> <20091124074817.GA6170@reiftel.karrenberg.net> <5.1.0.14.2.20091124113919.00c47098@efes.iucc.ac.il> <4B0C48DF.1040806@justinshore.com> Message-ID: <4B0C4D68.4030308@bogus.com> Justin Shore wrote: > Hank Nussbacher wrote: >> At 18:29 24/11/2009 +0900, Randy Bush wrote: >>> > RIS Routing History for AS1712 since 2001: >>> >>> on what date was AS1712 assigned to the current RIPE holder? >> >> Based on: >> ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest >> it doesn't show AS1712 ever being allocated to Renater (probably why >> the inter-RIR mistake happened) but the surrounding ASNs give you an >> idea of the timeframe: >> >> ripencc|IL|asn|1680|1|19930901|allocated >> ripencc|EU|asn|1707|1|19930901|allocated >> ripencc|EU|asn|1729|1|19930901|allocated >> ripencc|EU|asn|1732|1|19930901|allocated > > Since IANA says that the ASN is ARIN's to assign wouldn't that preclude > another RIR from assigning it? ARIN didn't exist when those ASN's were assigned, RIPE NCC did. > http://www.iana.org/assignments/as-numbers/ > > Of course if it was already assigned when IANA said that (no dates on > the link above) then maybe the fault is more IANA's for telling another > RIR that they could allocate an ASN that another RIR already allocated. > Who knows. It should be an interesting one to watch play out though. > > Justin > > From bmanning at vacation.karoshi.com Tue Nov 24 15:28:50 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 24 Nov 2009 21:28:50 +0000 Subject: Who has AS 1712? In-Reply-To: References: <20091124074817.GA6170@reiftel.karrenberg.net> <20091123151043.GA11349@nic.fr> <5.1.0.14.2.20091124113919.00c47098@efes.iucc.ac.il> <4B0C48DF.1040806@justinshore.com> Message-ID: <20091124212850.GA15384@vacation.karoshi.com.> the joys of non-uniqueness. ULAs are (going to be) your friends. :) back in the day, the IANA was pretty careful. the contractors less so. SRI had the "connected" and "unconnected" databases - duplications abounded and when interconnection occured... renumbering ensued. this is not a new or even recent problem. It is certainly compounded by multiple actors and lack of clean slate. Yet, I beleive that there will be a desire to "do the right thing" and this will get fixed. It might even lead to better tools and inter-actor releationships. Or it could melt into a pile of goo... --bill On Wed, Nov 25, 2009 at 06:21:00AM +0900, Randy Bush wrote: > > Of course if it was already assigned when IANA said that (no dates on > > the link above) then maybe the fault is more IANA's for telling another > > RIR that they could allocate an ASN that another RIR already allocated. > > i suspect that, in the erx project, there may have been more than one > case of the iana saying "ok, X now manages this block, excpet of course > for those pieces already allocated by Y and Z." and the latter were not > always well defined or easily learnable, and were not registered > directly with the iana, but other rirs. > > > > and the data are all buried in whois, which is not well-defined, stats > files, which are not defined, etc. the rirs, in the thrall of nih (you > did know that ripe/ncc invented the bicycle), spent decades not agreeing > on common formats, protocols, or code. this is one result thereof. > testosterone kills, and the community gets the collateral damage. > > randy From brad at brad-x.com Tue Nov 24 15:38:33 2009 From: brad at brad-x.com (Brad Laue) Date: Tue, 24 Nov 2009 16:38:33 -0500 Subject: AT&T SMTP Admin contact? In-Reply-To: <4B0C2582.90805@bogus.com> References: <9C081244-5E56-459B-9270-E0D10E65225C@brad-x.com> <4B0BE4F4.8080706@freebsdbrasil.com.br> <4B0C0EEE.50302@brad-x.com> <12522.1259086238@turing-police.cc.vt.edu> <4B0C2582.90805@bogus.com> Message-ID: <2AFB0EFD-0BFB-469A-AC46-4A3650C0F3CA@brad-x.com> On 2009-11-24, at 1:27 PM, Joel Jaeggli wrote: > > > Valdis.Kletnieks at vt.edu wrote: >> On Tue, 24 Nov 2009 11:50:54 EST, Brad Laue said: >>> maintained. I'm unclear as to why mail administrators don't work more >>> proactively with things like SenderID and SPF, as these seem to be far >>> more maintainable in the long-run than an ever-growing list of IP >>> address ranges. >> >> There's a difference between maintainable and usable. Yes, letting the remote >> end maintain their SenderID and SPF is more scalable, and both do at least a >> plausible job of answering "Is this mail claiming to be from foobar.com really >> from foobar.com?". However, there's like 140M+ .coms now, and neither of them >> actually tell you what you really want to know, which is "do I want e-mail from >> foobar.com or not?". Especially when the spammer is often in cahoots with the >> DNS admins... > > identify framework with trust anchors and reputation management are not > things that spf or pra actually solve. spammers can publish spf and > senderid records and in fact arguably have more incentive to do so if it > can be demonstrated that your mail is more likely to be accepted on the > basis of their existence. True, but wouldn't a blacklist of SPF records for known spam issuing domains be a more maintainable list than an IP block whitelist? (I'm no doubt missing something very obvious with this question) Brad From michael at linuxmagic.com Tue Nov 24 16:01:31 2009 From: michael at linuxmagic.com (Michael Peddemors) Date: Tue, 24 Nov 2009 14:01:31 -0800 Subject: AT&T SMTP Admin contact? In-Reply-To: <2AFB0EFD-0BFB-469A-AC46-4A3650C0F3CA@brad-x.com> References: <9C081244-5E56-459B-9270-E0D10E65225C@brad-x.com> <4B0C2582.90805@bogus.com> <2AFB0EFD-0BFB-469A-AC46-4A3650C0F3CA@brad-x.com> Message-ID: <200911241401.31752.michael@linuxmagic.com> On November 24, 2009, Brad Laue wrote: > True, but wouldn't a blacklist of SPF records for known spam issuing > domains be a more maintainable list than an IP block whitelist? > > (I'm no doubt missing something very obvious with this question) > > Brad > Yes, I think you are :) First of all, domains are easier to throw away than IP Addresses, IP Lookups are more efficient than DNS SPF records, and SPF is not really meant to address Spam problems, although it can address some forgeries. SPF works best to identify forgeries of large well known domains, but I think you do not really understand what SPF records do, or how they work. Don't worry, many email operators don't either, and simply put in an SPF record that says that every IP can send email for that domain ;) And think how large the theoretical database size would be for every domain, compared to the limited size of the IPv4 space.. But this is better taken off list you want to discuss SPF's usage in combatting spam. -- -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors - President/CEO - LinuxMagic Products, Services, Support and Development Visit us at http://www.linuxmagic.com ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-589-0037 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From justin at justinshore.com Tue Nov 24 16:47:48 2009 From: justin at justinshore.com (Justin Shore) Date: Tue, 24 Nov 2009 16:47:48 -0600 Subject: Ethernet over DS3 Converters In-Reply-To: <0F968957-1FE5-40EE-A572-6C8F1356EDCB@kanren.net> References: <0F968957-1FE5-40EE-A572-6C8F1356EDCB@kanren.net> Message-ID: <4B0C6294.70905@justinshore.com> Brad Fleming wrote: > My company is searching for some Ethernet over DS3 converters / adaptors > for a specific installation. I see several options from Adtran, > RAD-Direct, and a couple other (smaller) vendors and was wondering if > anyone out there has suggestions or insights. > > Our needs are pretty simple: > We'll need to pass multiple VLANs unless that's simply not possible. > We'll need copper 10/100 interfaces on each side. Hey Brad. We're doing this with Overture 2200s and 5100s. However, as others have pointed out, they have some issues. Their redundant PSUs for models below the 5x00s are a joke. A single DC PSU for those models requires 1U of space. The PSU has 2 power sources but is still a single PSU. A redundant PSU requires another 1U of space. Inside the 19" x roughly 8" 1U chassis is a PCB that's about the size of a wallet. Why they couldn't incorporate that into a modular PSU or make the external PSU chassis modular so a 2nd PSU didn't take up any more space I do not know. The CLI in the 2200 and 5100 can do a lot. I must admit that I still do not understand it. They just work and I don't have to mess with them very often so I struggle each time I get into one. I found their VLAN grooming to be confusing. Even tech support wasn't able to help in some cases. The ISG models (34, 45, 140, 180 for example) are completely different than the 2200s and 5x000s (I don't know about the ISG 2x models). They were an acquired from another company. What the others said about there being no CLI is right. They only have a web GUI. You can't pull off their config with common CLI tools like RANCID, CatTools, COSI tools, etc. That's a big deal for us. That to me makes them feel like non-telco grade equipment. You can certainly book-end the back to back but be absolutely certain that you get a config dump from each end every time a tech gets into one. I believe the 34, 45 and 140 models use the same PSU as the 2200 above. They can only connect to a single PSU though (the 180 supports 2). Same caveats as above. They are generally feature rich; I'll give that to them. They could be an excellent solution if the product was more mature and honed. Anyone wanting to bond T1s with MLPPP on the 140 and 180 back to a router BEWARE. They require BCP. On most platforms (anything that doesn't use a SPA) that requires disabling routing (research BCP configs on Cisco.com). They will work but understand the caveats before trying them. I'm sure that OV will send you demo units if you ask. I'll send you a picture of a 2200 with the PSU setup later tonight. Justin From ross at kallisti.us Tue Nov 24 16:54:52 2009 From: ross at kallisti.us (Ross Vandegrift) Date: Tue, 24 Nov 2009 17:54:52 -0500 Subject: OT: VSS + MEC - port-channel dynamically cloned? In-Reply-To: <1259097573.5897.2.camel@leland-laptop> References: <1259045489.12138.5.camel@leland-gandi> <20091124185720.GA13704@kallisti.us> <1259097573.5897.2.camel@leland-laptop> Message-ID: <20091124225452.GA16876@kallisti.us> On Tue, Nov 24, 2009 at 10:19:33PM +0100, Leland Vandervort wrote: > In this case, though I cannot see where the mismatch is given that the > encapsulation, trunking (vlans allowed, etc.) and channel mode (LACP) > are all configured identically across all ports and the channel itself. > > Just wondering if it's a left-over from before the VSS migration when > the original trunks were two separate etherchannels and then migrated > them "live" to MEC... Check flow control between all of the elements. The only time I've seen this was inconsistent flow control settings between different media types on an F5 BIG-IP <-> 6500 bundle. show interfaces flowcontrol Ross -- Ross Vandegrift ross at kallisti.us "If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher." --Woody Guthrie -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From Valdis.Kletnieks at vt.edu Tue Nov 24 17:15:52 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 24 Nov 2009 18:15:52 -0500 Subject: AT&T SMTP Admin contact? In-Reply-To: Your message of "Tue, 24 Nov 2009 16:38:33 EST." <2AFB0EFD-0BFB-469A-AC46-4A3650C0F3CA@brad-x.com> References: <9C081244-5E56-459B-9270-E0D10E65225C@brad-x.com> <4B0BE4F4.8080706@freebsdbrasil.com.br> <4B0C0EEE.50302@brad-x.com> <12522.1259086238@turing-police.cc.vt.edu> <4B0C2582.90805@bogus.com> <2AFB0EFD-0BFB-469A-AC46-4A3650C0F3CA@brad-x.com> Message-ID: <3743.1259104552@turing-police.cc.vt.edu> On Tue, 24 Nov 2009 16:38:33 EST, Brad Laue said: > True, but wouldn't a blacklist of SPF records for known spam issuing > domains be a more maintainable list than an IP block whitelist? > > (I'm no doubt missing something very obvious with this question) 140M+ .com where a malicious DNS server in East Podunk can be authoritative for a domain actually in Bratslavia and domains are cheap and throw-away. 16M /24's, where you (mostly(*)) need to be able to actually route the packets, so if you have a /24 in Bratslavia, you need something resembling a router in Bratslavia as well, and somebody willing to light up the other end of the cable, and you need a way to make BGP announcements (legal or otherwise ;) to be able to exploit it. Choose wisely which you'd rather use for defense. (*) Mostly - though the BGP hack demonstrated at last year's DefCon did qualify as an Epic Win for kewl presentations. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From brad at brad-x.com Tue Nov 24 18:06:42 2009 From: brad at brad-x.com (Brad Laue) Date: Tue, 24 Nov 2009 19:06:42 -0500 Subject: AT&T SMTP Admin contact? In-Reply-To: <3743.1259104552@turing-police.cc.vt.edu> References: <9C081244-5E56-459B-9270-E0D10E65225C@brad-x.com> <4B0BE4F4.8080706@freebsdbrasil.com.br> <4B0C0EEE.50302@brad-x.com> <12522.1259086238@turing-police.cc.vt.edu> <4B0C2582.90805@bogus.com> <2AFB0EFD-0BFB-469A-AC46-4A3650C0F3CA@brad-x.com> <3743.1259104552@turing-police.cc.vt.edu> Message-ID: <1EF873FE-8137-4C7C-9BE3-10843B8EFE03@brad-x.com> On 2009-11-24, at 6:15 PM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 24 Nov 2009 16:38:33 EST, Brad Laue said: > >> True, but wouldn't a blacklist of SPF records for known spam issuing >> domains be a more maintainable list than an IP block whitelist? >> >> (I'm no doubt missing something very obvious with this question) > > 140M+ .com where a malicious DNS server in East Podunk can be authoritative for > a domain actually in Bratslavia and domains are cheap and throw-away. > > 16M /24's, where you (mostly(*)) need to be able to actually route the packets, > so if you have a /24 in Bratslavia, you need something resembling a router > in Bratslavia as well, and somebody willing to light up the other end of > the cable, and you need a way to make BGP announcements (legal or otherwise ;) > to be able to exploit it. > > Choose wisely which you'd rather use for defense. > > (*) Mostly - though the BGP hack demonstrated at last year's DefCon > did qualify as an Epic Win for kewl presentations. ;) Ah, very true. Still really hoping to get in touch with someone from AT&T. :-) Thanks for the info. From justin at justinshore.com Tue Nov 24 18:16:55 2009 From: justin at justinshore.com (Justin Shore) Date: Tue, 24 Nov 2009 18:16:55 -0600 Subject: AT&T SMTP Admin contact? In-Reply-To: <1EF873FE-8137-4C7C-9BE3-10843B8EFE03@brad-x.com> References: <9C081244-5E56-459B-9270-E0D10E65225C@brad-x.com> <4B0BE4F4.8080706@freebsdbrasil.com.br> <4B0C0EEE.50302@brad-x.com> <12522.1259086238@turing-police.cc.vt.edu> <4B0C2582.90805@bogus.com> <2AFB0EFD-0BFB-469A-AC46-4A3650C0F3CA@brad-x.com> <3743.1259104552@turing-police.cc.vt.edu> <1EF873FE-8137-4C7C-9BE3-10843B8EFE03@brad-x.com> Message-ID: <4B0C7777.8030501@justinshore.com> Brad Laue wrote: > Ah, very true. Still really hoping to get in touch with someone from AT&T. :-) Good luck. You might be a better response from posting a video complaint on Youtube. "AT&T Breaks Guitars" perhaps. :-) Justin From rusmyba at gmail.com Tue Nov 24 21:22:36 2009 From: rusmyba at gmail.com (Russell Myba) Date: Tue, 24 Nov 2009 22:22:36 -0500 Subject: I got a live one! - Spam source Message-ID: <5e1ca1ac0911241922u25634547u7eeb7ec6e357b352@mail.gmail.com> Looks like of our customers has decided to turn their /24 into a nice little space spewing machine. Doesn't seem like just one compromised host. Reverse DNS for most of the /24 are suspicious domains. Each domain used in the message-id forwards to a single .net which lists their mailing address as a PO box an single link to an unsubscribe field. I've contacted at least three known contacts for the customer about the abuse without a single response. It would seem there are many layers to this entity: The domains are registered to one business Our billing information for the customer has one name, they colo with another person (whom the cross connect reaches) Our customer has an IT solutions person working for them (Strange since our customer and their colo provider are "IT solutions" people themselves. Abuse handle phone #s are supposedly incorrect (I called it) Besides the obvious of me at the minimum filtering port tcp/25 is their an organization that tracks businesses like these who seem like they are building a web of insulation in which to move? I think this case might interest them. From fergdawgster at gmail.com Tue Nov 24 21:26:34 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 24 Nov 2009 19:26:34 -0800 Subject: I got a live one! - Spam source In-Reply-To: <5e1ca1ac0911241922u25634547u7eeb7ec6e357b352@mail.gmail.com> References: <5e1ca1ac0911241922u25634547u7eeb7ec6e357b352@mail.gmail.com> Message-ID: <6cd462c00911241926v37018854j9d59b47afd85f780@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Nov 24, 2009 at 7:22 PM, Russell Myba wrote: > Looks like of our customers has decided to turn their /24 into a nice > little space spewing machine. Doesn't seem like just one compromised > host. > > Reverse DNS for most of the /24 are suspicious domains. Each domain used > in the message-id forwards to a single .net which lists their mailing > address as a PO box an single link to an unsubscribe field. > > I've contacted at least three known contacts for the customer about the > abuse without a single response. > > It would seem there are many layers to this entity: > > The domains are registered to one business > Our billing information for the customer has one name, they colo with > another person (whom the cross connect reaches) > Our customer has an IT solutions person working for them (Strange since > our customer and their colo provider are "IT solutions" people > themselves. > Abuse handle phone #s are supposedly incorrect (I called it) > > Besides the obvious of me at the minimum filtering port tcp/25 is their > an organization that tracks businesses like these who seem like they are > building a web of insulation in which to move? > > I think this case might interest them. > Can you name the /24? I can't say that this sound unfamiliar -- we are seeing an increase in "facilitated" criminal activity across the board... - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLDKPkq1pz9mNUZTMRAg4pAKCZK6srbs1H2zp2FwKvB+T1xe3eKQCfSNFC Gv0xuZ7Lc0q94Yet+xUD3GY= =3sfS -----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 jlewis at lewis.org Tue Nov 24 21:43:33 2009 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 24 Nov 2009 22:43:33 -0500 (EST) Subject: I got a live one! - Spam source In-Reply-To: <5e1ca1ac0911241922u25634547u7eeb7ec6e357b352@mail.gmail.com> References: <5e1ca1ac0911241922u25634547u7eeb7ec6e357b352@mail.gmail.com> Message-ID: On Tue, 24 Nov 2009, Russell Myba wrote: > Looks like of our customers has decided to turn their /24 into a nice little > space spewing machine. Doesn't seem like just one compromised host. > > Reverse DNS for most of the /24 are suspicious domains. Each domain used in > the message-id forwards to a single .net which lists their mailing address > as a PO box an single link to an unsubscribe field. > > I've contacted at least three known contacts for the customer about the > abuse without a single response. I've found that in cases like this, the best way to get in contact with the customer is to interrupt their service. Suddenly, they'll go from being too busy to take/return your call to calling you. > It would seem there are many layers to this entity: > > The domains are registered to one business > Our billing information for the customer has one name, they colo with > another person (whom the cross connect reaches) > Our customer has an IT solutions person working for them (Strange since our > customer and their colo provider are "IT solutions" people themselves. > Abuse handle phone #s are supposedly incorrect (I called it) I'm confused. Who are you billing and for what services? > Besides the obvious of me at the minimum filtering port tcp/25 is their an > organization that tracks businesses like these who seem like they are > building a web of insulation in which to move? > > I think this case might interest them. Spamhaus is the first one that comes to mind. From what I understand of your description, this doesn't sound all that different from typical spammer behavior. Multiple layers of indirection seems to be the latest thing for spammers. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jabley at hopcount.ca Tue Nov 24 21:54:08 2009 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 24 Nov 2009 19:54:08 -0800 Subject: Who has AS 1712? In-Reply-To: References: <20091123151043.GA11349@nic.fr> <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> <75cb24520911232033x24bacf13xa3bb9d32599f45ea@mail.gmail.com> Message-ID: On 2009-11-23, at 21:32, Jon Lewis wrote: > Checking "global BGP" only works if the ASN is being announced at that instant. How do you announce an ASN? Are you suggesting that I should be able to block the assignment of particular ASNs by simply including them in an AS_PATH attribute on a route I originate, and making sure that route shows up in route-views? Cool. :-) Joe From ge at linuxbox.org Tue Nov 24 21:57:30 2009 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 25 Nov 2009 05:57:30 +0200 Subject: I got a live one! - Spam source In-Reply-To: <5e1ca1ac0911241922u25634547u7eeb7ec6e357b352@mail.gmail.com> References: <5e1ca1ac0911241922u25634547u7eeb7ec6e357b352@mail.gmail.com> Message-ID: <4B0CAB2A.4030808@linuxbox.org> Russell Myba wrote: > Looks like of our customers has decided to turn their /24 into a nice little > space spewing machine. Doesn't seem like just one compromised host. > > Reverse DNS for most of the /24 are suspicious domains. Each domain used in > the message-id forwards to a single .net which lists their mailing address > as a PO box an single link to an unsubscribe field. > > I've contacted at least three known contacts for the customer about the > abuse without a single response. > > It would seem there are many layers to this entity: > > The domains are registered to one business > Our billing information for the customer has one name, they colo with > another person (whom the cross connect reaches) > Our customer has an IT solutions person working for them (Strange since our > customer and their colo provider are "IT solutions" people themselves. > Abuse handle phone #s are supposedly incorrect (I called it) > > Besides the obvious of me at the minimum filtering port tcp/25 is their an > organization that tracks businesses like these who seem like they are > building a web of insulation in which to move? > > I think this case might interest them. > From principle, I want to jump up and down and say "zap `em!". However, I also make several assumption which need to be clearned, pragmatically. I assume you have authority over the decision of what to do with them, and I also assume that your contract with them does not bind you in some fashion, can get you in trouble with the business side of the business, or can introduce *liability* issues. And naturally, that if you are not the decision maker, that you are synched with whomever it is. These assumptions aside, kicking them might not be the best solution. "Starving them" out by blocking port 25, as an example you gave, or following some of the other suggestions in this thread, may be workable. Which brings me three very important questions: 1. How much intelligence can you collect if you let them stay? 2. Have you considered legal action against them? 3. Did you consult with legal about possible law enforcement involvement? As to the intricate web of who they are and where their resources lie, these are usually cases where the more you dig, the more you find -- ad infinitum. Me? I'd just kick them after verifying they are not victims themselves. I hope this helps, Gadi. -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From randy at psg.com Tue Nov 24 22:02:28 2009 From: randy at psg.com (Randy Bush) Date: Wed, 25 Nov 2009 13:02:28 +0900 Subject: Who has AS 1712? In-Reply-To: References: <20091123151043.GA11349@nic.fr> <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> <75cb24520911232033x24bacf13xa3bb9d32599f45ea@mail.gmail.com> Message-ID: >> Checking "global BGP" only works if the ASN is being announced at that instant. > How do you announce an ASN? read a basic bgp primer and look at as-path attribute frackin' intentionally silly questions From rusmyba at gmail.com Tue Nov 24 22:07:20 2009 From: rusmyba at gmail.com (Russell Myba) Date: Tue, 24 Nov 2009 23:07:20 -0500 Subject: I got a live one! - Spam source In-Reply-To: References: <5e1ca1ac0911241922u25634547u7eeb7ec6e357b352@mail.gmail.com> Message-ID: <5e1ca1ac0911242007v1b6cb4a7gd2b08a37b4226d1e@mail.gmail.com> > > > I'm confused. Who are you billing and for what services? > > Let's say our direct customer is CustomerA. They seem to buy rackspace from BusinessB. CustomerA seem to retain BusinessC for "IT Solutions" even though all three entities purport to be IT solutions providers. BusinessC came into the picture after the spamming started saying a wholly different /24 (Different from the spam source) "doesn't work". It routes fine on our end. I have a feeling they've been added to some RBLs but I haven't found them listed yet. Just a simple ethernet handoff in a colo. We delegated rDNS to the servers of their choice and haven't heard a peep out of them until now. > Spamhaus is the first one that comes to mind. From what I understand of > your description, this doesn't sound all that different from typical spammer > behavior. Multiple layers of indirection seems to be the latest thing for > spammers. > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgpfor PGP public key_________ > From jabley at hopcount.ca Tue Nov 24 22:09:32 2009 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 24 Nov 2009 20:09:32 -0800 Subject: Who has AS 1712? In-Reply-To: References: <20091123151043.GA11349@nic.fr> <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> <75cb24520911232033x24bacf13xa3bb9d32599f45ea@mail.gmail.com> Message-ID: On 2009-11-24, at 20:02, Randy Bush wrote: >>> Checking "global BGP" only works if the ASN is being announced at that instant. >> How do you announce an ASN? > > read a basic bgp primer and look at as-path attribute Right. You can't advertise an ASN; you can only advertise a route and include an AS_PATH attribute on it which makes mention of a particular AS number. My point is that in the absence of any mechanism for announcing an ASN, a plan to gate assignment of numbers based on an announcement doesn't make any sense. Even in the loose sense of the phrase that you seem to prefer it's trivial (and arguably legitimate, although I appreciate that not everybody shares my libertarian views on AS_PATH attribute construction) for anybody at all to insert an AS number into an AS_PATH, and for the route bearing that AS_PATH attribute to propagate globally, whatever that means. So automated checking of "the BGP tables" for "existing announcements of an ASN" doesn't seem very helpful. > frackin' intentionally silly questions Apologies for expecting anybody to read beyond the first line of my reply. Joe From ops.lists at gmail.com Tue Nov 24 22:48:17 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 24 Nov 2009 20:48:17 -0800 Subject: fight club :) richard bennett vs various nanogers, on paid peering Message-ID: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> http://gigaom.com/2009/11/22/how-video-is-changing-the-internet/ Does the FTC's question 106 hurt paid peering or not? 88 comments. Makes real interesting reading, I must say. srs From richard at bennett.com Tue Nov 24 22:55:59 2009 From: richard at bennett.com (Richard Bennett) Date: Tue, 24 Nov 2009 20:55:59 -0800 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> Message-ID: <4B0CB8DF.4000100@bennett.com> Yes, it's a good old-fashioned Usenet-style flame-fest. Sort of. It turns out you can say any damn thing you want about peering since nobody has any facts. RB Suresh Ramasubramanian wrote: > http://gigaom.com/2009/11/22/how-video-is-changing-the-internet/ > > Does the FTC's question 106 hurt paid peering or not? 88 comments. > Makes real interesting reading, I must say. > > srs > > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From randy at psg.com Tue Nov 24 22:58:28 2009 From: randy at psg.com (Randy Bush) Date: Wed, 25 Nov 2009 13:58:28 +0900 Subject: Who has AS 1712? In-Reply-To: References: <20091123151043.GA11349@nic.fr> <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> <75cb24520911232033x24bacf13xa3bb9d32599f45ea@mail.gmail.com> Message-ID: > Right. You can't advertise an ASN > you can only advertise a route and include an AS_PATH attribute on it > which makes mention of a particular AS number. that bit of biff-like pedantry quickly leads to you can't advertise a prefix. a bgp announcement has, in the case of ip unicast, an nlri and, among other things, an as-path. see rfc 1771 4.3 on Path Attributes. as to what is being announced and what is merely loitering waiting for a hot pick-up, you can work that out with your mullah, priest, rabbi, spouse, ... for unusual utility of intentionally announcing a particular asn, see as-path poisoning, e.g. lorenzo's thesis [0], the talk which was banned at nanog [1], or the full paper [2]. > My point is that in the absence of any mechanism for announcing an > ASN, a plan to gate assignment of numbers based on an announcement > doesn't make any sense. seeing if an asn is in a currently-announced as-path is useful, as has been pointed out in this discussion. and it very well might have caught the problem at hand. the problem is that it is far from definitive as bgp presents a highly biased view (see [1] and [2]), and an asn may be held but not announced. but, as chris morrow said, every little bit helps. randy -- [0] - http://www.colitti.com/lorenzo/publications/phdthesis/thesis.pdf [1] - http:archive.psg.com/091006.nag-default.pdf [2] - http://portal.acm.org/citation.cfm?id=1644893.1644923&coll=portal&dl=ACM&type=series&idx=SERIES10693&part=series&WantType=Proceedings&title=IMC acm member portal, sorry. those really interested, email me for a copy From niels=nanog at bakker.net Tue Nov 24 23:07:54 2009 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 25 Nov 2009 06:07:54 +0100 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: <4B0CB8DF.4000100@bennett.com> References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> <4B0CB8DF.4000100@bennett.com> Message-ID: <20091125050754.GK20638@burnout.tpb.net> * richard at bennett.com (Richard Bennett) [Wed 25 Nov 2009, 05:56 CET]: >It turns out you can say any damn thing you want about peering since >nobody has any facts. You're projecting. -- Niels. From jlewis at lewis.org Tue Nov 24 23:08:52 2009 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 25 Nov 2009 00:08:52 -0500 (EST) Subject: Who has AS 1712? In-Reply-To: References: <20091123151043.GA11349@nic.fr> <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> <75cb24520911232033x24bacf13xa3bb9d32599f45ea@mail.gmail.com> Message-ID: On Tue, 24 Nov 2009, Joe Abley wrote: > > On 2009-11-23, at 21:32, Jon Lewis wrote: > >> Checking "global BGP" only works if the ASN is being announced at that instant. > > How do you announce an ASN? Ok...bad wording. s/announced/used to announce or propagate one or more routes/ > Are you suggesting that I should be able to block the assignment of > particular ASNs by simply including them in an AS_PATH attribute on a > route I originate, and making sure that route shows up in route-views? No...but that would hopefully be cause for further investigation before an ASN is assigned. With multiple orgs assigning from the same small pool of numbers, and an early history of, shall we say, incomplete record keeping, a little extra caution could avoid a lot of pain. I would hope the number of orgs that would pollute the global table with bogus AS Paths for the purpose of making more work for ARIN/RIPE/APNIC/etc. is not very large. If you want to announce certain routes with "bogus" AS Paths to keep certain networks from seeing them, that's one thing, but why would you do this with ASNs not currently assigned? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From randy at psg.com Tue Nov 24 23:10:51 2009 From: randy at psg.com (Randy Bush) Date: Wed, 25 Nov 2009 14:10:51 +0900 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: <4B0CB8DF.4000100@bennett.com> References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> <4B0CB8DF.4000100@bennett.com> Message-ID: > It turns out you can say any damn thing you want about peering since > nobody has any facts. not really. it's just that those with the facts have no reason to blab them and reasons not to do so. randy From ops.lists at gmail.com Tue Nov 24 23:45:20 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 25 Nov 2009 11:15:20 +0530 Subject: I got a live one! - Spam source In-Reply-To: <5e1ca1ac0911241922u25634547u7eeb7ec6e357b352@mail.gmail.com> References: <5e1ca1ac0911241922u25634547u7eeb7ec6e357b352@mail.gmail.com> Message-ID: On Wed, Nov 25, 2009 at 8:52 AM, Russell Myba wrote: > Looks like of our customers has decided to turn their /24 into a nice little > space spewing machine. ?Doesn't seem like just one compromised host. > > Reverse DNS for most of the /24 are suspicious domains. ?Each domain used in > the message-id forwards to a single .net which lists their mailing address > as a PO box an single link to an unsubscribe field. Sounds like what spamhaus.org calls snowshoe. What /24 would this be? From richard at bennett.com Wed Nov 25 00:00:52 2009 From: richard at bennett.com (Richard Bennett) Date: Tue, 24 Nov 2009 22:00:52 -0800 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> <4B0CB8DF.4000100@bennett.com> Message-ID: <4B0CC814.4030609@bennett.com> I haven't found a good source who knows what's going on outside his own network. Randy Bush wrote: It turns out you can say any damn thing you want about peering since nobody has any facts. not really. it's just that those with the facts have no reason to blab them and reasons not to do so. randy -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From pauldotwall at gmail.com Wed Nov 25 00:22:04 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Wed, 25 Nov 2009 06:22:04 +0000 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: <4B0CB8DF.4000100@bennett.com> References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> <4B0CB8DF.4000100@bennett.com> Message-ID: <620fd17c0911242222l122ade20o65034eb16d2f7380@mail.gmail.com> On 11/25/09, Richard Bennett wrote: > It turns out you can say any damn thing you want about peering since > nobody has any facts. Indeed you can. This is one of things where the people with the hard facts aren't talking due to NDA, regard for their pride, or both. In the absence of solid data, most journalists (and I use the term loosely) take the high road, writing on only what they know about and can back up with fact. It is unfortunate that you approach this differently, attempting to pass off Bill Norton's blog, itself very flawed and comprised of error upon error which he simply refuses to acknowledge or correct, as the new gospel. You write that "the shift of an enormous amount of Internet traffic from transit to paid peering is new, that?s what the data in the Arbor Networks study shows". Nowhere in the Arbor study is there any analysis of where money is passing hands, or any settlement-based vs. settlement-free interconnection arrangement. The report is a scientific one based upon aggregated netflow/sflow data, which doesn't take layers 8 and above into account. Also suspiciously absent is any disclosure of employer affiliations and biases. You write that "[you're] opposed to the anti-discrimination rule that the FCC is considering". What you fail to mention is that you work for the ITIF, a Washington think-tank allegedly funded by big cable. Is it really any surprise that you want to preserve this revenue stream? Likewise, Norton neglects to mention that he works for NuMetra, a company going around to content and broadband operators trying to pitch a some black box which will enforce last-mile QoS and automatically pay the friendly local Internet monopoly/duopoly in "settlement" fees *on top* of your regular transit costs. Of course he wants Uncle Sam to back off; that's how his employer benefits. It is also important to consider Mr. Norton's role in Equinix, where he worked in MARKETING, far distanced from the establishment of actual peering agreements. The real co-founders were Jay Adelson and Al Avery. It is sad to see that Mr. Norton, once a valued member of the community, so blatantly favoring the green stuff over fact-checking and journalistic integrity. One can only hope Om Malik will carry out better due diligence in the future when hiring "industry experts" to write for him. Drive Slow, Paul Wall From richard at bennett.com Wed Nov 25 00:27:23 2009 From: richard at bennett.com (Richard Bennett) Date: Tue, 24 Nov 2009 22:27:23 -0800 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: <620fd17c0911242222l122ade20o65034eb16d2f7380@mail.gmail.com> References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> <4B0CB8DF.4000100@bennett.com> <620fd17c0911242222l122ade20o65034eb16d2f7380@mail.gmail.com> Message-ID: <4B0CCE4B.8000600@bennett.com> Speculation about how the money flows is a worthwhile activity. Paul Wall wrote: On 11/25/09, Richard Bennett [1] wrote: It turns out you can say any damn thing you want about peering since nobody has any facts. Indeed you can. This is one of things where the people with the hard facts aren't talking due to NDA, regard for their pride, or both. In the absence of solid data, most journalists (and I use the term loosely) take the high road, writing on only what they know about and can back up with fact. It is unfortunate that you approach this differently, attempting to pass off Bill Norton's blog, itself very flawed and comprised of error upon error which he simply refuses to acknowledge or correct, as the new gospel. You write that "the shift of an enormous amount of Internet traffic from transit to paid peering is new, that's what the data in the Arbor Networks study shows". Nowhere in the Arbor study is there any analysis of where money is passing hands, or any settlement-based vs. settlement-free interconnection arrangement. The report is a scientific one based upon aggregated netflow/sflow data, which doesn't take layers 8 and above into account. Also suspiciously absent is any disclosure of employer affiliations and biases. You write that "[you're] opposed to the anti-discrimination rule that the FCC is considering". What you fail to mention is that you work for the ITIF, a Washington think-tank allegedly funded by big cable. Is it really any surprise that you want to preserve this revenue stream? Likewise, Norton neglects to mention that he works for NuMetra, a company going around to content and broadband operators trying to pitch a some black box which will enforce last-mile QoS and automatically pay the friendly local Internet monopoly/duopoly in "settlement" fees *on top* of your regular transit costs. Of course he wants Uncle Sam to back off; that's how his employer benefits. It is also important to consider Mr. Norton's role in Equinix, where he worked in MARKETING, far distanced from the establishment of actual peering agreements. The real co-founders were Jay Adelson and Al Avery. It is sad to see that Mr. Norton, once a valued member of the community, so blatantly favoring the green stuff over fact-checking and journalistic integrity. One can only hope Om Malik will carry out better due diligence in the future when hiring "industry experts" to write for him. Drive Slow, Paul Wall -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC References 1. mailto:richard at bennett.com From jabley at hopcount.ca Wed Nov 25 00:34:30 2009 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 24 Nov 2009 22:34:30 -0800 Subject: Who has AS 1712? In-Reply-To: References: <20091123151043.GA11349@nic.fr> <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> <75cb24520911232033x24bacf13xa3bb9d32599f45ea@mail.gmail.com> Message-ID: On 2009-11-24, at 20:58, Randy Bush wrote: >> Right. You can't advertise an ASN >> you can only advertise a route and include an AS_PATH attribute on it >> which makes mention of a particular AS number. > > that bit of biff-like pedantry quickly leads to you can't advertise a > prefix. Apologies if the pedantry seems unnecessary. I think the parallel between the announcement of a route (which has inherent reachability information contained within it) and use of an ASN in an AS_PATH attribute (which doesn't always) are different with respect to identifying use of a resource. Overloading "advertise" for both suggests you can identify use of a resource elsewhere using the same measurement technique, which I think is broken logic. > a bgp announcement has, in the case of ip unicast, an nlri and, > among other things, an as-path. see rfc 1771 4.3 on Path Attributes. I used the word "route" in the sense that it's defined in 4271. > as to what is being announced and what is merely loitering waiting for a > hot pick-up, you can work that out with your mullah, priest, rabbi, > spouse, ... As a divorced atheist I guess I'll just read RFCs :-) > for unusual utility of intentionally announcing a particular asn, see > as-path poisoning, e.g. lorenzo's thesis [0], the talk which was banned > at nanog [1], or the full paper [2]. Josh and I also talked about it at NANOG 24. I remember using it to poison routes advertised through certain edges of AS 1221 a decade ago after the idea was suggested to me by Geoff Huston, and I'm sure it was probably old news then. >> My point is that in the absence of any mechanism for announcing an >> ASN, a plan to gate assignment of numbers based on an announcement >> doesn't make any sense. > > seeing if an asn is in a currently-announced as-path is useful, as has > been pointed out in this discussion. I don't think it's as simple as people have suggested. The fact that nobody has ever seen a particular number present in an AS_PATH attribute might mean that the ASN has never been configured on a router, or it might mean that nobody has ever taken a measurement from a router who has seen such a route. The fact that someone has seen a particular number present in an AS_PATH attribute might mean that that number has been used for a particular autonomous system, or it might mean that someone is doing something (intentional or otherwise) with AS_PATHs for their own personal reasons. The topic of this thread is really concerned with database hygiene in a distributed system which, as you have pointed out repeatedly, lacks procedural or mathematical rigour. Checking whether or not a particular AS_PATH regex matches anything in one or more RIBs might tell you something, or it might give you clues as to who to call to find out more, but it can never tell you anything definitively. Definitive knowledge sure seems like it's what you want if your job is to guarantee uniqueness. It seems to me that at some point we need to stop trying to put dresses on the pig. Joe From richard at bennett.com Wed Nov 25 00:35:53 2009 From: richard at bennett.com (Richard Bennett) Date: Tue, 24 Nov 2009 22:35:53 -0800 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: <4B0CCE4B.8000600@bennett.com> References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> <4B0CB8DF.4000100@bennett.com> <620fd17c0911242222l122ade20o65034eb16d2f7380@mail.gmail.com> <4B0CCE4B.8000600@bennett.com> Message-ID: <4B0CD049.4060004@bennett.com> Of course, the FCC/FTC could always get involved and mandate full disclosure and peering neutrality. That might be fun. RB Richard Bennett wrote: > Speculation about how the money flows is a worthwhile activity. > Paul Wall wrote: > > On 11/25/09, Richard Bennett [1] wrote: > > It turns out you can say any damn thing you want about peering since > nobody has any facts. > > Indeed you can. This is one of things where the people with the hard > facts aren't talking due to NDA, regard for their pride, or both. In > the absence of solid data, most journalists (and I use the term > loosely) take the high road, writing on only what they know about and > can back up with fact. It is unfortunate that you approach this > differently, attempting to pass off Bill Norton's blog, itself very > flawed and comprised of error upon error which he simply refuses to > acknowledge or correct, as the new gospel. > > You write that "the shift of an enormous amount of Internet traffic > from transit to paid peering is new, that's what the data in the Arbor > Networks study shows". Nowhere in the Arbor study is there any > analysis of where money is passing hands, or any settlement-based vs. > settlement-free interconnection arrangement. The report is a > scientific one based upon aggregated netflow/sflow data, which doesn't > take layers 8 and above into account. > > Also suspiciously absent is any disclosure of employer affiliations > and biases. You write that "[you're] opposed to the > anti-discrimination rule that the FCC is considering". What you > fail to mention is that you work for the ITIF, a Washington think-tank > allegedly funded by big cable. Is it really any surprise that you > want to preserve this revenue stream? > > Likewise, Norton neglects to mention that he works for NuMetra, a > company going around to content and broadband operators trying to > pitch a some black box which will enforce last-mile QoS and > automatically pay the friendly local Internet monopoly/duopoly in > "settlement" fees *on top* of your regular transit costs. Of course > he wants Uncle Sam to back off; that's how his employer benefits. It > is also important to consider Mr. Norton's role in Equinix, where he > worked in MARKETING, far distanced from the establishment of actual > peering agreements. The real co-founders were Jay Adelson and Al Avery. > > It is sad to see that Mr. Norton, once a valued member of the > community, so blatantly favoring the green stuff over fact-checking > and journalistic integrity. One can only hope Om Malik will carry out > better due diligence in the future when hiring "industry experts" to > write for him. > > Drive Slow, > Paul Wall > > -- > Richard Bennett > Research Fellow > Information Technology and Innovation Foundation > Washington, DC > > References > > 1. mailto:richard at bennett.com > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From bmanning at vacation.karoshi.com Wed Nov 25 00:46:18 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 25 Nov 2009 06:46:18 +0000 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: <4B0CC814.4030609@bennett.com> References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> <4B0CB8DF.4000100@bennett.com> <4B0CC814.4030609@bennett.com> Message-ID: <20091125064618.GA16378@vacation.karoshi.com.> and in the absence of source routing, why would I care what happens past the first hop? to the extent I can know, document, and prove my internal network and its connectivity to its peers, that becomes the item of value, the reputation of the network and its treatment of its peers, clients and providers. and the funny thing about reputation. its so hard to build a good one and so easy to lose. the second odd thing about reputation, its nearly impossible to quantify. --bill (pre-dating norton and woodcock in the peering game) On Tue, Nov 24, 2009 at 10:00:52PM -0800, Richard Bennett wrote: > I haven't found a good source who knows what's going on outside his own > network. > Randy Bush wrote: > > not really. it's just that those with the facts have no reason to blab > them and reasons not to do so. > > randy > > -- > Richard Bennett From michael at linuxmagic.com Wed Nov 25 00:55:53 2009 From: michael at linuxmagic.com (Michael Peddemors) Date: Tue, 24 Nov 2009 22:55:53 -0800 Subject: I got a live one! - Spam source In-Reply-To: <5e1ca1ac0911242007v1b6cb4a7gd2b08a37b4226d1e@mail.gmail.com> References: <5e1ca1ac0911241922u25634547u7eeb7ec6e357b352@mail.gmail.com> <5e1ca1ac0911242007v1b6cb4a7gd2b08a37b4226d1e@mail.gmail.com> Message-ID: <200911242255.53593.michael@linuxmagic.com> On November 24, 2009, Russell Myba wrote: > > Spamhaus is the first one that comes to mind. From what I understand of > > your description, this doesn't sound all that different from typical > > spammer behavior. Multiple layers of indirection seems to be the latest > > thing for spammers. Depends on the activity, but this re-iterates the importance of maintaining correct SWIP, so that only the offenders get listed, and not bordering customers. But if you give the info on the listed company and range, we might be able to give you a lot more information.. I was just reading the latest spam auditors report, and it is always amazing how the same guys keep finding new colo's to work out of .. -- -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors - President/CEO - LinuxMagic Products, Services, Support and Development Visit us at http://www.linuxmagic.com ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-589-0037 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From morrowc.lists at gmail.com Wed Nov 25 01:14:13 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 25 Nov 2009 02:14:13 -0500 Subject: Who has AS 1712? In-Reply-To: References: <20091123151043.GA11349@nic.fr> <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> <75cb24520911232033x24bacf13xa3bb9d32599f45ea@mail.gmail.com> Message-ID: <75cb24520911242314k17d6f01y98c6dddddef82d1a@mail.gmail.com> On Wed, Nov 25, 2009 at 1:34 AM, Joe Abley wrote: > It seems to me that at some point we need to stop trying to put dresses on the pig. how, given where we are today, do you do that? I agree that presence of an ASN in routing data (in as_paths really) isn't proof of existence/use/abuse but not checking is not helping. 100% perfect would be awesome, today we have less than 100%, we could be doing a job closer to 100% by acting on some low-hanging fruit. To really move forward and get to 100% (or as near as we can hope for) what steps/actions/changes do you propose? It seems that at least RIPE/ARIN have their attentioned aimed this way now :) -Chris From fergdawgster at gmail.com Wed Nov 25 01:17:57 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 24 Nov 2009 23:17:57 -0800 Subject: I got a live one! - Spam source In-Reply-To: <200911242255.53593.michael@linuxmagic.com> References: <5e1ca1ac0911241922u25634547u7eeb7ec6e357b352@mail.gmail.com> <5e1ca1ac0911242007v1b6cb4a7gd2b08a37b4226d1e@mail.gmail.com> <200911242255.53593.michael@linuxmagic.com> Message-ID: <6cd462c00911242317g5fa67dd4me2199661ca400791@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Nov 24, 2009 at 10:55 PM, Michael Peddemors wrote: > > Depends on the activity, but this re-iterates the importance of > maintaining correct SWIP, so that only the offenders get listed, and not > bordering > customers. > Right. There are *so many* loopholes in this entire process, Bad Guys are waltzing through it. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLDNofq1pz9mNUZTMRAgNrAKDz6JwFqBG3gvXEIKo1UVrJSTmxDQCfadqV Ph3qt/qPDze8Z5tsRP7LgSw= =gQrR -----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 justin at justinshore.com Wed Nov 25 01:27:04 2009 From: justin at justinshore.com (Justin Shore) Date: Wed, 25 Nov 2009 01:27:04 -0600 Subject: I got a live one! - Spam source In-Reply-To: <5e1ca1ac0911242007v1b6cb4a7gd2b08a37b4226d1e@mail.gmail.com> References: <5e1ca1ac0911241922u25634547u7eeb7ec6e357b352@mail.gmail.com> <5e1ca1ac0911242007v1b6cb4a7gd2b08a37b4226d1e@mail.gmail.com> Message-ID: <4B0CDC48.9050507@justinshore.com> Russell Myba wrote: > Let's say our direct customer is CustomerA. They seem to buy rackspace from > BusinessB. CustomerA seem to retain BusinessC for "IT Solutions" even > though all three entities purport to be IT solutions providers. > BusinessC came into the picture after the spamming started saying a wholly > different /24 (Different from the spam source) "doesn't work". It routes > fine on our end. I have a feeling they've been added to some RBLs but I > haven't found them listed yet. > > Just a simple ethernet handoff in a colo. We delegated rDNS to the servers > of their choice and haven't heard a peep out of them until now. I think it's an absolute crying shame that a freak bolt of lighting somehow fried their rackspace in the colo and didn't affect any of the surrounding neighbors. I hate it when that happens. It's karma I think... Justin From daniel.karrenberg at ripe.net Wed Nov 25 01:57:45 2009 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 25 Nov 2009 08:57:45 +0100 Subject: Who has AS 1712? In-Reply-To: References: <20091124074817.GA6170@reiftel.karrenberg.net> <20091123151043.GA11349@nic.fr> <5.1.0.14.2.20091124113919.00c47098@efes.iucc.ac.il> <4B0C48DF.1040806@justinshore.com> Message-ID: <20091125075745.GD6170@reiftel.karrenberg.net> On 25.11 06:21, Randy Bush wrote: > > Of course if it was already assigned when IANA said that (no dates on > > the link above) then maybe the fault is more IANA's for telling another > > RIR that they could allocate an ASN that another RIR already allocated. > > i suspect that, in the erx project, there may have been more than one > case of the iana saying "ok, X now manages this block, excpet of course > for those pieces already allocated by Y and Z." and the latter were not > always well defined or easily learnable, and were not registered > directly with the iana, but other rirs. > > > > and the data are all buried in whois, which is not well-defined, stats > files, which are not defined, etc. the rirs, in the thrall of nih (you > did know that ripe/ncc invented the bicycle), spent decades not agreeing > on common formats, protocols, or code. this is one result thereof. > testosterone kills, and the community gets the collateral damage. [Excuse the length of this. Randy just overloaded my patience circuit and I need to dissipate some testosterone induced energy. If you are only interested in details about the issue at hand, skip this message. If you are interested in a different view on (history of) the RIRs, read on.] Randy, it is absolutely unfair to shout at the RIRs and particularly at the RIPE NCC in this context and I take offence. This particular problem is caused by a record keeping error back in the days when RIRs did not even exist! So these resources never went through the hands of the RIPE NCC and were not conisdered by ERX at all. I'll leave it to ARIN to publish the detailed analysis once it is complete, but this is the essence of it. Back when I was responsible for the RIPE NCC in the 1990s, I personally spent considerable time developing and proposing exchange formats and database synchronisation tools. The RIPE NCC proposed close synchronisation of Internet number resource databases several times. This never got done because InterNIC and later ARIN resisted. It was quite frustrating. You can find polite expressions of my frustration in early RIPE NCC quarterly and annual reports if you look carefully. When APNIC was established, the RIPE NCC had close database synchroninsation with them from the start; the same occurred with AfriNIC later; both of these were achieved by definite *lack* of NIH and 'testosterone'. So if you cannot resist the urge to shout, please re-direct your shouting. This is all water under the bridge of course and we are moving on; but blaming the RIPE NCC in particular for NIH and 'testosterone' is just unfair! And no, we did not invent the bicycle, but in moments of hybris I do claim that we did in fact invent the RIR as such. ;-) I do not say everything is ideal now. However the RIRs are actively working to publish a complete set of stats files which also includes unallocated resources. This is the next best thing to full database synchronisation. APNIC and the RIPE NCC are driving this effort. In fact the track record of the RIRs is excellent so far, given the number of different resource blocks and the number of resource users. Yes, errors in historical records from two decades ago *should* be caught and all RIRs will certainly learn from this unfortunate episode. But the blanket shouting of the kind you did here is unfair, offensive and unwarranted. Respectfully Daniel From jabley at hopcount.ca Wed Nov 25 02:01:48 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 25 Nov 2009 00:01:48 -0800 Subject: Who has AS 1712? In-Reply-To: <75cb24520911242314k17d6f01y98c6dddddef82d1a@mail.gmail.com> References: <20091123151043.GA11349@nic.fr> <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> <75cb24520911232033x24bacf13xa3bb9d32599f45ea@mail.gmail.com> <75cb24520911242314k17d6f01y98c6dddddef82d1a@mail.gmail.com> Message-ID: <4C9E2A2F-0355-4C76-8722-5D9FA8473AA0@hopcount.ca> On 2009-11-24, at 23:14, Christopher Morrow wrote: > To really move forward and get to 100% (or as near as we can hope for) > what steps/actions/changes do you propose? It seems that at least > RIPE/ARIN have their attentioned aimed this way now :) Apparently I have accidentally climbed a soapbox whilst trying to explain what I thought was a fairly simple point. I'll get down. I am fairly sure the RIRs don't need my help in cleaning their databases or figuring out clever ways to keep them consistent in the future. Given the experience with ERX presumably there is enthusiasm for future transfers to be handled more rigourously. Joe From fweimer at bfk.de Wed Nov 25 02:22:59 2009 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 25 Nov 2009 08:22:59 +0000 Subject: Who has AS 1712? In-Reply-To: (Jared Mauch's message of "Tue\, 24 Nov 2009 14\:02\:04 -0500") References: <20091123151043.GA11349@nic.fr> <4B0AB307.9070400@merit.edu> <20091124011129.GA60839@puck.nether.net> Message-ID: <82ocmrm2sc.fsf@mid.bfk.de> * Jared Mauch: > The issue of zone signing is going to be interesting as some > nation-states (ccTLD) have been known to speak-up about their issues > with the signing of the zone. Which ones? In most cases, ccTLDs don't represent nation states, and vice versa. -- 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 ras at e-gerbil.net Wed Nov 25 02:41:58 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 25 Nov 2009 02:41:58 -0600 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: <4B0CC814.4030609@bennett.com> References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> <4B0CB8DF.4000100@bennett.com> <4B0CC814.4030609@bennett.com> Message-ID: <20091125084158.GT51443@gerbil.cluepon.net> On Tue, Nov 24, 2009 at 10:00:52PM -0800, Richard Bennett wrote: > I haven't found a good source who knows what's going on outside his own > network. Mr. Bennett, You know when I first read your post, I assumed you were just ignorant and confused about the topic of peering on the Internet. Then I saw you actively refusing to listen to intelligent feedback by some of the most experienced network operators and peering managers in the industry, dismiss any idea that you didn't agree with as part of the "Google conspiracy", and further embarrass yourself with comments which proved you lacked understanding of even the most basic concepts of peering or inter-network traffic exchange. Normally I would just write you off as another Dean Anderson style nutjob, but I'm afraid that your ramblings are so wrong and your closed-mindedness is so severe that you are actually dangerous to anyone who might happen to read your comments and think that they are in any way correct. Therefore, I think it is important for all of us that you be refuted. I'll start with a few points from your post and comments. You said: > I'm not sure that your 'on-net routes' is the same product as the Paid > Peering that Norton is interpreting; the Arbor study found a large > increase in the traffic that moves through these transit bypass paths, > and that's the actual story. While this service may have been > available for a while, its use is radically increasing. That's data, > BTW, not anecdote, so if you have a problem with the Arbor data, > you'll need some data of your own to refute it. For starters, if you aren't sure what "on-net routes" and "paid peering" even are, maybe you shouldn't be trying to comment on them. Second, the Arbor study said absolutely NOTHING about an increase in traffic that moves via peering vs transit, to say nothing of paid vs settlement free peering. Arbor is completely and totally unable to identify anything about money exchanged for bits in general, and from a technical perspective there is absolute no difference between a paid and non-paid peering. You seem to be convoluting the purported "increase in traffic between tier 2 networks" with a completely absurd belief that all traffic between tier 1's was transit and all traffic between tier 2's is peering. In reality, tier 2's routinely buy from and sell to each other, peer with some tier 1's, and sell paid peering between themselves when the business opportunities arise. You later go on to state: > The Arbor study is evidence that traffic is shifting, and the > carrier-neutral peering site managers I've spoken with tell me they're > making something like 300 cross-connects a month. Do you think all > those cross-connnects are implementing settlement-free peering or > conventional transit agreements? I'm surmising that they aren't. You have absolutely no basis to make the determination about what percentage of the crossconnects are peering and what percentage are transit. This is what we tried to explain to you with the "you can't know this about any network but your own" answer, which you seemed completely incapable of understanding. The reality is that no one can know the answer for anything but themselves. For my network, I'd say much less than 20% of our crossconnects are peering, with the vast majority being customers, and a significant amount being intra-network capacity (intra-pop, metro, and long-haul circuits) and transit. The number may vary between networks, but again you have absolutely zero basis to make any kind of claim about peering let alone settlement-free vs paid based on the number of crossconnects in a colo. Most of the other arguments are either meaningless or fall apart once you remove some of the fundamental misunderstandings above, but there are still plenty of other things which are completely absurd. For example, you said: > Paid peering is a better level of access to an ISP's customers for a > fee, but the fee is less than the price of generic access to the ISP > via a transit network. The practice of paid peering also reduces the > load on the Internet core, so what's not to like? Paid peering > agreements should be offered for sale on a non-discriminatory basis, > but they certainly shouldn't be banned. Paid peering (or peering of any kind) is absolutely no guarantee of "better" access to any network, nor is it guaranteed (or even likely) to reduce costs. There is also no such thing as "load on the Internet core" to reduce, and this further illustrates a complete failure to understand how the Internet works in general. Paid peering is simply another form of transit, where two networks agree to exchange money for the service of delivering connectivity. The only difference is that you're only selling a portion of the routing table rather than the "whole thing", for a specific subset of routes which have different properties than the rest. In the case of paid peering, the different property is that you'll get to bill your customer on the other side for the traffic, thus allowing you to "double dip" for the same bit and potentially make more money. Of course in practice it doesn't work this way at all. The vast majority of the cost of operating a network is transporting the bits from one place to another, and when you sell paid peering you are guaranteed that the traffic is going to stay on your network and be hauled. This makes it some of the most expensive traffic to deliver, and typically results in prices which are higher than those of another network who is hot potatoing those bits off their network in one location, and who is sending the traffic to a settlement-free peer. There is nothing wrong with paid peering, it often has a time and a place (such as when two networks are close to being settlement-free peers, but not quite, and someone needs to sweeten the deal a little bit), but it is not the panacea you think it is. Of course nobody else seems to think the FCC Question 106 is talking about regulating paid peering (which would be absurd), so fortunately I don't think we have anything to worry about. Of course all of these points (and more) were already quite elegantly expressed by fine folks like Vijay Gill, Dan Golding, Patrick Gilmore, Joe Provo, and others. They tried to help correct your misinformation with free advice, and you repaid them with delusional rants. Now you simply look like a fool to everyone. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From richard at bennett.com Wed Nov 25 02:54:50 2009 From: richard at bennett.com (Richard Bennett) Date: Wed, 25 Nov 2009 00:54:50 -0800 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: <20091125084158.GT51443@gerbil.cluepon.net> References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> <4B0CB8DF.4000100@bennett.com> <4B0CC814.4030609@bennett.com> <20091125084158.GT51443@gerbil.cluepon.net> Message-ID: <4B0CF0DA.5030400@bennett.com> Thank you for your insights. Richard A Steenbergen wrote: On Tue, Nov 24, 2009 at 10:00:52PM -0800, Richard Bennett wrote: I haven't found a good source who knows what's going on outside his own network. Mr. Bennett, You know when I first read your post, I assumed you were just ignorant and confused about the topic of peering on the Internet. Then I saw you actively refusing to listen to intelligent feedback by some of the most experienced network operators and peering managers in the industry, dismiss any idea that you didn't agree with as part of the "Google conspiracy", and further embarrass yourself with comments which proved you lacked understanding of even the most basic concepts of peering or inter-network traffic exchange. Normally I would just write you off as another Dean Anderson style nutjob, but I'm afraid that your ramblings are so wrong and your closed-mindedness is so severe that you are actually dangerous to anyone who might happen to read your comments and think that they are in any way correct. Therefore, I think it is important for all of us that you be refuted. I'll start with a few points from your post and comments. You said: I'm not sure that your 'on-net routes' is the same product as the Paid Peering that Norton is interpreting; the Arbor study found a large increase in the traffic that moves through these transit bypass paths, and that's the actual story. While this service may have been available for a while, its use is radically increasing. That's data, BTW, not anecdote, so if you have a problem with the Arbor data, you'll need some data of your own to refute it. For starters, if you aren't sure what "on-net routes" and "paid peering" even are, maybe you shouldn't be trying to comment on them. Second, the Arbor study said absolutely NOTHING about an increase in traffic that moves via peering vs transit, to say nothing of paid vs settlement free peering. Arbor is completely and totally unable to identify anything about money exchanged for bits in general, and from a technical perspective there is absolute no difference between a paid and non-paid peering. You seem to be convoluting the purported "increase in traffic between tier 2 networks" with a completely absurd belief that all traffic between tier 1's was transit and all traffic between tier 2's is peering. In reality, tier 2's routinely buy from and sell to each other, peer with some tier 1's, and sell paid peering between themselves when the business opportunities arise. You later go on to state: The Arbor study is evidence that traffic is shifting, and the carrier-neutral peering site managers I've spoken with tell me they're making something like 300 cross-connects a month. Do you think all those cross-connnects are implementing settlement-free peering or conventional transit agreements? I'm surmising that they aren't. You have absolutely no basis to make the determination about what percentage of the crossconnects are peering and what percentage are transit. This is what we tried to explain to you with the "you can't know this about any network but your own" answer, which you seemed completely incapable of understanding. The reality is that no one can know the answer for anything but themselves. For my network, I'd say much less than 20% of our crossconnects are peering, with the vast majority being customers, and a significant amount being intra-network capacity (intra-pop, metro, and long-haul circuits) and transit. The number may vary between networks, but again you have absolutely zero basis to make any kind of claim about peering let alone settlement-free vs paid based on the number of crossconnects in a colo. Most of the other arguments are either meaningless or fall apart once you remove some of the fundamental misunderstandings above, but there are still plenty of other things which are completely absurd. For example, you said: Paid peering is a better level of access to an ISP's customers for a fee, but the fee is less than the price of generic access to the ISP via a transit network. The practice of paid peering also reduces the load on the Internet core, so what's not to like? Paid peering agreements should be offered for sale on a non-discriminatory basis, but they certainly shouldn't be banned. Paid peering (or peering of any kind) is absolutely no guarantee of "better" access to any network, nor is it guaranteed (or even likely) to reduce costs. There is also no such thing as "load on the Internet core" to reduce, and this further illustrates a complete failure to understand how the Internet works in general. Paid peering is simply another form of transit, where two networks agree to exchange money for the service of delivering connectivity. The only difference is that you're only selling a portion of the routing table rather than the "whole thing", for a specific subset of routes which have different properties than the rest. In the case of paid peering, the different property is that you'll get to bill your customer on the other side for the traffic, thus allowing you to "double dip" for the same bit and potentially make more money. Of course in practice it doesn't work this way at all. The vast majority of the cost of operating a network is transporting the bits from one place to another, and when you sell paid peering you are guaranteed that the traffic is going to stay on your network and be hauled. This makes it some of the most expensive traffic to deliver, and typically results in prices which are higher than those of another network who is hot potatoing those bits off their network in one location, and who is sending the traffic to a settlement-free peer. There is nothing wrong with paid peering, it often has a time and a place (such as when two networks are close to being settlement-free peers, but not quite, and someone needs to sweeten the deal a little bit), but it is not the panacea you think it is. Of course nobody else seems to think the FCC Question 106 is talking about regulating paid peering (which would be absurd), so fortunately I don't think we have anything to worry about. Of course all of these points (and more) were already quite elegantly expressed by fine folks like Vijay Gill, Dan Golding, Patrick Gilmore, Joe Provo, and others. They tried to help correct your misinformation with free advice, and you repaid them with delusional rants. Now you simply look like a fool to everyone. -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From bortzmeyer at nic.fr Wed Nov 25 03:12:51 2009 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 25 Nov 2009 10:12:51 +0100 Subject: Who has AS 1712? In-Reply-To: References: <20091123151043.GA11349@nic.fr> <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> <75cb24520911232033x24bacf13xa3bb9d32599f45ea@mail.gmail.com> Message-ID: <20091125091251.GA30648@nic.fr> On Tue, Nov 24, 2009 at 07:54:08PM -0800, Joe Abley wrote a message of 13 lines which said: > Are you suggesting that I should be able to block the assignment of > particular ASNs by simply including them in an AS_PATH attribute on > a route I originate, and making sure that route shows up in > route-views? No one suggested a complete, blind and automatic blocking of the assignment. Just a suggestion to RIRs to check if the AS number they are ready to assign is used in an AS path somewhere and, if so, to raise a flag, to assign a physical person on the matter, to investigate, to check the databases, etc. This would have catched the AS 1712 issue. From hank at efes.iucc.ac.il Wed Nov 25 03:33:51 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 25 Nov 2009 11:33:51 +0200 Subject: Who has AS 1712? In-Reply-To: <20091125075745.GD6170@reiftel.karrenberg.net> References: <20091124074817.GA6170@reiftel.karrenberg.net> <20091123151043.GA11349@nic.fr> <5.1.0.14.2.20091124113919.00c47098@efes.iucc.ac.il> <4B0C48DF.1040806@justinshore.com> Message-ID: <5.1.0.14.2.20091125112942.0565e050@efes.iucc.ac.il> At 08:57 25/11/2009 +0100, Daniel Karrenberg wrote: >shouting. This is all water under the bridge of course and we are >moving on; >I do not say everything is ideal now. However the RIRs are actively >working to publish a complete set of stats files which also includes >unallocated resources. This is the next best thing to full database >synchronisation. APNIC and the RIPE NCC are driving this effort. Perhaps the RIRs could get together and agree on a common whois syntax so that when I check one RIR with one syntax - it would work on others as well? This issue has been around for over 7 years and I can't understand why the RIRs can't find common ground for the sake of the end users? Even if ARIN or APNIC won't accept "-B -G", then at least let their whois engine just ignore those extra parameters it doesn't understand. To me it looks like minor software changes. -Hank From randy at psg.com Wed Nov 25 03:36:13 2009 From: randy at psg.com (Randy Bush) Date: Wed, 25 Nov 2009 18:36:13 +0900 Subject: Who has AS 1712? In-Reply-To: <5.1.0.14.2.20091125112942.0565e050@efes.iucc.ac.il> References: <20091124074817.GA6170@reiftel.karrenberg.net> <20091123151043.GA11349@nic.fr> <5.1.0.14.2.20091124113919.00c47098@efes.iucc.ac.il> <4B0C48DF.1040806@justinshore.com> <20091125075745.GD6170@reiftel.karrenberg.net> <5.1.0.14.2.20091125112942.0565e050@efes.iucc.ac.il> Message-ID: > Perhaps the RIRs could get together and agree on a common whois syntax so > that when I check one RIR with one syntax - it would work on others as > well? This issue has been around for over 7 years and I can't understand > why the RIRs can't find common ground for the sake of the end users? s/7/15/ it was already feeling like brickmarks on my forhead at the first s'holm ietf in '95 randy From fweimer at bfk.de Wed Nov 25 03:52:14 2009 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 25 Nov 2009 09:52:14 +0000 Subject: Who has AS 1712? In-Reply-To: <5.1.0.14.2.20091125112942.0565e050@efes.iucc.ac.il> (Hank Nussbacher's message of "Wed\, 25 Nov 2009 11\:33\:51 +0200") References: <20091124074817.GA6170@reiftel.karrenberg.net> <20091123151043.GA11349@nic.fr> <5.1.0.14.2.20091124113919.00c47098@efes.iucc.ac.il> <4B0C48DF.1040806@justinshore.com> <5.1.0.14.2.20091125112942.0565e050@efes.iucc.ac.il> Message-ID: <82aayblynl.fsf@mid.bfk.de> * Hank Nussbacher: > Perhaps the RIRs could get together and agree on a common whois syntax > so that when I check one RIR with one syntax - it would work on others > as well? This issue has been around for over 7 years and I can't > understand why the RIRs can't find common ground for the sake of the > end users? Even if ARIN or APNIC won't accept "-B -G", then at least > let their whois engine just ignore those extra parameters it doesn't > understand. To me it looks like minor software changes. There's also the little-known issue that the correct syntax for querying ARIN's WHOIS for AS number is "23456", and not the "AS23456" syntax encoded in multiple tools. *sigh* -- 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 william.allen.simpson at gmail.com Wed Nov 25 04:24:17 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Wed, 25 Nov 2009 05:24:17 -0500 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: <4B0CCE4B.8000600@bennett.com> References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> <4B0CB8DF.4000100@bennett.com> <620fd17c0911242222l122ade20o65034eb16d2f7380@mail.gmail.com> <4B0CCE4B.8000600@bennett.com> Message-ID: <4B0D05D1.9000204@gmail.com> Richard Bennett wrote: > Speculation about how the money flows is a worthwhile activity. Sure, no problem. > -- > Richard Bennett > Research Fellow > Information Technology and Innovation Foundation > Washington, DC > In summary, Mr Bennett is an unregistered lobbyist, employed by other registered lobbyists. It's really a waste of time to engage him, as it's his full-time job to write his screed. We have neither the time nor manpower. "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!" -- Upton Sinclair (1935) http://www.itif.org/index.php?s=staff He claims to have been involved in IEEE Wi-Fi for 15 years. Meaning he's one of those responsible for the bad security (WEP, etc.), and the stagnation of ad hoc networking -- because the industry has a centralized solution they want to sell, customer be damned. His bio also says he was vice-chair for the hub standard, so prevented jumbo frames from being formally adopted -- again, customer be damned. Now, he works for a "think tank" called "Information Technology & Innovation Foundation". Basically, he goes to conferences. He's not responsible for operating any networks or doing any actual engineering. ITIF doesn't give out information about its funding, which usually means it's industry lobbyist funded. Apparently in this case, big cable and probably big telco. They're opposed to net neutrality, and (based on his comments and several of the papers) still think the Internet is some kind of bastard child that needs adult supervision in the middle -- by which they mean themselves /in loco parentis/. Looking at the board, it's populated by ultra-conservative wing-nut Republicans, and some Conservadems (as we call them in political circles, they call themselves "centrists") from the "New Democrat Caucus" for "bi-partisan" cover. And lots of lobbyists -- Federal lobbyists -- who seem to list their educational clients on their bio, but not whether they are also employed by a firm that represents other clients.... From bmanning at vacation.karoshi.com Wed Nov 25 04:32:16 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 25 Nov 2009 10:32:16 +0000 Subject: Who doesn't have AS 1712? In-Reply-To: References: <20091124074817.GA6170@reiftel.karrenberg.net> <20091123151043.GA11349@nic.fr> <5.1.0.14.2.20091124113919.00c47098@efes.iucc.ac.il> <4B0C48DF.1040806@justinshore.com> <20091125075745.GD6170@reiftel.karrenberg.net> <5.1.0.14.2.20091125112942.0565e050@efes.iucc.ac.il> Message-ID: <20091125103216.GA21938@vacation.karoshi.com.> On Wed, Nov 25, 2009 at 06:36:13PM +0900, Randy Bush wrote: > > Perhaps the RIRs could get together and agree on a common whois syntax so > > that when I check one RIR with one syntax - it would work on others as > > well? This issue has been around for over 7 years and I can't understand > > why the RIRs can't find common ground for the sake of the end users? > > s/7/15/ it was already feeling like brickmarks on my forhead at the > first s'holm ietf in '95 > > randy there are solutions, rwhois, iris, etc. some require changed behaviours from the actors, (why RIPE decided unilaterally to change the flags/syntax of whois escapes me at the mo), and some do not. basically we are stuck w/ things like whois, swip, ad-nausea, due to simple intertia. and here is a saving grace... IPv6. once, abt 8/9 years ago, I was talking w/ Richard Jimmerson about the wonderful opportunity the RIRs had to build a scalable, extensable resource tracking system that could be easily deployed by the RIR clients and seamlessly integrated into a heirarchy of resource management segments. the rational was/is that the RIRs are handing out functionally the entire IPv4 address pool to any and all comers. Thats the size of a /32, presuming one buys into the /64 chastity belt the IETF has wrapped around the lower 64 bits. How is a lowly ISP expected to track/manage address assignments over such a huge space w/o decent toolage? so we can let our collective interia drag us down into increasing chaos or we can use this one time chance to pull our collective bacon out of the fire. After SIDR - I think development and deployment of this type of thing would be a worthwhile use of my RIR fees. YMMV of course. --bill From hank at efes.iucc.ac.il Wed Nov 25 04:47:17 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 25 Nov 2009 12:47:17 +0200 Subject: Who has AS 1712? In-Reply-To: <82aayblynl.fsf@mid.bfk.de> References: <5.1.0.14.2.20091125112942.0565e050@efes.iucc.ac.il> <20091124074817.GA6170@reiftel.karrenberg.net> <20091123151043.GA11349@nic.fr> <5.1.0.14.2.20091124113919.00c47098@efes.iucc.ac.il> <4B0C48DF.1040806@justinshore.com> <5.1.0.14.2.20091125112942.0565e050@efes.iucc.ac.il> Message-ID: <5.1.0.14.2.20091125124643.05718d98@efes.iucc.ac.il> At 09:52 25/11/2009 +0000, Florian Weimer wrote: >* Hank Nussbacher: > > > Perhaps the RIRs could get together and agree on a common whois syntax > > so that when I check one RIR with one syntax - it would work on others > > as well? This issue has been around for over 7 years and I can't > > understand why the RIRs can't find common ground for the sake of the > > end users? Even if ARIN or APNIC won't accept "-B -G", then at least > > let their whois engine just ignore those extra parameters it doesn't > > understand. To me it looks like minor software changes. > >There's also the little-known issue that the correct syntax for >querying ARIN's WHOIS for AS number is "23456", and not the "AS23456" >syntax encoded in multiple tools. That used to be true. Don't know when they fixed it - but it was recently that AS12345 now works at ARIN. -Hank >*sigh* > >-- >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 richard at bennett.com Wed Nov 25 05:32:02 2009 From: richard at bennett.com (Richard Bennett) Date: Wed, 25 Nov 2009 03:32:02 -0800 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: <4B0D05D1.9000204@gmail.com> References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> <4B0CB8DF.4000100@bennett.com> <620fd17c0911242222l122ade20o65034eb16d2f7380@mail.gmail.com> <4B0CCE4B.8000600@bennett.com> <4B0D05D1.9000204@gmail.com> Message-ID: <4B0D15B2.8090407@bennett.com> Now you've descended from Steenbergen's hair-splitting between "on-net routes" (the mechanism) vs. "on-net access" (the actual product) into Simpson's straight-up lying. ITIF is not opposed to network neutrality in principle, having released a paper on "A Third Way on Network Neutrality", http://www.itif.org/index.php?id=63. There is not a single ultra-conservative on the ITIF board, they're all either moderate Democrats or moderate Republicans. I'm letting most of this childish venting slide, but I will point out the bald-faced lies. RB William Allen Simpson wrote: > They're opposed to net neutrality, and (based on his comments and several > of the papers) still think the Internet is some kind of bastard child > that > needs adult supervision in the middle -- by which they mean themselves > /in loco parentis/. > > Looking at the board, it's populated by ultra-conservative wing-nut > Republicans, and some Conservadems (as we call them in political circles, > they call themselves "centrists") from the "New Democrat Caucus" for > "bi-partisan" cover. And lots of lobbyists -- Federal lobbyists -- who > seem to list their educational clients on their bio, but not whether > they are also employed by a firm that represents other clients.... -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From truman at suspicious.org Wed Nov 25 05:47:38 2009 From: truman at suspicious.org (Truman Boyes) Date: Wed, 25 Nov 2009 22:47:38 +1100 Subject: I got a live one! - Spam source In-Reply-To: <5e1ca1ac0911242007v1b6cb4a7gd2b08a37b4226d1e@mail.gmail.com> References: <5e1ca1ac0911241922u25634547u7eeb7ec6e357b352@mail.gmail.com> <5e1ca1ac0911242007v1b6cb4a7gd2b08a37b4226d1e@mail.gmail.com> Message-ID: <1C42E192-4481-4BCC-9EEB-D81F63DD4186@suspicious.org> Interesting scenario ... but would be far more interesting to us if you share the /24? Truman On 25/11/2009, at 3:07 PM, Russell Myba wrote: >> >> >> I'm confused. Who are you billing and for what services? >> >> > Let's say our direct customer is CustomerA. They seem to buy rackspace from > BusinessB. CustomerA seem to retain BusinessC for "IT Solutions" even > though all three entities purport to be IT solutions providers. > BusinessC came into the picture after the spamming started saying a wholly > different /24 (Different from the spam source) "doesn't work". It routes > fine on our end. I have a feeling they've been added to some RBLs but I > haven't found them listed yet. > > Just a simple ethernet handoff in a colo. We delegated rDNS to the servers > of their choice and haven't heard a peep out of them until now. > > > >> Spamhaus is the first one that comes to mind. From what I understand of >> your description, this doesn't sound all that different from typical spammer >> behavior. Multiple layers of indirection seems to be the latest thing for >> spammers. >> >> ---------------------------------------------------------------------- >> Jon Lewis | I route >> Senior Network Engineer | therefore you are >> Atlantic Net | >> _________ http://www.lewis.org/~jlewis/pgpfor PGP public key_________ >> > From rsk at gsp.org Wed Nov 25 05:49:55 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 25 Nov 2009 06:49:55 -0500 Subject: I got a live one! - Spam source In-Reply-To: <5e1ca1ac0911241922u25634547u7eeb7ec6e357b352@mail.gmail.com> References: <5e1ca1ac0911241922u25634547u7eeb7ec6e357b352@mail.gmail.com> Message-ID: <20091125114955.GA18546@gsp.org> On Tue, Nov 24, 2009 at 10:22:36PM -0500, Russell Myba wrote: > Looks like of our customers has decided to turn their /24 into a nice little > space spewing machine. Doesn't seem like just one compromised host. 1. This is possibly/probably better on spam-l. 2. This is a very common operational model. Any number of spamgangs have been busy doing this with multiple /24's scattered over numerous providers in order to distribute the workload and minimize the impact of any takedown. 3. There is no point in reporting this to any law enforcment agency anywhere in the world *unless* child pornography is involved. Any action they take will be slow, inept, and ineffective. The best that you can probably do is (a) shut down them instantly and permanently and (b) publish all relevant details -- name names -- on spam-l so that workers and researchers can use the information. ---Rsk From Rod.Beck at hiberniaatlantic.com Wed Nov 25 06:10:50 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Wed, 25 Nov 2009 12:10:50 -0000 Subject: [SPAM-HEADER] - Re: fight club :) richard bennett vs various nanogers, on paid peering - Email has different SMTP TO: and MIME TO: fields in the email addresses References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> <4B0CB8DF.4000100@bennett.com><620fd17c0911242222l122ade20o65034eb16d2f7380@mail.gmail.com><4B0CCE4B.8000600@bennett.com> <4B0D05D1.9000204@gmail.com> <4B0D15B2.8090407@bennett.com> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB01628E5B@bert.HiberniaAtlantic.local> Hi Richard, I am late to this dicussion. So I don't have a full understanding of the context or history of this debate. It is clear to many of us that Telcos lost the content wars and this is their way of trying to get a slice of the content providers (Google, Microsoft, etc.) add revenues. It's a power play and way of trying to change the rules in the fourth quarter. Needless to say, these are my own personal opinions. Roderick S. Beck Director of European Sales Hibernia Atlantic Budapest, New York, and Paris http://www.hiberniaatlantic.com From pauldotwall at gmail.com Wed Nov 25 06:25:37 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Wed, 25 Nov 2009 07:25:37 -0500 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: <4B0D15B2.8090407@bennett.com> References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> <4B0CB8DF.4000100@bennett.com> <620fd17c0911242222l122ade20o65034eb16d2f7380@mail.gmail.com> <4B0CCE4B.8000600@bennett.com> <4B0D05D1.9000204@gmail.com> <4B0D15B2.8090407@bennett.com> Message-ID: <620fd17c0911250425r79cbdf64vbb47e6943ed7743d@mail.gmail.com> RB- Where can we find data on your group's funding sources? If we're to continue this discussion, we need to establish bias and motive, which you've not covered on your own accord. Drive Slow, Paul Wall On 11/25/09, Richard Bennett wrote: > Now you've descended from Steenbergen's hair-splitting between "on-net > routes" (the mechanism) vs. "on-net access" (the actual product) into > Simpson's straight-up lying. ITIF is not opposed to network neutrality > in principle, having released a paper on "A Third Way on Network > Neutrality", http://www.itif.org/index.php?id=63. There is not a single > ultra-conservative on the ITIF board, they're all either moderate > Democrats or moderate Republicans. > > I'm letting most of this childish venting slide, but I will point out > the bald-faced lies. > > RB > > William Allen Simpson wrote: >> They're opposed to net neutrality, and (based on his comments and several >> of the papers) still think the Internet is some kind of bastard child >> that >> needs adult supervision in the middle -- by which they mean themselves >> /in loco parentis/. >> >> Looking at the board, it's populated by ultra-conservative wing-nut >> Republicans, and some Conservadems (as we call them in political circles, >> they call themselves "centrists") from the "New Democrat Caucus" for >> "bi-partisan" cover. And lots of lobbyists -- Federal lobbyists -- who >> seem to list their educational clients on their bio, but not whether >> they are also employed by a firm that represents other clients.... > > -- > Richard Bennett > Research Fellow > Information Technology and Innovation Foundation > Washington, DC > > > -- Sent from my mobile device From aaron.cossey at gmail.com Wed Nov 25 06:38:00 2009 From: aaron.cossey at gmail.com (Aaron Cossey) Date: Wed, 25 Nov 2009 13:38:00 +0100 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: <620fd17c0911250425r79cbdf64vbb47e6943ed7743d@mail.gmail.com> References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> <4B0CB8DF.4000100@bennett.com> <620fd17c0911242222l122ade20o65034eb16d2f7380@mail.gmail.com> <4B0CCE4B.8000600@bennett.com> <4B0D05D1.9000204@gmail.com> <4B0D15B2.8090407@bennett.com> <620fd17c0911250425r79cbdf64vbb47e6943ed7743d@mail.gmail.com> Message-ID: Would you care to elaborate on how the investigation of someones funding sources is operationally relevant to the rest of the list? Aaron Cossey aaron.cossey at gmail.com On Wed, Nov 25, 2009 at 1:25 PM, Paul Wall wrote: > RB- > > Where can we find data on your group's funding sources? > > If we're to continue this discussion, we need to establish bias and > motive, which you've not covered on your own accord. > > Drive Slow, > Paul Wall > > On 11/25/09, Richard Bennett wrote: >> Now you've descended from Steenbergen's hair-splitting between "on-net >> routes" (the mechanism) vs. "on-net access" (the actual product) into >> Simpson's straight-up lying. ITIF is not opposed to network neutrality >> in principle, having released a paper on "A Third Way on Network >> Neutrality", http://www.itif.org/index.php?id=63. There is not a single >> ultra-conservative on the ITIF board, they're all either moderate >> Democrats or moderate Republicans. >> >> I'm letting most of this childish venting slide, but I will point out >> the bald-faced lies. >> >> RB >> >> William Allen Simpson wrote: >>> They're opposed to net neutrality, and (based on his comments and several >>> of the papers) still think the Internet is some kind of bastard child >>> that >>> needs adult supervision in the middle -- by which they mean themselves >>> /in loco parentis/. >>> >>> Looking at the board, it's populated by ultra-conservative wing-nut >>> Republicans, and some Conservadems (as we call them in political circles, >>> they call themselves "centrists") from the "New Democrat Caucus" for >>> "bi-partisan" cover. ?And lots of lobbyists -- Federal lobbyists -- who >>> seem to list their educational clients on their bio, but not whether >>> they are also employed by a firm that represents other clients.... >> >> -- >> Richard Bennett >> Research Fellow >> Information Technology and Innovation Foundation >> Washington, DC >> >> >> > > -- > Sent from my mobile device > > From randy at psg.com Wed Nov 25 06:47:55 2009 From: randy at psg.com (Randy Bush) Date: Wed, 25 Nov 2009 21:47:55 +0900 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> <4B0CB8DF.4000100@bennett.com> <620fd17c0911242222l122ade20o65034eb16d2f7380@mail.gmail.com> <4B0CCE4B.8000600@bennett.com> <4B0D05D1.9000204@gmail.com> <4B0D15B2.8090407@bennett.com> <620fd17c0911250425r79cbdf64vbb47e6943ed7743d@mail.gmail.com> Message-ID: > Would you care to elaborate on how the investigation of someones > funding sources is operationally relevant to the rest of the list? please no we have a greedy troll. stop feeding it. procmail is your friend. randy From brunner at nic-naa.net Wed Nov 25 06:49:20 2009 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 25 Nov 2009 07:49:20 -0500 Subject: I got a live one! - Spam source In-Reply-To: <4B0CAB2A.4030808@linuxbox.org> References: <5e1ca1ac0911241922u25634547u7eeb7ec6e357b352@mail.gmail.com> <4B0CAB2A.4030808@linuxbox.org> Message-ID: <4B0D27D0.7080000@nic-naa.net> Russell, My personal inclination would be to look for what legit entities are provisioning them with critical resources and what margins they appear to be paying. For DNS resources, the domains, to identify registry preference, probably a simple volume correlation, and the registrars, which may corollate better to other primary characteristics than simple volume, to RRset data, which may have interesting corollates to other, provisioned, critical resources. I'm not the "registrar police", I'm simply interested in ICANN having a policy towards registrars that looks beyond failure to respond to email, failure to pay $0.25/domain/year, and failure to escrow registrant data, which seem to be the only basis for breach of contract proceedings against, or non-renewals of its registrars. Whack-a-mole has been discussed lots of times, and as Gadi confirms at the end of his note, he's still mostly in the Whack-a-camp, though he does mention gathering information. When they stop providing you (and "you" could include parties who are paying you to look over your shoulder at this petri dish and its cultured agar) with data of value then their existence is of no value. Eric Gadi Evron wrote: > Russell Myba wrote: >> Looks like of our customers has decided to turn their /24 into a nice >> little >> space spewing machine. Doesn't seem like just one compromised host. >> >> Reverse DNS for most of the /24 are suspicious domains. Each domain >> used in >> the message-id forwards to a single .net which lists their mailing >> address >> as a PO box an single link to an unsubscribe field. >> >> I've contacted at least three known contacts for the customer about the >> abuse without a single response. >> >> It would seem there are many layers to this entity: >> >> The domains are registered to one business >> Our billing information for the customer has one name, they colo with >> another person (whom the cross connect reaches) >> Our customer has an IT solutions person working for them (Strange >> since our >> customer and their colo provider are "IT solutions" people themselves. >> Abuse handle phone #s are supposedly incorrect (I called it) >> >> Besides the obvious of me at the minimum filtering port tcp/25 is >> their an >> organization that tracks businesses like these who seem like they are >> building a web of insulation in which to move? >> >> I think this case might interest them. >> > > From principle, I want to jump up and down and say "zap `em!". > However, I also make several assumption which need to be clearned, > pragmatically. > > I assume you have authority over the decision of what to do with them, > and I also assume that your contract with them does not bind you in > some fashion, can get you in trouble with the business side of the > business, or can introduce *liability* issues. And naturally, that if > you are not the decision maker, that you are synched with whomever it is. > > These assumptions aside, kicking them might not be the best solution. > "Starving them" out by blocking port 25, as an example you gave, or > following some of the other suggestions in this thread, may be workable. > > Which brings me three very important questions: > 1. How much intelligence can you collect if you let them stay? > 2. Have you considered legal action against them? > 3. Did you consult with legal about possible law enforcement involvement? > > As to the intricate web of who they are and where their resources lie, > these are usually cases where the more you dig, the more you find -- > ad infinitum. > > Me? I'd just kick them after verifying they are not victims themselves. > > I hope this helps, > > Gadi. > > From jlewis at lewis.org Wed Nov 25 07:07:11 2009 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 25 Nov 2009 08:07:11 -0500 (EST) Subject: I got a live one! - Spam source In-Reply-To: <20091125114955.GA18546@gsp.org> References: <5e1ca1ac0911241922u25634547u7eeb7ec6e357b352@mail.gmail.com> <20091125114955.GA18546@gsp.org> Message-ID: On Wed, 25 Nov 2009, Rich Kulawiec wrote: > On Tue, Nov 24, 2009 at 10:22:36PM -0500, Russell Myba wrote: >> Looks like of our customers has decided to turn their /24 into a nice little >> space spewing machine. Doesn't seem like just one compromised host. > > 1. This is possibly/probably better on spam-l. > 2. This is a very common operational model. Any number of spamgangs > have been busy doing this with multiple /24's scattered over numerous > providers in order to distribute the workload and minimize the impact > of any takedown. One of them actually patented it. Further proof that you can patent just about anything in the US. http://www.faqs.org/patents/app/20090271475 ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From richard at bennett.com Wed Nov 25 07:39:53 2009 From: richard at bennett.com (Richard Bennett) Date: Wed, 25 Nov 2009 05:39:53 -0800 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> <4B0CB8DF.4000100@bennett.com> <620fd17c0911242222l122ade20o65034eb16d2f7380@mail.gmail.com> <4B0CCE4B.8000600@bennett.com> <4B0D05D1.9000204@gmail.com> <4B0D15B2.8090407@bennett.com> <620fd17c0911250425r79cbdf64vbb47e6943ed7743d@mail.gmail.com> Message-ID: <4B0D33A9.3040107@bennett.com> I didn't bring this discussion over here, hippie. Randy Bush wrote: Would you care to elaborate on how the investigation of someones funding sources is operationally relevant to the rest of the list? please no we have a greedy troll. stop feeding it. procmail is your friend. randy -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From rusmyba at gmail.com Wed Nov 25 08:40:55 2009 From: rusmyba at gmail.com (Russell Myba) Date: Wed, 25 Nov 2009 09:40:55 -0500 Subject: I got a live one! - Spam source In-Reply-To: <6cd462c00911242317g5fa67dd4me2199661ca400791@mail.gmail.com> References: <5e1ca1ac0911241922u25634547u7eeb7ec6e357b352@mail.gmail.com> <5e1ca1ac0911242007v1b6cb4a7gd2b08a37b4226d1e@mail.gmail.com> <200911242255.53593.michael@linuxmagic.com> <6cd462c00911242317g5fa67dd4me2199661ca400791@mail.gmail.com> Message-ID: <5e1ca1ac0911250640n724b9ad7ydb4f508091a9d5a1@mail.gmail.com> On Wed, Nov 25, 2009 at 2:17 AM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, Nov 24, 2009 at 10:55 PM, Michael Peddemors > wrote: > >> >> Depends on the activity, but this re-iterates the importance of >> maintaining correct SWIP, so that only the offenders get listed, and not >> bordering >> customers. >> > > Right. There are *so many* loopholes in this entire process, Bad Guys are > waltzing through it. > > - - ferg > > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.5.3 (Build 5003) > > wj8DBQFLDNofq1pz9mNUZTMRAgNrAKDz6JwFqBG3gvXEIKo1UVrJSTmxDQCfadqV > Ph3qt/qPDze8Z5tsRP7LgSw= > =gQrR > -----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/ > > Could you elaborate on what constitutes correct swip information? From tme at americafree.tv Wed Nov 25 08:42:29 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Wed, 25 Nov 2009 09:42:29 -0500 Subject: Tishman Neutral Exchange space Message-ID: <6378E454-3320-42FC-B163-EAAA0851B294@americafree.tv> Hello; There is a new carrier neutral exchange space opening up December 1st at 165 Halsey in Newark, NJ. This space will be operated by Tishman Hotel & Realty LP : http://www.datacentermap.com/usa/new-jersey/newark/165-halsey.html I am thinking of moving into there and I would be curious to hear feedback from anyone with experience in being in a Tishman operated exchange space. I think that replies should be off-list, please. Regards Marshall From drc at virtualized.org Wed Nov 25 08:57:30 2009 From: drc at virtualized.org (David Conrad) Date: Wed, 25 Nov 2009 06:57:30 -0800 Subject: Who has AS 1712? In-Reply-To: <5.1.0.14.2.20091125112942.0565e050@efes.iucc.ac.il> References: <20091124074817.GA6170@reiftel.karrenberg.net> <20091123151043.GA11349@nic.fr> <5.1.0.14.2.20091124113919.00c47098@efes.iucc.ac.il> <4B0C48DF.1040806@justinshore.com> <5.1.0.14.2.20091125112942.0565e050@efes.iucc.ac.il> Message-ID: <781B23B5-674D-4B28-9A0C-F5612CCB179A@virtualized.org> On Nov 25, 2009, at 1:33 AM, Hank Nussbacher wrote: > At 08:57 25/11/2009 +0100, Daniel Karrenberg wrote: >> shouting. This is all water under the bridge of course and we are >> moving on; >> I do not say everything is ideal now. However the RIRs are actively >> working to publish a complete set of stats files which also includes >> unallocated resources. I would've thought IANA would be responsible for unallocated resources. >> This is the next best thing to full database >> synchronisation. APNIC and the RIPE NCC are driving this effort. > > Perhaps the RIRs could get together and agree on a common whois syntax so that when I check one RIR with one syntax - it would work on others as well? http://www.rfc-editor.org/rfc/rfc4698.txt More seriously, the theory is that the RIRs are bottom-up driven. If you think a unified whois schema across all RIRs (or even IRIS deployment) would be a good thing to have, there are likely better venues to raise the issue than NANOG. Regards, -drc From Valdis.Kletnieks at vt.edu Wed Nov 25 09:13:10 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 25 Nov 2009 10:13:10 -0500 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: Your message of "Wed, 25 Nov 2009 03:32:02 PST." <4B0D15B2.8090407@bennett.com> References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> <4B0CB8DF.4000100@bennett.com> <620fd17c0911242222l122ade20o65034eb16d2f7380@mail.gmail.com> <4B0CCE4B.8000600@bennett.com> <4B0D05D1.9000204@gmail.com> <4B0D15B2.8090407@bennett.com> Message-ID: <48319.1259161990@turing-police.cc.vt.edu> On Wed, 25 Nov 2009 03:32:02 PST, Richard Bennett said: > ITIF is not opposed to network neutrality > in principle, having released a paper on "A Third Way on Network > Neutrality", http://www.itif.org/index.php?id=63. All of four paragraphs, which don't in fact address what the provider is or is not providing to Joe Sixpack - point 1 says discriminatory plans are OK as long as the discriminatory are on display in the cellar of the ISP office, with no stairs, in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying Beware of the Leopard. And points 2 and 3 are saying that this should all be overseen by the same agencies that oversaw the previous decade's massive buildout of fiber to the home that was financed by massive multi-billion dollar incentives. Oh wait, those billions got pocketed - if the massive fiber buildout had happened, we'd have so much bandwidth that neutrality wouldn't be an issue... But then, the Republicans keep saying they are not opposed to health care reform in principle either... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jared at puck.nether.net Wed Nov 25 09:33:15 2009 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 25 Nov 2009 10:33:15 -0500 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: <48319.1259161990@turing-police.cc.vt.edu> References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> <4B0CB8DF.4000100@bennett.com> <620fd17c0911242222l122ade20o65034eb16d2f7380@mail.gmail.com> <4B0CCE4B.8000600@bennett.com> <4B0D05D1.9000204@gmail.com> <4B0D15B2.8090407@bennett.com> <48319.1259161990@turing-police.cc.vt.edu> Message-ID: <01AB7475-2F92-4F4E-BBB4-0D65F1FC193D@puck.nether.net> On Nov 25, 2009, at 10:13 AM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 25 Nov 2009 03:32:02 PST, Richard Bennett said: > >> ITIF is not opposed to network neutrality >> in principle, having released a paper on "A Third Way on Network >> Neutrality", http://www.itif.org/index.php?id=63. > > All of four paragraphs, which don't in fact address what the provider is or is > not providing to Joe Sixpack - point 1 says discriminatory plans are OK as long > as the discriminatory are on display in the cellar of the ISP office, with no > stairs, in the bottom of a locked filing cabinet stuck in a disused lavatory > with a sign on the door saying Beware of the Leopard. > > And points 2 and 3 are saying that this should all be overseen by the same > agencies that oversaw the previous decade's massive buildout of fiber to the > home that was financed by massive multi-billion dollar incentives. > > Oh wait, those billions got pocketed - if the massive fiber buildout had > happened, we'd have so much bandwidth that neutrality wouldn't be an issue... > > But then, the Republicans keep saying they are not opposed to health care > reform in principle either... > Me, I'm reminded of the fact that those on the edge of suburban areas have fewer choices than those in purely rural areas. Some carriers have been formed just to solve the basic telephony access issues of PSTN recently, eg: http://telephonyonline.com/mag/telecom_dont_mad_ilec/ Me? I want to see a ban on replacing copper based networking as part of the outside plant. - Jared http://www.allband.org/ From ml at kenweb.org Wed Nov 25 10:26:05 2009 From: ml at kenweb.org (ML) Date: Wed, 25 Nov 2009 11:26:05 -0500 Subject: [c-nsp] is a DWDM SFP a DWDM SFP? In-Reply-To: <6069A203FD01884885C037F81DD75080173D69596A@wsc-mail-01.intra.nwresd.k12.or.us> References: <5A69C25361FED34F83ABF05F50475245072BC81D@wally.walleyetrading.net> <4B0CAA48.5000102@justinshore.com> <4B0D3424.30506@fas.harvard.edu>, <4B0D5303.5010908@justinshore.com> <6069A203FD01884885C037F81DD75080173D69596A@wsc-mail-01.intra.nwresd.k12.or.us> Message-ID: <4B0D5A9D.7010109@kenweb.org> Bill Blackford wrote: > I do not believe that Juniper keys their optics. My experience with this is limited though. I am able to get third-party optics to work just fine in EX switches. > > bblackford at wsc-asw-02-1> show chassis hardware > Hardware inventory: > Item Version Part number Serial number Description > Chassis BH0208188142 EX3200-24T > FPC 0 REV 07 750-021261 BH0208188142 EX3200-24T, 8 POE > CPU BUILTIN BUILTIN FPC CPU > PIC 0 BUILTIN BUILTIN 24x 10/100/1000 Base-T > PIC 1 REV 04 711-021270 AR0209216364 4x GE SFP > Xcvr 0 NON-JNPR FFX20H700284 SFP-SX > Power Supply 0 REV 02 740-020957 AT0508119769 PS 320W AC > Fan Tray Fan Tray > > As you can see it identifies the Xcvr as non-Juniper. > > > On the Cisco side, I have a Vertex 1310M GLC-LH-SM that is working fine in a 3560G. > > -b > Correct me if I'm wrong but there are good and bad 3rd party SFPs. The good ones being the SFPs with their EEPROM set to appear to be Cisco kit. From ip at ioshints.info Wed Nov 25 10:57:53 2009 From: ip at ioshints.info (Ivan Pepelnjak) Date: Wed, 25 Nov 2009 17:57:53 +0100 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: <48319.1259161990@turing-police.cc.vt.edu> References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com><4B0CB8DF.4000100@bennett.com><620fd17c0911242222l122ade20o65034eb16d2f7380@mail.gmail.com><4B0CCE4B.8000600@bennett.com> <4B0D05D1.9000204@gmail.com><4B0D15B2.8090407@bennett.com> <48319.1259161990@turing-police.cc.vt.edu> Message-ID: <007d01ca6df0$71187f90$0a00000a@nil.si> > Oh wait, those billions got pocketed - if the massive fiber > buildout had happened, we'd have so much bandwidth that > neutrality wouldn't be an issue... Maybe this is how the fiber got used :)) http://en.wikipedia.org/wiki/RFoG From asr+nanog at latency.net Wed Nov 25 10:59:32 2009 From: asr+nanog at latency.net (Adam Rothschild) Date: Wed, 25 Nov 2009 11:59:32 -0500 Subject: Tishman Neutral Exchange space In-Reply-To: <6378E454-3320-42FC-B163-EAAA0851B294@americafree.tv> References: <6378E454-3320-42FC-B163-EAAA0851B294@americafree.tv> Message-ID: <20091125165932.GA97657@latency.net> On 2009-11-25-09:42:29, Marshall Eubanks wrote: > There is a new carrier neutral exchange space opening up December 1st > at 165 Halsey in Newark, NJ. This space will be operated by Tishman > Hotel & Realty LP : > > http://www.datacentermap.com/usa/new-jersey/newark/165-halsey.html > > I am thinking of moving into there and I would be curious to hear > feedback from > anyone with experience in being in a Tishman operated exchange space. I've not seen the finished product, though I am familiar with its development. This is basically an annex of the building's meet-me area on the 9th floor. Depending on your specific reach objectives and density, you might find that a successful deployment in this building hinges on a build to both the Equinix suite on 8 (which is rich in carriers), and the MMR 9 (which has fewer carriers, but has some not built out to 8, and more favorable economics on cross-connection when amortized over a multi-year term). I hold a high regard for the building and its landlord as a whole. Just be careful at night... -a From michael at linuxmagic.com Wed Nov 25 11:25:27 2009 From: michael at linuxmagic.com (Michael Peddemors) Date: Wed, 25 Nov 2009 09:25:27 -0800 Subject: I got a live one! - Spam source Message-ID: <200911250925.27298.michael@linuxmagic.com> > > Could you elaborate on what constitutes correct swip information? > Sure, you just opened the door to my opinions on this :) -- WRONG -- OrgName: FortressITX OrgID: FORTR-5 Address: 100 Delawanna Ave City: Clifton StateProv: NJ PostalCode: 07014 Country: US Found a referral to rwhois.fortressitx.com:4443. Timeout. -- ----------------- The argument that whois information should not be made public, is ridiculous. I here people saying that they don't publish whois information because they don't want the email's made public. Okay, at least the registered company name, or individual who presented the ID should be there. -- WRONG -- OrgName: Peer 1 Dedicated Hosting OrgID: P1DH-1 Address: 101 Marietta Street Address: Suite 500 City: Atlanta StateProv: GA PostalCode: 30303 Country: US NetRange: 216.150.0.0 - 216.150.31.255 CIDR: 216.150.0.0/19 ------------------------------ Okay, you REALLY want people to get tired of playing whack a mole? This is why many list operators block large ranges.. according to this listing, one responsible party for the whole list.. (oh, and don't get me started on reporting.. the quote i heard here was .. 'Oh, we don't do anything about spammers unless it affects other customers') So, how big a range should you block when you start seeing a pattern? Remember, organizations like UCE-PROTECT tend to base a reputation on /24 This is probably because in a lot of cases, you cannot tell does the person own the whole range, or just the top /25 -- RIGHT -- OrgName: Network Operations Center Inc. OrgID: NOC Address: PO Box 591 City: Scranton network:Network-Name:NET-96.9.145.224/28 network:IP-Network:96.9.145.224/28 network:Organization;I:org--6898 network:Org-Name:ServerPlaceNet c/o Network Operations Center, Inc. -------------- Simple, if the IP's reflect some behavior we don't like, we know exactly which ranges should be affected. Basically, if you absolve yourself of the responsibility for the conduct of part of your networks, to a 3rd party.. you should SWIP it. Some hosting companies are really good about this, even as far as SWIP'ing down to the /32. There is a chain of responsbilitly, and when a hosting company has a known offender using portion(s) of their space, it makes it much easier to decide how much of that space should be blocked. Should we block the whole /24 or only a portion? Say you see... 66.104.246.36: mail1.clubdelivery.net 66.104.246.37: mail1.deliverydirect.info 66.104.246.38: mail1.deliverymobile.net 66.104.246.39: mail1.deliveryonline.info 66.104.246.40: mail1.deliveryrama.net 66.104.246.41: mail1.deliveryusa.net 66.104.246.42: mail1.deliveryzilla.net 66.104.246.43: mail1.godelivery.info 66.104.246.44: mail1.instantdelivery.info 66.104.246.45: mail1.date-meet.net 66.104.246.46: mail1.uchatfree.net 66.104.246.47: mail1.secureeasypay.net 66.104.246.48: mail1.idevelopthings.com 66.104.246.49: mail1.whocanvote.com 66.104.246.50: mail1.freedvdz.net 66.104.246.51: mail1.freecybercam.com 66.104.246.53: mail2.clubdelivery.net 66.104.246.54: mail2.deliverydirect.info 66.104.246.55: mail2.deliverymobile.net 66.104.246.56: mail2.deliveryonline.info 66.104.246.57: mail2.deliveryrama.net 66.104.246.58: mail2.deliveryusa.net 66.104.246.59: mail2.deliveryzilla.net 66.104.246.60: mail2.godelivery.info 66.104.246.61: mail2.instantdelivery.info 66.104.246.62: mail2.date-meet.net It's listed as.. network:Organization;I:Precision Technology, Inc (286563-1) network:IP-Network:66.104.244.0/22 Well, we don't have to affect the whole XO block.. but who is the operator responsible for the activities of these servers? The SWIP should reflect that. Also, it makes it easier to see relevant activities from other ranges that the customer might own.. Like older IP Ranges... -- Precision Technology INC mycouponsavingsmailcom MYCOUPONSAVINGSMAILCOM 24.155.144.16 - 24.155.144.31 # 24.155.144.16/28 Guess business was good.. but now of course, with proper SWIP, we know that those IP's are no longer controlled by the same party . (we hope) Of course, it can still be abused.. if the hosting provider is in colusion.. changes the SWIP regularly to hide that it is the same operator.. but even then, we will see such patterns.. if a hosting company 'constantly' gets a new 'problem customer' then we can see that as well. -- -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors - President/CEO - LinuxMagic Products, Services, Support and Development Visit us at http://www.linuxmagic.com ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-589-0037 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From john-nanog at johnpeach.com Wed Nov 25 11:40:48 2009 From: john-nanog at johnpeach.com (John Peach) Date: Wed, 25 Nov 2009 12:40:48 -0500 Subject: I got a live one! - Spam source In-Reply-To: <200911250925.27298.michael@linuxmagic.com> References: <200911250925.27298.michael@linuxmagic.com> Message-ID: <20091125124048.3dc87dde@jpeach-desktop.1425mad.mountsinai.org> On Wed, 25 Nov 2009 09:25:27 -0800 Michael Peddemors wrote: > > > > Could you elaborate on what constitutes correct swip information? > > > > Sure, you just opened the door to my opinions on this :) > hmmm - odd that the 2 you chose to show as wrong, both feature highly in my postfix reject_clients map..... -- John From eesslinger at fpu-tn.com Wed Nov 25 11:46:48 2009 From: eesslinger at fpu-tn.com (Eric J Esslinger) Date: Wed, 25 Nov 2009 11:46:48 -0600 Subject: iGlass CMTS monitoring solution Message-ID: We've been looking at the iGlass's cable system monitoring solution for monitoring our cable system; It integrates with billing to give the ability, at a csr level, to allow them to directly lookup the status of a customer's cable modem (for example, online, offline, negotiationg, flapping), history, and also integrates with the CMTS and will make SNMP polls of the modems to see signal levels, CPE's attached, configured speed vs current actual speed, etc. I was wondering if anyone had any comments for or against them, or of alternative companies or even open source alternatives. I'm perfectly fine with 'roll your own' but Nagios/cacti type monitoring really just doesn't cut it where this is concerned. We're < 10k customers. Contacting me offlist is fine. Thanks. __________________________ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 ________________________________ This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. -------------- next part -------------- A non-text attachment was scrubbed... Name: Eric J Esslinger.vcf Type: text/x-vcard Size: 498 bytes Desc: Eric J Esslinger.vcf URL: From peter at stardoll.com Wed Nov 25 12:39:23 2009 From: peter at stardoll.com (=?UTF-8?Q?Peter_Sandstr=C3=B6m?=) Date: Wed, 25 Nov 2009 10:39:23 -0800 Subject: Having trouble trying to activate a GigE connection> In-Reply-To: <9F285BFE1D7757499D9FF095B4EE347D0490FA5F@tw-xchange01.TWC.local> References: <9F285BFE1D7757499D9FF095B4EE347D0490F9A6@tw-xchange01.TWC.local> <17838240D9A5544AAA5FF95F8D520316071DE6C9@ad-exh01.adhost.lan> <9F285BFE1D7757499D9FF095B4EE347D0490FA5F@tw-xchange01.TWC.local> Message-ID: <76dee6640911251039r78b1356au6fb619fe73b4b3ef@mail.gmail.com> I have seen this behavior caused by a mismatch of SFPs, SX on one side and LX on the other. /p On Tue, Nov 24, 2009 at 9:04 AM, Michael Ruiz wrote: >>I don't think there is any reason to have hard-set speed and duplex, >>particularly between two Cisco's. ?Why not just set *both* sides (you >>can't set just one) to auto-negotation - 'no speed nonegotiate' on the >>7606 side. ?Is this a straight shot, single fiber pair between the two >>or are there intermediate junctions or optics? ?It sounds like you have >>questionable fiber or optics in the path. ?It could be the fiber itself >>or the GBICs on either side. > > Mike, > > ? ? ? ?I tried setting the 7206 to auto, and the 7606 to nonnegtiate, > however, no dice. ?We put light meter on both ends of the GBIC and light > readings are at -20, which are applicable. Between the two routers are > MMF and it is straight shot with no transport equipment in between. > > -----Original Message----- > From: Michael K. Smith - Adhost [mailto:mksmith at adhost.com] > Sent: Tuesday, November 24, 2009 10:25 AM > To: Michael Ruiz; nanog at nanog.org > Subject: RE: Having trouble trying to activate a GigE > connection> > > Hello Michael: > >> -----Original Message----- >> From: Michael Ruiz [mailto:mruiz at telwestservices.com] >> Sent: Tuesday, November 24, 2009 8:02 AM >> To: nanog at nanog.org >> Subject: Having trouble trying to activate a GigE > connection> >> >> Group, >> >> >> >> ? ? ? ? ? ? ? ? I am having an issue with activating a Gige interface >> between a Cisco 7206 VXR w/IO-1GE module to a 7606 w/sup720-3bxls >> connecting to a line module WS-X6416-GBIC. ?I have verified that the >> GBIC-MMF have good light reading and the MMF fiber jumper are not >> reversed. ?The GigE connection comes up briefly for about a few >> seconds, >> takes a burst of errors and goes down. ?I have tried to set the speed >> to >> nonegotiate on both ends, set one end to speed auto. ?No dice. ?Here > is >> the copy of the configuration. ?On my 7606 I show that the GigE >> interface is up/up but on the 7206vxr I show down/down. ?Any help will >> be greatly appreciated. ?Thanks! >> >> >> > I don't think there is any reason to have hard-set speed and duplex, > particularly between two Cisco's. ?Why not just set *both* sides (you > can't set just one) to auto-negotation - 'no speed nonegotiate' on the > 7606 side. ?Is this a straight shot, single fiber pair between the two > or are there intermediate junctions or optics? ?It sounds like you have > questionable fiber or optics in the path. ?It could be the fiber itself > or the GBICs on either side. > > Regards, > > Mike > > -- Peter Sandstr?m Head of Operations, Stardoll AB phone: +46 (0)70 456 05 28 e-mail: peter at stardoll.com | stardoll: pj0tr mail/visit: Hudiksvallsgatan 8, 113 30 Stockholm, Sweden www.stardoll.com - Fame, fashion and friends From mruiz at telwestservices.com Wed Nov 25 13:01:48 2009 From: mruiz at telwestservices.com (Michael Ruiz) Date: Wed, 25 Nov 2009 13:01:48 -0600 Subject: Having trouble trying to activate a GigE connection> In-Reply-To: <76dee6640911251039r78b1356au6fb619fe73b4b3ef@mail.gmail.com> References: <9F285BFE1D7757499D9FF095B4EE347D0490F9A6@tw-xchange01.TWC.local> <17838240D9A5544AAA5FF95F8D520316071DE6C9@ad-exh01.adhost.lan> <9F285BFE1D7757499D9FF095B4EE347D0490FA5F@tw-xchange01.TWC.local> <76dee6640911251039r78b1356au6fb619fe73b4b3ef@mail.gmail.com> Message-ID: <9F285BFE1D7757499D9FF095B4EE347D0491021B@tw-xchange01.TWC.local> >I have seen this behavior caused by a mismatch of SFPs, SX on one side >and LX on the other. We found the problem. After going through 5 MMF GBICS we found one that worked. -----Original Message----- From: Peter Sandstr?m [mailto:peter at stardoll.com] Sent: Wednesday, November 25, 2009 12:39 PM To: Michael Ruiz Cc: Michael K. Smith - Adhost; nanog at nanog.org Subject: Re: Having trouble trying to activate a GigE connection> I have seen this behavior caused by a mismatch of SFPs, SX on one side and LX on the other. /p On Tue, Nov 24, 2009 at 9:04 AM, Michael Ruiz wrote: >>I don't think there is any reason to have hard-set speed and duplex, >>particularly between two Cisco's. ?Why not just set *both* sides (you >>can't set just one) to auto-negotation - 'no speed nonegotiate' on the >>7606 side. ?Is this a straight shot, single fiber pair between the two >>or are there intermediate junctions or optics? ?It sounds like you have >>questionable fiber or optics in the path. ?It could be the fiber itself >>or the GBICs on either side. > > Mike, > > ? ? ? ?I tried setting the 7206 to auto, and the 7606 to nonnegtiate, > however, no dice. ?We put light meter on both ends of the GBIC and light > readings are at -20, which are applicable. Between the two routers are > MMF and it is straight shot with no transport equipment in between. > > -----Original Message----- > From: Michael K. Smith - Adhost [mailto:mksmith at adhost.com] > Sent: Tuesday, November 24, 2009 10:25 AM > To: Michael Ruiz; nanog at nanog.org > Subject: RE: Having trouble trying to activate a GigE > connection> > > Hello Michael: > >> -----Original Message----- >> From: Michael Ruiz [mailto:mruiz at telwestservices.com] >> Sent: Tuesday, November 24, 2009 8:02 AM >> To: nanog at nanog.org >> Subject: Having trouble trying to activate a GigE > connection> >> >> Group, >> >> >> >> ? ? ? ? ? ? ? ? I am having an issue with activating a Gige interface >> between a Cisco 7206 VXR w/IO-1GE module to a 7606 w/sup720-3bxls >> connecting to a line module WS-X6416-GBIC. ?I have verified that the >> GBIC-MMF have good light reading and the MMF fiber jumper are not >> reversed. ?The GigE connection comes up briefly for about a few >> seconds, >> takes a burst of errors and goes down. ?I have tried to set the speed >> to >> nonegotiate on both ends, set one end to speed auto. ?No dice. ?Here > is >> the copy of the configuration. ?On my 7606 I show that the GigE >> interface is up/up but on the 7206vxr I show down/down. ?Any help will >> be greatly appreciated. ?Thanks! >> >> >> > I don't think there is any reason to have hard-set speed and duplex, > particularly between two Cisco's. ?Why not just set *both* sides (you > can't set just one) to auto-negotation - 'no speed nonegotiate' on the > 7606 side. ?Is this a straight shot, single fiber pair between the two > or are there intermediate junctions or optics? ?It sounds like you have > questionable fiber or optics in the path. ?It could be the fiber itself > or the GBICs on either side. > > Regards, > > Mike > > -- Peter Sandstr?m Head of Operations, Stardoll AB phone: +46 (0)70 456 05 28 e-mail: peter at stardoll.com | stardoll: pj0tr mail/visit: Hudiksvallsgatan 8, 113 30 Stockholm, Sweden www.stardoll.com - Fame, fashion and friends From randy at psg.com Wed Nov 25 14:29:10 2009 From: randy at psg.com (Randy Bush) Date: Thu, 26 Nov 2009 05:29:10 +0900 Subject: Who has AS 1712? In-Reply-To: <781B23B5-674D-4B28-9A0C-F5612CCB179A@virtualized.org> References: <20091124074817.GA6170@reiftel.karrenberg.net> <20091123151043.GA11349@nic.fr> <5.1.0.14.2.20091124113919.00c47098@efes.iucc.ac.il> <4B0C48DF.1040806@justinshore.com> <5.1.0.14.2.20091125112942.0565e050@efes.iucc.ac.il> <781B23B5-674D-4B28-9A0C-F5612CCB179A@virtualized.org> Message-ID: >>> I do not say everything is ideal now. However the RIRs are actively >>> working to publish a complete set of stats files which also includes >>> unallocated resources. > I would've thought IANA would be responsible for unallocated > resources. history shows that rirs would rather fight the iana and among themselves than be equals in the internet community. how they do not see that this leads to the itu is beyond me. > More seriously, the theory is that the RIRs are bottom-up driven. If > you think a unified whois schema across all RIRs (or even IRIS > deployment) would be a good thing to have, there are likely better > venues to raise the issue than NANOG. have the tee shirt. did not work. nih is not just a us govt agency. why we needed to regionalize irs in the first place is lost on me. fiefdoms. randy From richard at bennett.com Wed Nov 25 14:46:30 2009 From: richard at bennett.com (Richard Bennett) Date: Wed, 25 Nov 2009 12:46:30 -0800 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: <48319.1259161990@turing-police.cc.vt.edu> References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> <4B0CB8DF.4000100@bennett.com> <620fd17c0911242222l122ade20o65034eb16d2f7380@mail.gmail.com> <4B0CCE4B.8000600@bennett.com> <4B0D05D1.9000204@gmail.com> <4B0D15B2.8090407@bennett.com> <48319.1259161990@turing-police.cc.vt.edu> Message-ID: <4B0D97A6.7000509@bennett.com> Click through to the PDF, it's a 16 page paper. RB [1]Valdis.Kletnieks at vt.edu wrote: On Wed, 25 Nov 2009 03:32:02 PST, Richard Bennett said: ITIF is not opposed to network neutrality in principle, having released a paper on "A Third Way on Network Neutrality", [2]http://www.itif.org/index.php?id=63. All of four paragraphs, which don't in fact address what the provider is or is not providing to Joe Sixpack - point 1 says discriminatory plans are OK as long as the discriminatory are on display in the cellar of the ISP office, with no stairs, in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying Beware of the Leopard. And points 2 and 3 are saying that this should all be overseen by the same agencies that oversaw the previous decade's massive buildout of fiber to the home that was financed by massive multi-billion dollar incentives. Oh wait, those billions got pocketed - if the massive fiber buildout had happened, we'd have so much bandwidth that neutrality wouldn't be an issue... But then, the Republicans keep saying they are not opposed to health care reform in principle either... -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC References 1. mailto:Valdis.Kletnieks at vt.edu 2. http://www.itif.org/index.php?id=63 From jmamodio at gmail.com Wed Nov 25 14:58:57 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 25 Nov 2009 14:58:57 -0600 Subject: What DNS Is Not In-Reply-To: <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> Message-ID: <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> Paul's article "What DNS Is Not" published in December's Issue of Communications of the ACM. Also ICANN publishes memorandum about Harms and Concerns Posed by NXDOMAIN Substitution: http://www.icann.org/en/topics/new-gtlds/nxdomain-substitution-harms-24nov09-en.pdf What needs to be done to have ISPs and other service providers stop tampering with DNS ? Cheers Jorge From darren at bolding.org Wed Nov 25 15:04:56 2009 From: darren at bolding.org (Darren Bolding) Date: Wed, 25 Nov 2009 13:04:56 -0800 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: <48319.1259161990@turing-police.cc.vt.edu> References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> <4B0CB8DF.4000100@bennett.com> <620fd17c0911242222l122ade20o65034eb16d2f7380@mail.gmail.com> <4B0CCE4B.8000600@bennett.com> <4B0D05D1.9000204@gmail.com> <4B0D15B2.8090407@bennett.com> <48319.1259161990@turing-police.cc.vt.edu> Message-ID: <5a318d410911251304t5d07bd60wdd968ccddcc71db2@mail.gmail.com> Whether or not Mr Bennett has any idea what he is talking about- and I have started to develop an opinion on that subject myself- I really would rather not see Nanog become a forum for partisan political discussion. There are _lots_ of places for that, which as a political junkie I read regularly. I like Nanog in part because it typically steers clear of this sort of thing (and you know the mailing list charter sez....) and in some way serves as a refreshing change between reading Daily Kos and Powerline blogs. I will also say that while Mr Bennett's affiliation and paycheck have some relevance to interpreting what he says, it isn't justification for tossing everything he says out. If he seems to have no idea what he is talking about, that is reason for tossing out what he says. One final point- referring to conservadems is about as telling about perspective as certain people referring to RINO's. Bennett hasn't said anything blatantly partisan (perhaps he is to polished for that), his critics certainly have. You diminish your argument by doing so. I say all this even though some of the people getting engaged in this are people I've known for a while and respect a great deal, and others are ones I've read on Nanog for a number of years. I'm actually intersted in the substantive content, but I'd rather avoid the rest if you wouldn't mind. Thanks for listening, --D On Wed, Nov 25, 2009 at 7:13 AM, wrote: > On Wed, 25 Nov 2009 03:32:02 PST, Richard Bennett said: > > > ITIF is not opposed to network neutrality > > in principle, having released a paper on "A Third Way on Network > > Neutrality", http://www.itif.org/index.php?id=63. > > All of four paragraphs, which don't in fact address what the provider is or > is > not providing to Joe Sixpack - point 1 says discriminatory plans are OK as > long > as the discriminatory are on display in the cellar of the ISP office, with > no > stairs, in the bottom of a locked filing cabinet stuck in a disused > lavatory > with a sign on the door saying Beware of the Leopard. > > And points 2 and 3 are saying that this should all be overseen by the same > agencies that oversaw the previous decade's massive buildout of fiber to > the > home that was financed by massive multi-billion dollar incentives. > > Oh wait, those billions got pocketed - if the massive fiber buildout had > happened, we'd have so much bandwidth that neutrality wouldn't be an > issue... > > But then, the Republicans keep saying they are not opposed to health care > reform in principle either... > > -- -- Darren Bolding -- -- darren at bolding.org -- From marka at isc.org Wed Nov 25 15:18:46 2009 From: marka at isc.org (Mark Andrews) Date: Thu, 26 Nov 2009 08:18:46 +1100 Subject: What DNS Is Not In-Reply-To: Your message of "Wed, 25 Nov 2009 14:58:57 MDT." <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> Message-ID: <200911252118.nAPLIk8v099559@drugs.dv.isc.org> In message <202705b0911251258s3256434vf7864d212a1f1cf1 at mail.gmail.com>, Jorge A modio writes: > Paul's article "What DNS Is Not" published in December's Issue of Communicati > ons > of the ACM. > > Also ICANN publishes memorandum about Harms and Concerns Posed by > NXDOMAIN Substitution: > > http://www.icann.org/en/topics/new-gtlds/nxdomain-substitution-harms-24nov09- > en.pdf > > What needs to be done to have ISPs and other service providers stop tampering > with DNS ? Sign your response (DNSSEC). That makes it abundently clear that you don't want your answers to be tampered with. Send cease-and-desist letter for all namespaces you own, to all ISP that you are aware of that are doing this. Followup if they fail to take corrective action. Mark > Cheers > Jorge > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From dwhite at olp.net Wed Nov 25 15:22:15 2009 From: dwhite at olp.net (Dan White) Date: Wed, 25 Nov 2009 15:22:15 -0600 Subject: What DNS Is Not In-Reply-To: <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> Message-ID: <20091125212214.GG5929@dan.olp.net> On 25/11/09?14:58?-0600, Jorge Amodio wrote: >Paul's article "What DNS Is Not" published in December's Issue of Communications >of the ACM. > >Also ICANN publishes memorandum about Harms and Concerns Posed by >NXDOMAIN Substitution: > >http://www.icann.org/en/topics/new-gtlds/nxdomain-substitution-harms-24nov09-en.pdf > >What needs to be done to have ISPs and other service providers stop tampering >with DNS ? Some options: Contact your local, state and federal legislators and convince them it's in the public interest for them to draft legislation to outlaw this practice - and hope among all hope that the end result resembles something technically benevolent. Contact ICANN/IANA and plead with them to stop assigning any more resources to said ISP. Publicize what said ISP is doing and let its customers decide if it's a significantly deplorable enough practice for them to find another ISP. -- Dan White From michael at linuxmagic.com Wed Nov 25 15:23:56 2009 From: michael at linuxmagic.com (Michael Peddemors) Date: Wed, 25 Nov 2009 13:23:56 -0800 Subject: What DNS Is Not In-Reply-To: <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> References: <20091119173153.F342645@resin18.mta.everyone.net> <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> Message-ID: <200911251323.56132.michael@linuxmagic.com> On November 25, 2009, Jorge Amodio wrote: > What needs to be done to have ISPs and other service providers stop > tampering with DNS ? > > Cheers > Jorge > And what is needed to have a consistant 'whois' reporting format :) Keeping adding to the list? -- -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors - President/CEO - LinuxMagic Products, Services, Support and Development Visit us at http://www.linuxmagic.com ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-589-0037 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From drc at virtualized.org Wed Nov 25 16:17:37 2009 From: drc at virtualized.org (David Conrad) Date: Wed, 25 Nov 2009 14:17:37 -0800 Subject: What DNS Is Not In-Reply-To: <20091125212214.GG5929@dan.olp.net> References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> <20091125212214.GG5929@dan.olp.net> Message-ID: <22D53292-E4E2-4020-8315-9C31746E2A0F@virtualized.org> Hi, On Nov 25, 2009, at 1:22 PM, Dan White wrote: > Contact ICANN/IANA and plead with them to stop assigning any more resources > to said ISP. ICANN/IANA doesn't assign resources to ISPs. Regards, -drc From richard at bennett.com Wed Nov 25 16:29:33 2009 From: richard at bennett.com (Richard Bennett) Date: Wed, 25 Nov 2009 14:29:33 -0800 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: <5a318d410911251304t5d07bd60wdd968ccddcc71db2@mail.gmail.com> References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> <4B0CB8DF.4000100@bennett.com> <620fd17c0911242222l122ade20o65034eb16d2f7380@mail.gmail.com> <4B0CCE4B.8000600@bennett.com> <4B0D05D1.9000204@gmail.com> <4B0D15B2.8090407@bennett.com> <48319.1259161990@turing-police.cc.vt.edu> <5a318d410911251304t5d07bd60wdd968ccddcc71db2@mail.gmail.com> Message-ID: <4B0DAFCD.7080302@bennett.com> (pardon me if this message is not formatted correctly, T-bird doesn't like this list) I agree that this is not the proper venue for discussion of the politics of Internet regulation; the post I wrote for GigaOm has comments enabled, and many people with an anti-capitalist bone to pick have already availed themselves of that forum to advocate for the people's revolution. There are some technical issues that might be of more interest and relevance to operators, however. * One claim I made in my blog post is that traffic increases on the Internet aren't measured by MINTS very well. MINTS uses data from Meet-me switches, but IX's and colos are pulling x-connects like mad so more and more traffic is passing directly through the x-connects and therefore not being captured by MINTS. Rate of traffic increase is important for regulators as it relates to the cost of running an ISP and the need for traffic shaping. Seems to me that MINTS understates traffic growth, and people are dealing with it by lighting more dark fiber, pulling more fiber, and the x-connects are the tip of the iceberg that says this is going on. * A number of people said I have no basis for the claim that paid peering is on the increase, and it's true that the empirical data is slim due to the secretive nature of peering and transit agreements. This claim is based on hearsay and on the observation that Comcast now has a nationwide network and a very open policy regarding peering and paid peering. So if paid peering is only increasing at Comcast, now a top 10 network, it's increasing overall. * Some other people said I'm not entitled to have an opinion; so much for democracy and free speech. I'd be glad to hear from anyone who has data or informed opinions on these subjects, on-list of off-. The reason you should share is that people in Washington and Brussels listen to me, so it's in everybody's interest for me to be well-informed; I don't really have an ax to grind one way or another, but I do want law and regulation to be based on fact, not speculation and ideology. Thanks and have a nice day. RB Darren Bolding wrote: > Whether or not Mr Bennett has any idea what he is talking about- and I > have started to develop an opinion on that subject myself- I really > would rather not see Nanog become a forum for partisan political > discussion. There are _lots_ of places for that, which as a political > junkie I read regularly. > > I like Nanog in part because it typically steers clear of this sort of > thing (and you know the mailing list charter sez....) and in some way > serves as a refreshing change between reading Daily Kos and Powerline > blogs. > > I will also say that while Mr Bennett's affiliation and paycheck have > some relevance to interpreting what he says, it isn't justification > for tossing everything he says out. If he seems to have no idea what > he is talking about, that is reason for tossing out what he says. > > One final point- referring to conservadems is about as telling about > perspective as certain people referring to RINO's. Bennett hasn't > said anything blatantly partisan (perhaps he is to polished for that), > his critics certainly have. You diminish your argument by doing so. > > I say all this even though some of the people getting engaged in this > are people I've known for a while and respect a great deal, and others > are ones I've read on Nanog for a number of years. > > I'm actually intersted in the substantive content, but I'd rather > avoid the rest if you wouldn't mind. > > Thanks for listening, > > --D > > > On Wed, Nov 25, 2009 at 7:13 AM, > wrote: > > On Wed, 25 Nov 2009 03:32:02 PST, Richard Bennett said: > > > ITIF is not opposed to network neutrality > > in principle, having released a paper on "A Third Way on Network > > Neutrality", http://www.itif.org/index.php?id=63. > > All of four paragraphs, which don't in fact address what the > provider is or is > not providing to Joe Sixpack - point 1 says discriminatory plans > are OK as long > as the discriminatory are on display in the cellar of the ISP > office, with no > stairs, in the bottom of a locked filing cabinet stuck in a > disused lavatory > with a sign on the door saying Beware of the Leopard. > > And points 2 and 3 are saying that this should all be overseen by > the same > agencies that oversaw the previous decade's massive buildout of > fiber to the > home that was financed by massive multi-billion dollar incentives. > > Oh wait, those billions got pocketed - if the massive fiber > buildout had > happened, we'd have so much bandwidth that neutrality wouldn't be > an issue... > > But then, the Republicans keep saying they are not opposed to > health care > reform in principle either... > > > > > -- > -- Darren Bolding -- > -- darren at bolding.org -- -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From ras at e-gerbil.net Wed Nov 25 17:14:42 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 25 Nov 2009 17:14:42 -0600 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: <4B0DAFCD.7080302@bennett.com> References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> <4B0CB8DF.4000100@bennett.com> <620fd17c0911242222l122ade20o65034eb16d2f7380@mail.gmail.com> <4B0CCE4B.8000600@bennett.com> <4B0D05D1.9000204@gmail.com> <4B0D15B2.8090407@bennett.com> <48319.1259161990@turing-police.cc.vt.edu> <5a318d410911251304t5d07bd60wdd968ccddcc71db2@mail.gmail.com> <4B0DAFCD.7080302@bennett.com> Message-ID: <20091125231442.GB51443@gerbil.cluepon.net> On Wed, Nov 25, 2009 at 02:29:33PM -0800, Richard Bennett wrote: > (pardon me if this message is not formatted correctly, T-bird doesn't > like this list) > > I agree that this is not the proper venue for discussion of the > politics of Internet regulation; the post I wrote for GigaOm has > comments enabled, and many people with an anti-capitalist bone to pick > have already availed themselves of that forum to advocate for the > people's revolution. There are some technical issues that might be of > more interest and relevance to operators, however. So now anyone who points out the massive flaws in your statements are part of an anti-capitalist movement? Any more conspiracy theories you'd like to put forward? I can't speak for anyone else, but personally I consider myself very pro-capitalism and it has absolutely no impact on how I feel about the blatantly wrong and baseless crap you are spewing. > * One claim I made in my blog post is that traffic increases on the > Internet aren't measured by MINTS very well. MINTS uses data from > Meet-me switches, but IX's and colos are pulling x-connects like mad > so more and more traffic is passing directly through the x-connects > and therefore not being captured by MINTS. Rate of traffic increase is > important for regulators as it relates to the cost of running an ISP > and the need for traffic shaping. Seems to me that MINTS understates > traffic growth, and people are dealing with it by lighting more dark > fiber, pulling more fiber, and the x-connects are the tip of the > iceberg that says this is going on. This is all completely irrelevent to everything else that has been discussed so far, but what the hell I'll bite. Traffic on the Internet is indeed growing rapidly, while the predominate technology for cost effectively interconnecting the vast majority of the bits (10 Gigabit Ethernet) has remained relatively static in recent years. Without a cost effective technology for interconnecting devices in > 10Gbps increments (40Gbps OC-768 has existed for a while, but is far more expensive than simply doing 4x10GbE), the only reasonable way to scale a network is to build your links out of Nx10G bundles. In places with reasonable crossconnect pricing, it is far cheaper to simply order multiple crossconnects than it is to pay for DWDM gear, and thus you see a rapid increase in fiber crossconnects. > * A number of people said I have no basis for the claim that paid > peering is on the increase, and it's true that the empirical data is > slim due to the secretive nature of peering and transit agreements. > This claim is based on hearsay and on the observation that Comcast now > has a nationwide network and a very open policy regarding peering and > paid peering. So if paid peering is only increasing at Comcast, now a > top 10 network, it's increasing overall. So in other words, you're admitting that you have absolutely no basis for your claim, and you're simply making it up based on indirect hearsay modified with your own ill-informed conclusions? First intelligent thing you've said so far. If you actually bothered to ask anyone in the industry with experience dealing with Comcast, they would tell you that while Comcast initially entered the market primarily trying to sell paid peering, they have since switched their efforts to primarily selling full transit. There are only a certain number of networks who even know what to DO with a paid peering product, and a vastly larger number who know what to do with a transit product, so it makes perfect sense really. > * Some other people said I'm not entitled to have an opinion; so much > for democracy and free speech. You are not entitled to opine an opinion on a subject matter which you do not understand, without being called out for it. Sane and rational people understand when they are talking out their ass and are being corrected by knowledgable experts, and will shut the hell up and listen. Sadly this seems to be a skill you lack. > I'd be glad to hear from anyone who has data or informed opinions on > these subjects, on-list of off-. The reason you should share is that > people in Washington and Brussels listen to me, so it's in everybody's > interest for me to be well-informed; I don't really have an ax to > grind one way or another, but I do want law and regulation to be based > on fact, not speculation and ideology. So far none of the above statements seem to be true. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From jmamodio at gmail.com Wed Nov 25 17:26:14 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 25 Nov 2009 17:26:14 -0600 Subject: What DNS Is Not In-Reply-To: <20091125212214.GG5929@dan.olp.net> References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> <20091125212214.GG5929@dan.olp.net> Message-ID: <202705b0911251526n75194c46m30cdfcb4809b6de5@mail.gmail.com> >> What needs to be done to have ISPs and other service providers stop >> tampering with DNS ? > > Some options: > > Contact your local, state and federal legislators and convince them it's in > the public interest for them to draft legislation to outlaw this practice - > and hope among all hope that the end result resembles something technically > benevolent. Do we really want big brother sniffing around ? What about net neutrality ? > Contact ICANN/IANA and plead with them to stop assigning any more resources > to said ISP. ICANN has no contractual relationship with the service providers abusing the DNS, but a far reaching idea could claim ICANN responsibility and commitment to preserve and enhance the operational stability, reliability, security, and global interoperability of the Internet, stated in one of its core values on its bylaws. > Publicize what said ISP is doing and let its customers decide if it's a > significantly deplorable enough practice for them to find another ISP. Well Time Warner/Road Runner does it at least here in San Antonio, at least the don't filter DNS traffic if you choose to use other name servers and don't have a nasty proxy like the guys from Telefonica in Argentina. Anyway some of this nasty behavior will go away when as Mark said DNSSEC is fully deployed (someday). Regards Jorge From ras at e-gerbil.net Wed Nov 25 17:38:19 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 25 Nov 2009 17:38:19 -0600 Subject: fight club :) richard bennett vs various nanogers, on paid peering In-Reply-To: <4B0DAFCD.7080302@bennett.com> References: <4b0cb711.wfivEH7u/aZcdwL0%ops.lists@gmail.com> <4B0CB8DF.4000100@bennett.com> <620fd17c0911242222l122ade20o65034eb16d2f7380@mail.gmail.com> <4B0CCE4B.8000600@bennett.com> <4B0D05D1.9000204@gmail.com> <4B0D15B2.8090407@bennett.com> <48319.1259161990@turing-police.cc.vt.edu> <5a318d410911251304t5d07bd60wdd968ccddcc71db2@mail.gmail.com> <4B0DAFCD.7080302@bennett.com> Message-ID: <20091125233819.GC51443@gerbil.cluepon.net> On Wed, Nov 25, 2009 at 02:29:33PM -0800, Richard Bennett wrote: > * One claim I made in my blog post is that traffic increases on the > Internet aren't measured by MINTS very well. MINTS uses data from > Meet-me switches, but IX's and colos are pulling x-connects like mad so > more and more traffic is passing directly through the x-connects and > therefore not being captured by MINTS. Rate of traffic increase is > important for regulators as it relates to the cost of running an ISP and > the need for traffic shaping. Seems to me that MINTS understates traffic > growth, and people are dealing with it by lighting more dark fiber, > pulling more fiber, and the x-connects are the tip of the iceberg that > says this is going on. Oh also I forgot to mention that trying to map a direct relationship between IX traffic growth and total IP traffic growth is completely bogus. There is a significant modifier you're missing, and it's called "price". Two years ago the price for an IX port at the large commercial exchange points in the US (which account for the vast majority of the traffic, no offense to the small non-comercial exchanges out there) was between 4-7x higher than the price for the same ports today. The reason for the price drop had nothing to do with changing economics of providing the service, but rather it was because of a wide-spread price war between the two largest IX operators in the US. Such a massive change in the economics for the IP network operators will obviously result in major changes to the amount of traffic delivered over IX fabrics vs private interconnection. Again, something you could have actually asked operators about rather than making up conclusons in your head. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From ops.lists at gmail.com Wed Nov 25 17:46:15 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 26 Nov 2009 05:16:15 +0530 Subject: I got a live one! - Spam source In-Reply-To: <200911250925.27298.michael@linuxmagic.com> References: <200911250925.27298.michael@linuxmagic.com> Message-ID: On Wed, Nov 25, 2009 at 10:55 PM, Michael Peddemors wrote: >> >> Could you elaborate on what constitutes correct swip information? >> > > Sure, you just opened the door to my opinions on this :) > Dysfunctional rwhois servers sounds more like general brokenness than malice. The other interesting (!) characteristic of thie sort of bulk mailer discussed in this thread is that the netblock is most likely swipped / rwhois'd to a brand new shell company LLC, headquartered in what looks like a UPS store maildrop. From john-nanog at johnpeach.com Wed Nov 25 18:16:53 2009 From: john-nanog at johnpeach.com (John Peach) Date: Wed, 25 Nov 2009 19:16:53 -0500 Subject: I got a live one! - Spam source In-Reply-To: References: <200911250925.27298.michael@linuxmagic.com> Message-ID: <20091125191653.704da4ac@milhouse.peachfamily.net> On Thu, 26 Nov 2009 05:16:15 +0530 Suresh Ramasubramanian wrote: > On Wed, Nov 25, 2009 at 10:55 PM, Michael Peddemors > wrote: > >> > >> Could you elaborate on what constitutes correct swip information? > >> > > > > Sure, you just opened the door to my opinions on this :) > > > > Dysfunctional rwhois servers sounds more like general brokenness than > malice. The other interesting (!) characteristic of thie sort of bulk > mailer discussed in this thread is that the netblock is most likely > swipped / rwhois'd to a brand new shell company LLC, headquartered in > what looks like a UPS store maildrop. > In the instances he quoted, I prefer, at best, a wish not to know about what is spewing from their address space. -- John From marka at isc.org Wed Nov 25 18:40:25 2009 From: marka at isc.org (Mark Andrews) Date: Thu, 26 Nov 2009 11:40:25 +1100 Subject: What DNS Is Not In-Reply-To: Your message of "Wed, 25 Nov 2009 17:26:14 MDT." <202705b0911251526n75194c46m30cdfcb4809b6de5@mail.gmail.com> References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> <20091125212214.GG5929@dan.olp.net> <202705b0911251526n75194c46m30cdfcb4809b6de5@mail.gmail.com> Message-ID: <200911260040.nAQ0eQIu002661@drugs.dv.isc.org> In message <202705b0911251526n75194c46m30cdfcb4809b6de5 at mail.gmail.com>, Jorge Amodio writes: > >> What needs to be done to have ISPs and other service providers stop > >> tampering with DNS ? > > > > Some options: > > > > Contact your local, state and federal legislators and convince them it's in > > the public interest for them to draft legislation to outlaw this practice - > > and hope among all hope that the end result resembles something technically > > benevolent. > > Do we really want big brother sniffing around ? What about net neutrality ? It's fraud, theft or both. The ISP's doing this don't own these names and they are pretending to be someone they are not. Just because lots of them are doing it doesn't make it right. You should be able to go to your local police and report this and have action taken. > > Contact ICANN/IANA and plead with them to stop assigning any more resources > > to said ISP. > > ICANN has no contractual relationship with the service providers abusing the > DNS, but a far reaching idea could claim ICANN responsibility and commitment > to preserve and enhance the operational stability, reliability, > security, and global > interoperability of the Internet, stated in one of its core values on > its bylaws. > > > Publicize what said ISP is doing and let its customers decide if it's a > > significantly deplorable enough practice for them to find another ISP. > > Well Time Warner/Road Runner does it at least here in San Antonio, at least > the don't filter DNS traffic if you choose to use other name servers and don't > have a nasty proxy like the guys from Telefonica in Argentina. > > Anyway some of this nasty behavior will go away when as Mark said > DNSSEC is fully deployed (someday). > > Regards > Jorge > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From dwhite at olp.net Wed Nov 25 18:41:09 2009 From: dwhite at olp.net (Dan White) Date: Wed, 25 Nov 2009 18:41:09 -0600 Subject: What DNS Is Not In-Reply-To: <22D53292-E4E2-4020-8315-9C31746E2A0F@virtualized.org> References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> <20091125212214.GG5929@dan.olp.net> <22D53292-E4E2-4020-8315-9C31746E2A0F@virtualized.org> Message-ID: <20091126004109.GA11670@dan.olp.net> On 25/11/09?14:17?-0800, David Conrad wrote: >Hi, > >On Nov 25, 2009, at 1:22 PM, Dan White wrote: >> Contact ICANN/IANA and plead with them to stop assigning any more resources >> to said ISP. > >ICANN/IANA doesn't assign resources to ISPs. Indirectly they're responsible for assignment of IP address, enterprise numbers, domain names etc. Of course you're not going to get very far with that approach. My point was there isn't really an authority to enforce rules on ISPs when it comes to how they manage their DNS servers. Government and IANA won't be interested in fielding such complaints. Shining a flash light on the problem publicly is going to be the best best. -- Dan White From srchlm at its.cz Wed Nov 25 21:03:40 2009 From: srchlm at its.cz (Lumir Srchlm) Date: Thu, 26 Nov 2009 04:03:40 +0100 Subject: =?ISO-8859-2?B?QVVUTzogTHVt7XIgU3JjaCBtbC4gaXMgb3V0IG9mIG9mZmljZSA=?= Message-ID: I am out of the office until 30.11.2009. Na Vas e-mail odpovim co nejdrive. V pripade urgentnich problemu prosim kontaktujte helpdesk. I will answer your e-mail as soon as possible. Your e-mail will not be forwarded. Please contact helpdesk for urgent issues. Dekuji za pochopen? Lumir Srch ml. Note: This is an automated response to your message "Re: I got a live one! - Spam source" sent on 26.11.09 1:16:53. This is the only notification you will receive while this person is away. From vixie at isc.org Wed Nov 25 22:16:49 2009 From: vixie at isc.org (Paul Vixie) Date: Thu, 26 Nov 2009 04:16:49 +0000 Subject: What DNS Is Not In-Reply-To: <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> (Jorge Amodio's message of "Wed\, 25 Nov 2009 14\:58\:57 -0600") References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> Message-ID: Jorge Amodio writes: > What needs to be done to have ISPs and other service providers stop > tampering with DNS ? we have to fix DNS so that provider-in-the-middle attacks no longer work. (this is why in spite of its technical excellence i am not a DNSCURVE fan, and also why in spite of its technical suckitude i'm working on DNSSEC.) lays out this case. -- Paul Vixie KI6YSY From bmanning at vacation.karoshi.com Wed Nov 25 23:21:05 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 26 Nov 2009 05:21:05 +0000 Subject: What DNS Is Not In-Reply-To: <22D53292-E4E2-4020-8315-9C31746E2A0F@virtualized.org> References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> <20091125212214.GG5929@dan.olp.net> <22D53292-E4E2-4020-8315-9C31746E2A0F@virtualized.org> Message-ID: <20091126052105.GA31889@vacation.karoshi.com.> On Wed, Nov 25, 2009 at 02:17:37PM -0800, David Conrad wrote: > Hi, > > On Nov 25, 2009, at 1:22 PM, Dan White wrote: > > Contact ICANN/IANA and plead with them to stop assigning any more resources > > to said ISP. > > ICANN/IANA doesn't assign resources to ISPs. > > Regards, > -drc > any more.... :) --bill From devangnp at gmail.com Thu Nov 26 00:27:46 2009 From: devangnp at gmail.com (devang patel) Date: Wed, 25 Nov 2009 23:27:46 -0700 Subject: Multicast LDP or P2MP RSVP & LDP Message-ID: Hi All, I just want to know about the deployment of Multicast LDP or P2MP RSVP and LDP is available from any vendor or they are still in draft status? Also it will be great if some one can give me an idea of Multicast VPN deployment in service providers; are they deployed with draft Rosen GRE based solution or BGP auto discovery mechanism? Thanks in advance for help... regards, Devang From rjs at eng.gxn.net Thu Nov 26 01:46:22 2009 From: rjs at eng.gxn.net (Rob Shakir) Date: Thu, 26 Nov 2009 07:46:22 +0000 Subject: Multicast LDP or P2MP RSVP & LDP In-Reply-To: References: Message-ID: On 26 Nov 2009, at 06:27, devang patel wrote: > Hi All, > > I just want to know about the deployment of Multicast LDP or P2MP > RSVP and > LDP is available from any vendor or they are still in draft status? Hi Devang, To the best of my knowledge, the only current P2MP LSP implementation available is in JunOS [0]. The guys at Juniper wrote a draft relating to their experience with scaling and implementing P2MP MVPN [1], which is worth a look -- this draft mentions that IOS XR has an implementation, although I struggled to find any documentation that confirms this. Both the LDP-based [2] P2MP standard are still in draft status, but the extensions required in RSVP-TE for signalling P2MP paths are in RFC4875 [3]. From a couple of discussions I've had, there are not very many people using this functionality -- with most common application being IPTV. For traditional transport of multicast over an SP core, it's often easier to provide some AToM/L2VPN service. Hope this helps somewhat. Kind regards, Rob [0]: http://www.juniper.net/techpubs/software/junos/junos91/feature-guide/configuring-traffic-engineering-p2mp-lsps-in-provider-tunnels.html [1]: http://tools.ietf.org/html/draft-joseph-p2mp-mvpn-experience-00 [2]: http://tools.ietf.org/html/draft-ietf-mpls-ldp-p2mp-08 [3]: http://tools.ietf.org/html/rfc4875 -- Rob Shakir Network Development Engineer GX Networks/Vialtus Solutions ddi: +44208 587 6077 mob: +44797 155 4098 pgp: 0xc07e6deb nic-hdl: RJS-RIPE This email is subject to: http://www.vialtus.com/disclaimer.html From devangnp at gmail.com Thu Nov 26 01:53:22 2009 From: devangnp at gmail.com (devang patel) Date: Thu, 26 Nov 2009 00:53:22 -0700 Subject: Multicast LDP or P2MP RSVP & LDP In-Reply-To: References: Message-ID: Rob, Can you share some documentation with me on how to configure as well as any kind of configuration example will be great help. Thanks, Devang On Thu, Nov 26, 2009 at 12:46 AM, Rob Shakir wrote: > > On 26 Nov 2009, at 06:27, devang patel wrote: > > Hi All, >> >> I just want to know about the deployment of Multicast LDP or P2MP RSVP and >> LDP is available from any vendor or they are still in draft status? >> > > Hi Devang, > > To the best of my knowledge, the only current P2MP LSP implementation > available is in JunOS [0]. The guys at Juniper wrote a draft relating to > their experience with scaling and implementing P2MP MVPN [1], which is worth > a look -- this draft mentions that IOS XR has an implementation, although I > struggled to find any documentation that confirms this. > > Both the LDP-based [2] P2MP standard are still in draft status, but the > extensions required in RSVP-TE for signalling P2MP paths are in RFC4875 [3]. > > From a couple of discussions I've had, there are not very many people using > this functionality -- with most common application being IPTV. For > traditional transport of multicast over an SP core, it's often easier to > provide some AToM/L2VPN service. > > Hope this helps somewhat. > > Kind regards, > Rob > > [0]: > http://www.juniper.net/techpubs/software/junos/junos91/feature-guide/configuring-traffic-engineering-p2mp-lsps-in-provider-tunnels.html > [1]: http://tools.ietf.org/html/draft-joseph-p2mp-mvpn-experience-00 > [2]: http://tools.ietf.org/html/draft-ietf-mpls-ldp-p2mp-08 > [3]: http://tools.ietf.org/html/rfc4875 > > -- > Rob Shakir > Network Development Engineer GX Networks/Vialtus Solutions > ddi: +44208 587 6077 mob: +44797 155 4098 > pgp: 0xc07e6deb nic-hdl: RJS-RIPE > > This email is subject to: http://www.vialtus.com/disclaimer.html > > > > From linford at spamhaus.org Thu Nov 26 03:53:42 2009 From: linford at spamhaus.org (Steve Linford) Date: Thu, 26 Nov 2009 09:53:42 +0000 Subject: I got a live one! - Spam source In-Reply-To: <5e1ca1ac0911241922u25634547u7eeb7ec6e357b352@mail.gmail.com> References: <5e1ca1ac0911241922u25634547u7eeb7ec6e357b352@mail.gmail.com> Message-ID: On 25 Nov 2009, at 04:22, Russell Myba wrote: > Looks like of our customers has decided to turn their /24 into a > nice little > space spewing machine. Doesn't seem like just one compromised host. > > Reverse DNS for most of the /24 are suspicious domains. Each > domain used in > the message-id forwards to a single .net which lists their mailing > address > as a PO box an single link to an unsubscribe field. Classic snowshoe spam setup, probably a professional snowshoe spam outfit known to Spamhaus as 'Tactara' and 'Webzero'. Snowshoe spam operations operate by contacting ISP pretending to be 'IP space brokers', they buy lots of IP space and have it all SWIPed in small chunks, mostly /24s, to an endless array of anonymous Wyoming and Delaware shell companies at UPS mailboxes. They then fill the /24s with freshly-registered 'nonsense' domains, tunnel into the server to hide their real location, and start the spamming. Usually almost every IP in the /24 has a spam cannon on it and a web page with just an 'unsubscribe' field. They're the reason we created the CSS announced here: http://www.spamhaus.org/news.lasso?article=646 (please don't follow up to this post here on NANOG, as NANOG is not an appropriate forum for spam discussions) Steve Linford The Spamhaus Project http://www.spamhaus.org From rsk at gsp.org Thu Nov 26 06:55:05 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 26 Nov 2009 07:55:05 -0500 Subject: I got a live one! - Spam source In-Reply-To: <200911250925.27298.michael@linuxmagic.com> References: <200911250925.27298.michael@linuxmagic.com> Message-ID: <20091126125505.GA3569@gsp.org> On Wed, Nov 25, 2009 at 09:25:27AM -0800, Michael Peddemors wrote: > I here people saying that they don't publish whois information because they > don't want the email's made public. Okay, at least the registered company > name, or individual who presented the ID should be there. Without delving too far into this: there is no point whatsoever in attempting to conceal or obfuscate email addresses --not any more. It is an obsolete, "cargo cult" practice that many are still engaged in without grasping that it was quite thoroughly defeated by spammers and their associates years ago. That said, I concur in full with your opinions in re whois data and the need to assign it properly. I've long since stopped trying to deal with missing information and have adopted the rule that if the neighborhood looks sufficiently bad, I just block a /24 worth. That may sound arbitrary, but in practice it works extremely well. ---Rsk From wavetossed at googlemail.com Thu Nov 26 08:16:38 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Thu, 26 Nov 2009 14:16:38 +0000 Subject: Who has AS 1712? In-Reply-To: References: <20091123151043.GA11349@nic.fr> <75cb24520911230750y28cf48f4j925ebbfdb1296cee@mail.gmail.com> <75cb24520911232033x24bacf13xa3bb9d32599f45ea@mail.gmail.com> Message-ID: <877585b00911260616l77675e76tc6bb79db0cc7fdcd@mail.gmail.com> > How do you announce an ASN? Using RSS. Doesn't ARIN already announce all allocations via RSS? --Michael Dillon From drc at virtualized.org Thu Nov 26 09:37:56 2009 From: drc at virtualized.org (David Conrad) Date: Thu, 26 Nov 2009 07:37:56 -0800 Subject: What DNS Is Not In-Reply-To: <20091126004109.GA11670@dan.olp.net> References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> <20091125212214.GG5929@dan.olp.net> <22D53292-E4E2-4020-8315-9C31746E2A0F@virtualized.org> <20091126004109.GA11670@dan.olp.net> Message-ID: <96B33E83-1F14-4BEF-A580-BDA72CA6F65C@virtualized.org> Hi, On Nov 25, 2009, at 4:41 PM, Dan White wrote: > On 25/11/09 14:17 -0800, David Conrad wrote: >> On Nov 25, 2009, at 1:22 PM, Dan White wrote: >>> Contact ICANN/IANA and plead with them to stop assigning any more resources >>> to said ISP. >> >> ICANN/IANA doesn't assign resources to ISPs. > > Indirectly they're responsible for assignment of IP address, In the sense that they allocate /8s (and, in IPv6, /12s) to the RIRs, sure. I'm just guessing but I don't think the RIRs would be very happy if ICANN/IANA were to refuse to allocate a /8 (or a /12) to an RIR because one of the RIRs' customers was hijacking NXDOMAINs. > enterprise numbers, Actually, ICANN/IANA assigns these directly (see http://pen.iana.org), but I suspect the folks in the IETF would get a bit distressed if ICANN/IANA started imposing restrictions on who could get PENs. > domain names ICANN/IANA is directly responsible for (and has contractual relationships with folks who operate) gTLDs and has, to the distress of some folks on this list, imposed restrictions on wildcards/synthesis/etc. ICANN/IANA discourages wildcards/synthesis/etc for ccTLDs, but the operation of a ccTLD is considered a national sovereignty issue and thus, ICANN/IANA has no way to do anything other than point out the problems wildcards/synthesis/etc. can lead to. As I write this, there are 11 ccTLDs that do wildcards/synthesis/etc. and there will undoubtedly be more in the future. ICANN/IANA has no interaction with, much less control, over ISPs. > My point was there isn't really an authority to enforce rules on ISPs when > it comes to how they manage their DNS servers. Yep. > Government and IANA won't be interested in fielding such complaints. Government might -- politicians like to be seen solving problems, even if they haven't the slightest idea what the problem is, whether it actually is a problem, or how to go about fixing it. With the exception of the gTLDs, ICANN/IANA simply can't -- it has no mechanism to do anything other than wag its finger. > Shining a flash light on the problem publicly is going to be the best best. There are folks on this list who work for ISPs which are doing wildcards/synthesis/etc. They (or, more likely their management) can tell you there are obvious business reasons why they do wildcards/synthesis/etc. Perhaps I'm overly cynical, but I suspect that until those business reasons go away, shining a flash light will probably just result in more ISPs implementing wildcards/synthesis/etc. Regards, -drc From drc at virtualized.org Thu Nov 26 09:42:15 2009 From: drc at virtualized.org (David Conrad) Date: Thu, 26 Nov 2009 07:42:15 -0800 Subject: What DNS Is Not In-Reply-To: References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> Message-ID: On Nov 25, 2009, at 8:16 PM, Paul Vixie wrote: > we have to fix DNS so that provider-in-the-middle attacks no longer work. > (this is why in spite of its technical excellence i am not a DNSCURVE fan, > and also why in spite of its technical suckitude i'm working on DNSSEC.) As you know, as long as people rely on their ISPs for resolution services, DNSSEC isn't going to help. Where things get really offensive if when the ISPs _require_ customers (through port 53 blocking, T-Mobile Hotspot, I'm looking at you) to use the ISP's resolution services. Regards, -drc From jcurran at arin.net Thu Nov 26 10:31:10 2009 From: jcurran at arin.net (John Curran) Date: Thu, 26 Nov 2009 11:31:10 -0500 Subject: ARIN/RIPE NCC Joint Statement on ASN Assignment Discrepancies Message-ID: ARIN and the RIPE NCC have worked together to research the issues with the Autonomous System Number (ASN) range AS1707-AS1726. Below is our analysis of what happened and a plan to resolve these issues. It appears that prior to 1993, Renater was issued AS1707 with an AS name of "ASNBLOCKA". This is the name format used to assign a block of ASNs, but the DDN NIC (the Defense Data Network Network Information Center, which was responsible for ASN assignments until 1993) recorded only a single assignment of AS1707, rather than the entire block of 20 ASNs (AS1707-AS1726), as would have been expected. AS1712 was never registered in the DDN NIC database. Since the proper registration was never recorded, this mistake carried over from the InterNIC database into ARIN's database at ARIN?s inception in 1997. The ASN range was not transferred to the RIPE NCC along with AS1707 because AS1708-AS1726 appeared to be unassigned, and thus remained with ARIN. Because this is simply an error in registry data and Renater is the actual registrant of this entire range of ASNs (AS1707-AS1726), ARIN will work with its customers who received ASNs from this range in July and August of 2009 to provide them with replacement ASNs. While we understand that this may cause some difficulty for these customers, we feel that this is the best path forward given the circumstances. RIPE NCC and ARIN will update their respective databases and work with the IANA to ensure that the ASN registry data is properly updated for this range. To prevent future issues, ARIN and RIPE NCC will implement two new processes for issuing new ASNs: checking all other RIR databases to ensure that the ASN is not previously registered, and checking BGP routing tables to ensure the ASN is not already found in an announced AS-path. ASNs that fail either of these conditions will not be issued until the discrepancy has been addressed. Regards, John Curran, President and CEO, ARIN Axek Pawlik, Managing Director, RIPE NCC From vixie at isc.org Thu Nov 26 10:37:39 2009 From: vixie at isc.org (Paul Vixie) Date: Thu, 26 Nov 2009 16:37:39 +0000 Subject: What DNS Is Not In-Reply-To: Your message of "Thu, 26 Nov 2009 07:42:15 PST." References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> Message-ID: <56156.1259253459@nsa.vix.com> > From: David Conrad > Date: Thu, 26 Nov 2009 07:42:15 -0800 > > As you know, as long as people rely on their ISPs for resolution > services, DNSSEC isn't going to help. Where things get really offensive > if when the ISPs _require_ customers (through port 53 blocking, T-Mobile > Hotspot, I'm looking at you) to use the ISP's resolution services. the endgame for provider-in-the-middle attacks is enduser validators, which is unfortunate since this use case is not well supported by current DNSSEC and so there's some more protocol work in our future ("noooooooooooo!!"). i also expect to see DNS carried via HTTPS, which providers tend to leave alone since they don't want to hear from the lawyers at 1-800-flowers.com. (so, get ready for https://ns.vix.com/dns/query/www.vix.com/in/a&rd=1&ad=1). From fw at deneb.enyo.de Thu Nov 26 11:40:25 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 26 Nov 2009 18:40:25 +0100 Subject: What DNS Is Not In-Reply-To: <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> (Jorge Amodio's message of "Wed, 25 Nov 2009 14:58:57 -0600") References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> Message-ID: <87pr75nq0m.fsf@mid.deneb.enyo.de> * Jorge Amodio: > What needs to be done to have ISPs and other service providers stop tampering > with DNS ? First, stop calling it "NXDOMAIN rewriting". These guys are rewriting everything they want, so that they can respond to your search queries, or serve different ads to you. Then try to opt out of rewriting for your own domains, asking the offenders to stop doing it in your namespace, and if that doesn't help, use the court system. Fight your own fights, and don't expect others to do it for you. (Oh, in case you wonder---I can't, because in Germany, registering a domain name does not grant you rights to that name, even if you've been using it for quite a while.) From dwhite at olp.net Thu Nov 26 12:25:49 2009 From: dwhite at olp.net (Dan White) Date: Thu, 26 Nov 2009 12:25:49 -0600 Subject: What DNS Is Not In-Reply-To: <96B33E83-1F14-4BEF-A580-BDA72CA6F65C@virtualized.org> References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> <20091125212214.GG5929@dan.olp.net> <22D53292-E4E2-4020-8315-9C31746E2A0F@virtualized.org> <20091126004109.GA11670@dan.olp.net> <96B33E83-1F14-4BEF-A580-BDA72CA6F65C@virtualized.org> Message-ID: <20091126182548.GB4965@dan.olp.net> On 26/11/09?07:37?-0800, David Conrad wrote: >There are folks on this list who work for ISPs which are doing wildcards/synthesis/etc. They (or, more likely their management) can tell you there are obvious business reasons why they do wildcards/synthesis/etc. Perhaps I'm overly cynical, but I suspect that until those business reasons go away, shining a flash light will probably just result in more ISPs implementing wildcards/synthesis/etc. That's a disagreement we'll have to have. Anytime this issue has been brought up in a public setting (here, slashdot, etc.) has resulted in terrible press and even corrective action. In particular, Network Solutions' attempt to at this at the .com level was corrected. Of course I don't know what, if any, ICANN pressure has to do with that, but the flash light practice was apparently successful. -- Dan White From Valdis.Kletnieks at vt.edu Thu Nov 26 13:54:01 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 26 Nov 2009 14:54:01 -0500 Subject: What DNS Is Not In-Reply-To: Your message of "Thu, 26 Nov 2009 12:25:49 CST." <20091126182548.GB4965@dan.olp.net> References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> <20091125212214.GG5929@dan.olp.net> <22D53292-E4E2-4020-8315-9C31746E2A0F@virtualized.org> <20091126004109.GA11670@dan.olp.net> <96B33E83-1F14-4BEF-A580-BDA72CA6F65C@virtualized.org> <20091126182548.GB4965@dan.olp.net> Message-ID: <85977.1259265241@turing-police.cc.vt.edu> On Thu, 26 Nov 2009 12:25:49 CST, Dan White said: > That's a disagreement we'll have to have. Anytime this issue has been brought > up in a public setting (here, slashdot, etc.) has resulted in terrible press > and even corrective action. In particular, Network Solutions' attempt to > at this at the .com level was corrected. There's two types of in-flight editing of data by a provider: 1) The kind I've requested that they do. 2) The kind they're doing without my knowledge or consent. The first should be monetized, the second needs a really bright flashlight. Why is this distinction so hard for people to comprehend? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rdobbins at arbor.net Thu Nov 26 14:45:22 2009 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 26 Nov 2009 20:45:22 +0000 Subject: What DNS Is Not In-Reply-To: <20091126182548.GB4965@dan.olp.net> References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> <20091125212214.GG5929@dan.olp.net> <22D53292-E4E2-4020-8315-9C31746E2A0F@virtualized.org> <20091126004109.GA11670@dan.olp.net> <96B33E83-1F14-4BEF-A580-BDA72CA6F65C@virtualized.org> <20091126182548.GB4965@dan.olp.net> Message-ID: On Nov 27, 2009, at 2:25 AM, Dan White wrote: > Anytime this issue has been brought up in a public setting (here, slashdot, etc.) has resulted in terrible press > and even corrective action. Does anyone have any idea of the financial 'rewards' SPs who do this kind of thing reap from it? I'm wondering if the money is sufficient for the SPs in question to resist DNSSEC on the grounds that it will 'cost them revenue'. If it isn't, then what's the economic case for doing it in the first place? ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From brunner at nic-naa.net Thu Nov 26 14:55:49 2009 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Thu, 26 Nov 2009 15:55:49 -0500 Subject: What DNS Is Not In-Reply-To: <20091126182548.GB4965@dan.olp.net> References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> <20091125212214.GG5929@dan.olp.net> <22D53292-E4E2-4020-8315-9C31746E2A0F@virtualized.org> <20091126004109.GA11670@dan.olp.net> <96B33E83-1F14-4BEF-A580-BDA72CA6F65C@virtualized.org> <20091126182548.GB4965@dan.olp.net> Message-ID: <4B0EEB55.1030708@nic-naa.net> Dan White wrote: > On 26/11/09 07:37 -0800, David Conrad wrote: >> There are folks on this list who work for ISPs which are doing >> wildcards/synthesis/etc. They (or, more likely their management) can >> tell you there are obvious business reasons why they do >> wildcards/synthesis/etc. Perhaps I'm overly cynical, but I suspect >> that until those business reasons go away, shining a flash light will >> probably just result in more ISPs implementing wildcards/synthesis/etc. > > That's a disagreement we'll have to have. Anytime this issue has been > brought > up in a public setting (here, slashdot, etc.) has resulted in terrible > press > and even corrective action. In particular, Network Solutions' attempt to > at this at the .com level was corrected. Of course I don't know what, if > any, ICANN pressure has to do with that, but the flash light practice was > apparently successful. I do know what, if any, ICANN pressure had to do with that. The pressure on ICANN was real, and the pressure ICANN put on VGRS was sufficient. Eric From drc at virtualized.org Thu Nov 26 15:25:39 2009 From: drc at virtualized.org (David Conrad) Date: Thu, 26 Nov 2009 13:25:39 -0800 Subject: What DNS Is Not In-Reply-To: <56156.1259253459@nsa.vix.com> References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> <56156.1259253459@nsa.vix.com> Message-ID: <3FD64F1D-C7B9-4FBD-8716-390FCE23FBF4@virtualized.org> On Nov 26, 2009, at 8:37 AM, Paul Vixie wrote: >> From: David Conrad >> Date: Thu, 26 Nov 2009 07:42:15 -0800 >> >> As you know, as long as people rely on their ISPs for resolution >> services, DNSSEC isn't going to help. Where things get really offensive >> if when the ISPs _require_ customers (through port 53 blocking, T-Mobile >> Hotspot, I'm looking at you) to use the ISP's resolution services. > > the endgame for provider-in-the-middle attacks is enduser validators, which > is unfortunate since this use case is not well supported by current DNSSEC > and so there's some more protocol work in our future ("noooooooooooo!!"). Why not simply run a validating resolver locally? > i also expect to see DNS carried via HTTPS, which providers tend to leave > alone since they don't want to hear from the lawyers at 1-800-flowers.com. > (so, get ready for https://ns.vix.com/dns/query/www.vix.com/in/a&rd=1&ad=1). To quote you, "noooooooooooo!!" At some point, we may as well bite the bullet and redefine http{,s} as IPv7. Regards, -drc From drc at virtualized.org Thu Nov 26 15:38:48 2009 From: drc at virtualized.org (David Conrad) Date: Thu, 26 Nov 2009 13:38:48 -0800 Subject: What DNS Is Not In-Reply-To: <20091126182548.GB4965@dan.olp.net> References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> <20091125212214.GG5929@dan.olp.net> <22D53292-E4E2-4020-8315-9C31746E2A0F@virtualized.org> <20091126004109.GA11670@dan.olp.net> <96B33E83-1F14-4BEF-A580-BDA72CA6F65C@virtualized.org> <20091126182548.GB4965@dan.olp.net> Message-ID: <386F44B9-8C7C-4185-B3AB-E303A9A26663@virtualized.org> Dan, On Nov 26, 2009, at 10:25 AM, Dan White wrote: > On 26/11/09 07:37 -0800, David Conrad wrote: >> There are folks on this list who work for ISPs which are doing wildcards/synthesis/etc. They (or, more likely their management) can tell you there are obvious business reasons why they do wildcards/synthesis/etc. Perhaps I'm overly cynical, but I suspect that until those business reasons go away, shining a flash light will probably just result in more ISPs implementing wildcards/synthesis/etc. > > That's a disagreement we'll have to have. Anytime this issue has been brought > up in a public setting (here, slashdot, etc.) has resulted in terrible press > and even corrective action. In particular, Network Solutions' attempt to > at this at the .com level was corrected. Right. And since then, ICANN has contractually disallowed gTLD registries from doing SiteFinder like services (unless they can demonstrate such a service won't have a negative security/stability impact). However, as I said, ICANN has no control over what ccTLDs do and there are 12 doing wildcards/synthesis/NXDOMAIN redirection/etc. as I type this, namely: CG (Congo) -- Web redirects to the registry website to register a .CG domain. KR (South Korea) -- If it is a non IDNA-encoded IDN, converts to IDNA. For ASCII, generates a ?fake? page-not-found error for web requests. NU (Niue) -- Web requests solicit you to register the domain. PH (Philippines) -- Web requests solicit you to register the domain. PW (Palau) -- File not found error. Uses an invalid SSL certificate. RW (Rwanda) -- Connection time out (wildcard site is down) ST (Sao Tome) -- Web requests solicit you to register the domain. Uses an invalid SSL certificate. TK (Tokelau) -- Connection refused (wildcard site is down) VG (Virgin Is., UK) -- Web requests solicit you to register the domain. VN (Viet Nam) -- Web requests solicit you to register the domain. WS (Samoa) -- Web requests solicit you to register the domain. CN (China) -- Uses synthesis for IDN labels. Returns NXDOMAIN for ASCII labels. However, that's different than what I thought we were talking about. I thought we were talking about ISPs doing wildcards/synthesis/NXDOMAIN redirection/etc. There are a number of ISPs that do this, some of which are quite well known (there is even an Internet Draft on the techniques, see http://tools.ietf.org/html/draft-livingood-dns-redirect-00). Pretty large flash light... Regards, -drc From vixie at isc.org Thu Nov 26 16:13:44 2009 From: vixie at isc.org (Paul Vixie) Date: Thu, 26 Nov 2009 22:13:44 +0000 Subject: What DNS Is Not In-Reply-To: Your message of "Thu, 26 Nov 2009 13:25:39 PST." <3FD64F1D-C7B9-4FBD-8716-390FCE23FBF4@virtualized.org> References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> <56156.1259253459@nsa.vix.com> <3FD64F1D-C7B9-4FBD-8716-390FCE23FBF4@virtualized.org> Message-ID: <69657.1259273624@nsa.vix.com> > From: David Conrad > Date: Thu, 26 Nov 2009 13:25:39 -0800 > > At some point, we may as well bite the bullet and redefine http{,s} as IPv7. since products and services designed to look inside encrypted streams and inspect, modify, or redirect them are illegal in most parts of the world: "yes, inevitably." From sronan at fattoc.com Thu Nov 26 16:38:43 2009 From: sronan at fattoc.com (Shane Ronan) Date: Thu, 26 Nov 2009 17:38:43 -0500 Subject: Happy Thanksgiving Message-ID: <3467DE56-575D-4CFA-A536-AE10E8038EAD@fattoc.com> Happy Thanksgiving From wbailey at gci.com Thu Nov 26 16:41:06 2009 From: wbailey at gci.com (Warren Bailey) Date: Thu, 26 Nov 2009 13:41:06 -0900 Subject: Happy Thanksgiving Message-ID: <5B3743FC2D0D8B41B27EE4F5EACA79D10C2EA5E6@DTN1EX01.gci.com> I was wondering when someone was gonna tell Paul to go have a stiff drink and relax lol Sent from my Blackberry. Please execute spelling errors. ----- Original Message ----- From: Shane Ronan To: nanog Sent: Thu Nov 26 13:38:43 2009 Subject: Happy Thanksgiving Happy Thanksgiving From chaim.rieger at gmail.com Thu Nov 26 16:45:23 2009 From: chaim.rieger at gmail.com (chaim.rieger at gmail.com) Date: Thu, 26 Nov 2009 22:45:23 +0000 Subject: Happy Thanksgiving Message-ID: <861599695-1259275533-cardhu_decombobulator_blackberry.rim.net-1603777287-@bda630.bisx.prod.on.blackberry> Paul, have a stiff one . Sent via BlackBerry from T-Mobile From sronan at fattoc.com Thu Nov 26 17:34:11 2009 From: sronan at fattoc.com (Shane Ronan) Date: Thu, 26 Nov 2009 18:34:11 -0500 Subject: Happy Thanksgiving In-Reply-To: <5B3743FC2D0D8B41B27EE4F5EACA79D10C2EA5E6@DTN1EX01.gci.com> References: <5B3743FC2D0D8B41B27EE4F5EACA79D10C2EA5E6@DTN1EX01.gci.com> Message-ID: <91F1533B-2F03-47DF-AAE1-A88976F311FA@fattoc.com> The reality is, lets see you create something that ends up being used in a manner wildly different from your intentions, and not be emotional about it. On Nov 26, 2009, at 5:41 PM, Warren Bailey wrote: > I was wondering when someone was gonna tell Paul to go have a stiff drink and relax lol > Sent from my Blackberry. Please execute spelling errors. > > ----- Original Message ----- > From: Shane Ronan > To: nanog > Sent: Thu Nov 26 13:38:43 2009 > Subject: Happy Thanksgiving > > Happy Thanksgiving > > > > > From michael at linuxmagic.com Thu Nov 26 19:06:57 2009 From: michael at linuxmagic.com (Michael Peddemors) Date: Thu, 26 Nov 2009 17:06:57 -0800 Subject: I got a live one! - Spam source In-Reply-To: <20091126125505.GA3569@gsp.org> References: <200911250925.27298.michael@linuxmagic.com> <20091126125505.GA3569@gsp.org> Message-ID: <200911261706.57847.michael@linuxmagic.com> Not to keep endlessly on this thread, but again with reference to good whois record keeping and bad.. 64.21.87.136: mx2.yvzus.com 64.21.87.141: mx3.xmabs.com 64.21.87.168: mx5.zgows.com 64.21.87.170: mx5.zntas.com We know the activity is probably limited to: Found a referral to whois.nac.net:43. NAC-Rwhoisd32 Server Ready - [hydrogen/43] Rwhoisd32 - 1.0.76 Private (NET-40155780-26) 1000 Elliott Ave W Seattle, WA 98119 US OrgID : NAC-40612 Netname : NET-40155780-26 Netblock: 64.21.87.128/26 NetUse : additional loopback ips for 66.246.252.57 Coordinator: Whitaker, Claude washwhitaker at aol.com Phone: 206-407-3201 67.229.101.206: hikmvo.leadingsolutionlinks.com 67.229.101.207: noqo.leadingsolutionlinks.com 67.229.101.208: rqecf.leadingsolutionlinks.com We know that the activity is probably limited to: VPLS Inc. d/b/a Krypt Technologies VPLSNET (NET-67-229-0-0-1) 67.229.0.0 - 67.229.255.255 Roy Diaz ROY (NET-67-229-96-0-1) 67.229.96.0 - 67.229.111.255 (Other than VPLS/Krypt seems to really like these type of customers) 70.97.119.58: mail1.ugallshwomange.com 70.97.119.59: mail1.ugouricarali.com 70.97.119.60: mail1.utanonesiana.com 70.97.119.61: mail1.vatetricarkose.com 70.97.119.62: mail1.venesiandsgu.com 70.97.119.63: mail1.viandslahass.com 70.97.119.64: mail1.vientianarica.com 70.97.119.65: mail1.vientuckyan.com Integra Telecom, Inc. ELI-NETWORK-ELIX (NET-70-96-0-0-1) 70.96.0.0 - 70.99.255.255 Syptec ITCM-70-97-118-0-23 (NET-70-97-118-0-1) 70.97.118.0 - 70.97.119.255 This is a /23 but with Syptec's record... They sure like opening ranges to email marketers first :) Unless Syptec is operating those machines themselves.. but in that class C all the IP's don't appear to start on a normal boundary, .35-.65 with all the rest of the IP's having no reverse DNS. Does this client of theirs have control over the whole /23 or just a part? 205.251.11.130: loneas41.instantcasheasynow.com 205.251.11.163: lon69.instantcasheasynow.com 205.251.11.70: lon83.instantcasheasynow.com 205.251.7.144: click37.fallcreditcash.com 205.251.7.204: track42.fallcreditcash.com 205.251.7.253: click14.fallcreditcash.com 205.251.7.99: track4.fallcreditcash.com InfoRelay Online Systems, Inc. INFORELAY-EST-02 (NET-205-251-0-0-1) 205.251.0.0 - 205.251.127.255 Reaction54 REACT54-03 (NET-205-251-8-0-1) 205.251.8.0 - 205.251.15.255 Is this two different clients on Reaction54, or is this Reaction54 themselves? I think you have to assume the later based on this whois information.. Especially when you see that the whole class C has the same naming patterns. 216.52.246.253: host6.chemistryearth.com 216.52.246.254: host6.consecutiveworld.com Internap Network Services Corporation PNAP-8-98 (NET-216-52-0-0-1) 216.52.0.0 - 216.52.255.255 Aurora Networking INAP-LAX-AURORA-34937 (NET-216-52-246-0-1) 216.52.246.0 - 216.52.246.255 More companies on Internap, but at least we know exactly what range is owned by this company.. We can just look at the one class 'C'. And of course we can see that this is quite typical right across the range.. 218.213.228.76: ad-a11.pointdnshere.com 218.213.228.92: ns193.pointdnshere.com Ummm.. we can't say the same operator is using all of these can we? inetnum: 218.213.0.0 - 218.213.255.255 netname: HKNET-HK descr: HKNet Company Limited descr: 15/F, Tower 2, Ever Gain Plaza, descr: 88 Container Port Road, Kwai Chung, N.T. country: HK And if we guessed, and said the same behavior was across the board, we would be hurting the poor guy on that class C in the top of the range.. (Oh, yeah.. I know.. I threw that last example to show that this isn't just a North American problem) On November 26, 2009, Rich Kulawiec wrote: > On Wed, Nov 25, 2009 at 09:25:27AM -0800, Michael Peddemors wrote: > > I here people saying that they don't publish whois information because > > they don't want the email's made public. Okay, at least the registered > > company name, or individual who presented the ID should be there. > > Without delving too far into this: there is no point whatsoever in > attempting to conceal or obfuscate email addresses --not any more. It is > an obsolete, "cargo cult" practice that many are still engaged in without > grasping that it was quite thoroughly defeated by spammers and their > associates years ago. > > That said, I concur in full with your opinions in re whois data and > the need to assign it properly. I've long since stopped trying to > deal with missing information and have adopted the rule that if the > neighborhood looks sufficiently bad, I just block a /24 worth. That > may sound arbitrary, but in practice it works extremely well. > > ---Rsk > -- -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors - President/CEO - LinuxMagic Products, Services, Support and Development Visit us at http://www.linuxmagic.com ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-589-0037 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From devangnp at gmail.com Thu Nov 26 21:51:52 2009 From: devangnp at gmail.com (devang patel) Date: Thu, 26 Nov 2009 20:51:52 -0700 Subject: Multicast LDP or P2MP RSVP & LDP In-Reply-To: <74EE85F3-DA7C-4C85-976A-CF8E4B70006B@juniper.net> References: <74EE85F3-DA7C-4C85-976A-CF8E4B70006B@juniper.net> Message-ID: Brendan, Thanks for your reply and link. Do you have any good white paper or scenario based example to share? Thanks, Devang On Thu, Nov 26, 2009 at 7:45 PM, Brendan Kelly wrote: > Devang here is our guide. > > > http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-vpns/vpns-configuring-point-to-multipoint-lsps-for-multicast-vpns.html#jd0e38149 > > Thanks > Brendan > On Nov 26, 2009, at 12:53 AM, devang patel wrote: > > > Rob, > > > > Can you share some documentation with me on how to configure as well as > any > > kind of configuration example will be great help. > > > > Thanks, > > Devang > > > > On Thu, Nov 26, 2009 at 12:46 AM, Rob Shakir wrote: > > > >> > >> On 26 Nov 2009, at 06:27, devang patel wrote: > >> > >> Hi All, > >>> > >>> I just want to know about the deployment of Multicast LDP or P2MP RSVP > and > >>> LDP is available from any vendor or they are still in draft status? > >>> > >> > >> Hi Devang, > >> > >> To the best of my knowledge, the only current P2MP LSP implementation > >> available is in JunOS [0]. The guys at Juniper wrote a draft relating to > >> their experience with scaling and implementing P2MP MVPN [1], which is > worth > >> a look -- this draft mentions that IOS XR has an implementation, > although I > >> struggled to find any documentation that confirms this. > >> > >> Both the LDP-based [2] P2MP standard are still in draft status, but the > >> extensions required in RSVP-TE for signalling P2MP paths are in RFC4875 > [3]. > >> > >> From a couple of discussions I've had, there are not very many people > using > >> this functionality -- with most common application being IPTV. For > >> traditional transport of multicast over an SP core, it's often easier to > >> provide some AToM/L2VPN service. > >> > >> Hope this helps somewhat. > >> > >> Kind regards, > >> Rob > >> > >> [0]: > >> > http://www.juniper.net/techpubs/software/junos/junos91/feature-guide/configuring-traffic-engineering-p2mp-lsps-in-provider-tunnels.html > >> [1]: http://tools.ietf.org/html/draft-joseph-p2mp-mvpn-experience-00 > >> [2]: http://tools.ietf.org/html/draft-ietf-mpls-ldp-p2mp-08 > >> [3]: http://tools.ietf.org/html/rfc4875 > >> > >> -- > >> Rob Shakir > >> Network Development Engineer GX Networks/Vialtus Solutions > >> ddi: +44208 587 6077 mob: +44797 155 4098 > >> pgp: 0xc07e6deb nic-hdl: RJS-RIPE > >> > >> This email is subject to: http://www.vialtus.com/disclaimer.html > >> > >> > >> > >> > > From mysidia at gmail.com Thu Nov 26 21:57:46 2009 From: mysidia at gmail.com (James Hess) Date: Thu, 26 Nov 2009 21:57:46 -0600 Subject: What DNS Is Not In-Reply-To: <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> Message-ID: <6eb799ab0911261957q63b81ef6m961c156ef8eef029@mail.gmail.com> On Wed, Nov 25, 2009 at 2:58 PM, Jorge Amodio wrote: [snip] > What needs to be done to have ISPs and other service providers stop tampering > with DNS ? Well, NXDOMAIN substitution, on ISP provided DNS servers, is not "tampering with DNS", anymore than spam/virus filtering/attachment limits, disk quotas, or message expiration on ISP mail servers is "tampering with E-mail", It's ISPs providing their customers with a modified service. Their DNS resolvers, their terms. They _could_ accomplish similar by requiring all their customers utilize a custom web browser, but that would be less convenient. "Tampering with DNS" would be hijacking port 53 UDP packets a customer sent directly to an outside authoritative DNS server, and substituting their own answer. That would be very harmful, especially if the ISP customer is attempting to troubleshoot a DNS issue... Just because someone registered EXAMPLE.COM with one particular internet registry, doesn't mean they own the lookup result for every DNS server in the world. All they have paid for is the creation and maintenance of entries in one particular shared database, and they only have control for the (large) subset of DNS servers that utilize that particular database. People can start new DNS roots, old DNS roots can be superceded, there can even be multiple conflicting private roots. In the long run, the only method to discourage might be a form of blacklisting. If major DNS hosting providers discriminate in the authoritative replies they give, based on asker: *If the IP asking for a DNS record is in the IP range of an ISP that you know substitutes NXDOMAINs with their own reply, then you discriminate against that DNS query source, and don't give them NXDOMAINs. *Why hand them a NXDOMAIN response that they will just substitute? If major DNS providers barred the ISP's overall range from getting any NXDOMAIN replies from the authoritative nameservers, then the ISP would derive no benefit from substituting them, since their acts caused them to be deemed unfit to receive NXDOMAIN responses at all. In addition, their now lack of ability to get NXDOMAIN responses, could be an inconvenience to them, esp. in the operation of mail servers, since latency of certain mail server DNS requests will increase, due to the delay to time out the query (that would be NXDOMAIN if they were allowed to receive NXDOMAIN). *That is: always reply SERVFAIL or send no reply to such blacklisted IP ranges, when the database entry doesn't exist, instead of NXDOMAIN. However, it doesn't really penalize the NXDOMAIN substitution practice too much, unless the root and TLD servers also implement the blacklisting, it only deprives them of benefit. -- As for ccTLDs performing wildcarding, One could consider patches to recursive resolvers to detect the IPs that are wildcarding, and substitute responses detected as the wildcard host IP addresses, with NXDOMAIN. For example, randomly generate 2 test lookups for domains that are unlikely to exist, eg afut429.ahfeai4728.xyz.xx . If both randomized lookups return A record responses for the same IP addresses, then you detected the wildcard method used by that ccTLD. Substitute NXDOMAIN in for any responses for the ccTLD that respond with the same list of A records. In other words: retaliating against NXDOMAIN substitution, by substituting response with those IPs back to NXDOMAIN. -- -J From mmc at internode.com.au Thu Nov 26 22:05:15 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Fri, 27 Nov 2009 14:35:15 +1030 Subject: Happy Thanksgiving In-Reply-To: <91F1533B-2F03-47DF-AAE1-A88976F311FA@fattoc.com> References: <5B3743FC2D0D8B41B27EE4F5EACA79D10C2EA5E6@DTN1EX01.gci.com> <91F1533B-2F03-47DF-AAE1-A88976F311FA@fattoc.com> Message-ID: I think most fathers who have daughters have that happen when they start going out with boys ... Happy Thanksgiving USA people. MMC On 27/11/2009, at 10:04 AM, Shane Ronan wrote: > The reality is, lets see you create something that ends up being used in a manner wildly different from your intentions, and not be emotional about it. > > On Nov 26, 2009, at 5:41 PM, Warren Bailey wrote: > >> I was wondering when someone was gonna tell Paul to go have a stiff drink and relax lol >> Sent from my Blackberry. Please execute spelling errors. >> >> ----- Original Message ----- >> From: Shane Ronan >> To: nanog >> Sent: Thu Nov 26 13:38:43 2009 >> Subject: Happy Thanksgiving >> >> Happy Thanksgiving >> >> >> >> >> > > -- Matthew Moyle-Croft Peering Manager and Team Lead - Commercial and DSLAMs Internode /Agile From Valdis.Kletnieks at vt.edu Fri Nov 27 10:51:29 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 27 Nov 2009 11:51:29 -0500 Subject: What DNS Is Not In-Reply-To: Your message of "Thu, 26 Nov 2009 21:57:46 CST." <6eb799ab0911261957q63b81ef6m961c156ef8eef029@mail.gmail.com> References: <20091119173153.F342645@resin18.mta.everyone.net> <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar> <200911200203.nAK23DHI072927@drugs.dv.isc.org> <202705b0911191830g5c8d566ta54eb2a1e65d5af5@mail.gmail.com> <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com> <6eb799ab0911261957q63b81ef6m961c156ef8eef029@mail.gmail.com> Message-ID: <133958.1259340689@turing-police.cc.vt.edu> On Thu, 26 Nov 2009 21:57:46 CST, James Hess said: > Just because someone registered EXAMPLE.COM with one particular > internet registry, doesn't mean they own the lookup result for every > DNS server in the world. All they have paid for is the creation > and maintenance of entries in one particular shared database, and > they only have control for the (large) subset of DNS servers that > utilize that particular database. > > People can start new DNS roots, old DNS roots can be superceded, > there can even be multiple conflicting private roots. Those who didn't read RFC2826 are condemned to repeat it. Of course, it's *your* help desk that gets to answer the phone and explain to your users why www.giraffes-r-us.com went to a nice page of cute pictures of giraffes when they were at Starbucks, but when they got home to show their kids, it was giraffe pr0n. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From cscora at apnic.net Fri Nov 27 12:36:54 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 28 Nov 2009 04:36:54 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200911271836.nARIas8A011334@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 28 Nov, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 304342 Prefixes after maximum aggregation: 142008 Deaggregation factor: 2.14 Unique aggregates announced to Internet: 150155 Total ASes present in the Internet Routing Table: 32808 Prefixes per ASN: 9.28 Origin-only ASes present in the Internet Routing Table: 28489 Origin ASes announcing only one prefix: 13901 Transit ASes present in the Internet Routing Table: 4319 Transit-only ASes present in the Internet Routing Table: 103 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 39 Max AS path prepend of ASN (22394) 36 Prefixes from unregistered ASNs in the Routing Table: 690 Unregistered ASNs in the Routing Table: 150 Number of 32-bit ASNs allocated by the RIRs: 338 Prefixes from 32-bit ASNs in the Routing Table: 278 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 206 Number of addresses announced to Internet: 2137469824 Equivalent to 127 /8s, 103 /16s and 51 /24s Percentage of available address space announced: 57.7 Percentage of allocated address space announced: 65.4 Percentage of available address space allocated: 88.2 Percentage of address space in use by end-sites: 80.2 Total number of prefixes smaller than registry allocations: 146251 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 72689 Total APNIC prefixes after maximum aggregation: 25380 APNIC Deaggregation factor: 2.86 Prefixes being announced from the APNIC address blocks: 69408 Unique aggregates announced from the APNIC address blocks: 30885 APNIC Region origin ASes present in the Internet Routing Table: 3882 APNIC Prefixes per ASN: 17.88 APNIC Region origin ASes announcing only one prefix: 1062 APNIC Region transit ASes present in the Internet Routing Table: 595 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 23 Number of APNIC addresses announced to Internet: 482336544 Equivalent to 28 /8s, 191 /16s and 223 /24s Percentage of available APNIC address space announced: 79.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 43/8, 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, 133/8, 175/8, 180/8, 182/8, 183/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: 128214 Total ARIN prefixes after maximum aggregation: 67287 ARIN Deaggregation factor: 1.91 Prefixes being announced from the ARIN address blocks: 102380 Unique aggregates announced from the ARIN address blocks: 38817 ARIN Region origin ASes present in the Internet Routing Table: 13369 ARIN Prefixes per ASN: 7.66 ARIN Region origin ASes announcing only one prefix: 5172 ARIN Region transit ASes present in the Internet Routing Table: 1330 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 39 Number of ARIN addresses announced to Internet: 731696160 Equivalent to 43 /8s, 156 /16s and 204 /24s Percentage of available ARIN address space announced: 64.1 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 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/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, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 70605 Total RIPE prefixes after maximum aggregation: 41017 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 63782 Unique aggregates announced from the RIPE address blocks: 42335 RIPE Region origin ASes present in the Internet Routing Table: 13820 RIPE Prefixes per ASN: 4.62 RIPE Region origin ASes announcing only one prefix: 7179 RIPE Region transit ASes present in the Internet Routing Table: 2082 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 20 Number of RIPE addresses announced to Internet: 405627328 Equivalent to 24 /8s, 45 /16s and 97 /24s Percentage of available RIPE address space announced: 75.6 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-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 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, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 26457 Total LACNIC prefixes after maximum aggregation: 6452 LACNIC Deaggregation factor: 4.10 Prefixes being announced from the LACNIC address blocks: 24770 Unique aggregates announced from the LACNIC address blocks: 13634 LACNIC Region origin ASes present in the Internet Routing Table: 1214 LACNIC Prefixes per ASN: 20.40 LACNIC Region origin ASes announcing only one prefix: 394 LACNIC Region transit ASes present in the Internet Routing Table: 201 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 23 Number of LACNIC addresses announced to Internet: 68329472 Equivalent to 4 /8s, 18 /16s and 160 /24s Percentage of available LACNIC address space announced: 67.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 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: 5868 Total AfriNIC prefixes after maximum aggregation: 1557 AfriNIC Deaggregation factor: 3.77 Prefixes being announced from the AfriNIC address blocks: 4252 Unique aggregates announced from the AfriNIC address blocks: 1436 AfriNIC Region origin ASes present in the Internet Routing Table: 333 AfriNIC Prefixes per ASN: 12.77 AfriNIC Region origin ASes announcing only one prefix: 94 AfriNIC Region transit ASes present in the Internet Routing Table: 70 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 13325568 Equivalent to 0 /8s, 203 /16s and 85 /24s Percentage of available AfriNIC address space announced: 39.7 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1767 7507 461 Korea Telecom (KIX) 17488 1447 143 133 Hathway IP Over Cable Interne 4755 1278 296 148 TATA Communications formerly 4134 1013 19459 395 CHINANET-BACKBONE 9583 1007 75 495 Sify Limited 18101 984 204 35 Reliance Infocom Ltd Internet 7545 911 198 98 TPG Internet Pty Ltd 17974 861 265 60 PT TELEKOMUNIKASI INDONESIA 9829 848 664 24 BSNL National Internet Backbo 24560 806 293 175 Bharti Airtel Ltd., Telemedia 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 4244 3879 311 bellsouth.net, inc. 4323 3751 1069 399 Time Warner Telecom 1785 1780 714 136 PaeTec Communications, Inc. 7018 1589 5808 1034 AT&T WorldNet Services 20115 1520 1483 666 Charter Communications 2386 1297 632 933 AT&T Data Communications Serv 3356 1229 10966 447 Level 3 Communications, LLC 6478 1188 251 315 AT&T Worldnet Services 11492 1142 222 14 Cable One 22773 1123 2600 66 Cox Communications, Inc. 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 30890 514 98 207 Evolva Telecom 9198 471 138 12 Kazakhtelecom Data Network Ad 35805 467 40 5 United Telecom of Georgia 3292 448 1906 393 TDC Tele Danmark 702 417 1837 335 UUNET - Commercial IP service 8551 377 354 41 Bezeq International 8866 371 110 23 Bulgarian Telecommunication C 3320 358 7067 304 Deutsche Telekom AG 3215 349 3144 111 France Telecom Transpac 3301 347 1427 303 TeliaNet Sweden 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 1567 2899 233 UniNet S.A. de C.V. 10620 1004 224 138 TVCABLE BOGOTA 28573 814 666 82 NET Servicos de Comunicao S.A 7303 664 350 95 Telecom Argentina Stet-France 22047 546 302 14 VTR PUNTO NET S.A. 11830 474 308 59 Instituto Costarricense de El 11172 445 99 70 Servicios Alestra S.A de C.V 14117 437 29 11 Telefonica del Sur S.A. 7738 431 858 29 Telecomunicacoes da Bahia S.A 6503 424 162 184 AVANTEL, 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 8452 1022 188 7 TEDATA 24863 753 130 46 LINKdotNET AS number 3741 274 857 234 The Internet Solution 2018 190 188 118 Tertiary Education Network 6713 176 167 12 Itissalat Al-MAGHRIB 29975 134 506 15 Vodacom 29571 133 15 8 Ci Telecom Autonomous system 33776 124 7 11 Starcomms Nigeria Limited 5536 121 8 18 Internet Egypt Network 5713 116 508 67 Telkom SA Ltd 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 4244 3879 311 bellsouth.net, inc. 4323 3751 1069 399 Time Warner Telecom 1785 1780 714 136 PaeTec Communications, Inc. 4766 1767 7507 461 Korea Telecom (KIX) 7018 1589 5808 1034 AT&T WorldNet Services 8151 1567 2899 233 UniNet S.A. de C.V. 20115 1520 1483 666 Charter Communications 17488 1447 143 133 Hathway IP Over Cable Interne 2386 1297 632 933 AT&T Data Communications Serv 4755 1278 296 148 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3751 3352 Time Warner Telecom 1785 1780 1644 PaeTec Communications, Inc. 8151 1567 1334 UniNet S.A. de C.V. 17488 1447 1314 Hathway IP Over Cable Interne 4766 1767 1306 Korea Telecom (KIX) 4755 1278 1130 TATA Communications formerly 11492 1142 1128 Cable One 22773 1123 1057 Cox Communications, Inc. 18566 1059 1049 Covad Communications 8452 1022 1015 TEDATA 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 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 46.0.0.0/16 12654 RIPE NCC RIS Project 46.1.0.0/21 12654 RIPE NCC RIS Project 46.1.24.0/24 12654 RIPE NCC RIS Project 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 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:10 /10:25 /11:65 /12:178 /13:363 /14:642 /15:1224 /16:10738 /17:4984 /18:8576 /19:17619 /20:21420 /21:21367 /22:27577 /23:27485 /24:159184 /25:923 /26:1129 /27:569 /28:217 /29:11 /30:8 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2776 4244 bellsouth.net, inc. 4323 2367 3751 Time Warner Telecom 4766 1435 1767 Korea Telecom (KIX) 1785 1247 1780 PaeTec Communications, Inc. 17488 1220 1447 Hathway IP Over Cable Interne 11492 1064 1142 Cable One 18566 1040 1059 Covad Communications 7018 954 1589 AT&T WorldNet Services 8452 920 1022 TEDATA 10620 909 1004 TVCABLE BOGOTA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 2:1 4:14 8:236 12:2056 13:8 15:22 16:3 17:5 20:36 24:1269 32:49 34:2 38:621 40:99 41:1783 43:1 44:2 46:1 47:20 52:6 55:2 56:2 57:23 58:640 59:611 60:445 61:977 62:958 63:2005 64:3696 65:2365 66:4076 67:1782 68:1002 69:2817 70:630 71:156 72:1755 73:2 74:2014 75:188 76:355 77:849 78:601 79:388 80:944 81:815 82:475 83:439 84:528 85:1010 86:381 87:687 88:443 89:1576 90:63 91:2658 92:447 93:1153 94:1332 95:833 96:201 97:276 98:425 99:27 109:171 110:274 111:466 112:151 113:180 114:277 115:382 116:1086 117:594 118:366 119:802 120:139 121:702 122:1308 123:793 124:1056 125:1353 128:214 129:203 130:134 131:453 132:82 133:16 134:187 135:41 136:232 137:166 138:236 139:84 140:461 141:122 142:381 143:339 144:384 145:52 146:392 147:171 148:558 149:192 150:149 151:172 152:219 153:161 154:2 155:273 156:166 157:314 158:98 159:360 160:294 161:175 162:277 163:163 164:316 165:469 166:490 167:391 168:753 169:159 170:559 171:42 172:1 173:394 174:401 180:202 183:134 184:1 186:185 187:172 188:1354 189:635 190:3283 192:5736 193:4311 194:3354 195:2769 196:1181 198:3568 199:3385 200:5251 201:1408 202:7921 203:8267 204:3982 205:2156 206:2413 207:3042 208:3970 209:3396 210:2531 211:1152 212:1648 213:1614 214:245 215:57 216:4438 217:1360 218:474 219:419 220:1139 221:447 222:300 End of report From cidr-report at potaroo.net Fri Nov 27 16:00:02 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 27 Nov 2009 22:00:02 GMT Subject: BGP Update Report Message-ID: <200911272200.nARM029m047519@wattle.apnic.net> BGP Update Report Interval: 19-Nov-09 -to- 26-Nov-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8452 22278 2.6% 34.4 -- TEDATA TEDATA 2 - AS7643 15001 1.7% 53.4 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 3 - AS30890 11880 1.4% 23.1 -- EVOLVA Evolva Telecom s.r.l. 4 - AS16814 8777 1.0% 17.9 -- NSS S.A. 5 - AS9829 7909 0.9% 22.7 -- BSNL-NIB National Internet Backbone 6 - AS34984 7370 0.9% 30.2 -- TELLCOM-AS Tellcom Iletisim Hizmetleri 7 - AS23700 6701 0.8% 18.5 -- BM-AS-ID PT. Broadband Multimedia, Tbk 8 - AS21826 6699 0.8% 25.2 -- Internet Cable Plus C. A. 9 - AS8551 6016 0.7% 35.2 -- BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbone 10 - AS8386 5997 0.7% 49.2 -- KOCNET KOCNET-AS 11 - AS7738 5595 0.7% 12.4 -- Telecomunicacoes da Bahia S.A. 12 - AS35805 5570 0.7% 10.9 -- UTG-AS United Telecom AS 13 - AS5800 5381 0.6% 29.2 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 14 - AS17974 5141 0.6% 9.6 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 15 - AS24863 5025 0.6% 14.4 -- LINKdotNET-AS 16 - AS39386 4614 0.5% 354.9 -- STC-IGW-AS Saudi Telecom Company 17 - AS28477 4576 0.5% 508.4 -- Universidad Autonoma del Esstado de Morelos 18 - AS17819 4538 0.5% 2269.0 -- ASN-EQUINIX-AP Equinix Asia Pacific 19 - AS48754 4442 0.5% 4442.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 20 - AS17964 4042 0.5% 33.7 -- DXTNET Beijing Dian-Xin-Tong Network Technologies Co., Ltd. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS48754 4442 0.5% 4442.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 2 - AS36239 2884 0.3% 2884.0 -- EXIGEN-CANADA - Exigen Canada 3 - AS5691 2372 0.3% 2372.0 -- MITRE-AS-5 - The MITRE Corporation 4 - AS17819 4538 0.5% 2269.0 -- ASN-EQUINIX-AP Equinix Asia Pacific 5 - AS14251 1203 0.1% 1203.0 -- MLSLI - Multiple Lising Service of Long Island, Inc. 6 - AS41060 874 0.1% 874.0 -- PRIMBANK-AS Joint-Stock Commercial Bank Primorye 7 - AS39803 1527 0.2% 763.5 -- UTI-AS SC UTI COMMUNICATIONS SYSTEMS SRL 8 - AS39342 755 0.1% 755.0 -- MEDIATRAFFIC Mediatraffic Oy as-number 9 - AS42182 735 0.1% 735.0 -- KFMC-ASN AS Number for King Fahd Medical City 10 - AS31699 3754 0.4% 625.7 -- BANK-AL-JAZIRA-AS bank al jazira aut.name 11 - AS22917 1236 0.1% 618.0 -- INFOCHANNEL ASN-INFOCHAN 12 - AS32738 3494 0.4% 582.3 -- ASPCCCINC - PCC Communications Inc. 13 - AS28477 4576 0.5% 508.4 -- Universidad Autonoma del Esstado de Morelos 14 - AS6550 498 0.1% 498.0 -- SBSERVICES-AS - Softbank Services Group 15 - AS31496 365 0.0% 365.0 -- ATNET-AS ATNET Autonomous System 16 - AS39386 4614 0.5% 354.9 -- STC-IGW-AS Saudi Telecom Company 17 - AS29544 666 0.1% 333.0 -- MAURITEL-AS 18 - AS12732 626 0.1% 313.0 -- bbTT GmbH 19 - AS11613 304 0.0% 304.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 20 - AS3 302 0.0% 143.0 -- GAMELINE LLC "Game-line International" TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 203.162.118.128/ 4840 0.5% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 2 - 200.13.36.0/24 4560 0.5% AS28477 -- Universidad Autonoma del Esstado de Morelos 3 - 91.212.23.0/24 4442 0.5% AS48754 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 4 - 202.167.247.0/24 3323 0.3% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 5 - 222.255.186.0/25 3114 0.3% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 6 - 72.28.75.0/24 2884 0.3% AS36239 -- EXIGEN-CANADA - Exigen Canada 7 - 222.255.186.192/ 2624 0.3% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 8 - 222.255.186.128/ 2624 0.3% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 9 - 192.12.120.0/24 2372 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 10 - 212.253.4.0/24 2076 0.2% AS6822 -- SUPERONLINE-AS SuperOnline autonomous system 11 - 143.138.107.0/24 1406 0.1% AS747 -- TAEGU-AS - Headquarters, USAISC 12 - 202.177.223.0/24 1215 0.1% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 13 - 90.150.0.0/24 1214 0.1% AS35400 -- MFIST Interregoinal Organization Network Technologies 14 - 65.223.235.0/24 1203 0.1% AS14251 -- MLSLI - Multiple Lising Service of Long Island, Inc. 15 - 67.201.89.0/24 1103 0.1% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 16 - 84.235.0.0/17 1026 0.1% AS39386 -- STC-IGW-AS Saudi Telecom Company 17 - 140.217.157.0/24 898 0.1% AS145 -- VBNS - MCI Communications Corporation 18 - 91.213.113.0/24 874 0.1% AS41060 -- PRIMBANK-AS Joint-Stock Commercial Bank Primorye 19 - 195.189.138.0/23 816 0.1% AS39803 -- UTI-AS SC UTI COMMUNICATIONS SYSTEMS SRL 20 - 209.136.29.0/24 802 0.1% AS10445 -- HTG - Huntleigh Telcom 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 Nov 27 16:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 27 Nov 2009 22:00:00 GMT Subject: The Cidr Report Message-ID: <200911272200.nARM00fO047513@wattle.apnic.net> This report has been generated at Fri Nov 27 21:11:23 2009 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 20-11-09 308769 190601 21-11-09 308772 190604 22-11-09 308853 190692 23-11-09 309016 191246 24-11-09 309137 191608 25-11-09 309330 191781 26-11-09 309536 191824 27-11-09 309743 191828 AS Summary 32976 Number of ASes in routing system 14019 Number of ASes announcing only one prefix 4351 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 92605376 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 27Nov09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 309895 191858 118037 38.1% All ASes AS6389 4244 318 3926 92.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4351 1940 2411 55.4% TWTC - tw telecom holdings, inc. AS1785 1780 313 1467 82.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS4766 1884 586 1298 68.9% KIXS-AS-KR Korea Telecom AS17488 1447 289 1158 80.0% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 1123 71 1052 93.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1569 663 906 57.7% Uninet S.A. de C.V. AS4755 1278 399 879 68.8% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS19262 1045 237 808 77.3% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8452 1022 286 736 72.0% TEDATA TEDATA AS18101 985 313 672 68.2% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS6478 1188 560 628 52.9% ATT-INTERNET3 - AT&T WorldNet Services AS10620 1004 382 622 62.0% TV Cable S.A. AS3356 1230 648 582 47.3% LEVEL3 Level 3 Communications AS4808 764 195 569 74.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS9498 654 87 567 86.7% BBIL-AP BHARTI Airtel Ltd. AS4804 635 72 563 88.7% MPX-AS Microplex PTY LTD AS4134 1013 451 562 55.5% CHINANET-BACKBONE No.31,Jin-rong Street AS7303 664 102 562 84.6% Telecom Argentina S.A. AS7018 1589 1035 554 34.9% ATT-INTERNET4 - AT&T WorldNet Services AS18566 1059 510 549 51.8% COVAD - Covad Communications Co. AS22047 546 49 497 91.0% VTR BANDA ANCHA S.A. AS11492 1142 649 493 43.2% CABLEONE - CABLE ONE, INC. AS4780 616 152 464 75.3% SEEDNET Digital United Inc. AS9443 533 81 452 84.8% INTERNETPRIMUS-AS-AP Primus Telecommunications AS28573 816 368 448 54.9% NET Servicos de Comunicao S.A. AS17676 564 129 435 77.1% GIGAINFRA Softbank BB Corp. AS5668 787 355 432 54.9% AS-5668 - CenturyTel Internet Holdings, Inc. AS855 615 188 427 69.4% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS7011 1036 629 407 39.3% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. Total 37183 12057 25126 67.6% Top 30 total Possible Bogus Routes 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 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 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 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-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.57.208.0/24 AS22662 69.57.209.0/24 AS22662 69.57.210.0/24 AS22662 69.57.211.0/24 AS22662 69.57.212.0/24 AS22662 69.57.213.0/24 AS22662 69.57.214.0/24 AS22662 69.57.215.0/24 AS22662 69.57.216.0/24 AS22662 69.57.217.0/24 AS22662 69.57.218.0/24 AS22662 69.57.219.0/24 AS22662 69.57.220.0/24 AS22662 69.57.221.0/24 AS22662 69.57.222.0/24 AS22662 69.57.223.0/24 AS22662 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 95.215.108.0/22 AS48924 VOLSBUD-NET BMP VolsBud Ltd 96.8.64.0/18 AS19166 ACRONOC - ACRONOC INC 96.8.127.0/24 AS19166 ACRONOC - ACRONOC INC 98.142.112.0/20 AS3257 TINET-BACKBONE Tinet SpA 117.103.72.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.10.0/24 AS38236 121.50.13.0/24 AS38236 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 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.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 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 193.33.148.0/23 AS30890 EVOLVA Evolva Telecom s.r.l. 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.207.128.0/20 AS26452 BRING-AS - BringCom, Inc. 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.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc. 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc. 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 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - 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 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 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.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet 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.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 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.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.143.56.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 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.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.86.96.0/19 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 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/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.108.96.0/19 AS577 BACOM - Bell Canada 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.189.62.0/23 AS7132 SBIS-AS - AT&T Internet Services 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.88.0/21 AS36835 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.224.0/24 AS36835 208.77.225.0/24 AS36835 208.77.226.0/24 AS36835 208.77.227.0/24 AS36835 208.77.228.0/24 AS36835 208.77.229.0/24 AS36835 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.77.230.0/24 AS36835 208.77.231.0/24 AS36835 208.87.152.0/21 AS25973 MZIMA - Mzima Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 213.181.70.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.80.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.81.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.83.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.84.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.85.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.86.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.87.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.88.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.89.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.90.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.91.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.92.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.93.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.94.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 213.181.95.0/24 AS16422 NEWSKIES-NETWORKS SES World Skies ARIN AS, for routing Talia (AS42705) IP space. 216.37.96.0/24 AS40096 216.37.97.0/24 AS40096 216.37.98.0/24 AS40096 216.37.99.0/24 AS40096 216.37.100.0/24 AS40096 216.37.101.0/24 AS40096 216.37.102.0/24 AS40096 216.37.103.0/24 AS40096 216.37.104.0/24 AS40096 216.37.105.0/24 AS40096 216.37.106.0/24 AS40096 216.37.107.0/24 AS40096 216.37.108.0/24 AS40096 216.37.109.0/24 AS40096 216.37.110.0/24 AS40096 216.37.111.0/24 AS40096 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, 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.251.207.0/24 AS1239 SPRINTLINK - Sprint 222.0.0.0/8 AS9484 MOBINET-AS-MN Mobicom Company. AS Mobinet Internet Service Provider 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 ml at kenweb.org Fri Nov 27 21:43:35 2009 From: ml at kenweb.org (ML) Date: Fri, 27 Nov 2009 22:43:35 -0500 Subject: Finding asymmetric path Message-ID: <4B109C67.3040808@kenweb.org> I'm reasonable certain a customer of ours who is using one of our netblocks is using a different reverse path to reach us. How might I figure out who is allowing them to source traffic from IPs that belong to us? From randy at psg.com Fri Nov 27 22:08:40 2009 From: randy at psg.com (Randy Bush) Date: Sat, 28 Nov 2009 13:08:40 +0900 Subject: Finding asymmetric path In-Reply-To: <4B109C67.3040808@kenweb.org> References: <4B109C67.3040808@kenweb.org> Message-ID: > I'm reasonable certain a customer of ours who is using one of our > netblocks is using a different reverse path to reach us. How might I > figure out who is allowing them to source traffic from IPs that belong > to us? you are implying that they are not allowed to multi-home using the ip space you have assigned to them. good way to lose a customer. randy From ml at kenweb.org Fri Nov 27 22:14:18 2009 From: ml at kenweb.org (ML) Date: Fri, 27 Nov 2009 23:14:18 -0500 Subject: Finding asymmetric path In-Reply-To: References: <4B109C67.3040808@kenweb.org> Message-ID: <4B10A39A.1090202@kenweb.org> Randy Bush wrote: >> I'm reasonable certain a customer of ours who is using one of our >> netblocks is using a different reverse path to reach us. How might I >> figure out who is allowing them to source traffic from IPs that belong >> to us? > > you are implying that they are not allowed to multi-home using the ip > space you have assigned to them. good way to lose a customer. > > randy Does it count as multihoming when we are the only ones announcing the space? From sfouant at shortestpathfirst.net Fri Nov 27 22:16:29 2009 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Fri, 27 Nov 2009 23:16:29 -0500 Subject: Finding asymmetric path In-Reply-To: <4B109C67.3040808@kenweb.org> References: <4B109C67.3040808@kenweb.org> Message-ID: <000d01ca6fe1$8fa1f0c0$aee5d240$@net> > -----Original Message----- > From: ML [mailto:ml at kenweb.org] > Sent: Friday, November 27, 2009 10:44 PM > > I'm reasonable certain a customer of ours who is using one of our > netblocks is using a different reverse path to reach us. How might I > figure out who is allowing them to source traffic from IPs that belong > to us? It's been my experience that many providers do not care what address is used for sourcing traffic. This is why it is not uncommon to see traffic sourced from RFC1918 space coming across various providers networks. If more providers adopted BCP 38 this wouldn't be a problem, but that doesn't seem to be happening anytime soon... I'd try to identify which providers the customer is connected to and take it from there... Stefan Fouant www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From randy at psg.com Fri Nov 27 22:23:53 2009 From: randy at psg.com (Randy Bush) Date: Sat, 28 Nov 2009 13:23:53 +0900 Subject: Finding asymmetric path In-Reply-To: <4B10A39A.1090202@kenweb.org> References: <4B109C67.3040808@kenweb.org> <4B10A39A.1090202@kenweb.org> Message-ID: >>> I'm reasonable certain a customer of ours who is using one of our >>> netblocks is using a different reverse path to reach us. How might I >>> figure out who is allowing them to source traffic from IPs that belong >>> to us? >> you are implying that they are not allowed to multi-home using the ip >> space you have assigned to them. good way to lose a customer. > Does it count as multihoming when we are the only ones announcing the > space? almost an interesting question. but i think it is playing with words. if i understand your original statement, they are clearly attached to at least two providers. perhaps it is fear of what they, possibly mistakenly, perceive to be your policy regarding announcement of space that keeps them from announcing normally to both, or more, links? randy From morrowc.lists at gmail.com Fri Nov 27 22:27:05 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 27 Nov 2009 23:27:05 -0500 Subject: Finding asymmetric path In-Reply-To: References: <4B109C67.3040808@kenweb.org> <4B10A39A.1090202@kenweb.org> Message-ID: <75cb24520911272027q7326fd6wf787a5d6f2cb918a@mail.gmail.com> On Fri, Nov 27, 2009 at 11:23 PM, Randy Bush wrote: > perhaps it is fear of what they, possibly mistakenly, perceive to be > your policy regarding announcement of space that keeps them from > announcing normally to both, or more, links? or maybe just better pricing on the other provider, and that provider offers something akin to 'no-export' (or maybe they just used no-export). -chris From jgreco at ns.sol.net Sat Nov 28 09:41:09 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 28 Nov 2009 09:41:09 -0600 (CST) Subject: Finding asymmetric path In-Reply-To: from "Randy Bush" at Nov 28, 2009 01:23:53 PM Message-ID: <200911281541.nASFf9PD028235@aurora.sol.net> > >>> I'm reasonable certain a customer of ours who is using one of our > >>> netblocks is using a different reverse path to reach us. How might I > >>> figure out who is allowing them to source traffic from IPs that belong > >>> to us? > >> you are implying that they are not allowed to multi-home using the ip > >> space you have assigned to them. good way to lose a customer. > > Does it count as multihoming when we are the only ones announcing the > > space? > > almost an interesting question. but i think it is playing with words. > if i understand your original statement, they are clearly attached to at > least two providers. > > perhaps it is fear of what they, possibly mistakenly, perceive to be > your policy regarding announcement of space that keeps them from > announcing normally to both, or more, links? It could also be something simple like pricing. For example, in a large colo facility, you might easily find that a number of providers offer low cost transit, but not IP space. For a customer who is heavy on the outbound traffic, they might find it more affordable to buy their inbound plus IP space from you, and then dump onto Cogent or something like that for outbound. Unless your contract specifically prohibits this, you're probably not going to be able to prevent it. ... 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 herrin-nanog at dirtside.com Sat Nov 28 10:22:04 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Sat, 28 Nov 2009 11:22:04 -0500 Subject: Finding asymmetric path In-Reply-To: <4B109C67.3040808@kenweb.org> References: <4B109C67.3040808@kenweb.org> Message-ID: <3c3e3fca0911280822u36bd0056xed8b41b4978c6e3b@mail.gmail.com> On Fri, Nov 27, 2009 at 10:43 PM, ML wrote: > I'm reasonable certain a customer of ours who is using one of our netblocks > is using a different reverse path to reach us. ?How might I figure out who > is allowing them to source traffic from IPs that belong to us? Hi, Are they complaining about somehting? If so, ask for a traceroute. You might also try calling and asking. "We're seeing some strange traffic purporting to be from your addresses but not coming from your circuit. We're concerned that someone might be attacking your network. Before taking action to protect you, we want to eliminate the possibility that you have a second ISP through which you're accidentally sourcing the packets." Beyond that, what's your game plan once you know the answer? Threaten to cut them off? That's a great way to lose a customer who you know *already* has a second ISP. Maybe you'll call their second ISP and complain about their filtering practices? I'd love to get that call from you. Tells me exactly which name to pass to my upsell specialist. Yes Mr. Customer, your other ISP is trying to cut you off. They even asked us to block your packets. But for just a little more we'll give you IP addresses that you can use with any ISP. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nanog-post at rsuc.gweep.net Sat Nov 28 10:48:37 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Sat, 28 Nov 2009 11:48:37 -0500 Subject: Finding asymmetric path In-Reply-To: <200911281541.nASFf9PD028235@aurora.sol.net> References: <200911281541.nASFf9PD028235@aurora.sol.net> Message-ID: <20091128164837.GA70115@gweep.net> On Sat, Nov 28, 2009 at 09:41:09AM -0600, Joe Greco wrote: [attributions lost] > > >>> I'm reasonable certain a customer of ours who is using one of our > > >>> netblocks is using a different reverse path to reach us. How might I > > >>> figure out who is allowing them to source traffic from IPs that belong > > >>> to us? > > >> you are implying that they are not allowed to multi-home using the ip > > >> space you have assigned to them. good way to lose a customer. > > > Does it count as multihoming when we are the only ones announcing the > > > space? > > > > almost an interesting question. but i think it is playing with words. > > if i understand your original statement, they are clearly attached to at > > least two providers. > > > > perhaps it is fear of what they, possibly mistakenly, perceive to be > > your policy regarding announcement of space that keeps them from > > announcing normally to both, or more, links? It wasn't clear that the customer was a BGP downstream though by saying 'We are the only ones announcing the space', I think not. Non-BGP multihoming is broken* and when not done out of ignorance generally is the smoke pointing to the fire of someone trying to hide something. Was very common for spammers to abuse no-uRPF networks in the early days of broadband. > It could also be something simple like pricing. For example, in a large > colo facility, you might easily find that a number of providers offer > low cost transit, but not IP space. For a customer who is heavy on the > outbound traffic, they might find it more affordable to buy their inbound > plus IP space from you, and then dump onto Cogent or something like that > for outbound. Unless your contract specifically prohibits this, you're > probably not going to be able to prevent it. I wonder if there is a drift of baseline assumptions between the current wave of operators and previous ones? To me (and BCP38) it is beyond bad practice to allow -and if allowed, to make use of- such sloppy edges. If the other network truly is practicing bad forwarding hygiene then they are a security problem for everyone else and IMO would be good for naming and shaming. Cheers, Joe * for the majority of the cases. I know there are purposeful Non-BGP MOAS/anycast purposefully run by those who understand the implications. It is unfortunate that their use of lack of inherent BGP path security contribute to fuzzing what would otherwise have been a clear indicator of 'bad' behavior. But same could be said for the deaggregators using longest-match to have everyone else do their TE; water under the bridge pushing work onto everyone else. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From bruns at 2mbit.com Sat Nov 28 11:14:27 2009 From: bruns at 2mbit.com (Brielle Bruns) Date: Sat, 28 Nov 2009 10:14:27 -0700 Subject: Finding asymmetric path In-Reply-To: <4B109C67.3040808@kenweb.org> References: <4B109C67.3040808@kenweb.org> Message-ID: <4B115A73.5060107@2mbit.com> On 11/27/09 8:43 PM, ML wrote: > I'm reasonable certain a customer of ours who is using one of our > netblocks is using a different reverse path to reach us. How might I > figure out who is allowing them to source traffic from IPs that belong > to us? > > > I've had two customers pull this stunt in the past with me - one, a spammer, tried to do this with an ADSL modem from me, the other (a non-spammer with a clueless 'consultant') had a T1 from me and a T1 from UUNet. It started with the T1 customer. I believe they had a smaller block of IPs (less then /24, more like a /25 or /26), and their 'computer consultant' with his infinite wisdom decided to send all outbound traffic through the UUNet T1 rather then source routing which we highly recommended to them. Of course, we had ingress filters in place to block IP ranges we have from coming into us from the WAN links, so when they tried to contact servers on the other half of the netblock on our end, the connections mysteriously failed. After lying up and down that it was our fault, that their computer 'consultant' was regarded as best in the country, blah blah blah, we flipped on logging on the ingress filters out of sheer curiosity and discovered exactly what was going on. The ADSL customer was a bit more tricky - we were getting spam reports about his single IP address sending spam, but we had his outbound port 25 blocked. Ended up sniffing the port off the router he sat off of, and discovering that it was all one sided, wasn't even tickling the ingress filters. Hey, at least your customer didn't convince AT&T to allow them to announce out one of your /24s when all they had was a /29. Your in a tricky bind, I'd approach them under the guise of ingress filtering issues. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From jgreco at ns.sol.net Sat Nov 28 11:56:39 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 28 Nov 2009 11:56:39 -0600 (CST) Subject: Finding asymmetric path In-Reply-To: <20091128164837.GA70115@gweep.net> from "Joe Provo" at Nov 28, 2009 11:48:37 AM Message-ID: <200911281756.nASHud6B032188@aurora.sol.net> > > On Sat, Nov 28, 2009 at 09:41:09AM -0600, Joe Greco wrote: > [attributions lost] > > > >>> I'm reasonable certain a customer of ours who is using one of our > > > >>> netblocks is using a different reverse path to reach us. How might I > > > >>> figure out who is allowing them to source traffic from IPs that belong > > > >>> to us? > > > >> you are implying that they are not allowed to multi-home using the ip > > > >> space you have assigned to them. good way to lose a customer. > > > > Does it count as multihoming when we are the only ones announcing the > > > > space? > > > > > > almost an interesting question. but i think it is playing with words. > > > if i understand your original statement, they are clearly attached to at > > > least two providers. > > > > > > perhaps it is fear of what they, possibly mistakenly, perceive to be > > > your policy regarding announcement of space that keeps them from > > > announcing normally to both, or more, links? > > It wasn't clear that the customer was a BGP downstream though by saying > 'We are the only ones announcing the space', I think not. Non-BGP > multihoming is broken* and when not done out of ignorance generally is > the smoke pointing to the fire of someone trying to hide something. > Was very common for spammers to abuse no-uRPF networks in the early > days of broadband. This is still rather common for people to do, at least where there's a significant cost differential. There are enough networks that can accept arbitrary traffic that BGP doesn't really play into it at all. > > It could also be something simple like pricing. For example, in a large > > colo facility, you might easily find that a number of providers offer > > low cost transit, but not IP space. For a customer who is heavy on the > > outbound traffic, they might find it more affordable to buy their inbound > > plus IP space from you, and then dump onto Cogent or something like that > > for outbound. Unless your contract specifically prohibits this, you're > > probably not going to be able to prevent it. > > I wonder if there is a drift of baseline assumptions between the current > wave of operators and previous ones? To me (and BCP38) it is beyond bad > practice to allow -and if allowed, to make use of- such sloppy edges. Of course it is. > If the other network truly is practicing bad forwarding hygiene then > they are a security problem for everyone else and IMO would be good for > naming and shaming. Sure. But it's easy enough to go to, for example, $BACKBONE_OF_CHOICE and say "I'm delegated 1.2.3.4/24 from $SMALLISP, I would like you to accept traffic from that prefix, here's my SWIP'd WHOIS to prove that" and there are lots of providers for whom that won't be a problem; it is not the same sort of security problem that a complete lack of filtering is. Generally speaking, what's needed is a control over what's being cast into the network. > * for the majority of the cases. I know there are purposeful Non-BGP > MOAS/anycast purposefully run by those who understand the implications. > It is unfortunate that their use of lack of inherent BGP path security > contribute to fuzzing what would otherwise have been a clear indicator > of 'bad' behavior. But same could be said for the deaggregators > using longest-match to have everyone else do their TE; water under > the bridge pushing work onto everyone else. :-) ... 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 ml at kenweb.org Sat Nov 28 13:14:07 2009 From: ml at kenweb.org (ML) Date: Sat, 28 Nov 2009 14:14:07 -0500 Subject: Finding asymmetric path In-Reply-To: <4B115A73.5060107@2mbit.com> References: <4B109C67.3040808@kenweb.org> <4B115A73.5060107@2mbit.com> Message-ID: <4B11767F.4070907@kenweb.org> Brielle Bruns wrote: > On 11/27/09 8:43 PM, ML wrote: >> I'm reasonable certain a customer of ours who is using one of our >> netblocks is using a different reverse path to reach us. How might I >> figure out who is allowing them to source traffic from IPs that belong >> to us? >> >> >> > > I've had two customers pull this stunt in the past with me - one, a > spammer, tried to do this with an ADSL modem from me, the other (a > non-spammer with a clueless 'consultant') had a T1 from me and a T1 from > UUNet. > > It started with the T1 customer. I believe they had a smaller block of > IPs (less then /24, more like a /25 or /26), and their 'computer > consultant' with his infinite wisdom decided to send all outbound > traffic through the UUNet T1 rather then source routing which we highly > recommended to them. Of course, we had ingress filters in place to > block IP ranges we have from coming into us from the WAN links, so when > they tried to contact servers on the other half of the netblock on our > end, the connections mysteriously failed. After lying up and down that > it was our fault, that their computer 'consultant' was regarded as best > in the country, blah blah blah, we flipped on logging on the ingress > filters out of sheer curiosity and discovered exactly what was going on. > > The ADSL customer was a bit more tricky - we were getting spam reports > about his single IP address sending spam, but we had his outbound port > 25 blocked. Ended up sniffing the port off the router he sat off of, > and discovering that it was all one sided, wasn't even tickling the > ingress filters. > > Hey, at least your customer didn't convince AT&T to allow them to > announce out one of your /24s when all they had was a /29. > > Your in a tricky bind, I'd approach them under the guise of ingress > filtering issues. > Brielle is correct. The customer in question is spamming networks and we are having trouble filtering them because another provider allows them to source traffic however they please. Of course the other provider seems to be a spam friendly upstream. Hopefully you can understand why I'm not hopeful of getting anywhere with them either. From bruns at 2mbit.com Sat Nov 28 13:41:58 2009 From: bruns at 2mbit.com (Brielle Bruns) Date: Sat, 28 Nov 2009 19:41:58 +0000 Subject: Finding asymmetric path In-Reply-To: <4B11767F.4070907@kenweb.org> References: <4B109C67.3040808@kenweb.org> <4B115A73.5060107@2mbit.com><4B11767F.4070907@kenweb.org> Message-ID: <775962905-1259437326-cardhu_decombobulator_blackberry.rim.net-1366739286-@bda407.bisx.prod.on.blackberry> (Forgive the top posting, stupid blackberry can't do inline) A creative idea that I did in a test lab one time - stateful connection tracking, its not just for NAT you know. Would require a bit of moving stuff around and reengineering of your connection to them, but it would cripple their connection unless it originated through you. IE: You <-> UNIX/Linux firewall <-> T1/eth/dsl/etc If stuff went out the other way, it would come in, firewall says WTF, and drops it because it didn't see the initial SYN exchange. My partner Tammy says a PIX could probably accomplish the same task (we have some here for the corp lan stuff, including spares). Brielle -- Brielle Bruns http://www.sosdg.org / http://www.ahbl.org -----Original Message----- From: ML Date: Sat, 28 Nov 2009 14:14:07 To: nanog at nanog.org Subject: Re: Finding asymmetric path Brielle Bruns wrote: > On 11/27/09 8:43 PM, ML wrote: >> I'm reasonable certain a customer of ours who is using one of our >> netblocks is using a different reverse path to reach us. How might I >> figure out who is allowing them to source traffic from IPs that belong >> to us? >> >> >> > > I've had two customers pull this stunt in the past with me - one, a > spammer, tried to do this with an ADSL modem from me, the other (a > non-spammer with a clueless 'consultant') had a T1 from me and a T1 from > UUNet. > > It started with the T1 customer. I believe they had a smaller block of > IPs (less then /24, more like a /25 or /26), and their 'computer > consultant' with his infinite wisdom decided to send all outbound > traffic through the UUNet T1 rather then source routing which we highly > recommended to them. Of course, we had ingress filters in place to > block IP ranges we have from coming into us from the WAN links, so when > they tried to contact servers on the other half of the netblock on our > end, the connections mysteriously failed. After lying up and down that > it was our fault, that their computer 'consultant' was regarded as best > in the country, blah blah blah, we flipped on logging on the ingress > filters out of sheer curiosity and discovered exactly what was going on. > > The ADSL customer was a bit more tricky - we were getting spam reports > about his single IP address sending spam, but we had his outbound port > 25 blocked. Ended up sniffing the port off the router he sat off of, > and discovering that it was all one sided, wasn't even tickling the > ingress filters. > > Hey, at least your customer didn't convince AT&T to allow them to > announce out one of your /24s when all they had was a /29. > > Your in a tricky bind, I'd approach them under the guise of ingress > filtering issues. > Brielle is correct. The customer in question is spamming networks and we are having trouble filtering them because another provider allows them to source traffic however they please. Of course the other provider seems to be a spam friendly upstream. Hopefully you can understand why I'm not hopeful of getting anywhere with them either. From duane.waddle at gmail.com Sat Nov 28 14:26:07 2009 From: duane.waddle at gmail.com (Duane Waddle) Date: Sat, 28 Nov 2009 14:26:07 -0600 Subject: Finding asymmetric path In-Reply-To: <775962905-1259437326-cardhu_decombobulator_blackberry.rim.net-1366739286-@bda407.bisx.prod.on.blackberry> References: <4B109C67.3040808@kenweb.org> <4B115A73.5060107@2mbit.com> <4B11767F.4070907@kenweb.org> <775962905-1259437326-cardhu_decombobulator_blackberry.rim.net-1366739286-@bda407.bisx.prod.on.blackberry> Message-ID: <80e7195b0911281226yd219664haf5245812fa97b62@mail.gmail.com> On Sat, Nov 28, 2009 at 1:41 PM, Brielle Bruns wrote: > My partner Tammy says a PIX could probably accomplish the same task (we have some here for the corp lan stuff, including spares). Yes, a PIX/ASA would stop this cold. The TCP state tracking would not allow traffic to pass unless the whole 3-way handshake was observed by the box. Only recently did Cisco add features to make tracking the TCP connection state optional. (http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/conns_tcpstatebypass.pdf) The larger ASA-5580 machines can be virtualized into dozens (or more) security contexts as needed. I imagine it would take some effort to figure out how to cleanly integrate such a configuration into a POP. --D From bruns at 2mbit.com Sat Nov 28 15:02:23 2009 From: bruns at 2mbit.com (Brielle Bruns) Date: Sat, 28 Nov 2009 21:02:23 +0000 Subject: Finding asymmetric path Message-ID: <409621632-1259442149-cardhu_decombobulator_blackberry.rim.net-542764739-@bda407.bisx.prod.on.blackberry> (Forgive the top posting, stupid blackberry can't do inline) If the PoP is connected to a central location, reroute the affected netblock there through the appropriate equipment. If you snag it going both ways before it hits the PoP, you should be good. ------Original Message------ From: Duane Waddle To: nanog at nanog.org Subject: Re: Finding asymmetric path Sent: Nov 28, 2009 1:26 PM On Sat, Nov 28, 2009 at 1:41 PM, Brielle Bruns wrote: > My partner Tammy says a PIX could probably accomplish the same task (we have some here for the corp lan stuff, including spares). Yes, a PIX/ASA would stop this cold. The TCP state tracking would not allow traffic to pass unless the whole 3-way handshake was observed by the box. Only recently did Cisco add features to make tracking the TCP connection state optional. (http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/conns_tcpstatebypass.pdf) The larger ASA-5580 machines can be virtualized into dozens (or more) security contexts as needed. I imagine it would take some effort to figure out how to cleanly integrate such a configuration into a POP. --D -- Brielle Bruns http://www.sosdg.org / http://www.ahbl.org From herrin-nanog at dirtside.com Sat Nov 28 16:28:01 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Sat, 28 Nov 2009 17:28:01 -0500 Subject: Finding asymmetric path In-Reply-To: <4B11767F.4070907@kenweb.org> References: <4B109C67.3040808@kenweb.org> <4B115A73.5060107@2mbit.com> <4B11767F.4070907@kenweb.org> Message-ID: <3c3e3fca0911281428x668ced3bk5dfd5d63c7dfca9d@mail.gmail.com> On Sat, Nov 28, 2009 at 2:14 PM, ML wrote: > Brielle is correct. ?The customer in question is spamming networks and we > are having trouble filtering them because another provider allows them to > source traffic however they please. What trouble? SMTP requires two-way traffic with a static port number that nothing else uses. If for some reason you don't want to simply terminate their account altogether, block packets outbound to your customer sourced from TCP port 25 but not from your SMTP smarthosts. Seriously though, if you can prove they're spamming (regardless of whether the packets pass through your network) save yourself some grief and just terminate the account. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bruns at 2mbit.com Sat Nov 28 16:42:29 2009 From: bruns at 2mbit.com (Brielle Bruns) Date: Sat, 28 Nov 2009 15:42:29 -0700 Subject: Fwd: News Delivery Report (Failure) Message-ID: <4B11A755.7040105@2mbit.com> Is anyone else getting these when you post to the nanog list? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org -------- Original Message -------- Subject: News Delivery Report (Failure) Date: Sat, 28 Nov 2009 16:06:42 -0500 From: mail To: bruns at 2mbit.com Your Article "Re: Finding asymmetric path" (Sat, 28 Nov 2009 21:02:23 +0000) could not be successfully delivered to the following news groups :- homeless.security News Server: news.barkto.com Response: 441 Faulty message ID format Your message is quoted below :- X-rim-org-msg-ref-id: 409621632 Message-ID: <409621632-1259442149-cardhu_decombobulator_blackberry.rim.net-542764739- at bda407.bisx.prod.on.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal Sensitivity: Normal Importance: Normal To: nanog at nanog.org Subject: Re: Finding asymmetric path From: "Brielle Bruns" Newsgroups: homeless.security Path: mail.theyscrewedusagain.com Date: Sat, 28 Nov 2009 21:02:23 +0000 Lines: 28 Content-Type: text/plain MIME-Version: 1.0 X-BeenThere: nanog at nanog.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bruns at 2mbit.com List-Id: North American Network Operators Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , ________________________________________________________________________ Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com) From peter at peter-dambier.de Sat Nov 28 16:46:38 2009 From: peter at peter-dambier.de (Peter Dambier) Date: Sat, 28 Nov 2009 23:46:38 +0100 Subject: DTAG.de routing? Message-ID: <4B11A84E.5000308@peter-dambier.de> Hi, I am missing manitu from dtag dsl. Hetzner can see them: DTAG: traceroute to f-root.cesidio.net (89.238.64.147), 64 hops max, 40 byte packets 1 yttrium.anul.nsa (7.19.30.39) 3 ms 1 ms 0 ms 2 217.0.116.228 (217.0.116.228) 47 ms 46 ms 45 ms 3 217.0.78.58 (217.0.78.58) 45 ms !H 46 ms !H * Hetzner: traceroute to f-root.cesidio.net (89.238.64.147), 64 hops max, 40 byte packets 1 88.198.54.193 (88.198.54.193) 1 ms 1 ms 1 ms 2 213.239.229.1 (213.239.229.1) 0 ms 213.239.229.129 (213.239.229.129) 0 ms 213.239.252.129 (213.239.252.129) 0 ms 3 213.239.240.226 (213.239.240.226) 3 ms 3 ms 3 ms 4 80.81.192.204 (80.81.192.204) 15 ms 5 ms 4 ms 5 78.141.176.2 (78.141.176.2) 4 ms 4 ms 4 ms 6 89.238.127.2 (89.238.127.2) 8 ms 8 ms 8 ms 7 89.238.64.147 (89.238.64.147) 8 ms 8 ms 9 ms Kind regards Peter -- 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 sethm at rollernet.us Sat Nov 28 17:00:59 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 28 Nov 2009 15:00:59 -0800 Subject: Fwd: News Delivery Report (Failure) In-Reply-To: <4B11A755.7040105@2mbit.com> References: <4B11A755.7040105@2mbit.com> Message-ID: <4B11ABAB.2010605@rollernet.us> Brielle Bruns wrote: > Is anyone else getting these when you post to the nanog list? > Looks like someone subscribed a broken news feeder thing to the list. ~Seth From peter at peter-dambier.de Sat Nov 28 17:08:41 2009 From: peter at peter-dambier.de (Peter Dambier) Date: Sun, 29 Nov 2009 00:08:41 +0100 Subject: DTAG.de routing? In-Reply-To: <4B11A84E.5000308@peter-dambier.de> References: <4B11A84E.5000308@peter-dambier.de> Message-ID: <4B11AD79.6010809@peter-dambier.de> Peter Dambier wrote: > Hi, > > I am missing manitu from dtag dsl. > Hetzner can see them: > > DTAG: > traceroute to f-root.cesidio.net (89.238.64.147), 64 hops max, 40 byte packets > 1 yttrium.anul.nsa (7.19.30.39) 3 ms 1 ms 0 ms <<< (NAT 62.227.194.126) > 2 217.0.116.228 (217.0.116.228) 47 ms 46 ms 45 ms > 3 217.0.78.58 (217.0.78.58) 45 ms !H 46 ms !H * > > Hetzner: > traceroute to f-root.cesidio.net (89.238.64.147), 64 hops max, 40 byte packets > 1 88.198.54.193 (88.198.54.193) 1 ms 1 ms 1 ms > 2 213.239.229.1 (213.239.229.1) 0 ms 213.239.229.129 (213.239.229.129) 0 ms 213.239.252.129 (213.239.252.129) 0 ms > 3 213.239.240.226 (213.239.240.226) 3 ms 3 ms 3 ms > 4 80.81.192.204 (80.81.192.204) 15 ms 5 ms 4 ms > 5 78.141.176.2 (78.141.176.2) 4 ms 4 ms 4 ms <<< see below > 6 89.238.127.2 (89.238.127.2) 8 ms 8 ms 8 ms > 7 89.238.64.147 (89.238.64.147) 8 ms 8 ms 9 ms > > traceroute to 78.141.176.2 (78.141.176.2), 64 hops max, 40 byte packets 1 yttrium.anul.nsa (7.19.30.39) 1 ms 1 ms 0 ms <<< (NAT 62.227.194.126) 2 217.0.116.228 (217.0.116.228) 45 ms 47 ms 47 ms 3 217.0.78.50 (217.0.78.50) 45 ms 46 ms 45 ms 4 f-ea5-i.F.DE.NET.DTAG.DE (62.154.16.161) 47 ms 48 ms 47 ms 5 te-4-4.car2.Frankfurt1.Level3.net (4.68.110.253) 97 ms 92 ms 221 ms 6 vlan89.csw3.Frankfurt1.Level3.net (4.68.23.190) 65 ms 58 ms 55 ms 7 ae-82-82.ebr2.Frankfurt1.Level3.net (4.69.140.25) 56 ms 57 ms 58 ms 8 ae-2-2.ebr1.Dusseldorf1.Level3.net (4.69.132.137) 51 ms 57 ms 55 ms 9 ae-1-100.ebr2.Dusseldorf1.Level3.net (4.69.141.150) 52 ms 56 ms 56 ms 10 ae-2-2.ebr1.Amsterdam1.Level3.net (4.69.133.89) 62 ms 61 ms 66 ms 11 ae-1-100.ebr2.Amsterdam1.Level3.net (4.69.141.170) 64 ms 60 ms 66 ms 12 ae-2-2.ebr2.London1.Level3.net (4.69.132.133) 69 ms 69 ms 69 ms 13 ae-24-52.car3.London1.Level3.net (4.69.139.100) 64 ms 62 ms 64 ms 14 195.50.90.186 (195.50.90.186) 65 ms 65 ms 64 ms 15 213.166.61.130 (213.166.61.130) 78 ms 79 ms 79 ms 16 213.135.247.101 (213.135.247.101) 85 ms 79 ms 78 ms 17 213.135.247.106 (213.135.247.106) 67 ms 64 ms 65 ms 18 PTLUX-Teralink-Frankfurt.pt.lu (213.166.61.205) 859 ms 994 ms 850 ms 19 78.141.176.2 (78.141.176.2) 65 ms !A 69 ms !A 65 ms !A > Kind regards > Peter -- 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 ghicks at hicks-net.net Sat Nov 28 17:16:13 2009 From: ghicks at hicks-net.net (Gregory Hicks) Date: Sat, 28 Nov 2009 15:16:13 -0800 (PST) Subject: Fwd: News Delivery Report (Failure) Message-ID: <200911282316.nASNGDd1005841@metis.hicks-net.net> > Date: Sat, 28 Nov 2009 15:42:29 -0700 > From: Brielle Bruns > To: nanog at nanog.org > Subject: Fwd: News Delivery Report (Failure) > > Is anyone else getting these when you post to the nanog list? Similar. I get these from Ritz Camera: From: Antigen_RITZEXCHANGE To: ghicks at hicks-net.net Subject: Antigen Notification: Antigen found a message matching a filter Date: 5 Nov 2009 14:32:53 -0500 Microsoft Antigen for Exchange found a message matching a filter. The message is currently Detected. Message: "Re_ Email filtering and protection Help" Filter name: "KEYWORD= racial discrimination: hicks" Sent from: "Gregory Hicks " Folder: "SMTP Messages\Inbound" Location: "Ritz/Corp/RITZEXCHANGE" --------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer | Direct: 408.569.7928 People sleep peaceably in their beds at night only because rough men stand ready to do violence on their behalf -- George Orwell The price of freedom is eternal vigilance. -- Thomas Jefferson "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton From randy at psg.com Sat Nov 28 19:51:03 2009 From: randy at psg.com (Randy Bush) Date: Sun, 29 Nov 2009 10:51:03 +0900 Subject: Finding asymmetric path In-Reply-To: <4B11767F.4070907@kenweb.org> References: <4B109C67.3040808@kenweb.org> <4B115A73.5060107@2mbit.com> <4B11767F.4070907@kenweb.org> Message-ID: > Brielle is correct. The customer in question is spamming networks and > we are having trouble filtering them because another provider allows > them to source traffic however they please. then perhaps the issue is a bit larger than their traffic incoming to you. disconnect the schmucks. randy From ops.lists at gmail.com Sat Nov 28 21:02:31 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 29 Nov 2009 08:32:31 +0530 Subject: Finding asymmetric path In-Reply-To: <3c3e3fca0911281428x668ced3bk5dfd5d63c7dfca9d@mail.gmail.com> References: <4B109C67.3040808@kenweb.org> <4B115A73.5060107@2mbit.com> <4B11767F.4070907@kenweb.org> <3c3e3fca0911281428x668ced3bk5dfd5d63c7dfca9d@mail.gmail.com> Message-ID: Yes - term the account would be my recommendation And if you filter port 25 traffic do it both ways Read these old nanog threads .. http://www.irbs.net/internet/nanog/0408/0465.html and http://www.mail-archive.com/nanog at merit.edu/msg28863.html On Sun, Nov 29, 2009 at 3:58 AM, William Herrin wrote: > On Sat, Nov 28, 2009 at 2:14 PM, ML wrote: >> Brielle is correct. ?The customer in question is spamming networks and we >> are having trouble filtering them because another provider allows them to >> source traffic however they please. > > What trouble? SMTP requires two-way traffic with a static port number > that nothing else uses. If for some reason you don't want to simply > terminate their account altogether, block packets outbound to your > customer sourced from TCP port 25 but not from your SMTP smarthosts. > > Seriously though, if you can prove they're spamming (regardless of > whether the packets pass through your network) save yourself some > grief and just terminate the account. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com ?bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From jmamodio at gmail.com Sun Nov 29 00:02:49 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Sun, 29 Nov 2009 00:02:49 -0600 Subject: Finding asymmetric path In-Reply-To: <4B11767F.4070907@kenweb.org> References: <4B109C67.3040808@kenweb.org> <4B115A73.5060107@2mbit.com> <4B11767F.4070907@kenweb.org> Message-ID: <202705b0911282202y3e0fa946oee6ca52e3f27d12a@mail.gmail.com> > Brielle is correct. ?The customer in question is spamming networks and we > are having trouble filtering them because another provider allows them to > source traffic however they please. If they are spamming just pull the plug, whatever revenue you get from them is not worth your reputation and caring for other good customers, and the rest of us will speak highly of you for taking another spamcrock out of the net. Cheers Jorge From arievayner at gmail.com Sun Nov 29 02:17:18 2009 From: arievayner at gmail.com (Arie Vayner) Date: Sun, 29 Nov 2009 10:17:18 +0200 Subject: Finding asymmetric path In-Reply-To: <80e7195b0911281226yd219664haf5245812fa97b62@mail.gmail.com> References: <4B109C67.3040808@kenweb.org> <4B115A73.5060107@2mbit.com> <4B11767F.4070907@kenweb.org> <775962905-1259437326-cardhu_decombobulator_blackberry.rim.net-1366739286-@bda407.bisx.prod.on.blackberry> <80e7195b0911281226yd219664haf5245812fa97b62@mail.gmail.com> Message-ID: <20b13c6b0911290017tcd214efs81afdf2b4c3e950f@mail.gmail.com> Actually, this can be achieved easily using reflexive ACLs on any Cisco router, so no real need to change the topology or add new devices in the path: http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a00800a5b9a.shtml#reflexacl Arie On Sat, Nov 28, 2009 at 10:26 PM, Duane Waddle wrote: > On Sat, Nov 28, 2009 at 1:41 PM, Brielle Bruns wrote: > > > My partner Tammy says a PIX could probably accomplish the same task (we > have some here for the corp lan stuff, including spares). > > Yes, a PIX/ASA would stop this cold. The TCP state tracking would not > allow traffic to pass unless the whole 3-way handshake was observed by > the box. Only recently did Cisco add features to make tracking the > TCP connection state optional. > ( > http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/conns_tcpstatebypass.pdf > ) > The larger ASA-5580 machines can be virtualized into dozens (or more) > security contexts as needed. I imagine it would take some effort to > figure out how to cleanly integrate such a configuration into a POP. > > --D > > From ssrigha at gmail.com Sun Nov 29 20:34:53 2009 From: ssrigha at gmail.com (shake righa) Date: Mon, 30 Nov 2009 05:34:53 +0300 Subject: Route Target rewrite Message-ID: <73439e5a0911291834pc088ehb6eb88005a0b8222@mail.gmail.com> Anyone with material on how to perform route target re-write as well as filtering during vpnv4 BGP sessions. Have been ttying but the rewrite is not occuring. Regards, Shake Righa From sshafi at gmail.com Sun Nov 29 23:17:40 2009 From: sshafi at gmail.com (Lala Lander) Date: Sun, 29 Nov 2009 21:17:40 -0800 Subject: Route Target rewrite In-Reply-To: <73439e5a0911291834pc088ehb6eb88005a0b8222@mail.gmail.com> References: <73439e5a0911291834pc088ehb6eb88005a0b8222@mail.gmail.com> Message-ID: Please try this URL. If it doesnt work for you, let me know and I'll send you a working example. http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fsrtrw4.html Pretty straight forward configuration. thanks, Shahid On Sun, Nov 29, 2009 at 6:34 PM, shake righa wrote: > Anyone with material on how to perform route target re-write as well as > filtering during vpnv4 BGP sessions. > > Have been ttying but the rewrite is not occuring. > > Regards, > Shake Righa > From hank at efes.iucc.ac.il Mon Nov 30 01:40:11 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 30 Nov 2009 09:40:11 +0200 Subject: Fiber Cut in Italy Message-ID: <5.1.0.14.2.20091130093257.00c59c90@efes.iucc.ac.il> The first cable cut occurred at 13:43 GMT close to Vernegues-France involving a group of six cables, damaged by an excavator, interrupting the service on the segment Marseille-Lyon. The second cable cut occurred at 14:21 GMT on a highway near to Milano/Bersaglio, about 530km away, interrupting the service on the segment Milano-Zurich. Service was restored at 1:40 GMT the next day. It just shows that protected fiber rings do have an enemy - and his name is Murphy. -Hank >TI Sparkle just confirmed they are having a fault. > >Email from Telecom Italia Sparkle - Seabone NOC: > >Dear >We have a big fault ( fiber cut) in france 2 cuts and one in milan. > >We are working to solve it asap. > >Regards > > >???????????????- Telecom Italia Sparkle SpA >Customer Assistance/Assurance I? t Se at bone Network Operations Center Via >M. Palocco, 223 ? Rome, IT > > > -----Original Message----- > > From: Varaillon Jean Christophe [mailto:varaillon at cosmoline.com] > > Sent: Monday, November 16, 2009 7:05 PM > > To: nanog at nanog.org > > Subject: Fiber Cut in Italy > > > > Hi, > > > > It seems that there is a major fiber cut in Italy (not really near > nanog, so > > just in case...) > > > > I was just wondering if anybody has heard of any possible recovery time > - as > > there is none official one yet. > > > > Thank you, > > > > Jean-Christophe VARAILLON From goemon at anime.net Mon Nov 30 02:29:02 2009 From: goemon at anime.net (goemon at anime.net) Date: Mon, 30 Nov 2009 00:29:02 -0800 (PST) Subject: tpg.com.au contact? Message-ID: Anyone have a clueful mail admin contact for tpg.com.au? The usual attempts result in completely clueless and unhelpful responses, going round in circles with no progress. -Dan From bfeeny at mac.com Mon Nov 30 11:07:46 2009 From: bfeeny at mac.com (Brian Feeny) Date: Mon, 30 Nov 2009 12:07:46 -0500 Subject: STP Visualization Message-ID: <26F19896-6A92-4E58-A5BE-2C5B41CDB884@mac.com> Can anyone recommend a good tool for spanning tree visualization? I am needing to get a good visual depiction of forwarding for many vlans, across 4 core switches. Two of them are CatOS, 2 are IOS, root is different for many of the vlans, lots of port costing in place, in other words it would take a while by hand. Thanks, Brian From david.freedman at uk.clara.net Mon Nov 30 12:16:53 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Mon, 30 Nov 2009 18:16:53 +0000 Subject: STP Visualization In-Reply-To: <26F19896-6A92-4E58-A5BE-2C5B41CDB884@mac.com> References: <26F19896-6A92-4E58-A5BE-2C5B41CDB884@mac.com> Message-ID: I wrote a perl/libgd tool some time ago which acts as a cgi script and takes live data and makes pretty pictures of it (per vlan). Note due a bunch of stuff not being uniformly implemented in IOS via SNMP I've had to screen scrape a little and I'm afraid this means I don't have any CatOS support. Let me know offlist if you are interested in the code. Brian Feeny wrote: > > Can anyone recommend a good tool for spanning tree visualization? I am > needing to get a good visual depiction of forwarding for many vlans, > across 4 core switches. > Two of them are CatOS, 2 are IOS, root is different for many of the > vlans, lots of port costing in place, in other words it would take a > while by hand. > > Thanks, > > Brian > > > From w.d.clayton at gmail.com Mon Nov 30 13:15:47 2009 From: w.d.clayton at gmail.com (Will Clayton) Date: Mon, 30 Nov 2009 13:15:47 -0600 Subject: STP Visualization In-Reply-To: <26F19896-6A92-4E58-A5BE-2C5B41CDB884@mac.com> References: <26F19896-6A92-4E58-A5BE-2C5B41CDB884@mac.com> Message-ID: <69069bc20911301115h2838e8bdm45638822c47b8269@mail.gmail.com> Graphviz? On Mon, Nov 30, 2009 at 11:07 AM, Brian Feeny wrote: > > Can anyone recommend a good tool for spanning tree visualization? I am > needing to get a good visual depiction of forwarding for many vlans, across > 4 core switches. > Two of them are CatOS, 2 are IOS, root is different for many of the vlans, > lots of port costing in place, in other words it would take a while by hand. > > Thanks, > > Brian > > > From bfeeny at mac.com Mon Nov 30 13:26:20 2009 From: bfeeny at mac.com (Brian Feeny) Date: Mon, 30 Nov 2009 14:26:20 -0500 Subject: STP Visualization In-Reply-To: <69069bc20911301115h2838e8bdm45638822c47b8269@mail.gmail.com> References: <26F19896-6A92-4E58-A5BE-2C5B41CDB884@mac.com> <69069bc20911301115h2838e8bdm45638822c47b8269@mail.gmail.com> Message-ID: <1D58FE15-82F4-4D0E-AED2-3E4A4B0DD0C6@mac.com> Although that looks like a pretty cool visualization program, I does not have the ability to automatically grok STP info via snmp/ssh/ telnet/cdp/etc. I am looking for a program to do the work of showing me STP forwarding paths on a per vlan basis, it doesn't have to be pretty, just something that can do it. Brian On Nov 30, 2009, at 2:15 PM, Will Clayton wrote: > Graphviz? > > On Mon, Nov 30, 2009 at 11:07 AM, Brian Feeny wrote: > > Can anyone recommend a good tool for spanning tree visualization? I > am needing to get a good visual depiction of forwarding for many > vlans, across 4 core switches. > Two of them are CatOS, 2 are IOS, root is different for many of the > vlans, lots of port costing in place, in other words it would take a > while by hand. > > Thanks, > > Brian > > > From plonka at doit.wisc.edu Mon Nov 30 13:30:31 2009 From: plonka at doit.wisc.edu (Dave Plonka) Date: Mon, 30 Nov 2009 13:30:31 -0600 Subject: STP Visualization In-Reply-To: References: <26F19896-6A92-4E58-A5BE-2C5B41CDB884@mac.com> Message-ID: <20091130193031.GA5613@doit.wisc.edu> On Mon, Nov 30, 2009 at 06:16:53PM +0000, David Freedman wrote: > I wrote a perl/libgd tool some time ago which acts as a cgi script and > takes live data and makes pretty pictures of it (per vlan). > Note due a bunch of stuff not being uniformly implemented in IOS via > SNMP I've had to screen scrape a little and I'm afraid this means I > don't have any CatOS support. > > Let me know offlist if you are interested in the code. I have something to do this as well, using perl to grab all the details via SNMP, and then visualization using GraphViz. You're welcome to use it to start with: http://net.doit.wisc.edu/~plonka/stpgraph/ There's a sample PDF in the "examples/" sub-dir. Dave P.S. I know initially you request a "good tool", which is in the eye of the beholder. This one will want a programmer's eye, I guess. -- plonka at cs.wisc.edu http://net.doit.wisc.edu/~plonka/ Madison, WI From jjackson at aninetworks.net Mon Nov 30 18:06:45 2009 From: jjackson at aninetworks.net (Joseph Jackson) Date: Mon, 30 Nov 2009 16:06:45 -0800 Subject: DNS query analyzer Message-ID: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> Hey List! Anyone know of a tool that can take a pcap file from wireshark that was used to collect dns queries and then spit out statistics about the queries such as RTT and timeouts? Thanks! Joseph From nanog at daork.net Mon Nov 30 19:12:13 2009 From: nanog at daork.net (Nathan Ward) Date: Tue, 1 Dec 2009 14:12:13 +1300 Subject: DNS query analyzer In-Reply-To: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> References: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> Message-ID: On 1/12/2009, at 1:06 PM, Joseph Jackson wrote: > Hey List! > > Anyone know of a tool that can take a pcap file from wireshark that > was used to collect dns queries and then spit out statistics about > the queries such as RTT and timeouts? Not off the top of my head, but, you could use wireshark's Lua extension system to write a plugin to do this for you right within wireshark. The wireshark/Lua stuff is quite powerful (though not super super fast), it's a really useful tool to have on hand. -- Nathan Ward From sfouant at shortestpathfirst.net Mon Nov 30 20:48:53 2009 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Mon, 30 Nov 2009 21:48:53 -0500 Subject: DNS query analyzer In-Reply-To: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> References: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> Message-ID: <000701ca7230$d2467530$76d35f90$@net> > -----Original Message----- > From: Joseph Jackson [mailto:jjackson at aninetworks.net] > Sent: Monday, November 30, 2009 7:07 PM > > Anyone know of a tool that can take a pcap file from wireshark that was > used to collect dns queries and then spit out statistics about the > queries such as RTT and timeouts? It just so happens there is a tool aptly named DNS Analyzer by NLnet Labs. I used it a while back but if I recall you could feed it a pcap and it could spit out all kinds of useful statistical data. I don't think it's being actively maintained at the moment but you should be able to find it on the NLnet Labs site - http://www.nlnetlabs.nl/projects/dns-analyzer/ HTHs. Stefan Fouant www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From raymond at prolocation.net Mon Nov 30 20:54:03 2009 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Tue, 1 Dec 2009 03:54:03 +0100 (CET) Subject: DNS query analyzer In-Reply-To: <000701ca7230$d2467530$76d35f90$@net> References: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> <000701ca7230$d2467530$76d35f90$@net> Message-ID: Hi! >> Anyone know of a tool that can take a pcap file from wireshark that was >> used to collect dns queries and then spit out statistics about the >> queries such as RTT and timeouts? > It just so happens there is a tool aptly named DNS Analyzer by NLnet Labs. > I used it a while back but if I recall you could feed it a pcap and it could > spit out all kinds of useful statistical data. > > I don't think it's being actively maintained at the moment but you should be > able to find it on the NLnet Labs site - > http://www.nlnetlabs.nl/projects/dns-analyzer/ I very recently asked the maintainers of that package if its still under development but i heard if was unfortunately dropped. Bye, Raymond. From luke.marrott at gmail.com Mon Nov 30 20:57:58 2009 From: luke.marrott at gmail.com (Luke Marrott) Date: Mon, 30 Nov 2009 19:57:58 -0700 Subject: FTTH Active vs Passive Message-ID: <4a9edb810911301857w43df369ap6994eabc00c8f57c@mail.gmail.com> I'm wondering what everyones thoughts are in regards to FTTH using Active Ethernet or Passive. I work for a FTTH Provider that has done Active Ethernet on a few networks so I'm always biased in discussions, but I don't know anyone with experience in PON. I've read before that almost all PON technology is proprietary, locking you into a specific hardware vendor. However I think this is changing or has already changed, opening PON up for interoperability. Can anyone confirm this? Thanks in advance. :Luke Marrott From sfouant at shortestpathfirst.net Mon Nov 30 21:02:01 2009 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Mon, 30 Nov 2009 22:02:01 -0500 Subject: DNS query analyzer In-Reply-To: References: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> <000701ca7230$d2467530$76d35f90$@net> Message-ID: <000801ca7232$a8ca4540$fa5ecfc0$@net> > -----Original Message----- > From: Raymond Dijkxhoorn [mailto:raymond at prolocation.net] > Sent: Monday, November 30, 2009 9:54 PM > > > I don't think it's being actively maintained at the moment but you > should be > > able to find it on the NLnet Labs site - > > http://www.nlnetlabs.nl/projects/dns-analyzer/ > > I very recently asked the maintainers of that package if its still > under > development but i heard if was unfortunately dropped. It would be nice if we could convince them to release the source code into the public domain. I'm sure there are a few people who would find it highly useful and would work on it to add to its utility. Stefan Fouant www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From jay at west.net Mon Nov 30 21:19:48 2009 From: jay at west.net (Jay Hennigan) Date: Mon, 30 Nov 2009 19:19:48 -0800 Subject: DNS query analyzer In-Reply-To: <000801ca7232$a8ca4540$fa5ecfc0$@net> References: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> <000701ca7230$d2467530$76d35f90$@net> <000801ca7232$a8ca4540$fa5ecfc0$@net> Message-ID: <4B148B54.3010309@west.net> Stefan Fouant wrote: >> -----Original Message----- >> From: Raymond Dijkxhoorn [mailto:raymond at prolocation.net] >>> I don't think it's being actively maintained at the moment but you >> should be >>> able to find it on the NLnet Labs site - >>> http://www.nlnetlabs.nl/projects/dns-analyzer/ >> I very recently asked the maintainers of that package if its still >> under >> development but i heard if was unfortunately dropped. > > It would be nice if we could convince them to release the source code into > the public domain. I'm sure there are a few people who would find it highly > useful and would work on it to add to its utility. The source (versions 0.2.0 and 0.3.0) is available at the above URL and there is a GPL license in the tarball. -- 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 jtk at cymru.com Mon Nov 30 22:11:05 2009 From: jtk at cymru.com (John Kristoff) Date: Mon, 30 Nov 2009 22:11:05 -0600 Subject: DNS query analyzer In-Reply-To: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> References: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> Message-ID: <20091130221105.649dfe53@t61p> On Mon, 30 Nov 2009 16:06:45 -0800 Joseph Jackson wrote: > Anyone know of a tool that can take a pcap file from wireshark that > was used to collect dns queries and then spit out statistics about > the queries such as RTT and timeouts? Nothing with RTT and timeouts in this, but it could probably be adapted with an additional, rudimentary subroutine to try summarizing that too: If you or no one else comes up with something or modifies this to do it, give me a holler and I'll whip something up for you. As is, it'll count DNS messages, header flags and give a top X list of qnames seen. It uses the somewhat limited NetPacket modules, but it would be easy to either switch wholesale to the Net::Packet modules or pull in just those needed (e.g. VLAN and IPv6 support). It is what it is, hopefully its of use. John From meekjt at gmail.com Mon Nov 30 23:05:38 2009 From: meekjt at gmail.com (Jon Meek) Date: Tue, 1 Dec 2009 00:05:38 -0500 Subject: DNS query analyzer In-Reply-To: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> References: <695277448C537A469D28FF68D0938C8372F23B5EDB@EXMBX04.exchhosting.com> Message-ID: I have a "DNSaudit" program that takes libpcap (wireshark/tcpdump) files. Originally its purpose was to identify AnswersWithoutQuestions, and QuestionsWithoutAnswers when we were having some routing issues causing answers to return via a different ISP. Later I added statistics for response time by server. I suggest trying the other programs mentioned first, I am the only user of my program... Jon On Mon, Nov 30, 2009 at 7:06 PM, Joseph Jackson wrote: > Hey List! > > Anyone know of a tool that can take a pcap file from wireshark that was used to collect dns queries and then spit out statistics about the queries such as RTT and timeouts? > > > Thanks! > > Joseph