From paul at jakma.org Tue Sep 1 05:55:45 2009 From: paul at jakma.org (Paul Jakma) Date: Tue, 1 Sep 2009 11:55:45 +0100 (BST) Subject: Link capacity upgrade threshold In-Reply-To: <4A9A7011.1010908@foobar.org> References: <3c3e3fca0908292115s12039efch61c0b1138530d814@mail.gmail.com> <4A9A7011.1010908@foobar.org> Message-ID: On Sun, 30 Aug 2009, Nick Hilliard wrote: > In order to get a really good idea of what's going on at a > microburst level, you would need to poll as often as it takes to > fill the buffer of the port in question. This is not feasible in > the general case, which is why we resort to hacks like QoS to make > sure that when there is congestion, it is handled semi-sensibly. Or some enterprising vendor could start recording utilisation stats? regards, -- Paul Jakma paul at jakma.org Key ID: 64A2FF6A Fortune: Try to value useful qualities in one who loves you. From john-nanog at johnpeach.com Tue Sep 1 07:06:50 2009 From: john-nanog at johnpeach.com (John Peach) Date: Tue, 1 Sep 2009 08:06:50 -0400 Subject: Beware: a very bad precedent set In-Reply-To: <200908312212.n7VMCXtO017475@drugs.dv.isc.org> References: <737736526.145171251754543998.JavaMail.root@zimbra.wbsconnect.com> <4A9C45D2.1000605@brightok.net> <200908312212.n7VMCXtO017475@drugs.dv.isc.org> Message-ID: <20090901080650.68d73726@jpeach-desktop.1425mad.mountsinai.org> On Tue, 01 Sep 2009 08:12:33 +1000 Mark Andrews wrote: > > In message <4A9C45D2.1000605 at brightok.net>, Jack Bates writes: > > nanog at wbsconnect.com wrote: > > > Any and all nefarious activity alleged in this lawsuit was > > > conducted by a c > > ustomer, of a customer, of a customer yet the hosting provider was > > found liab le, not the actual criminal manufacturing and selling > > the fakes. > > > > > > We had all better watch our backs since it seems that claims of > > > not being a > > ble to inspected tens of millions of packets per second is no > > longer a viable excuse. > > > > > > > Hmmm. I thought DMCA made it quite clear that a service provider > > cannot ignore reports. > > > > "The Akanoc Defendants___ specific business model of providing > > unmanaged server capacity to web hosting resellers does not exempt > > them from taking active steps to effectively prevent infringing > > activity upon notification from an intellectual property rights > > owner. " > > > > I consider that the more important statement in the article. The > > "upon > notification" being the largest issue. Don't know if DMCA covers > > anything outside the scope of copyright, but I think it's been > > generally accepted that ignoring reports of infringement can bring > > about liability. > > > > Jack > > It will be interesting to see the court cases against ISP's that > don't shutdown other illegal activities once they have been notified. > abuse@ better not be a blackhole or you are putting yourself at risk > based on this. ..and not before time. -- John From vbono at 2nplus1.com Tue Sep 1 13:59:55 2009 From: vbono at 2nplus1.com (Vincent J. Bono) Date: Tue, 01 Sep 2009 14:59:55 -0400 Subject: QWEST in Washington DC Contact Message-ID: <0KPB00I6C3FG31@lswsmta04.nmcc.sprintspectrum.com> If anyone from Qwest with site access to 1500 Eckington is around please reply to me privately. Have an urgent issue. -Vin From agrier at poofygoof.com Tue Sep 1 14:18:38 2009 From: agrier at poofygoof.com (Aaron J. Grier) Date: Tue, 1 Sep 2009 12:18:38 -0700 Subject: Link capacity upgrade threshold In-Reply-To: References: <3c3e3fca0908292115s12039efch61c0b1138530d814@mail.gmail.com> <4A9A7011.1010908@foobar.org> Message-ID: <20090901191838.GO8127@arwen.poofy.goof.com> On Tue, Sep 01, 2009 at 11:55:45AM +0100, Paul Jakma wrote: > On Sun, 30 Aug 2009, Nick Hilliard wrote: > >In order to get a really good idea of what's going on at a microburst > >level, you would need to poll as often as it takes to fill the buffer > >of the port in question. This is not feasible in the general case, > >which is why we resort to hacks like QoS to make sure that when there > >is congestion, it is handled semi-sensibly. > > Or some enterprising vendor could start recording utilisation stats? do any router vendors provide something akin to hardware latches to keep track of highest buffer fill levels? poll as frequently/infrequently as you like... -- Aaron J. Grier | "Not your ordinary poofy goof." | agrier at poofygoof.com From up at 3.am Tue Sep 1 14:28:35 2009 From: up at 3.am (up at 3.am) Date: Tue, 1 Sep 2009 15:28:35 -0400 (EDT) Subject: POP3 DoS attacks and mailanyone.net? Message-ID: For the first time since I can remember, my POP3 server was effectively shut down by too many simultaneous connections today. The first fix I tried was to raise the number of connections from the default 40 to 100, but the problem soon returned. I finally ipfw'd off the offending IP (98.190.204.2 for anyone interested), then went to look for other possible offenders in the log. I noticed several thousand connections today to a few dozen former users from 4 IPs from 208.70.128.0/21. One of the users was actually legitimate. These IPs belong to mailanyone.net. The tech contact in their ARIN record is listed as: OrgTechHandle: BHE57-ARIN OrgTechName: Heitman, Bryan OrgTechPhone: +1-816-587-4700 OrgTechEmail: hostmaster at mailanyone.net However, that phone number goes to a UPS store that has no idea what I'm talking about. I then dialed their suppseod NOC number: Comment: FuseMail, LLC Network Operations Center contact Comment: 877.888.3873 x3 I am on hold with that number right now with some very loud and annoying music. Can anyone offer any insight as to these people and how/who to deal with there? Would a provider be amiss to just block their entire /21? TIA, James Smallacombe PlantageNet, Inc. CEO and Janitor up at 3.am http://3.am ========================================================================= From WJohnston at induscorp.com Tue Sep 1 14:58:42 2009 From: WJohnston at induscorp.com (Winn Johnston) Date: Tue, 1 Sep 2009 15:58:42 -0400 Subject: POP3 DoS attacks and mailanyone.net? In-Reply-To: References: Message-ID: Issues with gmail.com here in DC Winn Johnston ________________________________________ From: up at 3.am [up at 3.am] Sent: Tuesday, September 01, 2009 3:28 PM To: nanog at nanog.org Subject: POP3 DoS attacks and mailanyone.net? For the first time since I can remember, my POP3 server was effectively shut down by too many simultaneous connections today. The first fix I tried was to raise the number of connections from the default 40 to 100, but the problem soon returned. I finally ipfw'd off the offending IP (98.190.204.2 for anyone interested), then went to look for other possible offenders in the log. I noticed several thousand connections today to a few dozen former users from 4 IPs from 208.70.128.0/21. One of the users was actually legitimate. These IPs belong to mailanyone.net. The tech contact in their ARIN record is listed as: OrgTechHandle: BHE57-ARIN OrgTechName: Heitman, Bryan OrgTechPhone: +1-816-587-4700 OrgTechEmail: hostmaster at mailanyone.net However, that phone number goes to a UPS store that has no idea what I'm talking about. I then dialed their suppseod NOC number: Comment: FuseMail, LLC Network Operations Center contact Comment: 877.888.3873 x3 I am on hold with that number right now with some very loud and annoying music. Can anyone offer any insight as to these people and how/who to deal with there? Would a provider be amiss to just block their entire /21? TIA, James Smallacombe PlantageNet, Inc. CEO and Janitor up at 3.am http://3.am ========================================================================= ______________________________________________________________________ This inbound email was scanned by MessageLabs _____________________________________________________________________ ______________________________________________________________________ This email was scanned by MessageLabs _____________________________________________________________________ From jwininger at indianafiber.net Tue Sep 1 15:01:46 2009 From: jwininger at indianafiber.net (Jim Wininger) Date: Tue, 01 Sep 2009 16:01:46 -0400 Subject: Issues with Gmail Message-ID: Anyone else seeing issues with gmail? -- Jim Wininger From chaim.rieger at gmail.com Tue Sep 1 15:04:28 2009 From: chaim.rieger at gmail.com (chaim.rieger at gmail.com) Date: Tue, 1 Sep 2009 20:04:28 +0000 Subject: Issues with Gmail Message-ID: <826079248-1251835481-cardhu_decombobulator_blackberry.rim.net-1679427793-@bda630.bisx.prod.on.blackberry> Full gmail outage as per the status page EOM ------Original Message------ From: Jim Wininger To: nanog at nanog.org Subject: Issues with Gmail Sent: Sep 1, 2009 13:01 Anyone else seeing issues with gmail? -- Jim Wininger Sent via BlackBerry from T-Mobile From rapple at rapidlink.com Tue Sep 1 15:05:16 2009 From: rapple at rapidlink.com (Raleigh Apple) Date: Tue, 01 Sep 2009 16:05:16 -0400 Subject: Issues with Gmail In-Reply-To: References: Message-ID: <4A9D7E7C.60401@rapidlink.com> Yes, I'm seeing errors like: Google Error Server Error The server encountered a temporary error and could not complete your request. Please try again in 30 seconds. r Jim Wininger wrote: > Anyone else seeing issues with gmail? > From kgasso-lists at visp.net Tue Sep 1 15:05:03 2009 From: kgasso-lists at visp.net (Kameron Gasso) Date: Tue, 01 Sep 2009 13:05:03 -0700 Subject: Issues with Gmail In-Reply-To: References: Message-ID: <4A9D7E6F.9060401@visp.net> Jim Wininger wrote: > Anyone else seeing issues with gmail? Yep, it's been throwing 502 HTTP errors for about 25 minutes now. We've been getting a handful of calls from frantic Gmail users wondering why we broke their interwebs. ;) -- Kameron Gasso | Senior Systems Administrator | visp.net Direct: 541-955-6903 | Fax: 541-471-0821 From nathana at fsr.com Tue Sep 1 15:05:51 2009 From: nathana at fsr.com (Nathan Anderson) Date: Tue, 1 Sep 2009 13:05:51 -0700 Subject: Issues with Gmail In-Reply-To: References: Message-ID: The minute I saw your question, I tabbed over to an open session, and sure enough... -- Nathan Anderson First Step Internet, LLC nathana at fsr.com -----Original Message----- From: Jim Wininger [mailto:jwininger at indianafiber.net] Sent: Tuesday, September 01, 2009 1:02 PM To: nanog at nanog.org Subject: Issues with Gmail Anyone else seeing issues with gmail? -- Jim Wininger From abalashov at evaristesys.com Tue Sep 1 15:07:09 2009 From: abalashov at evaristesys.com (Alex Balashov) Date: Tue, 01 Sep 2009 16:07:09 -0400 Subject: Issues with Gmail In-Reply-To: References: Message-ID: <4A9D7EED.9060707@evaristesys.com> Jim Wininger wrote: > Anyone else seeing issues with gmail? More specifically? -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 From SBrown at clackesd.k12.or.us Tue Sep 1 15:06:21 2009 From: SBrown at clackesd.k12.or.us (Scott Brown/Clack/ESD) Date: Tue, 1 Sep 2009 13:06:21 -0700 Subject: Issues with Gmail In-Reply-To: References: Message-ID: Gmail and Google Apps are down in our neck of the woods. -- Scott From: Jim Wininger To: Date: 09/01/2009 01:02 PM Subject: Issues with Gmail Anyone else seeing issues with gmail? -- Jim Wininger From sauron at the-infinite.org Tue Sep 1 15:11:57 2009 From: sauron at the-infinite.org (Dominic J. Eidson) Date: Tue, 1 Sep 2009 15:11:57 -0500 (CDT) Subject: Issues with Gmail In-Reply-To: <4A9D7E6F.9060401@visp.net> References: <4A9D7E6F.9060401@visp.net> Message-ID: It appears to be much more a problem with gmail (the MUA) than gmail (the MDA). Gmail/imap appears to be working fine, at least from AUS. - d. On Tue, 1 Sep 2009, Kameron Gasso wrote: > Jim Wininger wrote: >> Anyone else seeing issues with gmail? > > Yep, it's been throwing 502 HTTP errors for about 25 minutes now. We've > been getting a handful of calls from frantic Gmail users wondering why > we broke their interwebs. ;) > > -- Dominic J. Eidson "Baruk Khazad! Khazad ai-menu!" - Gimli ---------------------------------------------------------------------------- http://www.dominiceidson.com/ From shasan at email.unc.edu Tue Sep 1 15:12:18 2009 From: shasan at email.unc.edu (shasan) Date: Tue, 01 Sep 2009 16:12:18 -0400 Subject: Issues with Gmail In-Reply-To: References: Message-ID: <244ae7d2e2f97674b4a31f09904b54cd@email.unc.edu> Yup, it's down. http://thenextweb.com/2009/09/01/google-experiencing-downtime-world/# http://www.google.com/appsstatus#hl=en Been down for the past twenty minutes or so for me in Chapel Hill, NC. Other Google services seem to be working fine. Shaddi On Tue, 01 Sep 2009 16:01:46 -0400, Jim Wininger wrote: > Anyone else seeing issues with gmail? From mike at sabbota.com Tue Sep 1 15:14:01 2009 From: mike at sabbota.com (mike at sabbota.com) Date: Tue, 1 Sep 2009 20:14:01 +0000 Subject: Issues with Gmail Message-ID: <87641694-1251836040-cardhu_decombobulator_blackberry.rim.net-358882098-@bda001.bisx.prod.on.blackberry> I think it just may be front end services that are impacted. I'm able to send/receive mail through my BB BIS gmail account. ------Original Message------ From: Nathan Anderson To: nanog at nanog.org Subject: RE: Issues with Gmail Sent: Sep 1, 2009 2:05 PM The minute I saw your question, I tabbed over to an open session, and sure enough... -- Nathan Anderson First Step Internet, LLC nathana at fsr.com -----Original Message----- From: Jim Wininger [mailto:jwininger at indianafiber.net] Sent: Tuesday, September 01, 2009 1:02 PM To: nanog at nanog.org Subject: Issues with Gmail Anyone else seeing issues with gmail? -- Jim Wininger Sent via BlackBerry by AT&T From mhernand1 at comcast.net Tue Sep 1 15:15:38 2009 From: mhernand1 at comcast.net (manolo hernandez) Date: Tue, 01 Sep 2009 16:15:38 -0400 Subject: Issues with Gmail In-Reply-To: References: Message-ID: <4A9D80EA.8070305@comcast.net> Same here. Complete outage Nathan Anderson wrote: > The minute I saw your question, I tabbed over to an open session, and sure enough... > From kevin at steadfast.net Tue Sep 1 15:15:57 2009 From: kevin at steadfast.net (Kevin Stange) Date: Tue, 01 Sep 2009 15:15:57 -0500 Subject: Issues with Gmail In-Reply-To: References: Message-ID: <4A9D80FD.90302@steadfast.net> Jim Wininger wrote: > Anyone else seeing issues with gmail? http://mail.google.com/support/?hl=en -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From tme at americafree.tv Tue Sep 1 15:20:28 2009 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 1 Sep 2009 16:20:28 -0400 Subject: Issues with Gmail In-Reply-To: <4A9D7EED.9060707@evaristesys.com> References: <4A9D7EED.9060707@evaristesys.com> Message-ID: <4B9ABE78-1007-48FD-8D53-AAC8E44FC48C@americafree.tv> From Spint EVD0 I get Unable to reach Gmail. Please check your internet connection. Trying to reconnect now? Marshall On Sep 1, 2009, at 4:07 PM, Alex Balashov wrote: > Jim Wininger wrote: > >> Anyone else seeing issues with gmail? > > More specifically? > > -- > Alex Balashov - Principal > Evariste Systems > Web : http://www.evaristesys.com/ > Tel : (+1) (678) 954-0670 > Direct : (+1) (678) 954-0671 > > From jeff-kell at utc.edu Tue Sep 1 15:25:00 2009 From: jeff-kell at utc.edu (Jeff Kell) Date: Tue, 01 Sep 2009 16:25:00 -0400 Subject: Issues with Gmail In-Reply-To: <87641694-1251836040-cardhu_decombobulator_blackberry.rim.net-358882098-@bda001.bisx.prod.on.blackberry> References: <87641694-1251836040-cardhu_decombobulator_blackberry.rim.net-358882098-@bda001.bisx.prod.on.blackberry> Message-ID: <4A9D831C.4080908@utc.edu> mike at sabbota.com wrote: > I think it just may be front end services that are impacted. I'm able to send/receive mail through my BB BIS gmail account. IMAP seems to still be up. Jeff From glenn.s.johnson at gmail.com Tue Sep 1 15:25:12 2009 From: glenn.s.johnson at gmail.com (Glenn Johnson) Date: Tue, 1 Sep 2009 13:25:12 -0700 Subject: Issues with Gmail In-Reply-To: References: Message-ID: FWIW: http://gmail.com doesn't work for me either right now, but I've read the whole "Issues with Gmail" thread and posted this email via GMail POP and GMail SMTP.... Glenn.S.Johnson at gmail.com On Sep 1, 2009, at 1:06 PM, Scott Brown/Clack/ESD wrote: > Gmail and Google Apps are down in our neck of the woods. > > > -- > Scott > > > > > From: Jim Wininger > > To: > > Date: 09/01/2009 01:02 PM > > Subject: Issues with Gmail > > > > > > > Anyone else seeing issues with gmail? > -- > Jim Wininger > > > > > > From nathana at fsr.com Tue Sep 1 15:27:45 2009 From: nathana at fsr.com (Nathan Anderson) Date: Tue, 1 Sep 2009 13:27:45 -0700 Subject: Issues with Gmail In-Reply-To: <4A9D7E6F.9060401@visp.net> References: <4A9D7E6F.9060401@visp.net> Message-ID: Kameron Gasso wrote: > Yep, it's been throwing 502 HTTP errors for about 25 minutes now. > We've been getting a handful of calls from frantic Gmail users > wondering why we broke their interwebs. ;) Somehow it's always our fault, isn't it? :P (Sorry about the earlier top-posting...have been forced to switch to Outlook, and just discovered Outlook QuiteFix.) -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From setient at gmail.com Tue Sep 1 15:29:18 2009 From: setient at gmail.com (Ronald Cotoni) Date: Tue, 01 Sep 2009 15:29:18 -0500 Subject: Issues with Gmail In-Reply-To: References: <4A9D7E6F.9060401@visp.net> Message-ID: <4A9D841E.5000208@gmail.com> Dominic J. Eidson wrote: > > It appears to be much more a problem with gmail (the MUA) than gmail > (the MDA). > > Gmail/imap appears to be working fine, at least from AUS. > > - d. > > On Tue, 1 Sep 2009, Kameron Gasso wrote: > >> Jim Wininger wrote: >>> Anyone else seeing issues with gmail? >> >> Yep, it's been throwing 502 HTTP errors for about 25 minutes now. We've >> been getting a handful of calls from frantic Gmail users wondering why >> we broke their interwebs. ;) >> >> > Works fine from chicago via imap From andrey.gordon at gmail.com Tue Sep 1 15:29:53 2009 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Tue, 1 Sep 2009 16:29:53 -0400 Subject: Issues with Gmail In-Reply-To: <87641694-1251836040-cardhu_decombobulator_blackberry.rim.net-358882098-@bda001.bisx.prod.on.blackberry> References: <87641694-1251836040-cardhu_decombobulator_blackberry.rim.net-358882098-@bda001.bisx.prod.on.blackberry> Message-ID: <78382527-2491-4011-B28D-CD0A915AC540@gmail.com> Seems to work with IMAP/SMTP, but no luck on the web UI in boston. On Sep 1, 2009, at 4:14 PM, mike at sabbota.com wrote: > > I think it just may be front end services that are impacted. I'm > able to send/receive mail through my BB BIS gmail account. > > ------Original Message------ > From: Nathan Anderson > To: nanog at nanog.org > Subject: RE: Issues with Gmail > Sent: Sep 1, 2009 2:05 PM > > The minute I saw your question, I tabbed over to an open session, > and sure enough... > > -- > Nathan Anderson > First Step Internet, LLC > nathana at fsr.com > > -----Original Message----- > From: Jim Wininger [mailto:jwininger at indianafiber.net] > Sent: Tuesday, September 01, 2009 1:02 PM > To: nanog at nanog.org > Subject: Issues with Gmail > > Anyone else seeing issues with gmail? > -- > Jim Wininger > > > > > > > Sent via BlackBerry by AT&T > From andrew.fried at gmail.com Tue Sep 1 15:30:47 2009 From: andrew.fried at gmail.com (Andrew Fried) Date: Tue, 01 Sep 2009 16:30:47 -0400 Subject: POP3 DoS attacks and mailanyone.net? In-Reply-To: References: Message-ID: <4A9D8477.9020302@gmail.com> Hummm. Looking through some of my data I found that the domain NORTHROANOKE.COM resolves to 98.190.204.2 (the first attack vector). That box is running Microsoft Business Server 2003. NORTHROANOKE.COM appears to be some kind of assisted living facility in Roanoke, Virginia (based on whois). Doesn't look gmail related from that perspective... Andrew Andrew Fried andrew.fried at gmail.com Winn Johnston wrote: > Issues with gmail.com > > here in DC > > Winn Johnston > ________________________________________ > From: up at 3.am [up at 3.am] > Sent: Tuesday, September 01, 2009 3:28 PM > To: nanog at nanog.org > Subject: POP3 DoS attacks and mailanyone.net? > > For the first time since I can remember, my POP3 server was effectively > shut down by too many simultaneous connections today. The first fix I > tried was to raise the number of connections from the default 40 to 100, > but the problem soon returned. > > I finally ipfw'd off the offending IP (98.190.204.2 for anyone > interested), then went to look for other possible offenders in the log. I > noticed several thousand connections today to a few dozen former users > from 4 IPs from 208.70.128.0/21. One of the users was actually > legitimate. > > These IPs belong to mailanyone.net. The tech contact in their ARIN record > is listed as: > > OrgTechHandle: BHE57-ARIN > OrgTechName: Heitman, Bryan > OrgTechPhone: +1-816-587-4700 > OrgTechEmail: hostmaster at mailanyone.net > > However, that phone number goes to a UPS store that has no idea what I'm > talking about. I then dialed their suppseod NOC number: > > Comment: FuseMail, LLC Network Operations Center contact > Comment: 877.888.3873 x3 > > I am on hold with that number right now with some very loud and annoying > music. > > Can anyone offer any insight as to these people and how/who to deal with > there? > > Would a provider be amiss to just block their entire /21? > > TIA, > > James Smallacombe PlantageNet, Inc. CEO and Janitor > up at 3.am http://3.am > ========================================================================= > > > ______________________________________________________________________ > This inbound email was scanned by MessageLabs > _____________________________________________________________________ > > ______________________________________________________________________ > This email was scanned by MessageLabs > _____________________________________________________________________ > From nick at foobar.org Tue Sep 1 15:32:57 2009 From: nick at foobar.org (Nick Hilliard) Date: Tue, 01 Sep 2009 21:32:57 +0100 Subject: Issues with Gmail In-Reply-To: References: Message-ID: <4A9D84F9.6000702@foobar.org> On 01/09/2009 21:01, Jim Wininger wrote: > Anyone else seeing issues with gmail? Down, definitely down. Call the White House! It should be clear that the root cause here is a lack of regulation, so could someone phone Sen. Jay Rockefeller (D-WV) _urgently_ and advise him that the only way to stop problems like this happening in future is to ensure that the government has a firm grip of the steering wheel at all these web2.0 companies. Also, rather than letting these trendy, fashionable Googlers attempt to fix critical systems like gmail, that real service problems like this ought to be fixed by accredited cyber security professionals, preferably ones which can demonstrate their computing ability by wearing a suit and tie. If we've learned anything in the telecommunications world, it's that if any organisation can respond quickly to a problem and deal with it efficiently and effectively, it's a Government. Nick From deleskie at gmail.com Tue Sep 1 15:34:51 2009 From: deleskie at gmail.com (deleskie at gmail.com) Date: Tue, 1 Sep 2009 20:34:51 +0000 Subject: Issues with Gmail Message-ID: <1284177788-1251837318-cardhu_decombobulator_blackberry.rim.net-390559378-@bda023.bisx.prod.on.blackberry> Working on my BB here. Acct with rogers in canada but right now on ATT in Vegas ------Original Message------ From: Jeff Kell To: mike at sabbota.com Cc: nanog at nanog.org Subject: Re: Issues with Gmail Sent: Sep 1, 2009 4:25 PM mike at sabbota.com wrote: > I think it just may be front end services that are impacted. I'm able to send/receive mail through my BB BIS gmail account. IMAP seems to still be up. Jeff Sent from my BlackBerry device on the Rogers Wireless Network From egon at egon.cc Tue Sep 1 15:34:45 2009 From: egon at egon.cc (James Downs) Date: Tue, 1 Sep 2009 13:34:45 -0700 Subject: Issues with Gmail In-Reply-To: References: <4A9D7E6F.9060401@visp.net> Message-ID: <45F7A2B9-8591-4D63-B123-FFBD38AF1404@egon.cc> On Sep 1, 2009, at 1:11 PM, Dominic J. Eidson wrote: > It appears to be much more a problem with gmail (the MUA) than > gmail (the MDA). > > Gmail/imap appears to be working fine, at least from AUS. Same thing here in the US. Pop/Imap access remains solid. I never use the web interface. -j From tome.nerd at gmail.com Tue Sep 1 15:38:15 2009 From: tome.nerd at gmail.com (tome.nerd at gmail.com) Date: Tue, 01 Sep 2009 20:38:15 +0000 Subject: Issues with Gmail In-Reply-To: Message-ID: <001636833e6e35a87a04728a2103@google.com> access via igoogle via a web client works as well ... On Sep 1, 2009 4:25pm, Glenn Johnson wrote: > FWIW: > http://gmail.com doesn't work for me either right now, but I've read the > whole "Issues with Gmail" thread and posted this email via GMail POP and > GMail SMTP.... > Glenn.S.Johnson at gmail.com > On Sep 1, 2009, at 1:06 PM, Scott Brown/Clack/ESD wrote: > Gmail and Google Apps are down in our neck of the woods. > -- > Scott > From: Jim Wininger jwininger at indianafiber.net> > To: nanog at nanog.org> > Date: 09/01/2009 01:02 PM > Subject: Issues with Gmail > Anyone else seeing issues with gmail? > -- > Jim Wininger From up at 3.am Tue Sep 1 15:38:38 2009 From: up at 3.am (up at 3.am) Date: Tue, 1 Sep 2009 16:38:38 -0400 (EDT) Subject: Issues with Gmail In-Reply-To: <4A9D831C.4080908@utc.edu> References: <87641694-1251836040-cardhu_decombobulator_blackberry.rim.net-358882098-@bda001.bisx.prod.on.blackberry> <4A9D831C.4080908@utc.edu> Message-ID: pop.gmail.com is answering on port 995 (pop3 ssl) as well, so I think it's safe to assume this is probably a httpd-side problem. On Tue, 1 Sep 2009, Jeff Kell wrote: > mike at sabbota.com wrote: >> I think it just may be front end services that are impacted. I'm able to send/receive mail through my BB BIS gmail account. > > IMAP seems to still be up. > > Jeff > > James Smallacombe PlantageNet, Inc. CEO and Janitor up at 3.am http://3.am ========================================================================= From nanog-amuse at foofus.com Tue Sep 1 15:56:50 2009 From: nanog-amuse at foofus.com (AMuse) Date: Tue, 01 Sep 2009 13:56:50 -0700 Subject: Issues with Gmail In-Reply-To: <4A9D84F9.6000702@foobar.org> References: <4A9D84F9.6000702@foobar.org> Message-ID: <4A9D8A92.9070309@foofus.com> As a government-employed computer security guy who has never owned or worn a suit OR tie, I feel entitled to ask... WTF? Nick Hilliard wrote: > On 01/09/2009 21:01, Jim Wininger wrote: >> Anyone else seeing issues with gmail? > > Down, definitely down. Call the White House! > > It should be clear that the root cause here is a lack of regulation, > so could someone phone Sen. Jay Rockefeller (D-WV) _urgently_ and > advise him that the only way to stop problems like this happening in > future is to ensure that the government has a firm grip of the > steering wheel at all these web2.0 companies. Also, rather than > letting these trendy, fashionable Googlers attempt to fix critical > systems like gmail, that real service problems like this ought to be > fixed by accredited cyber security professionals, preferably ones > which can demonstrate their computing ability by wearing a suit and tie. > > If we've learned anything in the telecommunications world, it's that > if any organisation can respond quickly to a problem and deal with it > efficiently and effectively, it's a Government. > > Nick From Jon.Kibler at aset.com Tue Sep 1 16:00:11 2009 From: Jon.Kibler at aset.com (Jon Kibler) Date: Tue, 01 Sep 2009 17:00:11 -0400 Subject: Issues with Gmail In-Reply-To: References: <87641694-1251836040-cardhu_decombobulator_blackberry.rim.net-358882098-@bda001.bisx.prod.on.blackberry> <4A9D831C.4080908@utc.edu> Message-ID: <4A9D8B5B.5030904@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 up at 3.am wrote: > > pop.gmail.com is answering on port 995 (pop3 ssl) as well, so I think > it's safe to assume this is probably a httpd-side problem. > > On Tue, 1 Sep 2009, Jeff Kell wrote: > Google says they have issues with gmail: http://gmailblog.blogspot.com/2009/09/todays-gmail-problems.html - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-813-2924 (NEW!) s: 843-564-4224 http://www.linkedin.com/in/jonrkibler My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqdi1sACgkQUVxQRc85QlOAuACgn10QwyDFjGkMmsf8EmU3FO7Q MJgAn3364ABeTm+MyrCQqDiZMVOAXwS+ =iCs+ -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From jason at lixfeld.ca Tue Sep 1 16:01:03 2009 From: jason at lixfeld.ca (Jason Lixfeld) Date: Tue, 1 Sep 2009 17:01:03 -0400 Subject: Issues with Gmail In-Reply-To: <45F7A2B9-8591-4D63-B123-FFBD38AF1404@egon.cc> References: <4A9D7E6F.9060401@visp.net> <45F7A2B9-8591-4D63-B123-FFBD38AF1404@egon.cc> Message-ID: On 2009-09-01, at 4:34 PM, James Downs wrote: > > On Sep 1, 2009, at 1:11 PM, Dominic J. Eidson wrote: > >> It appears to be much more a problem with gmail (the MUA) than >> gmail (the MDA). >> >> Gmail/imap appears to be working fine, at least from AUS. > > Same thing here in the US. Pop/Imap access remains solid. I never > use the web interface. > > -j > Google's 4:02 PM App Status update specifically said IMAP and POP were unaffected. http://www.google.com/appsstatus#rm=1&di=1&hl=en From dholmes at mwdh2o.com Tue Sep 1 17:00:56 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Tue, 1 Sep 2009 15:00:56 -0700 Subject: Link capacity upgrade threshold In-Reply-To: <20090901191838.GO8127@arwen.poofy.goof.com> References: <3c3e3fca0908292115s12039efch61c0b1138530d814@mail.gmail.com> <4A9A7011.1010908@foobar.org> <20090901191838.GO8127@arwen.poofy.goof.com> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E098CAC29@usmsxt104.mwd.h2o> Another approach to collecting buffer utilization is to infer such utilization from other variables. Active measurement of round trip times (RTT), packet loss, and jitter on a link-by-link basis is a reliable way of inferring interface queuing which leads to packet loss. A link that runs with good values on all 3 measures (low RTT, little or no packet loss, low jitter with small inter-packet arrival variation) can be deemed not a candidate for bandwidth upgrades. The key to active measurement is random measurement of the links so as to catch the bursts. The BRIX active measurement product (now owned by EXFO) is a good active measurement tool which randomizes probe data so as to, over time, collect a randomized sample of link behavior. -----Original Message----- From: Aaron J. Grier [mailto:agrier at poofygoof.com] Sent: Tuesday, September 01, 2009 12:19 PM To: nanog at nanog.org Subject: Re: Link capacity upgrade threshold On Tue, Sep 01, 2009 at 11:55:45AM +0100, Paul Jakma wrote: > On Sun, 30 Aug 2009, Nick Hilliard wrote: > >In order to get a really good idea of what's going on at a microburst > >level, you would need to poll as often as it takes to fill the buffer > >of the port in question. This is not feasible in the general case, > >which is why we resort to hacks like QoS to make sure that when there > >is congestion, it is handled semi-sensibly. > > Or some enterprising vendor could start recording utilisation stats? do any router vendors provide something akin to hardware latches to keep track of highest buffer fill levels? poll as frequently/infrequently as you like... -- Aaron J. Grier | "Not your ordinary poofy goof." | agrier at poofygoof.com From sam.oduor at gmail.com Tue Sep 1 17:19:11 2009 From: sam.oduor at gmail.com (Sam Oduor) Date: Wed, 2 Sep 2009 01:19:11 +0300 Subject: Issues with Gmail In-Reply-To: References: <4A9D7E6F.9060401@visp.net> <45F7A2B9-8591-4D63-B123-FFBD38AF1404@egon.cc> Message-ID: <4f16c5450909011519v5a8f2e3fu68366626c7887a28@mail.gmail.com> Back up .. Nairobi Kenya. On Wed, Sep 2, 2009 at 12:01 AM, Jason Lixfeld wrote: > On 2009-09-01, at 4:34 PM, James Downs wrote: > > >> On Sep 1, 2009, at 1:11 PM, Dominic J. Eidson wrote: >> >> It appears to be much more a problem with gmail (the MUA) than gmail >>> (the MDA). >>> >>> Gmail/imap appears to be working fine, at least from AUS. >>> >> >> Same thing here in the US. Pop/Imap access remains solid. I never use >> the web interface. >> >> -j >> >> > Google's 4:02 PM App Status update specifically said IMAP and POP were > unaffected. > > http://www.google.com/appsstatus#rm=1&di=1&hl=en > -- Samson Oduor From deepak at ai.net Tue Sep 1 17:29:35 2009 From: deepak at ai.net (Deepak Jain) Date: Tue, 1 Sep 2009 18:29:35 -0400 Subject: Link capacity upgrade threshold In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E098CAC29@usmsxt104.mwd.h2o> References: <3c3e3fca0908292115s12039efch61c0b1138530d814@mail.gmail.com> <4A9A7011.1010908@foobar.org> <20090901191838.GO8127@arwen.poofy.goof.com> <485ED9BA02629E4BBBA53AC892EDA50E098CAC29@usmsxt104.mwd.h2o> Message-ID: > do any router vendors provide something akin to hardware latches to > keep > track of highest buffer fill levels? poll as frequently/infrequently > as > you like... Without getting into each permutation of a device's architecture, aren't buffer fills really just buffer drops? There are means to determine this. Lots of vendors have configurable buffer pools for inter-device traffic levels that record high water levels as well. Deepak Jain AiNET From cgrundemann at gmail.com Tue Sep 1 17:34:08 2009 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 1 Sep 2009 16:34:08 -0600 Subject: FCC's Definition of Broadband Message-ID: <443de7ad0909011534p3a58b9acqab3ecb02a710ba6e@mail.gmail.com> All, I am forwarding this on for Susan Estrada with FirstMile.US, a fellow ISOC'er: FirstMile.US has formulated a survey for the tech community. The responses will be complied and sent to the FCC as a formal comment in the reply round to the FCC's "Comment Sought on Defining Broadband, NBP Public Notice #1." It's vital that the tech community respond. We know that it is almost impossible to free up the time to write an individual response. Hence, this survey. https://www.surveymonkey.com/s.aspx?sm=VNQhAteAwZ0JZHpFHky_2bTQ_3d_3d Twitter length: Take this FirstMile.US survey on the FCC definition of broadband. Responses will be submitted in the FCC reply round. http://bit.ly/CFnYR Please urge your colleagues to take 2 minutes and provide their very important opinions. The survey closes at 5 pm Pacific on September 7. The response to the FCC will be sent on September 8. Here is Susan's contact info: Susan Estrada FirstMile.US Big Broadband Everywhere Phone: 760-510-8406 x1 Web: http://www.firstmile.us Blog: http://demandbroadband.blogspot.com Thanks all! ~Chris -- Chris Grundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From jbates at brightok.net Tue Sep 1 17:49:35 2009 From: jbates at brightok.net (Jack Bates) Date: Tue, 01 Sep 2009 17:49:35 -0500 Subject: Link capacity upgrade threshold In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E098CAC29@usmsxt104.mwd.h2o> References: <3c3e3fca0908292115s12039efch61c0b1138530d814@mail.gmail.com> <4A9A7011.1010908@foobar.org> <20090901191838.GO8127@arwen.poofy.goof.com> <485ED9BA02629E4BBBA53AC892EDA50E098CAC29@usmsxt104.mwd.h2o> Message-ID: <4A9DA4FF.4090908@brightok.net> Holmes,David A wrote: > runs with good values on all 3 measures (low RTT, little or no packet > loss, low jitter with small inter-packet arrival variation) can be > deemed not a candidate for bandwidth upgrades. The key to active Sounds great, unless you don't own the router on the other side of the link which is subject to icmp filtering has a loaded RE, etc. If you pass the traffic through the routers to a reliable server, you'll be monitoring multiple links/routers and not just a single one. Jack From mehmet at akcin.net Tue Sep 1 18:01:01 2009 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 1 Sep 2009 16:01:01 -0700 Subject: picking up server vendor in a global scope.. Message-ID: <6D5B7067-6D56-49E2-9432-10005F8A351B@akcin.net> Hey, Let's say you want to pick a server vendor and you don't necessarily want to buy from one country and ship it to 50 different locations but instead buy them locally in each country, and also have local parties provide support. If you were to compare brands such as Dell, IBM, HP, Supermicro (or any other vendor?) which one you would recommend for this kind of approach? The server specs are fairly standard. Nothing extraordinary.. and expected support isn't also 7/24/365 but a decent next day -5 hours M- F type of deal.. thanks for responses.. Mehmet From jbates at brightok.net Tue Sep 1 18:57:42 2009 From: jbates at brightok.net (Jack Bates) Date: Tue, 01 Sep 2009 18:57:42 -0500 Subject: picking up server vendor in a global scope.. In-Reply-To: <6D5B7067-6D56-49E2-9432-10005F8A351B@akcin.net> References: <6D5B7067-6D56-49E2-9432-10005F8A351B@akcin.net> Message-ID: <4A9DB4F6.9000101@brightok.net> Mehmet Akcin wrote: > If you were to compare brands such as Dell, IBM, HP, Supermicro (or any > other vendor?) which one you would recommend for this kind of approach? loadbalancer.org picked supermicro and dell. Their Dell option has better US support. They partnered with local companies in the US for build/ship. I've been happy with the supermicro and standard support, though. Jack From eschwei at comcast.net Tue Sep 1 20:22:18 2009 From: eschwei at comcast.net (Ed Schweitzer) Date: Tue, 1 Sep 2009 21:22:18 -0400 Subject: Ready to get your federal computer license? In-Reply-To: <200908301938220.6B95064B.8300@clifden.donelan.com> References: <81CDFC77FB2DC54DB875D4F8FFC36CE00A923B797E@DSMAIL2HE.ds.ad.adp.com> <81CDFC77FB2DC54DB875D4F8FFC36CE00B7A593500@DSMAIL2HE.ds.ad.adp.com> <4A989C59.10801@emanon.com> <873a7bm3mm.fsf@mid.deneb.enyo.de> <4A99259E.8000202@emanon.com> <5E9C4E81-05BA-42F4-996B-F5BE79F8FEB4@jsyoung.net> <200908301938220.6B95064B.8300@clifden.donelan.com> Message-ID: <002201ca2b6b$d07cdf20$71769d60$@net> Sean, We had a clipped conversation years ago. I'm no longer with the DIA or the NSA or the ASA (an old '70's agency) I've worked at Columbia University in the 80's, the NSA in the 70's, and a lot of other places in the 90's and beyond. Because of my past, I have to "lurk"... However, and you must be getting tired after all these years but, please, keep interjecting your points. My 2 cents.... Best Ed -----Original Message----- From: Sean Donelan [mailto:sean at donelan.com] Sent: Sunday, August 30, 2009 7:46 PM To: nanog at nanog.org Subject: Re: Ready to get your federal computer license? On Sun, 30 Aug 2009, Jeff Young wrote: > The more troubling parts of this bill had to do with the President, > at his discretion, classifying parts of public networks as "critical > infrastructure" and so on. Whatever your opinion, get involved. Let your representatives know about your better ideas. > currently living overseas and finding all of this very amusing... If any other country has solved the problem of protecting Internet/data/cyber/critical/etc infrastructures and have some great ideas, it would be great to hear what those ideas are and how they did it. From kgraham at industrial-marshmallow.com Wed Sep 2 01:31:40 2009 From: kgraham at industrial-marshmallow.com (Kevin Graham) Date: Tue, 1 Sep 2009 23:31:40 -0700 (PDT) Subject: Link capacity upgrade threshold In-Reply-To: <6E4AE737-9BF0-46BC-AE81-26E443BE9D56@pch.net> References: <6E4AE737-9BF0-46BC-AE81-26E443BE9D56@pch.net> Message-ID: <75264.91571.qm@web1206.biz.mail.gq1.yahoo.com> > So, in summary: Your dropped packet counters are the ones to be looking at > as a measure of goodput, more than your utilization counters. Indeed. Capacity upgrades are best gauged by drop rates; bit-rates without this context are largely useless. When you're only aware of the RX side though, in the absence of an equivalent to BECN, what's the best way to track this? Do any of the Ethernet OAM standards expose this data? Similarly, could anyone share experiences with transit link upgrades to accommodate bursts? In the past, any requests to transit providers have been answered w/ the need for significant increases to 95%ile commits. While this makes sense from a sales perspective, there's a strong (but insufficient) engineering argument against it. From swmike at swm.pp.se Wed Sep 2 01:39:20 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 2 Sep 2009 08:39:20 +0200 (CEST) Subject: Link capacity upgrade threshold In-Reply-To: <75264.91571.qm@web1206.biz.mail.gq1.yahoo.com> References: <6E4AE737-9BF0-46BC-AE81-26E443BE9D56@pch.net> <75264.91571.qm@web1206.biz.mail.gq1.yahoo.com> Message-ID: On Tue, 1 Sep 2009, Kevin Graham wrote: > Indeed. Capacity upgrades are best gauged by drop rates; bit-rates > without this context are largely useless. If you're dropping packets, you're already over the cliff. Our job as ISP is to forward the packets our customers send to us, how is that compatible with upgrading links when they're so full that you're not only buffering but you're actually DROPPING packets? -- Mikael Abrahamsson email: swmike at swm.pp.se From randy at psg.com Wed Sep 2 04:05:36 2009 From: randy at psg.com (Randy Bush) Date: Wed, 02 Sep 2009 02:05:36 -0700 Subject: Issues with Gmail In-Reply-To: References: Message-ID: happens and services break. the internet is a wonderful demonstration of building a reliable network out of reliable components. but what we have with google mail (and apps) is two scary problems o way too many users relying on a single point of failure. so it makes the nyt when it breaks because of the number of users affected, and o too many foolish people giving their private data to a data miner to whom they actually yeild rights to those data and who seems to store them for a scary long time. randy From jbates at brightok.net Wed Sep 2 09:16:10 2009 From: jbates at brightok.net (Jack Bates) Date: Wed, 02 Sep 2009 09:16:10 -0500 Subject: Link capacity upgrade threshold In-Reply-To: References: <6E4AE737-9BF0-46BC-AE81-26E443BE9D56@pch.net> <75264.91571.qm@web1206.biz.mail.gq1.yahoo.com> Message-ID: <4A9E7E2A.9030003@brightok.net> Mikael Abrahamsson wrote: > > If you're dropping packets, you're already over the cliff. Our job as > ISP is to forward the packets our customers send to us, how is that > compatible with upgrading links when they're so full that you're not > only buffering but you're actually DROPPING packets? Many ISPs don't even watch the dropping rate. Packets can easily start dropping long before you reach an 80% average mark or may not drop until 90% utilization. Dropped packets are a safeguard measurement to detect data collision that fills the buffers. One could argue that setting QOS with larger buffers and monitoring the buffer usage is better than waiting for the drop. Jack From martin at theicelandguy.com Wed Sep 2 09:31:16 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Wed, 2 Sep 2009 10:31:16 -0400 Subject: picking up server vendor in a global scope.. In-Reply-To: <6D5B7067-6D56-49E2-9432-10005F8A351B@akcin.net> References: <6D5B7067-6D56-49E2-9432-10005F8A351B@akcin.net> Message-ID: On Tue, Sep 1, 2009 at 7:01 PM, Mehmet Akcin wrote: > Hey, > > Let's say you want to pick a server vendor and you don't necessarily want > to buy from one country and ship it to 50 different locations but instead > buy them locally in each country, and also have local parties provide > support. > > If you were to compare brands such as Dell, IBM, HP, Supermicro (or any > other vendor?) which one you would recommend for this kind of approach? > > The server specs are fairly standard. Nothing extraordinary.. and expected > support isn't also 7/24/365 but a decent next day -5 hours M-F type of > deal.. > > IMHO, resellers are your friend. Companies like CDW and Dimension Data provide excellent programs that maximize your spend internationally and reduce headaches in purchasing and shipping. Trying to buy country to country will almost for sure cost you far more than dealing with an international reseller. If I had to make a hardware purchase based on requirements I'd obviously make the approach requirements and cost based and work from there managing trade-offs. I have excellent experience with IBM and HP internationally. I can't speak for any others. Local service is generally not an issue with larger vendors like HP, Cisco, Juniper, IBM, et. Al. Where a vendor does not have their own in-house operation they usually have a partner that provides them a white-label service that is indistinguishable from their own for the most part. There are a few gotchas dealing with resellers and international. Whatever money you leave on the table in terms of discounts (hardware, software, and support) the reseller is going to get. Handling fees are also another large gotcha. Paying a 5% across the board handling fee on a 1M$ order equates to a $50,000 fee for managing the shipment of a pallet. All of those fees are negotiable on an order by order basis. Best, -M< -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From martin at theicelandguy.com Wed Sep 2 09:33:37 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Wed, 2 Sep 2009 10:33:37 -0400 Subject: Issues with Gmail In-Reply-To: References: Message-ID: On Wed, Sep 2, 2009 at 5:05 AM, Randy Bush wrote: > happens and services break. the internet is a wonderful > demonstration of building a reliable network out of reliable components. > > but what we have with google mail (and apps) is two scary problems > > o way too many users relying on a single point of failure. so it > makes the nyt when it breaks because of the number of users > affected, and > > o too many foolish people giving their private data to a data miner to > whom they actually yeild rights to those data and who seems to store > them for a scary long time. > Amazing what we will pay for free service. -M< -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From rbonica at juniper.net Wed Sep 2 10:33:56 2009 From: rbonica at juniper.net (Ron Bonica) Date: Wed, 2 Sep 2009 11:33:56 -0400 Subject: draft-iana-ipv4-examples Message-ID: <4A9E9064.2020608@juniper.net> Folks, Please take a look at draft-iana-ipv4-examples. This draft discusses the following subnet allocations: - 192.0.2.0/24 (TEST-NET-1) - 198.51.100.0/24 (TEST-NET-2) - 203.0.113.0/24 (TEST-NET-3) RFC 1166 allocates TEST-NET-1 for use in documentation. Because the other two have been used in documentation, the current draft proposes allocating them, too. There has been some discussion of this on the IETF general mailing list. If you care about this issue, please visit the mailing list archive and check out the thread "Re: Last Call: draft-iana-ipv4-examples (IPv4 Address Blocks Reserved for Documentation) to Informational RFC". Ron From jayfar at jayfar.com Wed Sep 2 10:39:52 2009 From: jayfar at jayfar.com (Jay Farrell) Date: Wed, 2 Sep 2009 11:39:52 -0400 Subject: Issues with Gmail In-Reply-To: References: Message-ID: <890005330909020839q3fff1424o7900d1c18a9079a6@mail.gmail.com> There's a post-mortem on the gmail blog: NANOG list http://gmailblog.blogspot.com/2009/09/more-on-todays-gmail-issue.html From exstatica at gmail.com Wed Sep 2 12:14:46 2009 From: exstatica at gmail.com (Andrew Matthews) Date: Wed, 2 Sep 2009 10:14:46 -0700 Subject: UUnet issues Message-ID: <10f379910909021014i38dc2d6nf47b40b9ddbc300b@mail.gmail.com> Anyone seeing issues getting to level 3, att, or ntt? I seem to be seeing packet loss going to level 3 mostly in LA. From exstatica at gmail.com Wed Sep 2 12:24:06 2009 From: exstatica at gmail.com (Andrew Matthews) Date: Wed, 2 Sep 2009 10:24:06 -0700 Subject: UUnet issues In-Reply-To: <7F418D8BD48CD24F9035A927272A3FA004948993@cx49.800onemail.com> References: <10f379910909021014i38dc2d6nf47b40b9ddbc300b@mail.gmail.com> <7F418D8BD48CD24F9035A927272A3FA004948993@cx49.800onemail.com> Message-ID: <10f379910909021024n4be02064vacde8f11207c44fd@mail.gmail.com> I'm getting packet loss at xe-11-0-0.edge1.SanJose3.level3.net http://pastebin.com/m3b30e87e From mathews at hawaii.edu Wed Sep 2 12:33:55 2009 From: mathews at hawaii.edu (Robert Mathews (OSIA)) Date: Wed, 02 Sep 2009 13:33:55 -0400 Subject: Issues with Gmail In-Reply-To: References: Message-ID: <4A9EAC83.3020806@hawaii.edu> On Wed, Sep 2, 2009 at 5:05 AM, Randy Bush wrote: > [....] the internet is a wonderful > demonstration of building a reliable network out of reliable components. > > but what we have with google mail (and apps) is two scary problems > > o way too many users relying on a single point of failure. so it > makes the nyt when it breaks because of the number of users > affected, and I choose to not assume to "what/which single point of failure" this reference by Randy applies. However, we can take confidence in the fact that Google's Gmail service architecture is distributed; not to be interpreted of course, as suggesting that within the distribution, there isn't a single point of failure. Perhaps, from a network operations point of view, the point needs elaboration. > o too many foolish people giving their private data to a data miner to > whom they actually yeild rights to those data and who seems to store > them for a scary long time. Naturally, this is a separate issue, and indeed a very prickly one, which is beyond the charter of NANOG. Therefore, I refrain from penning any thoughts on it. All the best, Robert. -- From mike at mtcc.com Wed Sep 2 12:54:09 2009 From: mike at mtcc.com (Michael Thomas) Date: Wed, 02 Sep 2009 10:54:09 -0700 Subject: Issues with Gmail In-Reply-To: <4A9EAC83.3020806@hawaii.edu> References: <4A9EAC83.3020806@hawaii.edu> Message-ID: <4A9EB141.4070407@mtcc.com> On 09/02/2009 10:33 AM, Robert Mathews (OSIA) wrote: > > On Wed, Sep 2, 2009 at 5:05 AM, Randy Bush wrote: >> [....] the internet is a wonderful >> demonstration of building a reliable network out of reliable components. >> >> but what we have with google mail (and apps) is two scary problems >> >> o way too many users relying on a single point of failure. so it >> makes the nyt when it breaks because of the number of users >> affected, and > > I choose to not assume to "what/which single point of failure" this > reference by Randy applies. However, we can take confidence in the > fact that Google's Gmail service architecture is distributed; not to be > interpreted of course, as suggesting that within the distribution, there > isn't a single point of failure. Perhaps, from a network operations > point of view, the point needs elaboration. I think that Randy might be conflating single point of failure with "resilience". Google, distributed on every level as it is, is still just one operator and in this case the lemmings faithfully followed each other into the sea. We've been on an anti-resilience binge for quite some time, accelerated to warp speed by the advent of the Internet itself. There's something to be said about not having all of your police scanners, etc, etc on the internet from a resilience standpoint, but the siren call is strong for good reasons too. Mike From ktokash at hotmail.com Wed Sep 2 13:04:59 2009 From: ktokash at hotmail.com (keith tokash) Date: Wed, 2 Sep 2009 18:04:59 +0000 Subject: Cisco Virtual Port-Channel experience In-Reply-To: References: Message-ID: If anyone has deployed VPC on the Cisco Nexus 5/7k platforms in a production environment I'd appreciate knowing how you feel about it (off-list please). This isn't a hunt for negative Cisco bashing, we're very interested in deploying this feature and would like to know what new problems we may be replacing our old ones with. Hopefully nothing serious. :) Keith Tokash _________________________________________________________________ Windows Live: Keep your friends up to date with what you do online. http://windowslive.com/Campaign/SocialNetworking?ocid=PID23285::T:WLMTAGL:ON:WL:en-US:SI_SB_online:082009 From exstatica at gmail.com Wed Sep 2 13:07:59 2009 From: exstatica at gmail.com (Andrew Matthews) Date: Wed, 2 Sep 2009 11:07:59 -0700 Subject: UUnet issues In-Reply-To: <16749689.241831251912393883.JavaMail.root@zimbra> References: <10f379910909021024n4be02064vacde8f11207c44fd@mail.gmail.com> <16749689.241831251912393883.JavaMail.root@zimbra> Message-ID: <10f379910909021107l4a1cc46cyfdfc44bb9eacd605@mail.gmail.com> just spoke to level 3, they did have some latency issues in los angeles. Seems to be resolved now. On Wed, Sep 2, 2009 at 10:26 AM, Tom Pipes wrote: > The latency between Level 3 and NTT seems to have diminished according to > the Internet Health Report. > > > ----- Original Message ----- > From: "Andrew Matthews" > To: nanog at nanog.org > Sent: Wednesday, September 2, 2009 12:24:06 PM GMT -06:00 US/Canada Central > Subject: Re: UUnet issues > > I'm getting packet loss at xe-11-0-0.edge1.SanJose3.level3.net > > http://pastebin.com/m3b30e87e > > From joelja at bogus.com Wed Sep 2 13:20:49 2009 From: joelja at bogus.com (joel jaeggli) Date: Wed, 02 Sep 2009 11:20:49 -0700 Subject: Issues with Gmail Message-ID: <4A9EB141.4070407@mtcc.com> Long before we has widespread commercial internet, we still had to have the backup plan for when the single highly fault tollerant entitity on which we were dependant on for a particular service went out. Sometimes, that plan is wait for restoration, whether it was because the bell systems got a bit melty on the long distance, or because your regional utility managed to melt down the power grid taking out both substations providing diverse feeds. Systemic but temporarly localized failured has existed as long as the weather. One can move the failure around but I think I can confidently assert that we'll never entirely eleminate it. Michael Thomas wrote: >On 09/02/2009 10:33 AM, Robert Mathews (OSIA) wrote: >> >> On Wed, Sep 2, 2009 at 5:05 AM, Randy Bush wrote: >>> [....] the internet is a wonderful >>> demonstration of building a reliable network out of reliable components. >>> >>> but what we have with google mail (and apps) is two scary problems >>> >>> o way too many users relying on a single point of failure. so it >>> makes the nyt when it breaks because of the number of users >>> affected, and >> >> I choose to not assume to "what/which single point of failure" this >> reference by Randy applies. However, we can take confidence in the >> fact that Google's Gmail service architecture is distributed; not to be >> interpreted of course, as suggesting that within the distribution, there >> isn't a single point of failure. Perhaps, from a network operations >> point of view, the point needs elaboration. > >I think that Randy might be conflating single point of failure with >"resilience". Google, distributed on every level as it is, is still >just one operator and in this case the lemmings faithfully followed >each other into the sea. We've been on an anti-resilience binge for >quite some time, accelerated to warp speed by the advent of the >Internet itself. There's something to be said about not having all of your >police scanners, etc, etc on the internet from a resilience >standpoint, but the siren call is strong for good reasons too. > >Mike > From mathews at hawaii.edu Wed Sep 2 13:31:35 2009 From: mathews at hawaii.edu (Robert Mathews (OSIA)) Date: Wed, 02 Sep 2009 14:31:35 -0400 Subject: Issues with Gmail In-Reply-To: <4A9EB141.4070407@mtcc.com> References: <4A9EAC83.3020806@hawaii.edu> <4A9EB141.4070407@mtcc.com> Message-ID: <4A9EBA07.4060602@hawaii.edu> Michael Thomas wrote: > I think that Randy might be conflating single point of failure with > "resilience". Google, distributed on every level as it is, is still > just one operator and in this case the lemmings faithfully followed > each other into the sea. We've been on an anti-resilience binge for > quite some time, accelerated to warp speed by the advent of the > Internet itself. There's something to be said about not having all of > your > police scanners, etc, etc on the internet from a resilience > standpoint, but the siren call is strong for good reasons too. > > Mike As I have mentioned to Randy separately, my interest was to understand whether he had made the "single point of failure" reference colloquially, or in a /critical infrastructure/ context. Some treat, and relate to the Internet as though it is a part of /"critical infrastructures."/ I simply wished to better understand the point of reference. A caveat... in stating this above... it is not a personal intention, to now originate a vacuous and malodorous thread on NANOG regarding the Internet's place in critical infrastructures. Surely, that cannot be resolved here, in this community. Regards, Robert. -- From gschwim at gmail.com Wed Sep 2 13:59:53 2009 From: gschwim at gmail.com (Greg Schwimer) Date: Wed, 2 Sep 2009 11:59:53 -0700 Subject: Network load test equipment Message-ID: <702ea15b0909021159o62ae278p200fe35c36fc06da@mail.gmail.com> I'm looking for equipment that can be used to load test network equipment such as switches, routers, firewall, and load balancers with pre-defined traffic patterns at differing rates. Ideally, this is only something I think I'll need 2-3x a year, so purchasing is not necessarily justifiable. I'd prefer to rent. What products have you used? Where did you get them from? I need to be able to run pre-defined traffic patterns at various rates, in excess of 10Gbps in most cases. Thanks! Greg From luan at netcraftsmen.net Wed Sep 2 14:12:00 2009 From: luan at netcraftsmen.net (Luan Nguyen) Date: Wed, 2 Sep 2009 15:12:00 -0400 Subject: Network load test equipment In-Reply-To: <702ea15b0909021159o62ae278p200fe35c36fc06da@mail.gmail.com> References: <702ea15b0909021159o62ae278p200fe35c36fc06da@mail.gmail.com> Message-ID: <03ae01ca2c01$3f830120$be890360$@net> You can't go wrong with IXIA. http://www.ixiacom.com/how_to_buy/ixrent/ Regards, ------------------------------ Luan Nguyen Chesapeake NetCraftsmen, LLC. http://www.netcraftsmen.net ------------------------------- -----Original Message----- From: Greg Schwimer [mailto:gschwim at gmail.com] Sent: Wednesday, September 02, 2009 3:00 PM To: nanog Subject: Network load test equipment I'm looking for equipment that can be used to load test network equipment such as switches, routers, firewall, and load balancers with pre-defined traffic patterns at differing rates. Ideally, this is only something I think I'll need 2-3x a year, so purchasing is not necessarily justifiable. I'd prefer to rent. What products have you used? Where did you get them from? I need to be able to run pre-defined traffic patterns at various rates, in excess of 10Gbps in most cases. Thanks! Greg From tom.ammon at utah.edu Wed Sep 2 14:32:32 2009 From: tom.ammon at utah.edu (Tom Ammon) Date: Wed, 02 Sep 2009 13:32:32 -0600 Subject: Network load test equipment In-Reply-To: <702ea15b0909021159o62ae278p200fe35c36fc06da@mail.gmail.com> References: <702ea15b0909021159o62ae278p200fe35c36fc06da@mail.gmail.com> Message-ID: <4A9EC850.5040404@utah.edu> We've used Spirent with a lot of success. They have a good lease program, too: www.spirent.com Tom Greg Schwimer wrote: > I'm looking for equipment that can be used to load test network equipment > such as switches, routers, firewall, and load balancers with pre-defined > traffic patterns at differing rates. Ideally, this is only something I > think I'll need 2-3x a year, so purchasing is not necessarily justifiable. > I'd prefer to rent. What products have you used? Where did you get them > from? > > I need to be able to run pre-defined traffic patterns at various rates, in > excess of 10Gbps in most cases. > > Thanks! > Greg > -- -------------------------------------------------------------------- Tom Ammon Network Engineer Office: 801.587.0976 Mobile: 801.674.9273 Center for High Performance Computing University of Utah http://www.chpc.utah.edu From mike at mtcc.com Wed Sep 2 15:00:08 2009 From: mike at mtcc.com (Michael Thomas) Date: Wed, 02 Sep 2009 13:00:08 -0700 Subject: Issues with Gmail In-Reply-To: <4A9EB141.4070407@mtcc.com> References: <4A9EB141.4070407@mtcc.com> Message-ID: <4A9ECEC8.4080404@mtcc.com> On 09/02/2009 11:20 AM, joel jaeggli wrote: > Long before we has widespread commercial internet, we still had to have the backup plan for when the single highly fault tollerant entitity on which we were dependant on for a particular service went out. > > Sometimes, that plan is wait for restoration, whether it was because the bell systems got a bit melty on the long distance, or because your regional utility managed to melt down the power grid taking out both substations providing diverse feeds. > > Systemic but temporarly localized failured has existed as long as the weather. One can move the failure around but I think I can confidently assert that we'll never entirely eleminate it. Right, but a cascading failure now with the internet is liable to be far more serious than back in the good old days. The electrical grid is probably an example of a system with relatively low resilience, but once it goes onto the net its resilience is vastly lessened. So we're making this grand engineering and economic trade off of less resilience for better interconnection. Which has a tendency to be a great trade off when things are going right, and a terrible one when things are going wrong :) I've always wondered what is going to happen when we have our first catastrophic cascading failure ala the blackout of 1965 or something similar but with the net instead. The real miracle of the net is that we _haven't_ had such a thing yet, but it really is only a matter of time unless somebody's willing to stand up and say that such things have been safely engineered away :) Mike > > Michael Thomas wrote: > >> On 09/02/2009 10:33 AM, Robert Mathews (OSIA) wrote: >>> >>> On Wed, Sep 2, 2009 at 5:05 AM, Randy Bush wrote: >>>> [....] the internet is a wonderful >>>> demonstration of building a reliable network out of reliable components. >>>> >>>> but what we have with google mail (and apps) is two scary problems >>>> >>>> o way too many users relying on a single point of failure. so it >>>> makes the nyt when it breaks because of the number of users >>>> affected, and >>> >>> I choose to not assume to "what/which single point of failure" this >>> reference by Randy applies. However, we can take confidence in the >>> fact that Google's Gmail service architecture is distributed; not to be >>> interpreted of course, as suggesting that within the distribution, there >>> isn't a single point of failure. Perhaps, from a network operations >>> point of view, the point needs elaboration. >> >> I think that Randy might be conflating single point of failure with >> "resilience". Google, distributed on every level as it is, is still >> just one operator and in this case the lemmings faithfully followed >> each other into the sea. We've been on an anti-resilience binge for >> quite some time, accelerated to warp speed by the advent of the >> Internet itself. There's something to be said about not having all of your >> police scanners, etc, etc on the internet from a resilience >> standpoint, but the siren call is strong for good reasons too. >> >> Mike >> From buraglio at illinois.edu Wed Sep 2 15:02:47 2009 From: buraglio at illinois.edu (Nick Buraglio) Date: Wed, 2 Sep 2009 15:02:47 -0500 Subject: Network load test equipment In-Reply-To: <4A9EC850.5040404@utah.edu> References: <702ea15b0909021159o62ae278p200fe35c36fc06da@mail.gmail.com> <4A9EC850.5040404@utah.edu> Message-ID: <0D40C93B-6D58-404F-8A16-310C982E61BC@illinois.edu> I've used Spirent, IXIA and Anritsu test gear and I prefer the Anritsu boxes, even if they are a tad more complicated to configure. There are places that you can rent stuff like that (I've rented OTDRs in the past) but the details escape me. nb --- Nick Buraglio Network Engineer, CITES, University of Illinois / ICCN GPG key 0x2E5B44F4 Phone: 217.244.6428 buraglio at illinois.edu On Sep 2, 2009, at 2:32 PM, Tom Ammon wrote: > We've used Spirent with a lot of success. They have a good lease > program, too: > > www.spirent.com > > Tom > > Greg Schwimer wrote: >> I'm looking for equipment that can be used to load test network >> equipment >> such as switches, routers, firewall, and load balancers with pre- >> defined >> traffic patterns at differing rates. Ideally, this is only >> something I >> think I'll need 2-3x a year, so purchasing is not necessarily >> justifiable. >> I'd prefer to rent. What products have you used? Where did you >> get them >> from? >> >> I need to be able to run pre-defined traffic patterns at various >> rates, in >> excess of 10Gbps in most cases. >> >> Thanks! >> Greg >> > > -- > -------------------------------------------------------------------- > Tom Ammon > Network Engineer > Office: 801.587.0976 > Mobile: 801.674.9273 > > Center for High Performance Computing > University of Utah > http://www.chpc.utah.edu > > From gih at apnic.net Wed Sep 2 15:11:18 2009 From: gih at apnic.net (Geoff Huston) Date: Thu, 3 Sep 2009 06:11:18 +1000 Subject: draft-iana-ipv4-examples In-Reply-To: <4A9E9064.2020608@juniper.net> References: <4A9E9064.2020608@juniper.net> Message-ID: On 03/09/2009, at 1:33 AM, Ron Bonica wrote: > Folks, > > Please take a look at draft-iana-ipv4-examples. This draft discusses > the > following subnet allocations: > > - 192.0.2.0/24 (TEST-NET-1) > - 198.51.100.0/24 (TEST-NET-2) > - 203.0.113.0/24 (TEST-NET-3) > > RFC 1166 allocates TEST-NET-1 for use in documentation. Because the > other two have been used in documentation, the current draft proposes > allocating them, too. thats not exactly the case Ron. 198.151.100.0/24 and 203.0.113.0/24 were both recently passed to the IANA from APNIC for the specific purpose of having some diverse address blocks reserved for documentation to assist document writers. They are "new" blocks, in terms of a proposed designation for documentation use. The problem being encountered was that it was difficult to construct realistic network examples using only a single / 24 and the request made by the document authors was to add a couple of diverse /24's to the pool to help out here. regards, Geoff From ras at e-gerbil.net Wed Sep 2 15:50:54 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 2 Sep 2009 15:50:54 -0500 Subject: Link capacity upgrade threshold In-Reply-To: References: <6E4AE737-9BF0-46BC-AE81-26E443BE9D56@pch.net> <75264.91571.qm@web1206.biz.mail.gq1.yahoo.com> Message-ID: <20090902205054.GA51443@gerbil.cluepon.net> On Wed, Sep 02, 2009 at 08:39:20AM +0200, Mikael Abrahamsson wrote: > On Tue, 1 Sep 2009, Kevin Graham wrote: > > >Indeed. Capacity upgrades are best gauged by drop rates; bit-rates > >without this context are largely useless. > > If you're dropping packets, you're already over the cliff. Our job as ISP > is to forward the packets our customers send to us, how is that compatible > with upgrading links when they're so full that you're not only buffering > but you're actually DROPPING packets? By all means watch your traffic utilization and plan your upgrades in a timely fashion, but watching for dropped packets can help reveal unexpected issues, such as all of those routers out there that don't actually do line rate depending on your particular traffic profile or pattern of traffic between ports. Personally I find the whole argument over what % of utilization should trigger an upgrade to be little more than a giant excercise in penis waving. People throw out all kinds of numbers, 80%, 60%, 50%, 40%, I've even seen someone claim 25%, but in the end I find more value in a quick reaction time to ANY unexpected event than I do in adhering to some arbitrary rule about when to upgrade. I'd rather see someone leave their links 80% full but have enough spare parts and a competent enough operations staff that they can turn around an upgrade in a matter of hours, than I would see them upgrade something unnecessarily at 40% and then not be able to react to an unplanned issue on a different port. And honestly, I've peered with a lot of networks who claim to do preemptive upgrades at numbers like 40%, but I've never actually seen it happen. In fact, the relationship between the marketing claim of upgrading at x percentage and the number of weeks you have to run the port congested before the other side gets budgetary approval to sign the PO for the optics that they need to do the upgrade but don't own seems to be inversely proportional. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From mhernand1 at comcast.net Wed Sep 2 15:53:47 2009 From: mhernand1 at comcast.net (manolo hernandez) Date: Wed, 02 Sep 2009 16:53:47 -0400 Subject: Google DNS admin Message-ID: <4A9EDB5B.7080202@comcast.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Could someone from google that can assist with a dns issue that originates from their servers please contact me offlist? I have tried normal channels listed on their Arin contact list to no avail. Manolo -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJKnttbAAoJEOcnyWxdB1IrV8MH/3uru0O9tYH4c1jQEZkpbqhP ZoqGMJm7NSSoH8KUKjVN1Vwze1Hp2JbV6sD5LUL7Au9z9+5DZ5VXoXkfIbfxo48f 63iOsRtPLxBim7o7zxAUOeZbI2+RflbwlIGXERrI12oufmTXEKD/9JioiVKLzsV7 +RtvJ0oPjOBXnqR2axs+zsrRygmBZKNDFavwhNsjZ+cXMZrX0XkTEhbWBv7qBdjU +Q7W7MHfURjay7pO0KW8O5kpCUCetS7Gy9Puxy0qEz4oKIbt9zeEneM6vlPs+EII 45+xheAeDzMf3gKixc+YJYyV1JDXgKQdhdLuddUz8mRX7S0JtO4FX7YP7wEPWZw= =pfuQ -----END PGP SIGNATURE----- From lmarshall at inetspace.net Wed Sep 2 16:14:59 2009 From: lmarshall at inetspace.net (lmarshall at inetspace.net) Date: Wed, 2 Sep 2009 17:14:59 -0400 Subject: AT&T - realpages.com Admin Message-ID: <6344805E996C44C1AE8BF5C69E19E57B@QNAL001> Would an administrator from AT&T (specifically realpages.com) contact me off-list. We have been attempting to resolve a client issue but normal channels have proved fruitless. L Marshall From morrowc.lists at gmail.com Wed Sep 2 16:24:25 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 2 Sep 2009 17:24:25 -0400 Subject: Google DNS admin In-Reply-To: <4A9EDB5B.7080202@comcast.net> References: <4A9EDB5B.7080202@comcast.net> Message-ID: <75cb24520909021424g2c9c549jf628b1b04041e149@mail.gmail.com> On Wed, Sep 2, 2009 at 4:53 PM, manolo hernandez wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Could someone from google that can assist with a dns issue that > originates from their servers please contact me offlist? > > ?I have tried normal channels listed on their Arin contact list to no > avail. replied off-list, but... as an aside I don't see email from you to the 'normal' arin contact points. Where did you send it, so we may either correct information OR point you in the right direction. -chris (google person) From morrowc.lists at gmail.com Wed Sep 2 16:33:25 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 2 Sep 2009 17:33:25 -0400 Subject: Google DNS admin In-Reply-To: <75cb24520909021424g2c9c549jf628b1b04041e149@mail.gmail.com> References: <4A9EDB5B.7080202@comcast.net> <75cb24520909021424g2c9c549jf628b1b04041e149@mail.gmail.com> Message-ID: <75cb24520909021433q5f481fa1m6cba03c8cf5989fe@mail.gmail.com> On Wed, Sep 2, 2009 at 5:24 PM, Christopher Morrow wrote: > On Wed, Sep 2, 2009 at 4:53 PM, manolo hernandez wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Could someone from google that can assist with a dns issue that >> originates from their servers please contact me offlist? >> >> ?I have tried normal channels listed on their Arin contact list to no >> avail. > > replied off-list, but... as an aside I don't see email from you to the > 'normal' arin contact points. Where did you send it, so we may either > correct information OR point you in the right direction. Oops, correcting myself (I think), I see email from: MH at borneomanagement.com not from 'mhernand1 at comcast.net'... assuming this is you, please reply to my earlier private email, it looks like your named is tossing errors to you about it's actions (it asking for some name, not google asking for a name) -chris From marc at sans.org Wed Sep 2 18:59:05 2009 From: marc at sans.org (Marcus H. Sachs) Date: Wed, 02 Sep 2009 19:59:05 -0400 Subject: Telstra issues Message-ID: <028b01ca2c29$5ed2b930$1c782b90$@org> Anybody know what is going on with Telstra? We've got complaints coming in from Down Under that good chunks of the country are belly-up. More here: http://forums.whirlpool.net.au/forum-replies.cfm?t=1274075 Marc -- Marc Sachs Director, SANS ISC From andrew at parnell.ca Thu Sep 3 00:22:28 2009 From: andrew at parnell.ca (Andrew Parnell) Date: Thu, 3 Sep 2009 01:22:28 -0400 Subject: Telstra issues In-Reply-To: <028b01ca2c29$5ed2b930$1c782b90$@org> References: <028b01ca2c29$5ed2b930$1c782b90$@org> Message-ID: <2d54a02d0909022222p536cb2femf06126f6f52237dd@mail.gmail.com> I saw the wierest thing earlier this evening where one of our two /24 routes in sydney disappeared from the internet - from both our telstra and verizon connections. The only explanation i could come up with was that Australia had been somehow bizarrely severed from the internet. Anybody else happen to also run a network in Australia who saw something strange today? On Wed, Sep 2, 2009 at 7:59 PM, Marcus H. Sachs wrote: > Anybody know what is going on with Telstra? We've got complaints coming in > from Down Under that good chunks of the country are belly-up. More here: > http://forums.whirlpool.net.au/forum-replies.cfm?t=1274075 > > > Marc > > -- > Marc Sachs > Director, SANS ISC > > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > From newton at internode.com.au Thu Sep 3 00:47:30 2009 From: newton at internode.com.au (Mark Newton) Date: Thu, 3 Sep 2009 15:17:30 +0930 Subject: Telstra issues In-Reply-To: <2d54a02d0909022222p536cb2femf06126f6f52237dd@mail.gmail.com> References: <028b01ca2c29$5ed2b930$1c782b90$@org> <2d54a02d0909022222p536cb2femf06126f6f52237dd@mail.gmail.com> Message-ID: On 03/09/2009, at 2:52 PM, Andrew Parnell wrote: > I saw the wierest thing earlier this evening where one of our two / > 24 routes > in sydney disappeared from the internet - from both our telstra and > verizon > connections. The only explanation i could come up with was that > Australia > had been somehow bizarrely severed from the internet. Anybody else > happen > to also run a network in Australia who saw something strange today? We run one which isn't connected to Telstra :-) There are media reports this morning of major outages in Telstra's domestic network. http://www.australianit.news.com.au/story/0,24897,26021106-15306,00.html - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From frnkblk at iname.com Thu Sep 3 00:51:14 2009 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 3 Sep 2009 00:51:14 -0500 Subject: Link capacity upgrade threshold In-Reply-To: <75264.91571.qm@web1206.biz.mail.gq1.yahoo.com> References: <6E4AE737-9BF0-46BC-AE81-26E443BE9D56@pch.net> <75264.91571.qm@web1206.biz.mail.gq1.yahoo.com> Message-ID: What SNMP MIB records drops? I poked around for a short time, and I'm thinking that generically the drops fall into the errors counter. Hopefully that's not the case. Frank -----Original Message----- From: Kevin Graham [mailto:kgraham at industrial-marshmallow.com] Sent: Wednesday, September 02, 2009 1:32 AM To: Bill Woodcock; nanog Subject: Re: Link capacity upgrade threshold > So, in summary: Your dropped packet counters are the ones to be looking at > as a measure of goodput, more than your utilization counters. Indeed. Capacity upgrades are best gauged by drop rates; bit-rates without this context are largely useless. When you're only aware of the RX side though, in the absence of an equivalent to BECN, what's the best way to track this? Do any of the Ethernet OAM standards expose this data? Similarly, could anyone share experiences with transit link upgrades to accommodate bursts? In the past, any requests to transit providers have been answered w/ the need for significant increases to 95%ile commits. While this makes sense from a sales perspective, there's a strong (but insufficient) engineering argument against it. From frnkblk at iname.com Thu Sep 3 00:50:59 2009 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 3 Sep 2009 00:50:59 -0500 Subject: Link capacity upgrade threshold In-Reply-To: <75264.91571.qm@web1206.biz.mail.gq1.yahoo.com> References: <6E4AE737-9BF0-46BC-AE81-26E443BE9D56@pch.net> <75264.91571.qm@web1206.biz.mail.gq1.yahoo.com> Message-ID: What SNMP MIB records drops? I poked around for a short time, and I'm thinking that generically the drops fall into the errors counter. Hopefully that's not the case. Frank -----Original Message----- From: Kevin Graham [mailto:kgraham at industrial-marshmallow.com] Sent: Wednesday, September 02, 2009 1:32 AM To: Bill Woodcock; nanog Subject: Re: Link capacity upgrade threshold > So, in summary: Your dropped packet counters are the ones to be looking at > as a measure of goodput, more than your utilization counters. Indeed. Capacity upgrades are best gauged by drop rates; bit-rates without this context are largely useless. When you're only aware of the RX side though, in the absence of an equivalent to BECN, what's the best way to track this? Do any of the Ethernet OAM standards expose this data? Similarly, could anyone share experiences with transit link upgrades to accommodate bursts? In the past, any requests to transit providers have been answered w/ the need for significant increases to 95%ile commits. While this makes sense from a sales perspective, there's a strong (but insufficient) engineering argument against it. From chaz at chaz6.com Thu Sep 3 04:34:10 2009 From: chaz at chaz6.com (Chris Hills) Date: Thu, 03 Sep 2009 11:34:10 +0200 Subject: Telstra issues In-Reply-To: References: <028b01ca2c29$5ed2b930$1c782b90$@org> <2d54a02d0909022222p536cb2femf06126f6f52237dd@mail.gmail.com> Message-ID: On 03/09/09 07:47, Mark Newton wrote: > We run one which isn't connected to Telstra :-) > > There are media reports this morning of major outages in Telstra's domestic > network. > http://www.australianit.news.com.au/story/0,24897,26021106-15306,00.html Thank goodness PPC-1 is nearing completion, eh? http://www.pipeinternational.com/index.php?option=com_myblog&Itemid=65 From braaen at zcorum.com Thu Sep 3 06:29:18 2009 From: braaen at zcorum.com (Brian Raaen) Date: Thu, 03 Sep 2009 07:29:18 -0400 Subject: Need Help Getting IP Unblocked by AT&T Message-ID: <4A9FA88E.3040600@zcorum.com> I'm not sure where to take this issue. The Regular AT&T NOC contacts are refusing to talk to me since I do not have a circuit ID, and do not seem to have any understanding about transiting issues. I am unable to fully monitor and manage a router I control, as all traffic bound to its lan IP that transits through the AT&T network is blocked. The Router is connected to a Verizon circuit, but any connection that transits through AT&T is blocked. The ip in Question is from a direct ARIN allocation that I control. I have attached a ping demonstrating that I am receiving an ICMP deny from an AT&T core router. I have also attached a traceroute to both the offending IP and the WAN IP which appears to be working. braaen at brian-debian:~$ ping gw.bwtc.net PING gw.bwtc.net (72.14.76.1) 56(84) bytes of data. >From 12.89.27.105 icmp_seq=1 Packet filtered >From 12.89.27.105 icmp_seq=3 Packet filtered ^C --- gw.bwtc.net ping statistics --- 4 packets transmitted, 0 received, +2 errors, 100% packet loss, time 3004ms braaen at brian-debian:~$ sudo traceroute-nanog -AO gw.bwtc.net [sudo] password for braaen: traceroute to gw.bwtc.net (72.14.76.1), 64 hops max, 40 byte packets 1 gw-alpha.america.net (69.60.176.65) [AS4452] dns at america.net 3 ms 3 ms 3 ms 2 gw-alpha.america.net (69.60.176.65) [AS4452] dns at america.net 3 ms 3 ms 4 ms 3 69.60.160.8 (69.60.160.8) [AS4452] dns at america.net 13 ms rtrs00.america.net (69.60.176.21) [AS4452] dns at america.net 13 ms 69.60.160.8 (69.60.160.8) [AS4452] dns at america.net 13 ms 4 69.60.160.8 (69.60.160.8) [AS4452] dns at america.net 12 ms 35 ms 17 ms 5 gig4-16.core2.suw1.qualitytech.com (64.88.172.145) [AS20141] dnsadmin at globix.net [MPLS: Label 673 Exp 0] 15 ms 14 ms 25 ms 6 gig4-16.core2.suw1.qualitytech.com (64.88.172.145) [AS20141] dnsadmin at globix.net 14 ms 14 ms 18 ms 7 ten8-3.peer1.suw1.qualitytech.com (64.88.172.197) [AS20141] dnsadmin at globix.net 14 ms 12 ms 14 ms 8 border11.tge3-3.qts-1.acs.pnap.net (64.94.3.113) [AS14745] hostmaster at pnap.net 14 ms 14 ms 14 ms 9 core1.te2-2-bbnet2.acs002.pnap.net (64.94.0.79) [AS14745] hostmaster at pnap.net 14 ms core1.te2-1-bbnet1.acs002.pnap.net (64.94.0.15) [AS14745] hostmaster at pnap.net 14 ms 12.86.102.5 (12.86.102.5) [] rm-hostmaster at ems.att.com 14 ms 10 12.86.102.5 (12.86.102.5) [] rm-hostmaster at ems.att.com 13 ms 23 ms 13 ms 11 cr1.attga.ip.att.net (12.122.141.2) [] rm-hostmaster at ems.att.com [MPLS: Label 16745 Exp 0] 40 ms cr2.ormfl.ip.att.net (12.122.5.141) [] rm-hostmaster at ems.att.com [MPLS: Label 20348 Exp 0] More labels 40 ms More labels 40 ms 12 cr2.ormfl.ip.att.net (12.122.5.141) [] rm-hostmaster at ems.att.com More labels 40 ms More labels 41 ms More labels 40 ms 13 cr2.nwrla.ip.att.net (12.122.30.77) [] rm-hostmaster at ems.att.com [MPLS: Label 0 Exp 0] More labels 40 ms gar1.nwrla.ip.att.net (12.123.153.85) [] rm-hostmaster at ems.att.com 38 ms 38 ms 14 gar1.nwrla.ip.att.net (12.123.153.85) [] rm-hostmaster at ems.att.com 50 ms 38 ms 38 ms 15 12.89.27.106 (12.89.27.106) [] rm-hostmaster at ems.att.com 43 ms 44 ms 44 ms 16 * * 12.89.27.105 (12.89.27.105) [] rm-hostmaster at ems.att.com 44 ms !A braaen at brian-debian:~$ sudo traceroute-nanog -AO 157.130.26.166 traceroute to 157.130.26.166 (157.130.26.166), 64 hops max, 40 byte packets 1 gw-alpha.america.net (69.60.176.65) [AS4452] dns at america.net 4 ms 3 ms 6 ms 2 gw-alpha.america.net (69.60.176.65) [AS4452] dns at america.net 3 ms 3 ms 3 ms 3 rtrs00.america.net (69.60.176.21) [AS4452] dns at america.net 14 ms 13 ms 13 ms 4 69.60.160.8 (69.60.160.8) [AS4452] dns at america.net 13 ms 13 ms 12 ms 5 66.0.192.194 (66.0.192.194) [AS20141] dns at deltacom.net 13 ms 13 ms 15 ms 6 gig4-16.core2.suw1.qualitytech.com (64.88.172.145) [AS20141] dnsadmin at globix.net [MPLS: Label 673 Exp 0] 30 ms ten8-3.peer1.suw1.qualitytech.com (64.88.172.197) [AS20141] dnsadmin at globix.net 14 ms gig4-16.core2.suw1.qualitytech.com (64.88.172.145) [AS20141] dnsadmin at globix.net 34 ms 7 ten8-3.peer1.suw1.qualitytech.com (64.88.172.197) [AS20141] dnsadmin at globix.net 19 ms 13 ms 13 ms 8 core3.tge4-1-bbnet1.acs.pnap.net (64.94.0.3) [AS14745] hostmaster at pnap.net 14 ms core3.tge4-1-bbnet2.acs.pnap.net (64.94.0.67) [AS14745] hostmaster at pnap.net 14 ms 15 ms 9 core3.tge4-1-bbnet2.acs.pnap.net (64.94.0.67) [AS14745] hostmaster at pnap.net 14 ms core3.tge4-1-bbnet1.acs.pnap.net (64.94.0.3) [AS14745] hostmaster at pnap.net 14 ms 15 ms 10 TenGigabitEthernet3-4.ar5.ATL1.gblx.net (207.218.80.217) [AS3549] dns at gblx.net.80.218.207.in-addr.arpa 14 ms 14 ms 14 ms 11 ge4-3-1000M.ar3.PTY1.gblx.net (67.16.135.18) [AS22566] dns at gblx.net 18 ms 14 ms 14 ms 12 0.so-1-1-0.XT1.ATL4.ALTER.NET (152.63.86.170) [] hostmaster at uu.net 14 ms 49 ms verizon-1.ar2.ATL2.gblx.net (64.208.110.170) [AS3549] dns at gblx.net 17 ms 13 0.so-1-1-0.XT1.ATL4.ALTER.NET (152.63.86.170) [] hostmaster at uu.net 33 ms 14 ms 16 ms 14 0.so-7-1-0.XL3.BOS4.ALTER.NET (152.63.0.209) [] hostmaster at uu.net 42 ms 48 ms 49 ms 15 POS6-0.GW10.BOS4.ALTER.NET (152.63.17.37) [] hostmaster at uu.net 41 ms 42 ms 41 ms 16 * networkinnovations-gw.customer.alter.net (157.130.26.166) [] hostmaster at uu.net 53 ms * -- ----------------- Brian Raaen Network Engineer email: /braaen at zcorum.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: braaen.vcf Type: text/x-vcard Size: 206 bytes Desc: not available URL: From robert at ufl.edu Thu Sep 3 06:59:24 2009 From: robert at ufl.edu (Robert D. Scott) Date: Thu, 3 Sep 2009 07:59:24 -0400 Subject: Need Help Getting IP Unblocked by AT&T In-Reply-To: <4A9FA88E.3040600@zcorum.com> References: <4A9FA88E.3040600@zcorum.com> Message-ID: <032501ca2c8d$fb0c5220$f124f660$@edu> Work through your provider, I would start with you local end. They should help you, you ARE their customer. If not, you need a new provider. Look into out of band management. Robert D. Scott Robert at ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Phone Tree University of Florida 352-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell -----Original Message----- From: Brian Raaen [mailto:braaen at zcorum.com] Sent: Thursday, September 03, 2009 7:29 AM To: nanog at nanog.org Subject: Need Help Getting IP Unblocked by AT&T I'm not sure where to take this issue. The Regular AT&T NOC contacts are refusing to talk to me since I do not have a circuit ID, and do not seem to have any understanding about transiting issues. I am unable to fully monitor and manage a router I control, as all traffic bound to its lan IP that transits through the AT&T network is blocked. The Router is connected to a Verizon circuit, but any connection that transits through AT&T is blocked. The ip in Question is from a direct ARIN allocation that I control. I have attached a ping demonstrating that I am receiving an ICMP deny from an AT&T core router. I have also attached a traceroute to both the offending IP and the WAN IP which appears to be working. braaen at brian-debian:~$ ping gw.bwtc.net PING gw.bwtc.net (72.14.76.1) 56(84) bytes of data. >From 12.89.27.105 icmp_seq=1 Packet filtered From 12.89.27.105 >icmp_seq=3 Packet filtered ^C --- gw.bwtc.net ping statistics --- 4 packets transmitted, 0 received, +2 errors, 100% packet loss, time 3004ms braaen at brian-debian:~$ sudo traceroute-nanog -AO gw.bwtc.net [sudo] password for braaen: traceroute to gw.bwtc.net (72.14.76.1), 64 hops max, 40 byte packets 1 gw-alpha.america.net (69.60.176.65) [AS4452] dns at america.net 3 ms 3 ms 3 ms 2 gw-alpha.america.net (69.60.176.65) [AS4452] dns at america.net 3 ms 3 ms 4 ms 3 69.60.160.8 (69.60.160.8) [AS4452] dns at america.net 13 ms rtrs00.america.net (69.60.176.21) [AS4452] dns at america.net 13 ms 69.60.160.8 (69.60.160.8) [AS4452] dns at america.net 13 ms 4 69.60.160.8 (69.60.160.8) [AS4452] dns at america.net 12 ms 35 ms 17 ms 5 gig4-16.core2.suw1.qualitytech.com (64.88.172.145) [AS20141] dnsadmin at globix.net [MPLS: Label 673 Exp 0] 15 ms 14 ms 25 ms 6 gig4-16.core2.suw1.qualitytech.com (64.88.172.145) [AS20141] dnsadmin at globix.net 14 ms 14 ms 18 ms 7 ten8-3.peer1.suw1.qualitytech.com (64.88.172.197) [AS20141] dnsadmin at globix.net 14 ms 12 ms 14 ms 8 border11.tge3-3.qts-1.acs.pnap.net (64.94.3.113) [AS14745] hostmaster at pnap.net 14 ms 14 ms 14 ms 9 core1.te2-2-bbnet2.acs002.pnap.net (64.94.0.79) [AS14745] hostmaster at pnap.net 14 ms core1.te2-1-bbnet1.acs002.pnap.net (64.94.0.15) [AS14745] hostmaster at pnap.net 14 ms 12.86.102.5 (12.86.102.5) [] rm-hostmaster at ems.att.com 14 ms 10 12.86.102.5 (12.86.102.5) [] rm-hostmaster at ems.att.com 13 ms 23 ms 13 ms 11 cr1.attga.ip.att.net (12.122.141.2) [] rm-hostmaster at ems.att.com [MPLS: Label 16745 Exp 0] 40 ms cr2.ormfl.ip.att.net (12.122.5.141) [] rm-hostmaster at ems.att.com [MPLS: Label 20348 Exp 0] More labels 40 ms More labels 40 ms 12 cr2.ormfl.ip.att.net (12.122.5.141) [] rm-hostmaster at ems.att.com More labels 40 ms More labels 41 ms More labels 40 ms 13 cr2.nwrla.ip.att.net (12.122.30.77) [] rm-hostmaster at ems.att.com [MPLS: Label 0 Exp 0] More labels 40 ms gar1.nwrla.ip.att.net (12.123.153.85) [] rm-hostmaster at ems.att.com 38 ms 38 ms 14 gar1.nwrla.ip.att.net (12.123.153.85) [] rm-hostmaster at ems.att.com 50 ms 38 ms 38 ms 15 12.89.27.106 (12.89.27.106) [] rm-hostmaster at ems.att.com 43 ms 44 ms 44 ms 16 * * 12.89.27.105 (12.89.27.105) [] rm-hostmaster at ems.att.com 44 ms !A braaen at brian-debian:~$ sudo traceroute-nanog -AO 157.130.26.166 traceroute to 157.130.26.166 (157.130.26.166), 64 hops max, 40 byte packets 1 gw-alpha.america.net (69.60.176.65) [AS4452] dns at america.net 4 ms 3 ms 6 ms 2 gw-alpha.america.net (69.60.176.65) [AS4452] dns at america.net 3 ms 3 ms 3 ms 3 rtrs00.america.net (69.60.176.21) [AS4452] dns at america.net 14 ms 13 ms 13 ms 4 69.60.160.8 (69.60.160.8) [AS4452] dns at america.net 13 ms 13 ms 12 ms 5 66.0.192.194 (66.0.192.194) [AS20141] dns at deltacom.net 13 ms 13 ms 15 ms 6 gig4-16.core2.suw1.qualitytech.com (64.88.172.145) [AS20141] dnsadmin at globix.net [MPLS: Label 673 Exp 0] 30 ms ten8-3.peer1.suw1.qualitytech.com (64.88.172.197) [AS20141] dnsadmin at globix.net 14 ms gig4-16.core2.suw1.qualitytech.com (64.88.172.145) [AS20141] dnsadmin at globix.net 34 ms 7 ten8-3.peer1.suw1.qualitytech.com (64.88.172.197) [AS20141] dnsadmin at globix.net 19 ms 13 ms 13 ms 8 core3.tge4-1-bbnet1.acs.pnap.net (64.94.0.3) [AS14745] hostmaster at pnap.net 14 ms core3.tge4-1-bbnet2.acs.pnap.net (64.94.0.67) [AS14745] hostmaster at pnap.net 14 ms 15 ms 9 core3.tge4-1-bbnet2.acs.pnap.net (64.94.0.67) [AS14745] hostmaster at pnap.net 14 ms core3.tge4-1-bbnet1.acs.pnap.net (64.94.0.3) [AS14745] hostmaster at pnap.net 14 ms 15 ms 10 TenGigabitEthernet3-4.ar5.ATL1.gblx.net (207.218.80.217) [AS3549] dns at gblx.net.80.218.207.in-addr.arpa 14 ms 14 ms 14 ms 11 ge4-3-1000M.ar3.PTY1.gblx.net (67.16.135.18) [AS22566] dns at gblx.net 18 ms 14 ms 14 ms 12 0.so-1-1-0.XT1.ATL4.ALTER.NET (152.63.86.170) [] hostmaster at uu.net 14 ms 49 ms verizon-1.ar2.ATL2.gblx.net (64.208.110.170) [AS3549] dns at gblx.net 17 ms 13 0.so-1-1-0.XT1.ATL4.ALTER.NET (152.63.86.170) [] hostmaster at uu.net 33 ms 14 ms 16 ms 14 0.so-7-1-0.XL3.BOS4.ALTER.NET (152.63.0.209) [] hostmaster at uu.net 42 ms 48 ms 49 ms 15 POS6-0.GW10.BOS4.ALTER.NET (152.63.17.37) [] hostmaster at uu.net 41 ms 42 ms 41 ms 16 * networkinnovations-gw.customer.alter.net (157.130.26.166) [] hostmaster at uu.net 53 ms * -- ----------------- Brian Raaen Network Engineer email: /braaen at zcorum.com/ From braaen at zcorum.com Thu Sep 3 07:29:32 2009 From: braaen at zcorum.com (Brian Raaen) Date: Thu, 03 Sep 2009 08:29:32 -0400 Subject: Need Help Getting IP Unblocked by AT&T In-Reply-To: <4A9FA88E.3040600@zcorum.com> References: <4A9FA88E.3040600@zcorum.com> Message-ID: <4A9FB6AC.60201@zcorum.com> I appreciate the offline replies. After doing some more research myself the issue appears to be related to the fact that AT&T is announcing the block directly. I did show "ip bgp 72.14.76.0" in a couple routers and some showed the route originating in 701 (they were able to reach it) and others showed it originating in 7018 (and they could not reach it). Here is my question, since I am an ARIN admin contact for the IP block how is the best way to get AT&T to quit announcing the block. -- ----------------- Brian Raaen Network Engineer email: /braaen at zcorum.com/ Brian Raaen wrote: > I'm not sure where to take this issue. The Regular AT&T NOC contacts > are refusing to talk to me since I do not have a circuit ID, and do not > seem to have any understanding about transiting issues. I am unable to > fully monitor and manage a router I control, as all traffic bound to its > lan IP that transits through the AT&T network is blocked. The Router is > connected to a Verizon circuit, but any connection that transits through > AT&T is blocked. The ip in Question is from a direct ARIN allocation > that I control. I have attached a ping demonstrating that I am > receiving an ICMP deny from an AT&T core router. I have also attached a > traceroute to both the offending IP and the WAN IP which appears to be > working. > > braaen at brian-debian:~$ ping gw.bwtc.net > PING gw.bwtc.net (72.14.76.1) 56(84) bytes of data. > >From 12.89.27.105 icmp_seq=1 Packet filtered > >From 12.89.27.105 icmp_seq=3 Packet filtered > ^C > --- gw.bwtc.net ping statistics --- > 4 packets transmitted, 0 received, +2 errors, 100% packet loss, time 3004ms > > > braaen at brian-debian:~$ sudo traceroute-nanog -AO gw.bwtc.net > [sudo] password for braaen: > traceroute to gw.bwtc.net (72.14.76.1), 64 hops max, 40 byte packets > 1 gw-alpha.america.net (69.60.176.65) [AS4452] dns at america.net 3 ms > 3 ms 3 ms > 2 gw-alpha.america.net (69.60.176.65) [AS4452] dns at america.net 3 ms > 3 ms 4 ms > 3 69.60.160.8 (69.60.160.8) [AS4452] dns at america.net 13 ms > rtrs00.america.net (69.60.176.21) [AS4452] dns at america.net 13 ms > 69.60.160.8 (69.60.160.8) [AS4452] dns at america.net 13 ms > 4 69.60.160.8 (69.60.160.8) [AS4452] dns at america.net 12 ms 35 ms 17 ms > 5 gig4-16.core2.suw1.qualitytech.com (64.88.172.145) [AS20141] > dnsadmin at globix.net [MPLS: Label 673 Exp 0] 15 ms 14 ms 25 ms > 6 gig4-16.core2.suw1.qualitytech.com (64.88.172.145) [AS20141] > dnsadmin at globix.net 14 ms 14 ms 18 ms > 7 ten8-3.peer1.suw1.qualitytech.com (64.88.172.197) [AS20141] > dnsadmin at globix.net 14 ms 12 ms 14 ms > 8 border11.tge3-3.qts-1.acs.pnap.net (64.94.3.113) [AS14745] > hostmaster at pnap.net 14 ms 14 ms 14 ms > 9 core1.te2-2-bbnet2.acs002.pnap.net (64.94.0.79) [AS14745] > hostmaster at pnap.net 14 ms core1.te2-1-bbnet1.acs002.pnap.net > (64.94.0.15) [AS14745] hostmaster at pnap.net 14 ms 12.86.102.5 > (12.86.102.5) [] rm-hostmaster at ems.att.com 14 ms > 10 12.86.102.5 (12.86.102.5) [] rm-hostmaster at ems.att.com 13 ms > 23 ms 13 ms > 11 cr1.attga.ip.att.net (12.122.141.2) [] > rm-hostmaster at ems.att.com [MPLS: Label 16745 Exp 0] 40 ms > cr2.ormfl.ip.att.net (12.122.5.141) [] rm-hostmaster at ems.att.com > [MPLS: Label 20348 Exp 0] More labels 40 ms More labels 40 ms > 12 cr2.ormfl.ip.att.net (12.122.5.141) [] > rm-hostmaster at ems.att.com More labels 40 ms More labels 41 ms More > labels 40 ms > 13 cr2.nwrla.ip.att.net (12.122.30.77) [] > rm-hostmaster at ems.att.com [MPLS: Label 0 Exp 0] More labels 40 ms > gar1.nwrla.ip.att.net (12.123.153.85) [] > rm-hostmaster at ems.att.com 38 ms 38 ms > 14 gar1.nwrla.ip.att.net (12.123.153.85) [] > rm-hostmaster at ems.att.com 50 ms 38 ms 38 ms > 15 12.89.27.106 (12.89.27.106) [] rm-hostmaster at ems.att.com 43 > ms 44 ms 44 ms > 16 * * 12.89.27.105 (12.89.27.105) [] rm-hostmaster at ems.att.com > 44 ms !A > > > > > braaen at brian-debian:~$ sudo traceroute-nanog -AO 157.130.26.166 > traceroute to 157.130.26.166 (157.130.26.166), 64 hops max, 40 byte packets > 1 gw-alpha.america.net (69.60.176.65) [AS4452] dns at america.net 4 ms > 3 ms 6 ms > 2 gw-alpha.america.net (69.60.176.65) [AS4452] dns at america.net 3 ms > 3 ms 3 ms > 3 rtrs00.america.net (69.60.176.21) [AS4452] dns at america.net 14 ms > 13 ms 13 ms > 4 69.60.160.8 (69.60.160.8) [AS4452] dns at america.net 13 ms 13 ms 12 ms > 5 66.0.192.194 (66.0.192.194) [AS20141] dns at deltacom.net 13 ms 13 > ms 15 ms > 6 gig4-16.core2.suw1.qualitytech.com (64.88.172.145) [AS20141] > dnsadmin at globix.net [MPLS: Label 673 Exp 0] 30 ms > ten8-3.peer1.suw1.qualitytech.com (64.88.172.197) [AS20141] > dnsadmin at globix.net 14 ms gig4-16.core2.suw1.qualitytech.com > (64.88.172.145) [AS20141] dnsadmin at globix.net 34 ms > 7 ten8-3.peer1.suw1.qualitytech.com (64.88.172.197) [AS20141] > dnsadmin at globix.net 19 ms 13 ms 13 ms > 8 core3.tge4-1-bbnet1.acs.pnap.net (64.94.0.3) [AS14745] > hostmaster at pnap.net 14 ms core3.tge4-1-bbnet2.acs.pnap.net (64.94.0.67) > [AS14745] hostmaster at pnap.net 14 ms 15 ms > 9 core3.tge4-1-bbnet2.acs.pnap.net (64.94.0.67) [AS14745] > hostmaster at pnap.net 14 ms core3.tge4-1-bbnet1.acs.pnap.net (64.94.0.3) > [AS14745] hostmaster at pnap.net 14 ms 15 ms > 10 TenGigabitEthernet3-4.ar5.ATL1.gblx.net (207.218.80.217) [AS3549] > dns at gblx.net.80.218.207.in-addr.arpa 14 ms 14 ms 14 ms > 11 ge4-3-1000M.ar3.PTY1.gblx.net (67.16.135.18) [AS22566] dns at gblx.net > 18 ms 14 ms 14 ms > 12 0.so-1-1-0.XT1.ATL4.ALTER.NET (152.63.86.170) [] > hostmaster at uu.net 14 ms 49 ms verizon-1.ar2.ATL2.gblx.net > (64.208.110.170) [AS3549] dns at gblx.net 17 ms > 13 0.so-1-1-0.XT1.ATL4.ALTER.NET (152.63.86.170) [] > hostmaster at uu.net 33 ms 14 ms 16 ms > 14 0.so-7-1-0.XL3.BOS4.ALTER.NET (152.63.0.209) [] > hostmaster at uu.net 42 ms 48 ms 49 ms > 15 POS6-0.GW10.BOS4.ALTER.NET (152.63.17.37) [] > hostmaster at uu.net 41 ms 42 ms 41 ms > 16 * networkinnovations-gw.customer.alter.net (157.130.26.166) [] > hostmaster at uu.net 53 ms * > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: braaen.vcf Type: text/x-vcard Size: 206 bytes Desc: not available URL: From braaen at zcorum.com Thu Sep 3 07:43:34 2009 From: braaen at zcorum.com (Brian Raaen) Date: Thu, 03 Sep 2009 08:43:34 -0400 Subject: BGP Hijack by AT&T... was: Need Help Getting IP Unblocked by AT&T In-Reply-To: <4A9FB6AC.60201@zcorum.com> References: <4A9FA88E.3040600@zcorum.com> <4A9FB6AC.60201@zcorum.com> Message-ID: <4A9FB9F6.8020204@zcorum.com> I have sent a complaint to the AT&T abuse contact from my ARIN contact address asking them to stop announcing the route. -- ----------------- Brian Raaen Network Engineer email: /braaen at zcorum.com/ Brian Raaen wrote: > I appreciate the offline replies. After doing some more research myself > the issue appears to be related to the fact that AT&T is announcing the > block directly. I did show "ip bgp 72.14.76.0" in a couple routers and > some showed the route originating in 701 (they were able to reach it) > and others showed it originating in 7018 (and they could not reach it). > > Here is my question, since I am an ARIN admin contact for the IP block > how is the best way to get AT&T to quit announcing the block. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: braaen.vcf Type: text/x-vcard Size: 206 bytes Desc: not available URL: From jay at west.net Thu Sep 3 09:05:00 2009 From: jay at west.net (Jay Hennigan) Date: Thu, 03 Sep 2009 07:05:00 -0700 Subject: Need Help Getting IP Unblocked by AT&T In-Reply-To: <4A9FB6AC.60201@zcorum.com> References: <4A9FA88E.3040600@zcorum.com> <4A9FB6AC.60201@zcorum.com> Message-ID: <4A9FCD0C.9090306@west.net> Brian Raaen wrote: > I appreciate the offline replies. After doing some more research myself > the issue appears to be related to the fact that AT&T is announcing the > block directly. I did show "ip bgp 72.14.76.0" in a couple routers and > some showed the route originating in 701 (they were able to reach it) > and others showed it originating in 7018 (and they could not reach it). > > Here is my question, since I am an ARIN admin contact for the IP block > how is the best way to get AT&T to quit announcing the block. If they absolutely refuse to talk to you, have someone who is an AT&T customer open a ticket with them about being unable to reach your network. I would suspect that the discussion here. may get their attention. -- 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 braaen at zcorum.com Thu Sep 3 09:23:00 2009 From: braaen at zcorum.com (Brian Raaen) Date: Thu, 03 Sep 2009 10:23:00 -0400 Subject: BGP Hijack by AT&T... was: Need Help Getting IP Unblocked by AT&T In-Reply-To: <73d1f88a0909030712q7d5df487rb1868488e1f7ca38@mail.gmail.com> References: <4A9FA88E.3040600@zcorum.com> <4A9FB6AC.60201@zcorum.com> <4A9FB9F6.8020204@zcorum.com> <73d1f88a0909030712q7d5df487rb1868488e1f7ca38@mail.gmail.com> Message-ID: <4A9FD144.7040002@zcorum.com> I have not seen any changes yet, although I did get an automated response from their abuse address that they received my message. Also, to answer another question I have not changed backbones in over two years. I largely suspect that this is an issue of a simple typo and not anything malicious. -- ----------------- Brian Raaen Network Engineer email: /braaen at zcorum.com/ Gustavo Rodrigues Ramos wrote: > Hi Brian, has someone from at&t contacted you or have you noticed any change? > > Thanks, > Gustavo. > > > On Thu, Sep 3, 2009 at 9:43 AM, Brian Raaen wrote: > >> I have sent a complaint to the AT&T abuse contact from my ARIN contact >> address asking them to stop announcing the route. >> >> -- >> ----------------- >> Brian Raaen >> Network Engineer >> email: /braaen at zcorum.com/ >> >> Brian Raaen wrote: >> >>> I appreciate the offline replies. After doing some more research myself >>> the issue appears to be related to the fact that AT&T is announcing the >>> block directly. I did show "ip bgp 72.14.76.0" in a couple routers and >>> some showed the route originating in 701 (they were able to reach it) >>> and others showed it originating in 7018 (and they could not reach it). >>> >>> Here is my question, since I am an ARIN admin contact for the IP block >>> how is the best way to get AT&T to quit announcing the block. >>> >>> >>> -------------- next part -------------- A non-text attachment was scrubbed... Name: braaen.vcf Type: text/x-vcard Size: 206 bytes Desc: not available URL: From braaen at zcorum.com Thu Sep 3 09:46:52 2009 From: braaen at zcorum.com (Brian Raaen) Date: Thu, 03 Sep 2009 10:46:52 -0400 Subject: BGP Hijack by AT&T... was: Need Help Getting IP Unblocked by AT&T In-Reply-To: <7db2dcf90909030745n50a57749gd6da641e8045e494@mail.gmail.com> References: <4A9FA88E.3040600@zcorum.com> <4A9FB6AC.60201@zcorum.com> <4A9FB9F6.8020204@zcorum.com> <73d1f88a0909030712q7d5df487rb1868488e1f7ca38@mail.gmail.com> <4A9FD144.7040002@zcorum.com> <7db2dcf90909030745n50a57749gd6da641e8045e494@mail.gmail.com> Message-ID: <4A9FD6DC.8030300@zcorum.com> No is just seems to die in their core network. Dorn Hetzel wrote: > If you traceroute from someplace that sees the announcement from ATT, > does it actually go anywhere beyond the core in ATT (as if they are > sending it to any customer circuit of their) ? > > On Thu, Sep 3, 2009 at 10:23 AM, Brian Raaen > wrote: > > I have not seen any changes yet, although I did get an automated > response from their abuse address that they received my message. > Also, > to answer another question I have not changed backbones in over two > years. I largely suspect that this is an issue of a simple typo > and not > anything malicious. > > -- > ----------------- > Brian Raaen > Network Engineer > email: /braaen at zcorum.com/ > > > > > Gustavo Rodrigues Ramos wrote: > > Hi Brian, has someone from at&t contacted you or have you > noticed any change? > > > > Thanks, > > Gustavo. > > > > > > On Thu, Sep 3, 2009 at 9:43 AM, Brian Raaen > wrote: > > > >> I have sent a complaint to the AT&T abuse contact from my ARIN > contact > >> address asking them to stop announcing the route. > >> > >> -- > >> ----------------- > >> Brian Raaen > >> Network Engineer > >> email: /braaen at zcorum.com/ > > > >> > >> Brian Raaen wrote: > >> > >>> I appreciate the offline replies. After doing some more > research myself > >>> the issue appears to be related to the fact that AT&T is > announcing the > >>> block directly. I did show "ip bgp 72.14.76.0" in a couple > routers and > >>> some showed the route originating in 701 (they were able to > reach it) > >>> and others showed it originating in 7018 (and they could not > reach it). > >>> > >>> Here is my question, since I am an ARIN admin contact for the > IP block > >>> how is the best way to get AT&T to quit announcing the block. > >>> > >>> > >>> > > -- ----------------- Brian Raaen Network Engineer email: /braaen at zcorum.com/ Telephone /678-507-5000x5574/ -------------- next part -------------- A non-text attachment was scrubbed... Name: braaen.vcf Type: text/x-vcard Size: 206 bytes Desc: not available URL: From sergevautour at yahoo.ca Thu Sep 3 10:20:24 2009 From: sergevautour at yahoo.ca (Serge Vautour) Date: Thu, 3 Sep 2009 08:20:24 -0700 (PDT) Subject: Single router for P/PE functions Message-ID: <462083.54398.qm@web53604.mail.re2.yahoo.com> Hello, I'm pretty confident that a router can be used to perform P & PE functions simultaneously. What about from a best practice perspective? Is this something that should be completely avoided? Why? We're considering doing this as a temporary workaround but we all know temporary usually lasts a long time. I'd like to know what kind of mess awaits if we let this one go. Thanks, Serge __________________________________________________________________ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. From marcus at grmpf.org Thu Sep 3 10:53:31 2009 From: marcus at grmpf.org (Marcus Stoegbauer) Date: Thu, 03 Sep 2009 17:53:31 +0200 Subject: DENOG1 conference registrations are now open Message-ID: <4A9FE67B.9080705@grmpf.org> Hi all, the German Network Operators Group (DENOG) is holding its first meeting on the 5th of November 2009 in Frankfurt, Germany. Registrations are now open at http://meeting.denog.de/registration_en.html Please note that you can benefit from our early bird rebate if you register early. A full agenda will be available until the end of September. A quick reminder: We are still accepting applications for presentations or short lightning talks. If you are interested please read our CfP at http://meeting.denog.de/cfp_en.html Hope to see you in November, Marcus From mathews at hawaii.edu Thu Sep 3 11:51:41 2009 From: mathews at hawaii.edu (Robert Mathews (OSIA)) Date: Thu, 03 Sep 2009 12:51:41 -0400 Subject: Got this from Educause... Message-ID: <4A9FF41D.5080107@hawaii.edu> Apologies in advance, to those who, as administrators of EDU domains, may have already received this from EDUCASE... Finally, DNSSEC is going to make its way to ".edu" Are we ready? Has resistance been obliterated? Test-bed implementation.. Sept, '09.... -- -------- Original Message -------- Subject: Security of .edu Internet Domain to Increase September 3, 2009, Washington, D.C.?EDUCAUSE and VeriSign announced today the initiation of a project to enhance Internet reliability and stability. By the end of March 2010, the project will deploy a security system known as Domain Name Security Extensions (DNSSEC) within the .edu portion of the Internet, which EDUCAUSE manages under a cooperative agreement with the U.S. Department of Commerce. When the project is completed, institutions whose domain names end in .edu will be able to incorporate a digital signature into those names to limit a variety of security vulnerabilities. The Domain Name System (DNS) is the part of the Internet that translates names such as "educause.edu" into numeric addresses (for example, 198.59.61.90). All Internet applications?from electronic mail to online banking?depend on the accuracy and integrity of this translation. Over the years, Internet security experts have discovered a variety of ways that DNS translation may be compromised. The DNSSEC security system limits the problem by allowing owners of domain names to provide a digital signature that adds an extra level of authentication to the translation process. The project plan includes a test-bed implementation, targeted for September 2009, to allow predeployment testing by a number of selected campuses in a nonproduction environment. Final deployment of DNSSEC for .edu will build on the previously announced U.S. Department of Commerce project to deploy DNSSEC at the authoritative root zone of the Internet. [ .... ] From ren.provo at gmail.com Thu Sep 3 15:01:35 2009 From: ren.provo at gmail.com (Ren Provo) Date: Thu, 3 Sep 2009 16:01:35 -0400 Subject: NANOG47 - Program Committee will meet next week to review second round submissions Message-ID: <787581440909031301j6bf88a12p3f45c2398510f2ec@mail.gmail.com> Hi folks, There are many interesting abstracts in the tool at http://pc.nanog.org and we hope to see a few more presentations arrive prior to next Wednesday. Lightning talks will not be accepted until October. That doesn't mean you can't kick out that first draft to a friend for inspiration! Election season is also drawing close. The election timeline is now online at http://www.nanog.org/governance/elections/2009elections/ Last but not least, the hotel group rate expires this month - http://www.nanog.org/meetings/nanog47/hotel.php Cheers, -ren From rbonica at juniper.net Thu Sep 3 15:00:46 2009 From: rbonica at juniper.net (Ron Bonica) Date: Thu, 3 Sep 2009 16:00:46 -0400 Subject: draft-iana-ipv4-examples Message-ID: <4AA0206E.2080303@juniper.net> Folks, The IETF has recently passed draft-iana-rfc3330bis-08. This draft documents the fact that the following address ranges have been reserved for documentation: - 192.0.2.0/24 (TEST-NET-1) - 198.51.100.0/24 (TEST-NET-2) - 203.0.113.0/24 (TEST-NET-3) In addition, some authors have used 128.66.0.0/16 (TEST-B) for example purposes. There is no RFC that talks about this block, but my understanding is that IANA/ARIN have marked it as reserved. If you search the Internet you will find at least some number of examples and firewall rule sets that use this block, but I have no good idea about how widespread such usage is. What should we do about this block? Some of the potential answers include documenting its role, marking it as reserved but deprecating its use in examples, and returning it to the free pool immediately (with a warning sign about possible filtering problems). Comments? Ron From beckman at angryox.com Thu Sep 3 16:20:23 2009 From: beckman at angryox.com (Peter Beckman) Date: Thu, 3 Sep 2009 17:20:23 -0400 Subject: 83.222.0.0/19 Unroutable on Verizon Message-ID: I can't reach 83.222.0.0/19 from Verizon, but I can via Cox Communications Business Fiber as well as Level3. Dies at a peering point it seems: HOST: home Loss% Snt Last Avg Best Wrst StDev 1. mph 0.0% 20 0.7 0.6 0.5 0.7 0.1 2. 10.1.41.89 0.0% 20 2.3 3.6 1.7 26.4 5.6 3. G2-0-3-891.WASHDC-LCR-08.ver 0.0% 20 2.1 1.9 1.6 2.2 0.2 4. so-1-1-0-0.RES-BB-RTR2.veriz 0.0% 20 2.3 2.4 2.2 2.8 0.1 5. 0.so-6-1-0.XL4.IAD8.ALTER.NE 0.0% 20 2.8 2.8 2.6 3.0 0.1 6. 0.xe-8-1-0.BR1.IAD8.ALTER.NE 0.0% 20 5.1 8.4 3.0 40.3 9.4 7. 64.212.107.157 0.0% 20 203.2 14.0 3.0 203.2 44.6 8. ??? 100.0 20 0.0 0.0 0.0 0.0 0.0 Hop 7 alternates between 64.212.107.157 (GBLX) and 204.255.169.202 (MCI dba Verizon) and dies after that. 83.222.32.0/19 seems to route correctly. Can anyone else confirm? Bad BGP Announcement? Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From morrowc.lists at gmail.com Thu Sep 3 16:27:19 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 3 Sep 2009 17:27:19 -0400 Subject: 83.222.0.0/19 Unroutable on Verizon In-Reply-To: References: Message-ID: <75cb24520909031427l862cf88q11f38be57434ea86@mail.gmail.com> On Thu, Sep 3, 2009 at 5:20 PM, Peter Beckman wrote: > I can't reach 83.222.0.0/19 from Verizon, but I can via Cox Communications > Business Fiber as well as Level3. ?Dies at a peering point it seems: > > HOST: home ? ? ? ? ? ? ? ? ? ? ? ?Loss% ? Snt ? Last ? Avg ?Best ?Wrst StDev > ?1. mph ? ? ? ? ? ? ? ? ? ? ? ? ? 0.0% ? ?20 ? ?0.7 ? 0.6 ? 0.5 ? 0.7 ? 0.1 > ?2. 10.1.41.89 ? ? ? ? ? ? ? ? ? ?0.0% ? ?20 ? ?2.3 ? 3.6 ? 1.7 ?26.4 ? 5.6 > ?3. G2-0-3-891.WASHDC-LCR-08.ver ?0.0% ? ?20 ? ?2.1 ? 1.9 ? 1.6 ? 2.2 ? 0.2 > ?4. so-1-1-0-0.RES-BB-RTR2.veriz ?0.0% ? ?20 ? ?2.3 ? 2.4 ? 2.2 ? 2.8 ? 0.1 > ?5. 0.so-6-1-0.XL4.IAD8.ALTER.NE ?0.0% ? ?20 ? ?2.8 ? 2.8 ? 2.6 ? 3.0 ? 0.1 > ?6. 0.xe-8-1-0.BR1.IAD8.ALTER.NE ?0.0% ? ?20 ? ?5.1 ? 8.4 ? 3.0 ?40.3 ? 9.4 > ?7. 64.212.107.157 ? ? ? ? ? ? ? ?0.0% ? ?20 ?203.2 ?14.0 ? 3.0 203.2 ?44.6 > ?8. ??? ? ? ? ? ? ? ? ? ? ? ? ? ?100.0 ? ?20 ? ?0.0 ? 0.0 ? 0.0 ? 0.0 ? 0.0 it's actually being handed off to the next provider... so, maybe this thread is mis-named? this looks like GBLX route filtering or traffic filtering. From twtelecom I see this die inside 'retn.net' 111ms from ashburn-ish. (so, in emea somewhere) -chris > > Hop 7 alternates between 64.212.107.157 (GBLX) and 204.255.169.202 (MCI dba > Verizon) and dies after that. 83.222.32.0/19 seems to route correctly. > > Can anyone else confirm? ?Bad BGP Announcement? > > Beckman > --------------------------------------------------------------------------- > Peter Beckman ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Internet Guy > beckman at angryox.com ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? http://www.angryox.com/ > --------------------------------------------------------------------------- > > From cordmacleod at gmail.com Thu Sep 3 16:30:01 2009 From: cordmacleod at gmail.com (Cord MacLeod) Date: Thu, 3 Sep 2009 14:30:01 -0700 Subject: 83.222.0.0/19 Unroutable on Verizon In-Reply-To: References: Message-ID: On Sep 3, 2009, at 2:20 PM, Peter Beckman wrote: > I can't reach 83.222.0.0/19 from Verizon, but I can via Cox > Communications > Business Fiber as well as Level3. Dies at a peering point it seems: route-views.oregon-ix.net>sh ip bgp 83.222.0.0 BGP routing table entry for 83.222.0.0/19, version 14706715 Paths: (34 available, best #6, table Default-IP-Routing-Table) Not advertised to any peer 1221 4637 3549 9002 25532 203.62.252.186 from 203.62.252.186 (203.62.252.186) Origin IGP, localpref 100, valid, external 3549 9002 25532 208.51.134.254 from 208.51.134.254 (208.178.61.33) Origin IGP, metric 14088, localpref 100, valid, external 3561 9002 25532 206.24.210.102 from 206.24.210.102 (206.24.210.102) Origin IGP, localpref 100, valid, external 16150 9002 25532 217.75.96.60 from 217.75.96.60 (217.75.96.60) Origin IGP, metric 0, localpref 100, valid, external Community: 16150:63392 16150:65215 16150:65320 3277 3267 25532 194.85.4.55 from 194.85.4.55 (194.85.4.16) Origin IGP, localpref 100, valid, external Community: 3277:3267 3277:65100 3277:65320 3277:65326 3267 25532 194.85.40.15 from 194.85.40.15 (193.232.80.7) Origin IGP, localpref 100, valid, external, best 2914 9002 25532 129.250.0.171 from 129.250.0.171 (129.250.0.79) Origin IGP, metric 308, localpref 100, valid, external Community: 2914:410 2914:2202 2914:3200 3582 4600 11537 9002 25532 128.223.253.8 from 128.223.253.8 (128.223.253.8) Origin IGP, localpref 100, valid, external Community: 3582:567 4600:199 6079 9002 25532 207.172.6.1 from 207.172.6.1 (207.172.6.1) Origin IGP, metric 0, localpref 100, valid, external 2828 3561 9002 25532 65.106.7.139 from 65.106.7.139 (66.239.189.139) Origin IGP, metric 3, localpref 100, valid, external 2905 702 9002 25532 196.7.106.245 from 196.7.106.245 (196.7.106.245) Origin IGP, metric 0, localpref 100, valid, external 3333 9002 25532 193.0.0.56 from 193.0.0.56 (193.0.0.56) Origin IGP, localpref 100, valid, external 701 3549 9002 25532 157.130.10.233 from 157.130.10.233 (137.39.3.60) ^^^ Origin IGP, localpref 100, valid, external 812 174 3561 9002 25532 64.71.255.61 from 64.71.255.61 (64.71.255.61) Origin IGP, localpref 100, valid, external 7660 2516 3549 9002 25532 203.181.248.168 from 203.181.248.168 (203.181.248.168) Origin IGP, localpref 100, valid, external Community: 2516:1030 3257 3549 9002 25532 89.149.178.10 from 89.149.178.10 (213.200.87.91) Origin IGP, metric 10, localpref 100, valid, external Community: 3257:8012 3257:30070 3257:50001 3257:54900 3257:54901 6079 9002 25532 207.172.6.20 from 207.172.6.20 (207.172.6.20) Origin IGP, metric 117, localpref 100, valid, external 6453 3549 9002 25532 207.45.223.244 from 207.45.223.244 (66.110.0.124) Origin IGP, localpref 100, valid, external 6453 3549 9002 25532 195.219.96.239 from 195.219.96.239 (195.219.96.239) Origin IGP, localpref 100, valid, external 852 174 3549 9002 25532 154.11.11.113 from 154.11.11.113 (154.11.11.113) Origin IGP, metric 0, localpref 100, valid, external Community: 852:180 1668 3561 9002 25532 66.185.128.48 from 66.185.128.48 (66.185.128.50) Origin IGP, metric 511, localpref 100, valid, external 4826 9002 25532 114.31.199.1 from 114.31.199.1 (114.31.199.1) Origin IGP, localpref 100, valid, external 852 174 3549 9002 25532 154.11.98.225 from 154.11.98.225 (154.11.98.225) Origin IGP, metric 0, localpref 100, valid, external Community: 852:180 8075 9002 25532 207.46.32.34 from 207.46.32.34 (207.46.32.34) Origin IGP, localpref 100, valid, external 2914 9002 25532 129.250.0.11 from 129.250.0.11 (129.250.0.51) Origin IGP, metric 393, localpref 100, valid, external Community: 2914:410 2914:2202 2914:3200 2497 9002 25532 202.232.0.2 from 202.232.0.2 (202.232.0.2) Origin IGP, localpref 100, valid, external 7018 3561 9002 25532 12.0.1.63 from 12.0.1.63 (12.0.1.63) Origin IGP, localpref 100, valid, external Community: 7018:5000 3356 9002 25532 4.69.184.193 from 4.69.184.193 (4.68.3.50) Origin IGP, metric 0, localpref 100, valid, external Community: 3356:2 3356:22 3356:100 3356:123 3356:507 3356:2076 65000:0 286 3549 9002 25532 134.222.87.1 from 134.222.87.1 (134.222.86.1) Origin IGP, localpref 100, valid, external Community: 286:18 286:19 286:28 286:29 286:800 286:888 286:3049 286:4017 3549:350 3549:4811 3549:31752 6539 9002 25532 66.59.190.221 from 66.59.190.221 (66.59.190.221) Origin IGP, localpref 100, valid, external 3303 9002 25532 164.128.32.11 from 164.128.32.11 (164.128.32.11) Origin IGP, localpref 100, valid, external Community: 3303:1004 3303:1006 3303:3054 7500 2497 9002 25532 202.249.2.86 from 202.249.2.86 (203.178.133.115) Origin IGP, localpref 100, valid, external 5459 9002 25532 195.66.232.239 from 195.66.232.239 (195.66.232.239) Origin IGP, localpref 100, valid, external Community: 5459:1 5459:60 6939 9002 25532 216.218.252.164 from 216.218.252.164 (216.218.252.164) Origin IGP, localpref 100, valid, external From nanog-post at rsuc.gweep.net Thu Sep 3 16:34:48 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Thu, 3 Sep 2009 17:34:48 -0400 Subject: 83.222.0.0/19 Unroutable on Verizon In-Reply-To: References: Message-ID: <20090903213448.GA63114@gweep.net> [comment: subject is irksome - "Unroutable"? That is meaningless] On Thu, Sep 03, 2009 at 05:20:23PM -0400, Peter Beckman wrote: > I can't reach 83.222.0.0/19 from Verizon, but I can via Cox Communications > Business Fiber as well as Level3. Dies at a peering point it seems: > > HOST: home Loss% Snt Last Avg Best Wrst StDev > 1. mph 0.0% 20 0.7 0.6 0.5 0.7 0.1 [snip] Presumably ICMP probes - those are frequently rate-limited as counter-measures you realize? And which Verizon? 701 clearly shows it in its tables and packets go there. Since your mtr or whatever shows the traffic reaching a GBLX address, so you likely want to reach out to them. > Can anyone else confirm? Bad BGP Announcement? What does your table say? How does that compare to data in RIS, route-views, etc? Independent investigation with table data -if your concern is the state of someone's "routing"- would help. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From beckman at angryox.com Thu Sep 3 17:48:12 2009 From: beckman at angryox.com (Peter Beckman) Date: Thu, 3 Sep 2009 18:48:12 -0400 Subject: 83.222.0.0/19 Unreachable on Verizon In-Reply-To: References: Message-ID: Subject updated to be less wrong. On Thu, 3 Sep 2009, Peter Beckman wrote: > I can't reach 83.222.0.0/19 from Verizon, but I can via Cox Communications > Business Fiber as well as Level3. Dies at a peering point it seems: > > HOST: home Loss% Snt Last Avg Best Wrst StDev > 1. mph 0.0% 20 0.7 0.6 0.5 0.7 0.1 > 2. 10.1.41.89 0.0% 20 2.3 3.6 1.7 26.4 5.6 > 3. G2-0-3-891.WASHDC-LCR-08.ver 0.0% 20 2.1 1.9 1.6 2.2 0.2 > 4. so-1-1-0-0.RES-BB-RTR2.veriz 0.0% 20 2.3 2.4 2.2 2.8 0.1 > 5. 0.so-6-1-0.XL4.IAD8.ALTER.NE 0.0% 20 2.8 2.8 2.6 3.0 0.1 > 6. 0.xe-8-1-0.BR1.IAD8.ALTER.NE 0.0% 20 5.1 8.4 3.0 40.3 9.4 > 7. 64.212.107.157 0.0% 20 203.2 14.0 3.0 203.2 44.6 > 8. ??? 100.0 20 0.0 0.0 0.0 0.0 0.0 > > Hop 7 alternates between 64.212.107.157 (GBLX) and 204.255.169.202 (MCI dba > Verizon) and dies after that. 83.222.32.0/19 seems to route correctly. I've called both the Verizon NOC and UUNET NOC, talked to friendly people who told me nicely to go talk to someone else. My next step will be to contact ip-noc at verizonbusiness.com as per the netops NOC list. Any IPs in 83.222.0.0/19 that ARE reachable on L3 and Cox are not reachable on Verizon. Please note I'm not doing traceroutes to 83.222.0.0 or 83.222.0.0/19. I'm tracing hosts that are known to be up and traceable, and are within this block. An interesting side note -- I can't get to retn.net either on Verizon, but can elsewhere, which is 81.222.33.89. As an end user smart enough to figure out why a website isn't loading, it is a GIANT PAIN and next to impossible to report a network issue when you are a non-customer, non-ISP employee. This is why I posted this on NANOG, because I'm trying to promote dialog between people concerning the operation of IP networks. Verizon asked me to reboot my router. I hung up. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From darren at bolding.org Thu Sep 3 20:22:45 2009 From: darren at bolding.org (Darren Bolding) Date: Thu, 3 Sep 2009 18:22:45 -0700 Subject: Power basics- any resources? Message-ID: <5a318d410909031822t48407fdjeafed23034106725@mail.gmail.com> I need to teach an operations group (Systems, Network, Security, IT folks) some basics of power as it applies to the team. Normal things they will see and should understand when they are planning on bringing equipment online etc. I have an idea of many things to talk about, particularly as they apply to our environment, but I was hoping there might be some publicly available slides or docs that I could take advantage of. I'll be happy to share anything we come up with- though this may just be me in front of a whiteboard. Here are some of the questions I plan to cover: What are amps, volts and watts? What are Volt-Amps, and why do they matter? How much can I load that circuit? How does a breaker work? Where are the breakers at our sites? What should you do if a breaker trips? How do we know how much load a device will place on a circuit? How do we monitor power usage? Basic safety. Redundant power. Thanks for any pointers! -- -- Darren Bolding -- -- darren at bolding.org -- From darren at bolding.org Thu Sep 3 20:27:21 2009 From: darren at bolding.org (Darren Bolding) Date: Thu, 3 Sep 2009 18:27:21 -0700 Subject: Request for a pointer - Linux modifying DSCP on replies? In-Reply-To: <5a318d410908171608n70f20e08te3bd609a4f4951c1@mail.gmail.com> References: <5a318d410908171419n560075aar6e589145cf223efe@mail.gmail.com> <5a318d410908171608n70f20e08te3bd609a4f4951c1@mail.gmail.com> Message-ID: <5a318d410909031827u27b07c14sa44866d654c08833@mail.gmail.com> I wanted to go ahead and reply back with what I figured out. The easiest way to solve this problem turned out to be to utilize netfilters CONNMARK module, which sadly is not available in some older but still used linux kernels. Syntax for this is as follows: # Set outgoing DSCP on connections to same as incoming DSCP -A PREROUTING -m dscp --dscp 1 -j CONNMARK --set-mark 1 -A POSTROUTING -m connmark --mark 1 -j DSCP --set-dscp 1 -A PREROUTING -m dscp --dscp 2 -j CONNMARK --set-mark 2 -A POSTROUTING -m connmark --mark 2 -j DSCP --set-dscp 2 And this goes on for all 63 possible non-zero markings. This seems to have had negligible performance or memory impact on some very busy hosts, so it seems like a viable solution. --D On Mon, Aug 17, 2009 at 4:08 PM, Darren Bolding wrote: > Steve, > Perhaps it is outside the DS domain, and that is the issue. It seems odd > that the behavior with ICMP/Ping is different than that with TCP however. > Not sure which is technically correct, but I am going to follow up on some > of the pointers I've gotten to try and learn that. It just seems natural to > me that connection oriented traffic would have the same markings on both > sides of the conversation unless explicitly told otherwise. > > I would love to be able to mark the traffic at the edge of the DS domain- I > do this at ingress from one location. The challenge I am trying to solve is > that the DS edge switch will not reliably know how to policy-route traffic > unless it has been previously marked. > > To clarify, as in many other environments, we have stateful devices such as > firewalls and load balancers. I want to be able to route traffic > that ingressed through one of these devices to egress through it as well. > This is entirely solvable by splitting equipment functionally (a cluster of > servers and associated network equipment, real or virtual associated with a > service) or by employing SNAT solutions. However, for various reasons these > solutions are not preferred in our environment, and I dare say I am not > alone in that viewpoint. > > What I am trying to deploy now is a system where the stateful equipment (in > this case a load balancer) has its traffic to the rest of the network tagged > on ingress. Since I am using Cisco 6500's with sup720's, I can classify and > mark the traffic with a DSCP setting via PFC/DFC hardware. I then inspect > traffic at the layer-3 edge for the various pools of servers. Depending on > the DSCP marking of the packet, I change the next-hop. Since this is > implemented through an extended ACL for a route-map it is handled in > hardware (a good thing). Research shows that I can implement similar > functionality in hardware on L3 switching gear from Juniper, Foundry, etc. > so I am not boxing myself into a vendor. > > I don't believe Cisco supports using reflexive-acl's to apply policy > routing, and even if they did, that would likely swamp our sup's CPU's, so I > don't believe maintaining a stateful filter on the switch is viable. > > This all works as expected for Ping's and the ICMP replies. It breaks down > for TCP http/mysql connections. > > It sounds like the correct (per-spec) solution may be to have the Linux > servers track the incoming connections DSCP setting and mark the outgoing > packets related to those connections. I am not at all certain this will not > hit the servers CPU's more than desired or require additional > connection-tracking resources than the ones we currently implement via > iptables. > > Is there some other design option I am not considering? > > Thanks to those of you who have replied so far, it is at least a start down > some additional paths of research for me! It's been since the days of BSDI > that I have been involved in system networking internals, so I have been at > a loss who to even ask! > > --D > > On Mon, Aug 17, 2009 at 2:44 PM, Steve Miller wrote: > >> Would not the end station be considered to be outside of the DS >> domain? It does not necessarily make sense (to me) for reply packets >> to be marked unless they are appropriate classified and marked on the >> return path at the point they re-enter the DS domain. >> >> I would imagine that iptables and the DSCP target would do what you >> wanted, yes. I'd consider classifying and marking traffic at whatever >> switch you would consider to be at the edge of the DS domain >> (connected to this server.) >> >> -Steve >> >> 2009/8/17 Darren Bolding : >> > I believe this is operational content, but may well be better asked >> > somewhere else. I would love to have a pointer to another list/website. >> > I am looking to do some policy routing based on DSCP marking, and I have >> > this all working inside the networking equipment. I DSCP mark some >> packets >> > at ingress and I policy-route others based on ACL's matching those DSCP >> > markings. This should allow me to solve some problems in a rather >> elegant >> > manner, if I do say so myself. >> > >> > And this works fine for some things- I have verified that Ping's to a >> host >> > work as expected- the Ping shows up at the destination host DSCP marked, >> and >> > the ICMP reply leaves with the same DSCP marking. >> > >> > However, when I do this with apache and mysql connections (TCP 80/3306), >> the >> > incoming packets are marked, but the replies are not. >> > >> > My research into the subject doesn't seem to suggest there is a standard >> for >> > whether replies to a TCP connection are required to have the same DSCP >> > marking, but it seems to make a lot of sense that they would. >> > >> > I've disabled iptables on the server host to no avail. I've looked >> around >> > for an apache or Linux kernel setting and found nothing. >> > >> > At this point I'm looking for pointers- to a way to solve this issue, or >> to >> > a better place to ask. >> > >> > I've started investigating writing iptables rules to match incoming >> > connections that have DSCP marking and explicitly mark response traffic, >> but >> > that seems, I don't know... wrong. >> > >> > Linux kernel we are using is 2.6.9-67.ELsmp. >> > >> > Any help or pointers would be appreciated! >> > >> > --D >> > >> > -- >> > -- Darren Bolding -- >> > -- darren at bolding.org -- >> > >> >> >> >> -- >> Steve Miller, CCIE #23977 (R&S), RHCE >> Key fingerprint = 5CE3 A789 4CF5 666F 5CD6 2A8E 3132 77C7 483F 5F9D >> > > > > -- > -- Darren Bolding -- > -- darren at bolding.org -- > -- -- Darren Bolding -- -- darren at bolding.org -- From dpeterson at sixapart.com Thu Sep 3 20:40:53 2009 From: dpeterson at sixapart.com (David B. Peterson) Date: Thu, 3 Sep 2009 18:40:53 -0700 Subject: Power basics- any resources? In-Reply-To: <5a318d410909031822t48407fdjeafed23034106725@mail.gmail.com> References: <5a318d410909031822t48407fdjeafed23034106725@mail.gmail.com> Message-ID: <739410C8-7238-4ACB-A260-D1C34866B2FD@sixapart.com> When it's ok to use a C14 to NEMA 5-15R cable and when it's really NOT ok.. On Sep 3, 2009, at 6:22 PM, Darren Bolding wrote: > I need to teach an operations group (Systems, Network, Security, IT > folks) > some basics of power as it applies to the team. Normal things they > will see > and should understand when they are planning on bringing equipment > online > etc. > I have an idea of many things to talk about, particularly as they > apply to > our environment, but I was hoping there might be some publicly > available > slides or docs that I could take advantage of. > > I'll be happy to share anything we come up with- though this may > just be me > in front of a whiteboard. > > Here are some of the questions I plan to cover: > > What are amps, volts and watts? > > What are Volt-Amps, and why do they matter? > > How much can I load that circuit? > > How does a breaker work? > > Where are the breakers at our sites? > > What should you do if a breaker trips? > > How do we know how much load a device will place on a circuit? > > How do we monitor power usage? > > Basic safety. > > Redundant power. > > > Thanks for any pointers! > > -- > -- Darren Bolding -- > -- darren at bolding.org -- From netfortius at gmail.com Thu Sep 3 20:48:51 2009 From: netfortius at gmail.com (Stefan) Date: Thu, 3 Sep 2009 20:48:51 -0500 Subject: Power basics- any resources? In-Reply-To: <5a318d410909031822t48407fdjeafed23034106725@mail.gmail.com> References: <5a318d410909031822t48407fdjeafed23034106725@mail.gmail.com> Message-ID: APC (http://www.apc.com) has lots of info Data Center related (...support...), where you could find some good stuff. HTH On 9/3/09, Darren Bolding wrote: > I need to teach an operations group (Systems, Network, Security, IT folks) > some basics of power as it applies to the team. Normal things they will see > and should understand when they are planning on bringing equipment online > etc. > I have an idea of many things to talk about, particularly as they apply to > our environment, but I was hoping there might be some publicly available > slides or docs that I could take advantage of. > > I'll be happy to share anything we come up with- though this may just be me > in front of a whiteboard. > > Here are some of the questions I plan to cover: > > What are amps, volts and watts? > > What are Volt-Amps, and why do they matter? > > How much can I load that circuit? > > How does a breaker work? > > Where are the breakers at our sites? > > What should you do if a breaker trips? > > How do we know how much load a device will place on a circuit? > > How do we monitor power usage? > > Basic safety. > > Redundant power. > > > Thanks for any pointers! > > -- > -- Darren Bolding -- > -- darren at bolding.org -- > -- Sent from my mobile device ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius From jmamodio at gmail.com Thu Sep 3 21:50:57 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 3 Sep 2009 21:50:57 -0500 Subject: Power basics- any resources? In-Reply-To: <5a318d410909031822t48407fdjeafed23034106725@mail.gmail.com> References: <5a318d410909031822t48407fdjeafed23034106725@mail.gmail.com> Message-ID: <202705b0909031950o38bdaaf9q909578f44180bda6@mail.gmail.com> Remind them that power does not come from "the wall", there are many things they have to keep an eye on, and know where they are and what not to touch and who can touch and when. ie Transformers, transfer switches, dc power plants if you have them, etc, etc. My .02 From erik at schmersal.us Thu Sep 3 23:00:22 2009 From: erik at schmersal.us (Erik Schmersal) Date: Thu, 3 Sep 2009 23:00:22 -0500 Subject: Single router for P/PE functions In-Reply-To: References: <462083.54398.qm@web53604.mail.re2.yahoo.com> Message-ID: > Not only can they, it's done quite frequently. I just completed a >> deployment of seven Juniper MX series routers in a dual ring configuration, >> all acting as combination P/PE devices for a state government WAN backbone. >> Works like a charm. >> >> Erik >> >> >> On Thu, Sep 3, 2009 at 10:20 AM, Serge Vautour wrote: >> >>> Hello, >>> >>> I'm pretty confident that a router can be used to perform P & PE >>> functions simultaneously. What about from a best practice perspective? Is >>> this something that should be completely avoided? Why? We're considering >>> doing this as a temporary workaround but we all know temporary usually lasts >>> a long time. I'd like to know what kind of mess awaits if we let this one >>> go. >>> >>> Thanks, >>> Serge >>> >>> >>> >>> __________________________________________________________________ >>> Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your >>> favourite sites. Download it now >>> http://ca.toolbar.yahoo.com. >>> >>> >> > From william.mccall at gmail.com Thu Sep 3 23:07:40 2009 From: william.mccall at gmail.com (William McCall) Date: Thu, 3 Sep 2009 23:07:40 -0500 Subject: Single router for P/PE functions In-Reply-To: <462083.54398.qm@web53604.mail.re2.yahoo.com> References: <462083.54398.qm@web53604.mail.re2.yahoo.com> Message-ID: Kinda depends on what you're doing exactly, but like Erik said, it certainly possible and depending on your particular needs, it might not be much of an issue at all. Can you describe your scenario a bit more? --WM On Thu, Sep 3, 2009 at 10:20 AM, Serge Vautour wrote: > Hello, > > I'm pretty confident that a router can be used to perform P & PE functions > simultaneously. What about from a best practice perspective? Is this > something that should be completely avoided? Why? We're considering doing > this as a temporary workaround but we all know temporary usually lasts a > long time. I'd like to know what kind of mess awaits if we let this one go. > > Thanks, > Serge > > > > __________________________________________________________________ > Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your > favourite sites. Download it now > http://ca.toolbar.yahoo.com. > > -- William McCall, CCIE #25044 From swmike at swm.pp.se Thu Sep 3 23:14:52 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 4 Sep 2009 06:14:52 +0200 (CEST) Subject: Single router for P/PE functions In-Reply-To: <462083.54398.qm@web53604.mail.re2.yahoo.com> References: <462083.54398.qm@web53604.mail.re2.yahoo.com> Message-ID: On Thu, 3 Sep 2009, Serge Vautour wrote: > I'm pretty confident that a router can be used to perform P & PE > functions simultaneously. What about from a best practice perspective? > Is this something that should be completely avoided? Why? We're > considering doing this as a temporary workaround but we all know > temporary usually lasts a long time. I'd like to know what kind of mess > awaits if we let this one go. Collapsing P/PE functions certainly saves CAPEX, the downside is that you might need to reload your PE (affecting customers) due to a core feature upgrade or bug fix, or the other way around. With separate P and PE functions and PEs being dual attached to two Ps, you can reboot P layer with minimal end customer impact. I'd imagine that in smaller networks it makes more sense to collapse compared to larger network, because a smaller network has fewer customers to be affected by each router problem. It's basically "put all the eggs in one basket" kind of issue, it's easier to carry around but you lose more when something happens. -- Mikael Abrahamsson email: swmike at swm.pp.se From mehmet at icann.org Fri Sep 4 01:27:11 2009 From: mehmet at icann.org (Mehmet Akcin) Date: Thu, 3 Sep 2009 23:27:11 -0700 Subject: picking up server vendor in a global scope.. In-Reply-To: <6D5B7067-6D56-49E2-9432-10005F8A351B@akcin.net> References: <6D5B7067-6D56-49E2-9432-10005F8A351B@akcin.net> Message-ID: <793F7DF5-AEA0-451A-832A-7B275C6FF656@icann.org> Thank you for all your responses.. I thought i would drop a short recap note for those who will be reading this in the future while searching the same information. I have been recommended by various people who have personally dealt the relations with server vendors around the world and many have recommended Sun as a global choice. 2nd most popular in the answers were HP. Mehmet From Serg at Macomnet.ru Fri Sep 4 04:38:56 2009 From: Serg at Macomnet.ru (Serg Shubenkov) Date: Fri, 4 Sep 2009 13:38:56 +0400 (MSD) Subject: as702 looking glass? Message-ID: <20090904133726.D35511@mp2.macomnet.net> Folks, Does anyone know if Verizon (AS702) has a publicly accessable looking glass? -- Serg Shubenkov From william.allen.simpson at gmail.com Fri Sep 4 04:43:04 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Fri, 04 Sep 2009 05:43:04 -0400 Subject: draft-iana-ipv4-examples In-Reply-To: <4AA0206E.2080303@juniper.net> References: <4AA0206E.2080303@juniper.net> Message-ID: <4AA0E128.8040809@gmail.com> Ron Bonica wrote: > In addition, some authors have used 128.66.0.0/16 (TEST-B) for example > purposes. There is no RFC that talks about this block, but my > understanding is that IANA/ARIN have marked it as reserved. If you > search the Internet you will find at least some number of examples and > firewall rule sets that use this block, but I have no good idea about > how widespread such usage is. > The only examples that I've found are firewall rule sets that block many ranges now allocated. Such as NANOG 2002 email: http://www.merit.edu/mail.archives/nanog/2002-12/msg00127.html It's no different from net 69 et alia. A couple of larger examples, widely propagated: NoRouteIPs="{127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8, 0.0.0.0/7, 2.0.0.0/8, 5.0.0.0/8, 10.0.0.0/8, 23.0.0.0/8, 27.0.0.0/8, 31.0.0.0/8, 69.0.0.0/8, 70.0.0.0/7, 72.0.0.0/5, 82.0.0.0/7, 84.0.0.0/6, 88.0.0.0/5, 96.0.0.0/3, 127.0.0.0/8, 128.0.0.0/16, 128.66.0.0/16, 169.254.0.0/16, 172.16.0.0/12, 191.255.0.0/16, 192.0.0.0/19, 192.0.48.0/20, 192.0.64.0/18, 192.0.128.0/17}" block in log quick on external from 0.0.0.0/7 to any block in log quick on external from 2.0.0.0/8 to any block in log quick on external from 5.0.0.0/8 to any block in log quick on external from 10.0.0.0/8 to any block in log quick on external from 23.0.0.0/8 to any block in log quick on external from 27.0.0.0/8 to any block in log quick on external from 31.0.0.0/8 to any block in log quick on external from 69.0.0.0/8 to any block in log quick on external from 70.0.0.0/7 to any block in log quick on external from 72.0.0.0/5 to any block in log quick on external from 82.0.0.0/7 to any block in log quick on external from 84.0.0.0/6 to any block in log quick on external from 88.0.0.0/5 to any block in log quick on external from 96.0.0.0/3 to any block in log quick on external from 127.0.0.0/8 to any block in log quick on external from 128.0.0.0/16 to any block in log quick on external from 128.66.0.0/16 to any block in log quick on external from 169.254.0.0/16 to any block in log quick on external from 172.16.0.0/12 to any block in log quick on external from 191.255.0.0/16 to any block in log quick on external from 192.0.0.0/19 to any block in log quick on external from 192.0.48.0/20 to any block in log quick on external from 192.0.64.0/18 to any block in log quick on external from 192.0.128.0/17 to any block in log quick on external from 192.168.0.0/16 to any block in log quick on external from 197.0.0.0/8 to any block in log quick on external from 201.0.0.0/8 to any block in log quick on external from 204.152.64.0/23 to any block in log quick on external from 224.0.0.0/3 to any > What should we do about this block? Some of the potential answers > include documenting its role, marking it as reserved but deprecating its > use in examples, and returning it to the free pool immediately (with a > warning sign about possible filtering problems). > Return to the free pool immediately. Allocate it to *IXen, who might appreciate it being blocked from view by random outsiders. From nanog at schmersal.us Fri Sep 4 09:07:34 2009 From: nanog at schmersal.us (Erik Schmersal) Date: Fri, 4 Sep 2009 09:07:34 -0500 Subject: Single router for P/PE functions In-Reply-To: <4aa1189b.9e15f10a.5d53.ffffe1eeSMTPIN_ADDED@mx.google.com> References: <462083.54398.qm@web53604.mail.re2.yahoo.com> <4aa1189b.9e15f10a.5d53.ffffe1eeSMTPIN_ADDED@mx.google.com> Message-ID: Hi dave, Our setup was a dual ring with two devices common to both rings. It used a full mesh of LSP's but the majority of traffic was L3VPN. There were some VPLS connections as well, maybe a total of 30 VLAN's. LSP's were set up with static path's the short way around the ring and a standby active secondary path the long way around. Convergence time for a failure on either ring was barely noticable. I am no longer with that organization so I can't get access to the gear anymore :( >From my experience, you are probably just asking the EX4200 to do more than it was made to do. That is a lot of CCC circuits to reallocate on the fly, especially for a smaller device. You may me able to reduce convergence time by making your LSP's static with a standby secondary so the path is preconfigured when a failover occurs, the only problem with this is the scalability gets poor quickly as you start to add devices. Erik On Fri, Sep 4, 2009 at 8:39 AM, daveb wrote: > > Hi, I saw your response on NANOG and have a couple questions for you if you > don't mind. I'm doing a similar design with MPLS (OSPF/RSVP) on EX4200s in > a 10GE ring, mainly for 'ccc' circuits and IP connectivity. The EX4200 > serves both the P and PE functions and some of my rings may be as large as > 30 devices. > > In my informal lab test with just 4 EXs in a ring, the convergence time > (optomized with FRR, path protection and 50ms BDF) for 1 ccc circuit was > 300ms and with 200 ccc circuits it was several seconds, and 800 kills the > box. I can't imaging what it would be like with 20 or 30 device in the > ring. > > I was just wondering if you've doen similar testing with the MX as far as > scaling. I'm assuming the EX4200 just isn't up to the task but I'm also > concerned that ring topologies are problematic for re-routing LSPs. I can > test to find the optimum/maximum number of allowable ccc circuits with 4 > devices in the ring but I have no way or testing with 20 or 30 so I'm really > trying to determine how much worse convergence is with more devices vs > number of LSPs. > > Thanks, > Dave Bernardi > > > > At 12:00 AM 9/4/2009, Erik Schmersal wrote: > >> > Not only can they, it's done quite frequently. I just completed a >> >> deployment of seven Juniper MX series routers in a dual ring >> configuration, >> >> all acting as combination P/PE devices for a state government WAN >> backbone. >> >> Works like a charm. >> >> >> >> Erik >> >> >> >> >> >> On Thu, Sep 3, 2009 at 10:20 AM, Serge Vautour > >wrote: >> >> >> >>> Hello, >> >>> >> >>> I'm pretty confident that a router can be used to perform P & PE >> >>> functions simultaneously. What about from a best practice perspective? >> Is >> >>> this something that should be completely avoided? Why? We're >> considering >> >>> doing this as a temporary workaround but we all know temporary usually >> lasts >> >>> a long time. I'd like to know what kind of mess awaits if we let this >> one >> >>> go. >> >>> >> >>> Thanks, >> >>> Serge >> >>> >> >>> >> >>> >> >>> >> __________________________________________________________________ >> >>> Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark >> your >> >>> favourite sites. Download it now >> >>> http://ca.toolbar.yahoo.com. >> >>> >> >>> >> >> >> > >> > > From uri.joskovitch at telrad.com Fri Sep 4 09:29:43 2009 From: uri.joskovitch at telrad.com (Uri Joskovitch) Date: Fri, 4 Sep 2009 17:29:43 +0300 Subject: Single router for P/PE functions In-Reply-To: References: <462083.54398.qm@web53604.mail.re2.yahoo.com><4aa1189b.9e15f10a.5d53.ffffe1eeSMTPIN_ADDED@mx.google.com> Message-ID: <02755D474772E74E97471FC5BBE7641B025E074A@TLRD-MAIL1.Telrad.co.il> Hi All Any one is using PWE solutions? Any good/bad experience with this technology? Thanks Uri From sergevautour at yahoo.ca Fri Sep 4 10:28:04 2009 From: sergevautour at yahoo.ca (Serge Vautour) Date: Fri, 4 Sep 2009 08:28:04 -0700 (PDT) Subject: Single router for P/PE functions In-Reply-To: References: <462083.54398.qm@web53604.mail.re2.yahoo.com> Message-ID: <427721.8391.qm@web53611.mail.re2.yahoo.com> We're trying to save on Transport links. Instead of multi-homing each PE to 2 Ps, we're considering building a ring: P-PE-PE-PE-P. This ring follows the transport ring. Each link would be engineering to make sure it can handle all of the traffic from all 3PEs in case of a failure. As the network grows, we could get individual transport links from PE-P. Apart from bandwidth, I was curious if there were other problems I related to doing this that I wasn't thinking of. Thanks for all the replies. Much appreciated. Serge ________________________________ From: William McCall To: Serge Vautour Cc: nanog at nanog.org Sent: Friday, September 4, 2009 1:07:40 AM Subject: Re: Single router for P/PE functions Kinda depends on what you're doing exactly, but like Erik said, it certainly possible and depending on your particular needs, it might not be much of an issue at all. Can you describe your scenario a bit more? --WM On Thu, Sep 3, 2009 at 10:20 AM, Serge Vautour wrote: >Hello, > >>I'm pretty confident that a router can be used to perform P & PE functions simultaneously. What about from a best practice perspective? Is this something that should be completely avoided? Why? We're considering doing this as a temporary workaround but we all know temporary usually lasts a long time. I'd like to know what kind of mess awaits if we let this one go. > >>Thanks, >Serge > > > > >> __________________________________________________________________ >>Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now >http://ca.toolbar.yahoo.com. > > -- William McCall, CCIE #25044 __________________________________________________________________ Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com From r.hyunseog at ieee.org Fri Sep 4 10:44:19 2009 From: r.hyunseog at ieee.org (Alex H. Ryu) Date: Fri, 04 Sep 2009 10:44:19 -0500 Subject: Single router for P/PE functions In-Reply-To: <427721.8391.qm@web53611.mail.re2.yahoo.com> References: <462083.54398.qm@web53604.mail.re2.yahoo.com> <427721.8391.qm@web53611.mail.re2.yahoo.com> Message-ID: <4AA135D3.4010308@ieee.org> What if there is a problem from software, filter, mis-configuration from one of the routers ? It will affect whole ring network, not just that problem router. Also if there is routing protocol bounce because of link flapping, it will be propagate through the ring forever. Alex Serge Vautour wrote: > We're trying to save on Transport links. Instead of multi-homing each PE to 2 Ps, we're considering building a ring: P-PE-PE-PE-P. This ring follows the transport ring. Each link would be engineering to make sure it can handle all of the traffic from all 3PEs in case of a failure. As the network grows, we could get individual transport links from PE-P. > > Apart from bandwidth, I was curious if there were other problems I related to doing this that I wasn't thinking of. Thanks for all the replies. Much appreciated. > > Serge > > > > > ________________________________ > From: William McCall > To: Serge Vautour > Cc: nanog at nanog.org > Sent: Friday, September 4, 2009 1:07:40 AM > Subject: Re: Single router for P/PE functions > > Kinda depends on what you're doing exactly, but like Erik said, it certainly possible and depending on your particular needs, it might not be much of an issue at all. > > Can you describe your scenario a bit more? > > --WM > > > On Thu, Sep 3, 2009 at 10:20 AM, Serge Vautour wrote: > > >> Hello, >> >> >>> I'm pretty confident that a router can be used to perform P & PE functions simultaneously. What about from a best practice perspective? Is this something that should be completely avoided? Why? We're considering doing this as a temporary workaround but we all know temporary usually lasts a long time. I'd like to know what kind of mess awaits if we let this one go. >>> >>> Thanks, >>> >> Serge >> >> >> >> >> >>> __________________________________________________________________ >>> Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now >>> >> http://ca.toolbar.yahoo.com. >> >> >> > > > From jolsen at devry.com Fri Sep 4 11:07:04 2009 From: jolsen at devry.com (Olsen, Jason) Date: Fri, 4 Sep 2009 11:07:04 -0500 Subject: Route table prefix monitoring Message-ID: <19A6566FA5D52A44B7F7027F7E88BEE7DF65FD@OBT-W-EVS3P.dvuadmin.net> Howdy all, I've done a bit of digging through the Google machine and the MarkMail archive of NANOG (Which is a great resource I cannot plug enough - http://nanog.markmail.org) and have a few vague answers, but would like some deeper thought so I'm putting this out to the list. We recently had an event where, unbeknownst to us, a circuit went down and a /16 prefix inside our core routing table was withdrawn as a consequence of adjacency disappearing with that downed circuit (the fact that it went down without us knowing is being worked already). This caused a severe breakage for a legacy system that hasn't been touched in years, and tribal knowledge couldn't explain why we were seeing that legacy system going to a subnet that nobody knew anything about (again, documentation is something that's being worked already as a consequence of this). What I'm left thinking is that it would have been great if we'd had a snapshot of our core routing table as it stood hours or even days prior to this event occurring, so that I could compare it with our current "broken" state, so the team could have seen that subnet in the core table and what the next hop was for the prefix. Are there any tools that people are using to track when/what prefixes are added/withdrawn from their routing tables, or to pull the routing table as a whole at regular intervals for storage/comparison purposes? It looks like there's a plugin for NAGIOS, but I'm looking for suggestions on any other tools (commercial, open source, home grown) that we might take a look at. For reference, we are running Cisco as well as Juniper kit. Feel free to drop me your thoughts off-list. Thank you for any insight ahead of time, -Jason "Feren" Olsen From cscora at apnic.net Fri Sep 4 13:12:07 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 5 Sep 2009 04:12:07 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200909041812.n84IC73s010513@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 05 Sep, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 294331 Prefixes after maximum aggregation: 139398 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 147041 Total ASes present in the Internet Routing Table: 32126 Prefixes per ASN: 9.16 Origin-only ASes present in the Internet Routing Table: 27940 Origin ASes announcing only one prefix: 13641 Transit ASes present in the Internet Routing Table: 4186 Transit-only ASes present in the Internet Routing Table: 104 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 407 Unregistered ASNs in the Routing Table: 114 Number of 32-bit ASNs allocated by the RIRs: 260 Prefixes from 32-bit ASNs in the Routing Table: 105 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 319 Number of addresses announced to Internet: 2101706432 Equivalent to 125 /8s, 69 /16s and 126 /24s Percentage of available address space announced: 56.7 Percentage of allocated address space announced: 64.9 Percentage of available address space allocated: 87.3 Percentage of address space in use by end-sites: 78.8 Total number of prefixes smaller than registry allocations: 140659 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 70157 Total APNIC prefixes after maximum aggregation: 24968 APNIC Deaggregation factor: 2.81 Prefixes being announced from the APNIC address blocks: 69597 Unique aggregates announced from the APNIC address blocks: 31670 APNIC Region origin ASes present in the Internet Routing Table: 3774 APNIC Prefixes per ASN: 18.44 APNIC Region origin ASes announcing only one prefix: 1035 APNIC Region transit ASes present in the Internet Routing Table: 580 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 493030848 Equivalent to 29 /8s, 99 /16s and 13 /24s Percentage of available APNIC address space announced: 84.0 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 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: 124764 Total ARIN prefixes after maximum aggregation: 66482 ARIN Deaggregation factor: 1.88 Prefixes being announced from the ARIN address blocks: 125341 Unique aggregates announced from the ARIN address blocks: 52721 ARIN Region origin ASes present in the Internet Routing Table: 13211 ARIN Prefixes per ASN: 9.49 ARIN Region origin ASes announcing only one prefix: 5107 ARIN Region transit ASes present in the Internet Routing Table: 1297 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 1013346368 Equivalent to 60 /8s, 102 /16s and 112 /24s Percentage of available ARIN address space announced: 88.8 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 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: 67698 Total RIPE prefixes after maximum aggregation: 39917 RIPE Deaggregation factor: 1.70 Prefixes being announced from the RIPE address blocks: 67311 Unique aggregates announced from the RIPE address blocks: 45605 RIPE Region origin ASes present in the Internet Routing Table: 13456 RIPE Prefixes per ASN: 5.00 RIPE Region origin ASes announcing only one prefix: 7031 RIPE Region transit ASes present in the Internet Routing Table: 2002 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 499964864 Equivalent to 29 /8s, 204 /16s and 219 /24s Percentage of available RIPE address space announced: 99.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 RIPE Address Blocks 25/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: 25342 Total LACNIC prefixes after maximum aggregation: 6213 LACNIC Deaggregation factor: 4.08 Prefixes being announced from the LACNIC address blocks: 25334 Unique aggregates announced from the LACNIC address blocks: 14125 LACNIC Region origin ASes present in the Internet Routing Table: 1174 LACNIC Prefixes per ASN: 21.58 LACNIC Region origin ASes announcing only one prefix: 380 LACNIC Region transit ASes present in the Internet Routing Table: 192 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 22 Number of LACNIC addresses announced to Internet: 73761280 Equivalent to 4 /8s, 101 /16s and 130 /24s Percentage of available LACNIC address space announced: 73.3 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247 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: 6028 Total AfriNIC prefixes after maximum aggregation: 1570 AfriNIC Deaggregation factor: 3.84 Prefixes being announced from the AfriNIC address blocks: 6429 Unique aggregates announced from the AfriNIC address blocks: 2659 AfriNIC Region origin ASes present in the Internet Routing Table: 313 AfriNIC Prefixes per ASN: 20.54 AfriNIC Region origin ASes announcing only one prefix: 88 AfriNIC Region transit ASes present in the Internet Routing Table: 67 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 20185600 Equivalent to 1 /8s, 52 /16s and 2 /24s Percentage of available AfriNIC address space announced: 60.2 AfriNIC AS Blocks 36864-37887 & 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 1723 6982 427 Korea Telecom (KIX) 17488 1553 140 103 Hathway IP Over Cable Interne 4755 1231 292 141 TATA Communications formerly 9583 1095 87 534 Sify Limited 4134 1001 18165 390 CHINANET-BACKBONE 18101 952 201 31 Reliance Infocom Ltd Internet 7545 822 198 102 TPG Internet Pty Ltd 9829 798 625 18 BSNL National Internet Backbo 23577 770 33 654 Korea Telecom (ATM-MPLS) 4808 767 1531 182 CNCGROUP IP network: China169 Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4178 3610 312 bellsouth.net, inc. 4323 1924 1049 387 Time Warner Telecom 1785 1736 714 137 PaeTec Communications, Inc. 7018 1495 5908 1059 AT&T WorldNet Services 20115 1472 1475 683 Charter Communications 6478 1396 281 260 AT&T Worldnet Services 2386 1289 655 936 AT&T Data Communications Serv 3356 1218 10980 440 Level 3 Communications, LLC 22773 1095 2604 66 Cox Communications, Inc. 11492 1092 208 12 Cable One 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 487 92 197 Evolva Telecom 12479 477 578 6 Uni2 Autonomous System 3292 458 1904 395 TDC Tele Danmark 702 426 1821 344 UUNET - Commercial IP service 35805 385 40 5 United Telecom of Georgia 9198 368 138 12 Kazakhtelecom Data Network Ad 8866 358 109 22 Bulgarian Telecommunication C 3320 353 7067 303 Deutsche Telekom AG 3301 347 1412 308 TeliaNet Sweden 3215 344 3081 109 France Telecom Transpac 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 1477 2898 242 UniNet S.A. de C.V. 10620 1009 226 99 TVCABLE BOGOTA 28573 697 607 61 NET Servicos de Comunicao S.A 7303 635 336 93 Telecom Argentina Stet-France 22047 542 302 14 VTR PUNTO NET S.A. 11830 476 310 58 Instituto Costarricense de El 11172 441 99 70 Servicios Alestra S.A de C.V 14117 435 29 11 Telefonica del Sur S.A. 6471 421 96 31 ENTEL CHILE S.A. 7738 419 858 29 Telecomunicacoes da Bahia S.A Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 989 188 7 TEDATA 24863 884 94 60 LINKdotNET AS number 20858 296 34 6 EgyNet 3741 274 856 235 The Internet Solution 2018 202 180 142 Tertiary Education Network 6713 175 166 16 Itissalat Al-MAGHRIB 29571 139 14 6 Ci Telecom Autonomous system 5536 122 8 13 Internet Egypt Network 5713 116 508 67 Telkom SA Ltd 33776 115 7 11 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4178 3610 312 bellsouth.net, inc. 4323 1924 1049 387 Time Warner Telecom 1785 1736 714 137 PaeTec Communications, Inc. 4766 1723 6982 427 Korea Telecom (KIX) 17488 1553 140 103 Hathway IP Over Cable Interne 7018 1495 5908 1059 AT&T WorldNet Services 8151 1477 2898 242 UniNet S.A. de C.V. 20115 1472 1475 683 Charter Communications 6478 1396 281 260 AT&T Worldnet Services 2386 1289 655 936 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 1785 1736 1599 PaeTec Communications, Inc. 4323 1924 1537 Time Warner Telecom 17488 1553 1450 Hathway IP Over Cable Interne 4766 1723 1296 Korea Telecom (KIX) 8151 1477 1235 UniNet S.A. de C.V. 6478 1396 1136 AT&T Worldnet Services 4755 1231 1090 TATA Communications formerly 11492 1092 1080 Cable One 18566 1062 1052 Covad Communications 22773 1095 1029 Cox Communications, Inc. 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 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.176.0/22 36981 >>UNKNOWN<< 41.223.189.0/24 26452 Local Communications Networks 43.245.0.0/16 7502 Internetwork Kyoto 43.245.96.0/20 7502 Internetwork Kyoto 43.245.112.0/20 7502 Internetwork Kyoto 43.245.192.0/20 7502 Internetwork Kyoto 43.245.208.0/20 7502 Internetwork Kyoto 43.245.224.0/20 7502 Internetwork Kyoto 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:62 /12:168 /13:351 /14:624 /15:1181 /16:10644 /17:4824 /18:8362 /19:17349 /20:20714 /21:20551 /22:26629 /23:26406 /24:153628 /25:946 /26:1077 /27:583 /28:153 /29:8 /30:9 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2708 4178 bellsouth.net, inc. 4766 1408 1723 Korea Telecom (KIX) 17488 1299 1553 Hathway IP Over Cable Interne 1785 1206 1736 PaeTec Communications, Inc. 18566 1043 1062 Covad Communications 11492 1021 1092 Cable One 4323 968 1924 Time Warner Telecom 9583 947 1095 Sify Limited 10620 915 1009 TVCABLE BOGOTA 8452 913 989 TEDATA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:14 8:213 12:2137 13:7 15:21 16:3 17:5 20:35 24:1117 32:52 34:2 38:598 40:97 41:1730 43:1 44:2 47:20 52:6 55:2 56:2 57:25 58:595 59:607 60:461 61:958 62:1074 63:2013 64:3631 65:2392 66:3438 67:1773 68:946 69:2733 70:557 71:163 72:1682 73:2 74:1732 75:179 76:322 77:861 78:577 79:375 80:913 81:819 82:528 83:426 84:638 85:1042 86:378 87:674 88:369 89:1472 90:52 91:2520 92:397 93:1134 94:1155 95:912 96:166 97:268 98:271 99:30 109:1 110:184 111:398 112:128 113:151 114:243 115:306 116:1135 117:565 118:322 119:774 120:122 121:652 122:1247 123:761 124:1067 125:1356 128:223 129:219 130:129 131:420 132:75 133:9 134:174 135:42 136:225 137:161 138:171 139:84 140:442 141:125 142:385 143:332 144:385 145:49 146:390 147:157 148:530 149:213 150:205 151:186 152:210 153:153 154:2 155:279 156:167 157:305 158:112 159:349 160:291 161:164 162:270 163:159 164:276 165:526 166:474 167:365 168:708 169:167 170:481 171:42 172:2 173:407 174:332 175:1 178:1 180:17 182:1 186:141 187:150 188:761 189:580 190:3026 192:5766 193:4251 194:3284 195:2742 196:1126 198:3543 199:3356 200:5178 201:1306 202:7783 203:8285 204:3890 205:2195 206:2391 207:2739 208:3948 209:3406 210:2543 211:1107 212:1602 213:1649 214:174 215:32 216:4292 217:1334 218:411 219:414 220:1110 221:462 222:323 End of report From nanog at rsle.net Fri Sep 4 14:20:53 2009 From: nanog at rsle.net (R. Scott Evans) Date: Fri, 4 Sep 2009 15:20:53 -0400 Subject: as702 looking glass? In-Reply-To: <20090904133726.D35511@mp2.macomnet.net> References: <20090904133726.D35511@mp2.macomnet.net> Message-ID: <20090904191850.M59154@rsle.net> On Fri, 4 Sep 2009 13:38:56 +0400 (MSD), Serg Shubenkov wrote > Folks, > > Does anyone know if Verizon (AS702) has a publicly accessable looking > glass? > > -- > Serg Shubenkov it's been 2 years since I last inquired, but the answer then was: "Date: Fri, 17 Aug 2007 17:37:09 +0000 (GMT) From: help4u at verizonbusiness.com Subject: (2007081704481) BGP routes Hi there, I am afraid we do not have a public looking glass..." From danny at tcb.net Fri Sep 4 14:46:20 2009 From: danny at tcb.net (Danny McPherson) Date: Fri, 4 Sep 2009 13:46:20 -0600 Subject: OT: 2009 Infrastructure Security Survey Message-ID: Folks, We're in the process of collecting feedback for this years infrastructure security report, the fifth edition of the report. The 2008 Infrastructure Security Survey is up and available for input. You can register to complete the survey at this URL: I've again added many questions this time from past participants of the survey, this should be evidenced throughout. Feedback collection will end as soon as we've reached the desired number of respondents (ideally, 70+). We hope to make the results available by November 2009 at the latest. Also, please recall that NO personally (or organizationally) identifiable information will be shared in any manner. The 2008 edition of the survey is available here: Or on the Arbor web site (reg required): Thanks in advance for your participation! -danny From matthew at walster.org Fri Sep 4 15:48:39 2009 From: matthew at walster.org (Matthew Walster) Date: Fri, 4 Sep 2009 21:48:39 +0100 Subject: Route table prefix monitoring In-Reply-To: <19A6566FA5D52A44B7F7027F7E88BEE7DF65FD@OBT-W-EVS3P.dvuadmin.net> References: <19A6566FA5D52A44B7F7027F7E88BEE7DF65FD@OBT-W-EVS3P.dvuadmin.net> Message-ID: 2009/9/4 Olsen, Jason : >?Are there any tools > that people are using to track when/what prefixes are added/withdrawn > from their routing tables, Could you use something like BGPMon? http://bgpmon.com/ Matthew Walster From fergdawgster at gmail.com Fri Sep 4 15:59:01 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Fri, 4 Sep 2009 13:59:01 -0700 Subject: Route table prefix monitoring In-Reply-To: References: <19A6566FA5D52A44B7F7027F7E88BEE7DF65FD@OBT-W-EVS3P.dvuadmin.net> Message-ID: <6cd462c00909041359l740a279fsbdcfbbadcadd6fa@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Sep 4, 2009 at 1:48 PM, Matthew Walster wrote: > 2009/9/4 Olsen, Jason : >> Are there any tools >> that people are using to track when/what prefixes are added/withdrawn >> from their routing tables, > > Could you use something like BGPMon? > > http://bgpmon.com/ > There's also: MyASN: http://www.ripe.net/info/faq/projects/myasn.html PHAS: http://phas.netsec.colostate.edu/stat.html - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFKoX+Oq1pz9mNUZTMRAto+AJ9hn3ZlScq2Tv3TLUCAJCCzPWqmEwCcDImX lsmccRqdMpbWeoT6wkukuO8= =Mtdy -----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 morrowc.lists at gmail.com Fri Sep 4 16:06:38 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 4 Sep 2009 17:06:38 -0400 Subject: Route table prefix monitoring In-Reply-To: <6cd462c00909041359l740a279fsbdcfbbadcadd6fa@mail.gmail.com> References: <19A6566FA5D52A44B7F7027F7E88BEE7DF65FD@OBT-W-EVS3P.dvuadmin.net> <6cd462c00909041359l740a279fsbdcfbbadcadd6fa@mail.gmail.com> Message-ID: <75cb24520909041406n6b3eda01pb2c9ed955d3adba@mail.gmail.com> On Fri, Sep 4, 2009 at 4:59 PM, Paul Ferguson wrote: > On Fri, Sep 4, 2009 at 1:48 PM, Matthew Walster wrote: > >> 2009/9/4 Olsen, Jason : >>> Are there any tools >>> that people are using to track when/what prefixes are added/withdrawn >>> from their routing tables, >> >> Could you use something like BGPMon? >> >> http://bgpmon.com/ >> > > There's also: > > MyASN: > http://www.ripe.net/info/faq/projects/myasn.html > > PHAS: > http://phas.netsec.colostate.edu/stat.html I think the OP wanted something for 'internal route monitoring' ... since he's from DeVry I suspect it's to monitor things on DeVry's internal WAN which probably don't show in the global table. That said, you COULD have rancid (or abuse rancid) pull rib-dumps each 'period' and index those into something that alerted on large diff's (or alerted if some critical bits were missing). Or have a quagga box peer with some number of internal devices, log update messages, alert on withdrawal of critical bits. -chris (I don't know of any COTS tools that do this, sorry) From andree+nanog at toonk.nl Fri Sep 4 16:26:42 2009 From: andree+nanog at toonk.nl (Andree Toonk) Date: Fri, 4 Sep 2009 23:26:42 +0200 Subject: Route table prefix monitoring In-Reply-To: <19A6566FA5D52A44B7F7027F7E88BEE7DF65FD@OBT-W-EVS3P.dvuadmin.net> References: <19A6566FA5D52A44B7F7027F7E88BEE7DF65FD@OBT-W-EVS3P.dvuadmin.net> Message-ID: <20090904212641.GA26059@toonk.nl> Hi Jason, .-- My secret spy satellite informs me that at Fri, 04 Sep 2009, Olsen, Jason wrote: > What I'm left thinking is that it would have been great if we'd had a > snapshot of our core routing table as it stood hours or even days prior > to this event occurring, so that I could compare it with our current > "broken" state, so the team could have seen that subnet in the core > table and what the next hop was for the prefix. Are there any tools > that people are using to track when/what prefixes are added/withdrawn > from their routing tables, or to pull the routing table as a whole at > regular intervals for storage/comparison purposes? As already mentioned BGPmon.net can probably do what you're looking for. It will sent you a notification in cases of interesting path changes, possible hijacks, new adjacencies and new prefixes. It will also notify you when 'many' peers see a withdrawal of your prefix. This last feature might be useful for you. I'm currently also testing a new feature that basically compares yesterday's routing table with todays table. If there are any 'interesting' changes they will be emailed to you. You can think of this as a rancid for routing tables changes. I can include you in testing if you want to. All of this does assume that your prefixes are globally visible though. Cheers, Andree From Stefan.Fouant at neustar.biz Fri Sep 4 16:30:52 2009 From: Stefan.Fouant at neustar.biz (Fouant, Stefan) Date: Fri, 4 Sep 2009 17:30:52 -0400 Subject: Route table prefix monitoring In-Reply-To: <75cb24520909041406n6b3eda01pb2c9ed955d3adba@mail.gmail.com> References: <19A6566FA5D52A44B7F7027F7E88BEE7DF65FD@OBT-W-EVS3P.dvuadmin.net><6cd462c00909041359l740a279fsbdcfbbadcadd6fa@mail.gmail.com> <75cb24520909041406n6b3eda01pb2c9ed955d3adba@mail.gmail.com> Message-ID: <01B071CE08A7514CB72950074134151A013E9ED8@STNTEXCH12.cis.neustar.com> > -----Original Message----- > From: Christopher Morrow [mailto:morrowc.lists at gmail.com] > Sent: Friday, September 04, 2009 5:07 PM > To: Paul Ferguson > Cc: nanog at nanog.org > Subject: Re: Route table prefix monitoring > > On Fri, Sep 4, 2009 at 4:59 PM, Paul Ferguson > wrote: > > > On Fri, Sep 4, 2009 at 1:48 PM, Matthew Walster > wrote: > > > >> 2009/9/4 Olsen, Jason : > >>> Are there any tools > >>> that people are using to track when/what prefixes are > added/withdrawn > >>> from their routing tables, > >> > >> Could you use something like BGPMon? > >> > >> http://bgpmon.com/ > >> > > > > There's also: > > > > MyASN: > > http://www.ripe.net/info/faq/projects/myasn.html > > > > PHAS: > > http://phas.netsec.colostate.edu/stat.html > > I think the OP wanted something for 'internal route monitoring' ... > since he's from DeVry I suspect it's to monitor things on DeVry's > internal WAN which probably don't show in the global table. > > That said, you COULD have rancid (or abuse rancid) pull rib-dumps each > 'period' and index those into something that alerted on large diff's > (or alerted if some critical bits were missing). Or have a quagga box > peer with some number of internal devices, log update messages, alert > on withdrawal of critical bits. > > -chris > (I don't know of any COTS tools that do this, sorry) Tools such as Arbor Peakflow SP have a lot of cool traffic and routing analysis bits for internal monitoring of this sort, but it might be a bit out of your price range. Having said that, I second Chris's approach above utilizing some quagga box/low-end router (make sure you have enough memory!) and simply reflect routes from your production routers in conjunction with update message logging. If you're looking for tools that perform analysis from an exterior point-of-view, there is also BGPlay which has some cool widgetry to see particular prefixes within a user-specific time interval. Again it's using the operators route-servers so might not be of much value to you http://bgplay.routeviews.org/bgplay/ Stefan Fouant Neustar, Inc. / Principal Engineer 46000 Center Oak Plaza Sterling, VA 20166 Office: +1.571.434.5656 ? Mobile: +1.202.210.2075 ? GPG ID: 0xB5E3803D ? stefan.fouant at neustar.biz From cidr-report at potaroo.net Fri Sep 4 17:00:01 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 4 Sep 2009 22:00:01 GMT Subject: BGP Update Report Message-ID: <200909042200.n84M01dN042496@wattle.apnic.net> BGP Update Report Interval: 27-Aug-09 -to- 03-Sep-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9198 103193 5.5% 280.4 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - AS30890 88214 4.7% 181.1 -- EVOLVA Evolva Telecom / iLink Telecom 3 - AS33783 22610 1.2% 147.8 -- EEPAD 4 - AS8452 14795 0.8% 14.7 -- TEDATA TEDATA 5 - AS2708 14017 0.8% 128.6 -- Universidad de Guanajuato 6 - AS35805 10774 0.6% 28.0 -- UTG-AS United Telecom AS 7 - AS24863 10450 0.6% 11.1 -- LINKdotNET-AS 8 - AS9829 10214 0.6% 10.2 -- BSNL-NIB National Internet Backbone 9 - AS23700 9792 0.5% 27.3 -- BM-AS-ID PT. Broadband Multimedia, Tbk 10 - AS5668 9676 0.5% 9.4 -- AS-5668 - CenturyTel Internet Holdings, Inc. 11 - AS20115 9123 0.5% 6.2 -- CHARTER-NET-HKY-NC - Charter Communications 12 - AS3464 8771 0.5% 23.1 -- ASC-NET - Alabama Supercomputer Network 13 - AS25019 8719 0.5% 134.1 -- SAUDINETSTC-AS Autonomus System Number for SaudiNet 14 - AS8151 8514 0.5% 5.7 -- Uninet S.A. de C.V. 15 - AS4618 8080 0.4% 136.9 -- INET-TH-AS Internet Thailand Company Limited 16 - AS4323 7833 0.4% 3.8 -- TWTC - tw telecom holdings, inc. 17 - AS12479 7679 0.4% 16.1 -- UNI2-AS Uni2 Autonomous System 18 - AS4249 7546 0.4% 41.5 -- LILLY-AS - Eli Lilly and Company 19 - AS11769 7518 0.4% 375.9 -- MOBILENETICS-LA-GW1 - Mobilenetics Corporation 20 - AS5800 7170 0.4% 52.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS17136 1765 0.1% 1765.0 -- SPANGROUP-UTI - Span Manufacturing Ltd. 2 - AS44194 641 0.0% 641.0 -- FREIFUNK-BERLIN-AS Freifunk Berlin 3 - AS42969 590 0.0% 590.0 -- G4SCASH G4S Cash Services (CZ), a.s. 4 - AS26414 495 0.0% 495.0 -- LVCINT - LVC International, LLC 5 - AS49517 889 0.1% 444.5 -- TEIKHOS-AS Teikhos 6 - AS47640 1282 0.1% 427.3 -- TRICOMPAS Tricomp Sp. z. o. o. 7 - AS8668 2718 0.1% 388.3 -- TELONE-AS TelOne Zimbabwe P/L 8 - AS5050 6118 0.3% 382.4 -- PSC-EXT - Pittsburgh Supercomputing Center 9 - AS30341 1141 0.1% 380.3 -- SCTA-ASN - South Central Telephone Association 10 - AS19398 754 0.0% 377.0 -- INDENET - Indenet.net 11 - AS11769 7518 0.4% 375.9 -- MOBILENETICS-LA-GW1 - Mobilenetics Corporation 12 - AS30969 5308 0.3% 353.9 -- TAN-NET TransAfrica Networks 13 - AS29544 690 0.0% 345.0 -- MAURITEL-AS 14 - AS17301 315 0.0% 315.0 -- FASTENAL - Fastenal Company 15 - AS42182 306 0.0% 306.0 -- KFMC-ASN AS Number for King Fahd Medical City 16 - AS40060 2533 0.1% 281.4 -- AAAWI - AAA Wireless, Inc. 17 - AS9198 103193 5.5% 280.4 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 18 - AS47361 277 0.0% 277.0 -- SYSDESIGN-NET-AS System Design LLC 19 - AS35048 3181 0.2% 265.1 -- NETZONE-AS SC Power Netzone SRL 20 - AS43240 1050 0.1% 262.5 -- GLINNET GLINNET's AS Number TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 89.218.218.0/23 11017 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - 89.218.220.0/23 11016 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 3 - 92.46.244.0/23 11014 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 4 - 95.59.2.0/23 11002 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 5 - 95.59.8.0/23 11000 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 6 - 95.59.4.0/22 11000 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 7 - 95.59.3.0/24 10997 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 8 - 88.204.221.0/24 10723 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - 95.59.1.0/24 10687 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 10 - 72.23.246.0/24 6032 0.3% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 11 - 207.157.105.64/2 5239 0.3% AS3464 -- ASC-NET - Alabama Supercomputer Network 12 - 84.1.45.0/24 5187 0.3% AS41313 -- NOVATEL-AS Novatel Bulgaria 13 - 203.129.254.0/24 3948 0.2% AS7633 -- SOFTNET-AS-AP Software Technology Parks of India - Bangalore 14 - 85.60.208.0/21 2614 0.1% AS12479 -- UNI2-AS Uni2 Autonomous System 15 - 192.12.120.0/24 2550 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 16 - 72.42.193.0/24 2478 0.1% AS40060 -- AAAWI - AAA Wireless, Inc. 17 - 85.60.208.0/22 2456 0.1% AS12479 -- UNI2-AS Uni2 Autonomous System 18 - 196.27.104.0/21 2116 0.1% AS30969 -- TAN-NET TransAfrica Networks 19 - 196.27.108.0/22 2081 0.1% AS30969 -- TAN-NET TransAfrica Networks 20 - 200.21.217.0/24 2061 0.1% AS27817 -- Red Nacional Acad?mica de Tecnolog?a Avanzada - RENATA 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 Sep 4 17:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 4 Sep 2009 22:00:00 GMT Subject: The Cidr Report Message-ID: <200909042200.n84M00Md042477@wattle.apnic.net> This report has been generated at Fri Sep 4 21:11:40 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 28-08-09 301511 186429 29-08-09 301248 186322 30-08-09 301138 186464 31-08-09 301665 186538 01-09-09 301637 186574 02-09-09 301706 184566 03-09-09 301747 184730 04-09-09 301651 184941 AS Summary 32261 Number of ASes in routing system 13742 Number of ASes announcing only one prefix 4311 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 89478400 Largest address span announced by an AS (/32s) AS27064: DNIC-ASBLK-27032-27159 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 04Sep09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 301649 184909 116740 38.7% All ASes AS6389 4178 327 3851 92.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4311 1761 2550 59.2% TWTC - tw telecom holdings, inc. AS4766 1836 544 1292 70.4% KIXS-AS-KR Korea Telecom AS17488 1553 291 1262 81.3% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1232 144 1088 88.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS18566 1062 10 1052 99.1% COVAD - Covad Communications Co. AS22773 1095 70 1025 93.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1477 563 914 61.9% Uninet S.A. de C.V. AS10620 1009 134 875 86.7% TV Cable S.A. AS18101 952 85 867 91.1% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS19262 1043 236 807 77.4% VZGNI-TRANSIT - Verizon Internet Services Inc. AS6478 1396 644 752 53.9% ATT-INTERNET3 - AT&T WorldNet Services AS8452 989 287 702 71.0% TEDATA TEDATA AS3356 1220 592 628 51.5% LEVEL3 Level 3 Communications AS1785 1736 1115 621 35.8% AS-PAETEC-NET - PaeTec Communications, Inc. AS4804 686 68 618 90.1% MPX-AS Microplex PTY LTD AS4808 767 213 554 72.2% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS11492 1120 566 554 49.5% CABLEONE - CABLE ONE, INC. AS7303 635 94 541 85.2% Telecom Argentina S.A. AS9498 634 103 531 83.8% BBIL-AP BHARTI Airtel Ltd. AS22047 542 16 526 97.0% VTR BANDA ANCHA S.A. AS4134 1001 534 467 46.7% CHINANET-BACKBONE No.31,Jin-rong Street AS17676 564 127 437 77.5% GIGAINFRA Softbank BB Corp. AS7018 1497 1061 436 29.1% ATT-INTERNET4 - AT&T WorldNet Services AS7011 1015 590 425 41.9% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4780 566 146 420 74.2% SEEDNET Digital United Inc. AS5668 787 367 420 53.4% AS-5668 - CenturyTel Internet Holdings, Inc. AS7545 841 429 412 49.0% TPG-INTERNET-AP TPG Internet Pty Ltd AS4668 695 285 410 59.0% LGNET-AS-KR LG CNS AS7738 419 29 390 93.1% Telecomunicacoes da Bahia S.A. Total 36858 11431 25427 69.0% Top 30 total Possible Bogus Routes 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.176.0/22 AS36981 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 43.245.0.0/16 AS7502 IP-KYOTO Internetwork Kyoto 43.245.96.0/20 AS7502 IP-KYOTO Internetwork Kyoto 43.245.112.0/20 AS7502 IP-KYOTO Internetwork Kyoto 43.245.192.0/20 AS7502 IP-KYOTO Internetwork Kyoto 43.245.208.0/20 AS7502 IP-KYOTO Internetwork Kyoto 43.245.224.0/20 AS7502 IP-KYOTO Internetwork Kyoto 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 64.72.112.0/20 AS19166 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.83.80.0/20 AS26877 64.83.80.0/24 AS26877 64.83.81.0/24 AS26877 64.83.82.0/24 AS26877 64.83.83.0/24 AS26877 64.83.85.0/24 AS26877 64.83.86.0/24 AS26877 64.247.160.0/20 AS10937 IIS - Island Internet Services 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 74.117.132.0/22 AS23376 SPROCKETDATA - Sprocket Data, Inc. 74.120.160.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.161.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.162.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.163.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.164.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.165.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.166.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.167.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.168.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.169.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.170.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.171.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.172.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.173.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.174.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.175.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.8.64.0/18 AS19166 96.8.127.0/24 AS19166 100.100.100.0/30 AS38676 AS33005-AS-KR wizsolution co.,Ltd 116.50.0.0/24 AS17754 EXCELL-AS Excellmedia 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 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 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.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.132.58.0/24 AS20141 QUALITYTECH-SUW-300 - Quality Technology Services, LLC. 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.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 / iLink Telecom 195.225.58.0/24 AS6714 ATOMNET ATOM SA 196.1.130.0/24 AS3741 IS 196.1.131.0/24 AS3741 IS 196.1.132.0/24 AS3741 IS 196.1.133.0/24 AS3741 IS 196.6.108.0/24 AS5713 SAIX-NET 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.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.5.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet 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.114.0.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 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.134.0/24 AS3541 ITSDN-U4 - 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.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.84.10.0/23 AS9308 CHINA-ABITCOOL Abitcool(China) Inc. 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS2764 AAPT AAPT Limited 202.124.195.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 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.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 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.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 M-LINK M-Link Teleport s.a. 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.29.26.0/24 AS45289 INDOTRANS-AS-ID Indotrans Data, PT 203.29.27.0/24 AS45289 INDOTRANS-AS-ID Indotrans Data, PT 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.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/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.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.138.167.0/24 AS18990 AIRBAND-DALLAS - Airband Communications, 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.166.112.0/20 AS10937 IIS - Island Internet Services 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.151.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.177.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.178.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 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.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.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.217.224.0/19 AS6130 AIS-WEST - American Internet Services, LLC. 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 213.108.208.0/21 AS42765 INFOTEH-LINER-AS INFOTEH LTD (LINER) 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 217.78.71.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.72.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.73.0/24 AS12491 IPPLANET-AS Gilat Satcom 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 Sep 4 23:14:35 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 5 Sep 2009 00:14:35 -0400 Subject: Reach.com folks need email assistance? Message-ID: <75cb24520909042114h4286deb7qa2c87a0eb7ef8464@mail.gmail.com> Perhaps someone from REACH NOC can send me a private email? It seems your IRR POC email is non-functional. -Chris ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... Deferred: postoffice.net.reach.com.: No route to host Message could not be delivered for 3 days Message will be deleted from queue Final-Recipient: RFC822; irr at net.reach.com Action: failed Status: 4.4.7 Remote-MTA: DNS; postoffice.net.reach.com Last-Attempt-Date: Sat, 5 Sep 2009 05:05:22 +0100 From morrowc.lists at gmail.com Fri Sep 4 23:59:28 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 5 Sep 2009 00:59:28 -0400 Subject: Reach.com folks need email assistance? In-Reply-To: <75cb24520909042114h4286deb7qa2c87a0eb7ef8464@mail.gmail.com> References: <75cb24520909042114h4286deb7qa2c87a0eb7ef8464@mail.gmail.com> Message-ID: <75cb24520909042159gcd9e041n36b2dc2cd2451e7e@mail.gmail.com> hey! sam from the reach noc reached out to me :) Thanks! -chris On Sat, Sep 5, 2009 at 12:14 AM, Christopher Morrow wrote: > Perhaps someone from REACH NOC can send me a private email? It seems > your IRR POC email is non-functional. > > -Chris > > ?----- The following addresses had permanent fatal errors ----- > > > ?----- Transcript of session follows ----- > ... Deferred: postoffice.net.reach.com.: No route to host > Message could not be delivered for 3 days > Message will be deleted from queue > > Final-Recipient: RFC822; irr at net.reach.com > Action: failed > Status: 4.4.7 > Remote-MTA: DNS; postoffice.net.reach.com > Last-Attempt-Date: Sat, 5 Sep 2009 05:05:22 +0100 > From lcaron at unix-scripts.info Sat Sep 5 09:04:33 2009 From: lcaron at unix-scripts.info (Laurent CARON) Date: Sat, 05 Sep 2009 16:04:33 +0200 Subject: Is 213.215.28.0/23 (AS 49463) announced through AS 12670 and AS 13193 Message-ID: <4AA26FF1.2050505@unix-scripts.info> Hi, I did set-up this netblock behind two pipes. One on AS13193 (which is working flawlessy), and ahother on AS12670 (which I doubt of). Can please any of you tell me if from your location 213.215.28.0 is reachable through AS12670 ? Thanks Laurent From nicolas-ml at deffayet.com Sat Sep 5 09:30:59 2009 From: nicolas-ml at deffayet.com (Nicolas DEFFAYET) Date: Sat, 05 Sep 2009 16:30:59 +0200 Subject: Is 213.215.28.0/23 (AS 49463) announced through AS 12670 and AS 13193 In-Reply-To: <4AA26FF1.2050505@unix-scripts.info> References: <4AA26FF1.2050505@unix-scripts.info> Message-ID: <1252161059.8489.6.camel@fr-wks3.corp.novso.com> On Sat, 2009-09-05 at 16:04 +0200, Laurent CARON wrote: Hi Laurent, > I did set-up this netblock behind two pipes. > > One on AS13193 (which is working flawlessy), and ahother on AS12670 > (which I doubt of). > > Can please any of you tell me if from your location 213.215.28.0 is > reachable through AS12670 ? We, Novso AS25358, see only your route through Nerim AS13193. frpar-msr4>sh ip bgp 213.215.28.0 BGP routing table entry for 213.215.28.0/23, version 16779890 Paths: (3 available, best #3, table Default-IP-Routing-Table) Not advertised to any peer 13193 49463 194.68.129.181 from 194.68.129.181 (194.79.131.249) Origin IGP, metric 240, localpref 200, valid, external Community: 25358:2000 25358:2020 25358:7000 25358:8000 25358:9000 13193 49463, (received-only) 194.68.129.181 from 194.68.129.181 (194.79.131.249) Origin IGP, metric 100, localpref 100, valid, external 13193 49463, (received & used) 195.140.149.5 (metric 200) from 195.140.149.5 (195.140.149.5) Origin IGP, metric 200, localpref 200, valid, internal, best Community: 25358:2000 25358:2050 25358:7000 25358:8000 25358:9000 Our peering session with Completel AS12670: frpar-msr4>sh ip bgp sum | i 12670 194.68.129.188 4 12670 104682 103276 19335046 0 0 1d08h 195 frpar-msr4>sh ip bgp nei 194.68.129.188 received-routes | i 213.215.28.0 frpar-msr4> Our peering session with Nerim AS13193: frpar-msr4>sh ip bgp sum | i 13193 194.68.129.181 4 13193 103945 103222 19335046 0 0 1d08h 33 frpar-msr4>sh ip bgp nei 194.68.129.181 received-routes | i 213.215.28.0 * 213.215.28.0/23 194.68.129.181 100 0 13193 49463 i frpar-msr4> Completel AS12670 don't announce your route 213.215.28.0/23 to their peers so your route is only visible through Nerim AS13193. Did you announce your route 213.215.28.0/23 to Completel AS12670 ? Best Regards, -- Nicolas DEFFAYET (AS25358) From mike at sentex.net Sat Sep 5 11:04:19 2009 From: mike at sentex.net (Mike Tancsa) Date: Sat, 05 Sep 2009 12:04:19 -0400 Subject: Any RIM / blackberry folks around ? Message-ID: <200909051600.n85G0exS047513@lava.sentex.ca> Trying to open a ticket with Rogers but they say nothing is wrong. Seems to be some DNS issue at RIM? Their MX handlers are rejecting mail saying the sending domain does not exist... 0[marble]# host -tmx rogers.blackberry.net rogers.blackberry.net mail is handled by 10 mx01.bis.na.blackberry.com. rogers.blackberry.net mail is handled by 10 mx02.bis.na.blackberry.com. rogers.blackberry.net mail is handled by 10 mx03.bis.na.blackberry.com. rogers.blackberry.net mail is handled by 10 mx04.bis.na.blackberry.com. 0[marble]# telnet mx01.bis.na.blackberry.com 25 Trying 216.9.248.32... Connected to mx01.bis.na.blackberry.com. Escape character is '^]'. 220 as64.bis.na.blackberry.com ESMTP HELO marble.sentex.ca 250 as64.bis.na.blackberry.com MAIL From: 451 #4.1.8 Domain of sender address does not resolve MAIL From: 451 #4.1.8 Domain of sender address does not resolve 421 Exceeded allowable connection time, disconnecting. Connection closed by foreign host. 1[marble]# 0[marble]# host -tmx telus.blackberry.net telus.blackberry.net mail is handled by 10 mx01.bis.na.blackberry.com. telus.blackberry.net mail is handled by 10 mx02.bis.na.blackberry.com. telus.blackberry.net mail is handled by 10 mx03.bis.na.blackberry.com. telus.blackberry.net mail is handled by 10 mx04.bis.na.blackberry.com. 0[marble]# telnet mx01.bis.na.blackberry.com 25 Trying 216.9.248.32... Connected to mx01.bis.na.blackberry.com. Escape character is '^]'. 220 as18.bis.na.blackberry.com ESMTP HELO marble.sentex.ca 250 as18.bis.na.blackberry.com MAIL From: 250 sender ok QUIT 221 as18.bis.na.blackberry.com Connection closed by foreign host. 1[marble]# telnet mx01.bis.na.blackberry.com 25 Trying 216.9.248.32... Connected to mx01.bis.na.blackberry.com. Escape character is '^]'. 220 as08.bis.na.blackberry.com ESMTP HELO marble.sentex.ca 250 as08.bis.na.blackberry.com MAIL From: 451 #4.1.8 Domain of sender address does not resolve -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From lcaron at unix-scripts.info Sat Sep 5 11:32:35 2009 From: lcaron at unix-scripts.info (Laurent CARON) Date: Sat, 05 Sep 2009 18:32:35 +0200 Subject: Is 213.215.28.0/23 (AS 49463) announced through AS 12670 and AS 13193 In-Reply-To: <1252161059.8489.6.camel@fr-wks3.corp.novso.com> References: <4AA26FF1.2050505@unix-scripts.info> <1252161059.8489.6.camel@fr-wks3.corp.novso.com> Message-ID: <4AA292A3.9000102@unix-scripts.info> On 05/09/2009 16:30, Nicolas DEFFAYET wrote: > Completel AS12670 don't announce your route 213.215.28.0/23 to their > peers so your route is only visible through Nerim AS13193. > > Did you announce your route 213.215.28.0/23 to Completel AS12670 ? Hi, I'm of course announcing it to their upstream router. If their upstream router actually forwards it to its neighbors is another question...which I can't unfortunately not answer. But I guess the announce is not propagated outside of their network... Thanks for your help. Laurent From egon at egon.cc Sat Sep 5 12:02:21 2009 From: egon at egon.cc (James Downs) Date: Sat, 5 Sep 2009 10:02:21 -0700 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: References: <4A95CC85.8080102@gmail.com> Message-ID: <60F70284-7FE2-45C7-AC65-9FAEFCDF3132@egon.cc> On Aug 28, 2009, at 7:55 PM, Frank Bulk wrote: > I'm not following you here -- which party has the right of first > refusal? The incumbent companies (generally, a LEC or cable company) are able to refuse projects and also effectively prevent buildouts and upgrades from being done by a 3rd party. However, I have seen reports that in a few areas, municipalities are starting to win lawsuits against them (in apparently the long appeals process). > urban area receives no USF, and is not able to financially justify > it even > with a dense customer base. That might apply to fiber, but even speed upgrades (Newer DSL services) are apparently subject to the same refusal process, but the rules are different across the country, too. -j From ops.lists at gmail.com Sat Sep 5 22:06:48 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 6 Sep 2009 08:36:48 +0530 Subject: Is 213.215.28.0/23 (AS 49463) announced through AS 12670 and AS 13193 In-Reply-To: <4AA292A3.9000102@unix-scripts.info> References: <4AA26FF1.2050505@unix-scripts.info> <1252161059.8489.6.camel@fr-wks3.corp.novso.com> <4AA292A3.9000102@unix-scripts.info> Message-ID: This might explain it .. suresh at frodo 19:59:40 :~$ whois -h whois.radb.net 213.215.28.0 route: 213.215.0.0/18 descr: NERIM-213-215 origin: AS13193 holes: 213.215.38.0/24 mnt-by: NERIM-MNT changed: bouaziz at nerim.net 20020827 changed: bouaziz at nerim.net 20081107 source: RIPE You need to update radb with your other prefix. See http://www.radb.net/rfc2622.html On Sat, Sep 5, 2009 at 10:02 PM, Laurent CARON wrote: > On 05/09/2009 16:30, Nicolas DEFFAYET wrote: >> >> Completel AS12670 don't announce your route 213.215.28.0/23 to their >> peers so your route is only visible through Nerim AS13193. >> >> Did you announce your route 213.215.28.0/23 to Completel AS12670 ? > > Hi, > > I'm of course announcing it to their upstream router. > > If their upstream router actually forwards it to its neighbors is another > question...which I can't unfortunately not answer. But I guess the announce > is not propagated outside of their network... > > Thanks for your help. > > Laurent > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From lcaron at unix-scripts.info Sun Sep 6 09:25:59 2009 From: lcaron at unix-scripts.info (Laurent CARON) Date: Sun, 06 Sep 2009 16:25:59 +0200 Subject: hi, a question related to AS 49463 In-Reply-To: <32F88E7C-02D1-45BA-B5F2-D814EE00613A@gmail.com> References: <32F88E7C-02D1-45BA-B5F2-D814EE00613A@gmail.com> Message-ID: <4AA3C677.4010905@unix-scripts.info> On 06/09/2009 15:56, Bin Dai wrote: > Hi: > I am interested in ur question to nanog about doubting whether AS 49463 > is reachable thourgh AS 12670. > in ur case, AS 49463 is multihomed. what you want to do,if i am right, > is that you wanna make the following things happen: > the 213.215.28.0/23 is reachable both through AS 12670 and AS 13193. And > like what u said, you are certain that > that prefix is announced to AS 12670. So all the customers of AS 12670 > should be ok to reach that prefix. > Am I right? I have a question: if the link between 13193 and 4943 fails, > what will happen? will the guy: Nicolas DEFFAYET lose the > reachability to AS 49463? Hi, Since i do have direct connectivity to 13193 and 12670, if my prefix is correctly announced through both ISP, the failure of 1 ISP should allow me to still be reachable and reach the outside world. Laurent From fw at deneb.enyo.de Sun Sep 6 12:37:43 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 06 Sep 2009 17:37:43 +0000 Subject: Any RIM / blackberry folks around ? In-Reply-To: <200909051600.n85G0exS047513@lava.sentex.ca> (Mike Tancsa's message of "Sat, 05 Sep 2009 12:04:19 -0400") References: <200909051600.n85G0exS047513@lava.sentex.ca> Message-ID: <87zl98m0t4.fsf@mid.deneb.enyo.de> * Mike Tancsa: > 220 as08.bis.na.blackberry.com ESMTP > HELO marble.sentex.ca > 250 as08.bis.na.blackberry.com > MAIL From: > 451 #4.1.8 Domain of sender address does not resolve This could just be an SPF failure. Try some sender address you control. From marka at isc.org Sun Sep 6 18:46:01 2009 From: marka at isc.org (Mark Andrews) Date: Mon, 07 Sep 2009 09:46:01 +1000 Subject: Any RIM / blackberry folks around ? In-Reply-To: Your message of "Sun, 06 Sep 2009 17:37:43 GMT." <87zl98m0t4.fsf@mid.deneb.enyo.de> References: <200909051600.n85G0exS047513@lava.sentex.ca> <87zl98m0t4.fsf@mid.deneb.enyo.de> Message-ID: <200909062346.n86Nk1qv050549@drugs.dv.isc.org> In message <87zl98m0t4.fsf at mid.deneb.enyo.de>, Florian Weimer writes: > * Mike Tancsa: > > > 220 as08.bis.na.blackberry.com ESMTP > > HELO marble.sentex.ca > > 250 as08.bis.na.blackberry.com > > MAIL From: > > 451 #4.1.8 Domain of sender address does not resolve > > This could just be an SPF failure. Try some sender address you > control. > It if it then that is a very bad diagnostic message. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From chanty_kh at yahoo.com Sun Sep 6 23:14:03 2009 From: chanty_kh at yahoo.com (ty chan) Date: Sun, 6 Sep 2009 21:14:03 -0700 (PDT) Subject: Network Ring Message-ID: <354013.26624.qm@web52309.mail.re2.yahoo.com> Dear all, I am in process of planning ring network to cover 15 POPs in City. Some technologies are chosen for consideration like SDH(Huawei), PVRST+(Cisco), RSTP(Zyxel), EAPS (extreme network) and MPLS(VPLS). The purpose is to provide L2 Ethernet connectivities from POPs to central point (DC) and ring protection. I know you all are in those network for years. can you give me some advises? Best regards, chanty From j at arpa.com Sun Sep 6 23:51:17 2009 From: j at arpa.com (jamie) Date: Sun, 6 Sep 2009 23:51:17 -0500 Subject: Network Ring In-Reply-To: <354013.26624.qm@web52309.mail.re2.yahoo.com> References: <354013.26624.qm@web52309.mail.re2.yahoo.com> Message-ID: <6ff30abd0909062151v70e232e8r4feed7ceb88e36fa@mail.gmail.com> Step 1: Don't mix vendors. Period. On Sun, Sep 6, 2009 at 11:14 PM, ty chan wrote: > Dear all, > > I am in process of planning ring network to cover 15 POPs in City. Some > technologies are chosen for consideration like SDH(Huawei), PVRST+(Cisco), > RSTP(Zyxel), EAPS (extreme network) and MPLS(VPLS). The purpose is to > provide L2 Ethernet connectivities from POPs to central point (DC) and ring > protection. > > I know you all are in those network for years. can you give me some > advises? > > Best regards, > chanty > From chanty_kh at yahoo.com Sun Sep 6 23:52:54 2009 From: chanty_kh at yahoo.com (ty chan) Date: Sun, 6 Sep 2009 21:52:54 -0700 (PDT) Subject: Network Ring In-Reply-To: <6ff30abd0909062151v70e232e8r4feed7ceb88e36fa@mail.gmail.com> References: <354013.26624.qm@web52309.mail.re2.yahoo.com> <6ff30abd0909062151v70e232e8r4feed7ceb88e36fa@mail.gmail.com> Message-ID: <876693.5935.qm@web52301.mail.re2.yahoo.com> Only one vendor will be chosen. ________________________________ From: jamie To: ty chan Cc: nanog at nanog.org Sent: Monday, September 7, 2009 11:51:17 AM Subject: Re: Network Ring Step 1: Don't mix vendors. Period. On Sun, Sep 6, 2009 at 11:14 PM, ty chan wrote: Dear all, > >>I am in process of planning ring network to cover 15 POPs in City. Some technologies are chosen for consideration like SDH(Huawei), PVRST+(Cisco), RSTP(Zyxel), EAPS (extreme network) and MPLS(VPLS). The purpose is to provide L2 Ethernet connectivities from POPs to central point (DC) and ring protection. > >>I know you all are in those network for years. can you give me some advises? > >>Best regards, >>chanty > From rdobbins at arbor.net Sun Sep 6 23:56:24 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Mon, 7 Sep 2009 11:56:24 +0700 Subject: Network Ring In-Reply-To: <354013.26624.qm@web52309.mail.re2.yahoo.com> References: <354013.26624.qm@web52309.mail.re2.yahoo.com> Message-ID: On Sep 7, 2009, at 11:14 AM, ty chan wrote: > The purpose is to provide L2 Ethernet connectivities from POPs to > central point (DC) and ring protection. I'd strongly suggest trying to avoid a large, multi-geography layer-2 topology, and instead work to separate it out via layer-3. Otherwise, you're just asking for trouble, IMHO. ----------------------------------------------------------------------- Roland Dobbins // Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 From jmamodio at gmail.com Sun Sep 6 23:55:49 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Sun, 6 Sep 2009 23:55:49 -0500 Subject: Network Ring In-Reply-To: <6ff30abd0909062151v70e232e8r4feed7ceb88e36fa@mail.gmail.com> References: <354013.26624.qm@web52309.mail.re2.yahoo.com> <6ff30abd0909062151v70e232e8r4feed7ceb88e36fa@mail.gmail.com> Message-ID: <202705b0909062155l6893b2a8s9e4101135d8c02c5@mail.gmail.com> On Sun, Sep 6, 2009 at 11:51 PM, jamie wrote: > Step 1: Don't mix vendors. ?Period. Step 2: Hire a network consultant that gets paid for its job. From nanog at daork.net Mon Sep 7 01:09:45 2009 From: nanog at daork.net (Nathan Ward) Date: Mon, 7 Sep 2009 18:09:45 +1200 Subject: Network Ring In-Reply-To: <354013.26624.qm@web52309.mail.re2.yahoo.com> References: <354013.26624.qm@web52309.mail.re2.yahoo.com> Message-ID: On 7/09/2009, at 4:14 PM, ty chan wrote: > I am in process of planning ring network to cover 15 POPs in City. > Some technologies are chosen for consideration like SDH(Huawei), > PVRST+(Cisco), RSTP(Zyxel), EAPS (extreme network) and MPLS(VPLS). > The purpose is to provide L2 Ethernet connectivities from POPs to > central point (DC) and ring protection. Of the above, VPLS. But it really depends what you need to do. If you're selling customers cross-town L2 services then yeah VPLS is the best option in my opinion. If this is for use between your own equipment, other technologies might make more sense. I echo Roland's comment, but I'll make it more specific - stay away from anything with spanning tree in it. -- Nathan Ward From bannai at pacbell.net Mon Sep 7 01:32:02 2009 From: bannai at pacbell.net (VINAY BANNAI) Date: Sun, 6 Sep 2009 23:32:02 -0700 (PDT) Subject: Network Ring In-Reply-To: <876693.5935.qm@web52301.mail.re2.yahoo.com> Message-ID: <513536.19360.qm@web81003.mail.mud.yahoo.com> There are several ring technologies that are interesting but again it depends on what services you are planning to run and what kind of SLA guarantees? you need: - RPR (802.17) : This has quieted down but it is a fairly robust technology giving you packet rings with 50ms, CoS, fairness and upto 255 nodes in a ring - EAPS: This technology is more vendor specific (eventhough an informational RFC exists) - ERPS (G.8032 - ITU) : This standard from ITU folks supports ethernet based packet rings and is comparable to EAPS - SONET/SDH : This is tried and tested but do you want to deploy a TDM based technology if most of your traffic is packet based - MPLS/VPLS : This is a layer 3 based and may not work for pure layer 2 service providers. It is tried and tested but does have some operational complexity built-in compared to layer 2 based technologies I agree with an earlier suggestion made, do not mix vendors if you want service level interoperability.? Vinay Bannai Email : bannai at pacbell.net --- On Sun, 9/6/09, ty chan wrote: From: ty chan Subject: Re: Network Ring To: "jamie" Cc: nanog at nanog.org Date: Sunday, September 6, 2009, 9:52 PM Only one vendor will be chosen. ________________________________ From: jamie To: ty chan Cc: nanog at nanog.org Sent: Monday, September 7, 2009 11:51:17 AM Subject: Re: Network Ring Step 1: Don't mix vendors.? Period. On Sun, Sep 6, 2009 at 11:14 PM, ty chan wrote: Dear all, > >>I am in process of planning ring network to cover 15 POPs in City. Some technologies are chosen for consideration like SDH(Huawei), PVRST+(Cisco), RSTP(Zyxel), EAPS (extreme network) and MPLS(VPLS). The purpose is to provide L2 Ethernet connectivities from POPs to central point (DC) and ring protection. > >>I know you all are in those network for years. can you give me some advises? > >>Best regards, >>chanty > From sthaug at nethelp.no Mon Sep 7 02:51:51 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Mon, 07 Sep 2009 09:51:51 +0200 (CEST) Subject: Network Ring In-Reply-To: References: <354013.26624.qm@web52309.mail.re2.yahoo.com> Message-ID: <20090907.095151.74706289.sthaug@nethelp.no> > > I am in process of planning ring network to cover 15 POPs in City. > > Some technologies are chosen for consideration like SDH(Huawei), > > PVRST+(Cisco), RSTP(Zyxel), EAPS (extreme network) and MPLS(VPLS). > > The purpose is to provide L2 Ethernet connectivities from POPs to > > central point (DC) and ring protection. > > Of the above, VPLS. Strongly disagree. VPLS gives you ample rope to hang yourself. An L2 ring-based protocol like EAPS is much simpler to deploy. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From truman at suspicious.org Mon Sep 7 07:00:54 2009 From: truman at suspicious.org (Truman Boyes) Date: Mon, 7 Sep 2009 22:00:54 +1000 Subject: Network Ring In-Reply-To: <354013.26624.qm@web52309.mail.re2.yahoo.com> References: <354013.26624.qm@web52309.mail.re2.yahoo.com> Message-ID: <0A096D64-063F-482B-A614-D59FFCE498B8@suspicious.org> Hi there, Keep it really simple. MPLS/VPLS is the most scalable method to create Layer 2 and Layer 3 connectivity between sites. As previously mentioned, try to stick with one vendor, one code version for all the POPs, and use protocols that are designed to scale well. (ie. MP-BGP) If your goal is to provide layer 2 around across all 15 POPs you don't actually need to build a ring. With MPLS/VPLS you can use any topology that provides you the necessary efficiency and reliability. MPLS can be used on any of the transport technologies that are available to you (ie. SDH / dark fiber / dwdm / etc) ... Kind regards, Truman On 7/09/2009, at 2:14 PM, ty chan wrote: > Dear all, > > I am in process of planning ring network to cover 15 POPs in City. > Some technologies are chosen for consideration like SDH(Huawei), > PVRST+(Cisco), RSTP(Zyxel), EAPS (extreme network) and MPLS(VPLS). > The purpose is to provide L2 Ethernet connectivities from POPs to > central point (DC) and ring protection. > > I know you all are in those network for years. can you give me some > advises? > > Best regards, > chanty > From rubensk at gmail.com Mon Sep 7 08:15:23 2009 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 7 Sep 2009 10:15:23 -0300 Subject: Network Ring In-Reply-To: <354013.26624.qm@web52309.mail.re2.yahoo.com> References: <354013.26624.qm@web52309.mail.re2.yahoo.com> Message-ID: <6bb5f5b10909070615qf0fbdcdo195aba4fa08ffc82@mail.gmail.com> My vote goes to proprietary ring protection from the vendor you choose: - EAPS (Extreme) - REP (Cisco) - MRP (Foundry/Brocade) - EPSR (Allied Telesis) Although EAPS is implemented in all Extreme switches, select models from the other vendors implement ring protection, but these models also do other things you might want your network to have (QinQ, per-VLAN controls). Rubens On Mon, Sep 7, 2009 at 1:14 AM, ty chan wrote: > Dear all, > > I am in process of planning ring network to cover 15 POPs in City. Some technologies are chosen for consideration like SDH(Huawei), PVRST+(Cisco), RSTP(Zyxel), EAPS (extreme network) and MPLS(VPLS). The purpose is to provide L2 Ethernet connectivities from POPs to central point (DC) and ring protection. > > I know you all are in those network for years. can you give me some advises? > > Best regards, > chanty > From Rod.Beck at hiberniaatlantic.com Mon Sep 7 08:54:45 2009 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Mon, 7 Sep 2009 14:54:45 +0100 Subject: Network Ring References: <354013.26624.qm@web52309.mail.re2.yahoo.com> <20090907.095151.74706289.sthaug@nethelp.no> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB0162881C@bert.HiberniaAtlantic.local> > > I am in process of planning ring network to cover 15 POPs in City. > > Some technologies are chosen for consideration like SDH(Huawei), > > PVRST+(Cisco), RSTP(Zyxel), EAPS (extreme network) and MPLS(VPLS). > > The purpose is to provide L2 Ethernet connectivities from POPs to > > central point (DC) and ring protection. > > Of the above, VPLS. Strongly disagree. VPLS gives you ample rope to hang yourself. An L2 ring-based protocol like EAPS is much simpler to deploy. Steinar Haug, Nethelp consulting, sthaug at nethelp.no What is EAPS? From w3yni1 at gmail.com Mon Sep 7 09:00:58 2009 From: w3yni1 at gmail.com (Charles Mills) Date: Mon, 7 Sep 2009 10:00:58 -0400 Subject: Network Ring In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB0162881C@bert.HiberniaAtlantic.local> References: <354013.26624.qm@web52309.mail.re2.yahoo.com> <20090907.095151.74706289.sthaug@nethelp.no> <1E8B940C5E21014AB8BE70B975D40EDB0162881C@bert.HiberniaAtlantic.local> Message-ID: <607f1e0a0909070700ra6bea6aw23f9a680802dd058@mail.gmail.com> The power of google.... http://en.wikipedia.org/wiki/Ethernet_Automatic_Protection_Switching > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > > What is EAPS? > From Ben.Matthew at timlradio.co.uk Mon Sep 7 10:45:30 2009 From: Ben.Matthew at timlradio.co.uk (Ben Matthew) Date: Mon, 7 Sep 2009 16:45:30 +0100 Subject: IPv6 "real world" testing plea... Message-ID: Hi guys, Could really use some feedback here as it's quite difficult to test IPv6 services given nobody really seems to give much of a toss about it in the "real world". I work for Absolute Radio in the UK (formally Virgin Radio) - a national commercial radio service - and we have always been quite keen to support as many platforms and technologies as we can for our online streaming listeners. As such I want to make sure our own network and infrastructure can be as IPv6 ready as we can. Our network has a couple of good transit links for IPv6 including, if I may name check for a second, Hurricane Electric who have been very supportive of IPv6 with us. Anyhoo; I'm relatively happy that our first native IPv6 streaming platform is working ok but I'd appreciate it if anyone out there who is IPv6 enabled would have a go and let me know if there are any issues. If you experience buffering or drop-outs it'd be great to receive (off-list) a traceroute so I might diagnose. Only Windows Media at the moment, but I hope to launch a icecast driven OGG stream soon as well along with some multicast variants.... Addresses are: http://wm-ipv6.as34763.net/vruk_vr_hi [Absolute Radio (Poprock)] http://wm-ipv6.as34763.net/vruk_vc_hi [Absolute Radio Classic Rock] http://wm-ipv6.as34763.net/vruk_vx_hi [Absolute Radio Xtreme (Mainstream alternative*)] If tests are successful hopefully we can launch publically and encourage a few other broadcasters (and indeed network providers) to take IPv6 more seriously. Cheers, Ben *yeah alright that's a complete oxymoron; but I don't know how else to describe it! ________________________________________________ DISCLAIMER This e-mail message, including any attachments, is intended solely for the use of the addressee and may contain confidential information. If it is not intended for you, please inform the sender and delete the e-mail and any attachments immediately. Any review, retransmission, disclosure, copying or modification of it is strictly forbidden. Please be advised that the views and opinions expressed in this e-mail may not reflect the views and opinions of TIML Radio Limited or any of its parent and subsidiary companies. Whilst we take reasonable precautions to ensure that our emails are free from viruses, we cannot be responsible for any viruses transmitted with this e-mail and recommend that you subject any incoming e-mail to your own virus checking procedures. Use of this or any other e-mail facility signifies consent to any interception we might lawfully carry out to prevent abuse of these facilities. ________________________________________________ TIML Radio Limited (trading as Absolute Radio) Registered office: One Golden Square, London. W1F 9DJ Registered in England No 02674136 VAT No 927 2572 11 From lcaron at unix-scripts.info Mon Sep 7 10:47:04 2009 From: lcaron at unix-scripts.info (Laurent CARON) Date: Mon, 7 Sep 2009 17:47:04 +0200 Subject: Is 213.215.28.0/23 (AS 49463) announced through AS 12670 and AS 13193 In-Reply-To: <4AA26FF1.2050505@unix-scripts.info> References: <4AA26FF1.2050505@unix-scripts.info> Message-ID: <20090907174610.geirohva@trusted.unix-scripts.info> On Sat, Sep 05, 2009 at 04:04:33PM +0200, Laurent CARON wrote: > Hi, > > I did set-up this netblock behind two pipes. > > One on AS13193 (which is working flawlessy), and ahother on AS12670 > (which I doubt of). > > Can please any of you tell me if from your location 213.215.28.0 is > reachable through AS12670 ? Hi, It seems the netblock 213.215.28.0/23 is now reachable through AS13193 and AS12670. Thanks Laurent From ops.lists at gmail.com Mon Sep 7 12:01:24 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 7 Sep 2009 22:31:24 +0530 Subject: Is 213.215.28.0/23 (AS 49463) announced through AS 12670 and AS 13193 In-Reply-To: <20090907174610.geirohva@trusted.unix-scripts.info> References: <4AA26FF1.2050505@unix-scripts.info> <20090907174610.geirohva@trusted.unix-scripts.info> Message-ID: Yup. Compare this current radb lookup - suresh at frodo 09:53:21 :~$ whois -h whois.radb.net 213.215.28.0/23 route: 213.215.28.0/23 descr: LNC-1 origin: AS49463 mnt-by: NERIM-MNT changed: bouaziz at nerim.net 20090907 source: RIPE with the previous one - suresh at frodo 19:59:40 :~$ whois -h whois.radb.net 213.215.28.0 route: 213.215.0.0/18 descr: NERIM-213-215 origin: AS13193 holes: 213.215.38.0/24 mnt-by: NERIM-MNT changed: bouaziz at nerim.net 20020827 changed: bouaziz at nerim.net 20081107 source: RIPE On Mon, Sep 7, 2009 at 9:17 PM, Laurent CARON wrote: > On Sat, Sep 05, 2009 at 04:04:33PM +0200, Laurent CARON wrote: >> Hi, >> >> I did set-up this netblock behind two pipes. >> >> One on AS13193 (which is working flawlessy), and ahother on AS12670 >> (which I doubt of). >> >> Can please any of you tell me if from your location 213.215.28.0 is >> reachable through AS12670 ? > > Hi, > > It seems the netblock 213.215.28.0/23 is now reachable through AS13193 > and AS12670. > > Thanks > > Laurent > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From ge at linuxbox.org Mon Sep 7 11:57:54 2009 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 07 Sep 2009 19:57:54 +0300 Subject: ruling: liability for providers who don't act on clients' illegal activities? Message-ID: <4AA53B92.90806@linuxbox.org> Jury Exacts $32M Penalty From ISPs For Supporting Criminal Websites http://darkreading.com/securityservices/security/cybercrime/showArticle.jhtml 'Landmark case' indicates that ISPs may be held liable if they know about criminal activity on their customers' Websites and fail to act A federal jury in California this week levied a total of $32 million in damages from two Internet service providers that knowingly supported Websites that were running illegal operations. In a lawsuit brought by fashion company Louis Vuitton, a jury ruled that two ISPs -- Akanoc Solutions and Managed Solutions Group -- knew about counterfeit Vuitton goods that were being sold on their customers' sites, but didn't act quickly to pull the plug on those sites. The decision was first reported on Tuesday. The ruling has been called a landmark decision by some legal experts, who note that ISPs historically have been protected by the Digital Millennium Copyright Act, which limits service providers' liability for criminal actions that take place on their networks. From ge at linuxbox.org Mon Sep 7 11:59:42 2009 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 07 Sep 2009 19:59:42 +0300 Subject: ruling: liability for providers who don't act on clients' illegal activities? In-Reply-To: <4AA53B92.90806@linuxbox.org> References: <4AA53B92.90806@linuxbox.org> Message-ID: <4AA53BFE.9060701@linuxbox.org> Gadi Evron wrote: > Jury Exacts $32M Penalty From ISPs For Supporting Criminal Websites > http://darkreading.com/securityservices/security/cybercrime/showArticle.jhtml > Corrected URL: http://darkreading.com/securityservices/security/cybercrime/showArticle.jhtml;jsessionid=5P4BO3EZ4TBL3QE1GHPSKH4ATMY32JVN?articleID=219501314 > 'Landmark case' indicates that ISPs may be held liable if they know > about criminal activity on their customers' Websites and fail to act > > A federal jury in California this week levied a total of $32 million in > damages from two Internet service providers that knowingly supported > Websites that were running illegal operations. > > In a lawsuit brought by fashion company Louis Vuitton, a jury ruled that > two ISPs -- Akanoc Solutions and Managed Solutions Group -- knew about > counterfeit Vuitton goods that were being sold on their customers' > sites, but didn't act quickly to pull the plug on those sites. The > decision was first reported on Tuesday. > > The ruling has been called a landmark decision by some legal experts, > who note that ISPs historically have been protected by the Digital > Millennium Copyright Act, which limits service providers' liability for > criminal actions that take place on their networks. > > From lcaron at unix-scripts.info Mon Sep 7 12:20:54 2009 From: lcaron at unix-scripts.info (Laurent CARON) Date: Mon, 07 Sep 2009 19:20:54 +0200 Subject: Is 213.215.28.0/23 (AS 49463) announced through AS 12670 and AS 13193 In-Reply-To: References: <4AA26FF1.2050505@unix-scripts.info> <20090907174610.geirohva@trusted.unix-scripts.info> Message-ID: <4AA540F6.8080502@unix-scripts.info> On 07/09/2009 19:01, Suresh Ramasubramanian wrote: > Yup. Compare this current radb lookup - > > suresh at frodo 09:53:21 :~$ whois -h whois.radb.net 213.215.28.0/23 > route: 213.215.28.0/23 > descr: LNC-1 > origin: AS49463 > mnt-by: NERIM-MNT > changed: bouaziz at nerim.net 20090907 > source: RIPE > > with the previous one - > > suresh at frodo 19:59:40 :~$ whois -h whois.radb.net 213.215.28.0 > route: 213.215.0.0/18 > descr: NERIM-213-215 > origin: AS13193 > holes: 213.215.38.0/24 > mnt-by: NERIM-MNT > changed: bouaziz at nerim.net 20020827 > changed: bouaziz at nerim.net 20081107 > source: RIPE A hole in 213.215.0.0/18 was missing and has been added by the 1st ISP. From j at arpa.com Mon Sep 7 12:22:07 2009 From: j at arpa.com (jamie) Date: Mon, 7 Sep 2009 12:22:07 -0500 Subject: ruling: liability for providers who don't act on clients' illegal activities? In-Reply-To: <4AA53BFE.9060701@linuxbox.org> References: <4AA53B92.90806@linuxbox.org> <4AA53BFE.9060701@linuxbox.org> Message-ID: <6ff30abd0909071022k2a673591q834701379ccf1d4b@mail.gmail.com> FYI, This was discussed in the already-OT thread "Beware : a very bad precedent set" a week ago. On Mon, Sep 7, 2009 at 11:59 AM, Gadi Evron wrote: > Gadi Evron wrote: > >> Jury Exacts $32M Penalty From ISPs For Supporting Criminal Websites >> >> http://darkreading.com/securityservices/security/cybercrime/showArticle.jhtml >> > > Corrected URL: > > http://darkreading.com/securityservices/security/cybercrime/showArticle.jhtml;jsessionid=5P4BO3EZ4TBL3QE1GHPSKH4ATMY32JVN?articleID=219501314 > > > > > 'Landmark case' indicates that ISPs may be held liable if they know about >> criminal activity on their customers' Websites and fail to act >> >> A federal jury in California this week levied a total of $32 million in >> damages from two Internet service providers that knowingly supported >> Websites that were running illegal operations. >> >> In a lawsuit brought by fashion company Louis Vuitton, a jury ruled that >> two ISPs -- Akanoc Solutions and Managed Solutions Group -- knew about >> counterfeit Vuitton goods that were being sold on their customers' sites, >> but didn't act quickly to pull the plug on those sites. The decision was >> first reported on Tuesday. >> >> The ruling has been called a landmark decision by some legal experts, who >> note that ISPs historically have been protected by the Digital Millennium >> Copyright Act, which limits service providers' liability for criminal >> actions that take place on their networks. >> >> >> > > From frnkblk at iname.com Mon Sep 7 13:50:35 2009 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 7 Sep 2009 13:50:35 -0500 Subject: FCCs RFC for the Definition of Broadband In-Reply-To: <20090906150423.C94C21540024@smtp2.mtcnet.net> References: <4A95CC85.8080102@gmail.com> <20090906150423.C94C21540024@smtp2.mtcnet.net> Message-ID: I don't think LECs to MSOs have first right of refusal..it's possible that with MSOs that the city has give the franchise exclusivity, but blame the city then, not the MSO. What happens more often is that the LEC or MSO uses legal, lobbying, or legislative means to put a stop to the competition, but it's not first right of refusal. In the cases where munis lost, it was in relationship to telephone service and a city's ability to obtain a certificate of service (see here for one muni's story: http://www.cityofhawarden.com/HiTec/History.html). Another route to opposition is if it fills up RoW, though I haven't personally read as much about that. Possibly because if the new company is a desperate enough, they'll come up with a way to address the RoW constraints or show how it's not a real issue. Remember, if it really *is* constrained, the new company won't be super eager to build in there, either. Frank From: James Downs [mailto:egon at egon.cc] Sent: Saturday, September 05, 2009 12:02 PM To: frnkblk at iname.com Cc: nanog at nanog.org Subject: Re: FCCs RFC for the Definition of Broadband On Aug 28, 2009, at 7:55 PM, Frank Bulk wrote: I'm not following you here -- which party has the right of first refusal? The incumbent companies (generally, a LEC or cable company) are able to refuse projects and also effectively prevent buildouts and upgrades from being done by a 3rd party. However, I have seen reports that in a few areas, municipalities are starting to win lawsuits against them (in apparently the long appeals process). urban area receives no USF, and is not able to financially justify it even with a dense customer base. That might apply to fiber, but even speed upgrades (Newer DSL services) are apparently subject to the same refusal process, but the rules are different across the country, too. -j From ge at linuxbox.org Mon Sep 7 19:27:13 2009 From: ge at linuxbox.org (Gadi Evron) Date: Tue, 08 Sep 2009 03:27:13 +0300 Subject: ruling: liability for providers who don't act on clients' illegal activities? In-Reply-To: <6ff30abd0909071022k2a673591q834701379ccf1d4b@mail.gmail.com> References: <4AA53B92.90806@linuxbox.org> <4AA53BFE.9060701@linuxbox.org> <6ff30abd0909071022k2a673591q834701379ccf1d4b@mail.gmail.com> Message-ID: <4AA5A4E1.5070609@linuxbox.org> jamie wrote: > FYI, This was discussed in the already-OT thread "Beware : a very bad > precedent set" a week ago. Ah. I apologize. It happens. > > On Mon, Sep 7, 2009 at 11:59 AM, Gadi Evron > wrote: > > Gadi Evron wrote: > > Jury Exacts $32M Penalty From ISPs For Supporting Criminal Websites > http://darkreading.com/securityservices/security/cybercrime/showArticle.jhtml > > > > Corrected URL: > http://darkreading.com/securityservices/security/cybercrime/showArticle.jhtml;jsessionid=5P4BO3EZ4TBL3QE1GHPSKH4ATMY32JVN?articleID=219501314 > > > > > 'Landmark case' indicates that ISPs may be held liable if they > know about criminal activity on their customers' Websites and > fail to act > > A federal jury in California this week levied a total of $32 > million in damages from two Internet service providers that > knowingly supported Websites that were running illegal operations. > > In a lawsuit brought by fashion company Louis Vuitton, a jury > ruled that two ISPs -- Akanoc Solutions and Managed Solutions > Group -- knew about counterfeit Vuitton goods that were being > sold on their customers' sites, but didn't act quickly to pull > the plug on those sites. The decision was first reported on Tuesday. > > The ruling has been called a landmark decision by some legal > experts, who note that ISPs historically have been protected by > the Digital Millennium Copyright Act, which limits service > providers' liability for criminal actions that take place on > their networks. > > > > > -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From ken.gilmour at gmail.com Mon Sep 7 23:17:30 2009 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Mon, 7 Sep 2009 22:17:30 -0600 Subject: Comcast Abuse Contact Message-ID: <5b6f80200909072117g218d368ds6e67b8364f28787a@mail.gmail.com> Hi There, I am trying to get through to Comcast Abuse dept in a hurry due to a DoS... I have called the normal number on the whois for the offending IP: RAbuseHandle: NAPO-ARIN RAbuseName: Network Abuse and Policy Observance RAbusePhone: +1-856-317-7272 RAbuseEmail: abuse at comcast.net Which tells me to call +1-877-477-5537, Which gives me a busy tone. Is there anyone on the list from Comcast watching right now? Thanks! Ken From braaen at zcorum.com Tue Sep 8 06:21:46 2009 From: braaen at zcorum.com (Brian Raaen) Date: Tue, 08 Sep 2009 07:21:46 -0400 Subject: BGP Hijack by AT&T... was: Need Help Getting IP Unblocked by AT&T In-Reply-To: <4A9FB9F6.8020204@zcorum.com> References: <4A9FA88E.3040600@zcorum.com> <4A9FB6AC.60201@zcorum.com> <4A9FB9F6.8020204@zcorum.com> Message-ID: <4AA63E4A.7080206@zcorum.com> It appears that AT&T started announcing a block of a former customer that we had reclaimed. AT&T contacted me offline and let me know that the issue was resolved. Brian Raaen wrote: > I have sent a complaint to the AT&T abuse contact from my ARIN contact > address asking them to stop announcing the route. > > -- ----------------- Brian Raaen Network Engineer email: /braaen at zcorum.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: braaen.vcf Type: text/x-vcard Size: 206 bytes Desc: not available URL: From justin at justinshore.com Tue Sep 8 06:29:28 2009 From: justin at justinshore.com (Justin Shore) Date: Tue, 08 Sep 2009 06:29:28 -0500 Subject: Network Ring In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB0162881C@bert.HiberniaAtlantic.local> References: <354013.26624.qm@web52309.mail.re2.yahoo.com> <20090907.095151.74706289.sthaug@nethelp.no> <1E8B940C5E21014AB8BE70B975D40EDB0162881C@bert.HiberniaAtlantic.local> Message-ID: <4AA64018.7080006@justinshore.com> Rod Beck wrote: > What is EAPS? A joke of a "standard" and something to be avoided at all costs. I would echo the last part about Extreme switches too. Justin From pstewart at nexicomgroup.net Tue Sep 8 07:21:42 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Tue, 8 Sep 2009 08:21:42 -0400 Subject: Network Ring In-Reply-To: <4AA64018.7080006@justinshore.com> References: <354013.26624.qm@web52309.mail.re2.yahoo.com> <20090907.095151.74706289.sthaug@nethelp.no><1E8B940C5E21014AB8BE70B975D40EDB0162881C@bert.HiberniaAtlantic.local> <4AA64018.7080006@justinshore.com> Message-ID: Since it was brought up - curious as we were recently approached by Extreme. Good/bad experiences? We're a Cisco shop and I plan to keep us that way but some "powers to be" are interested in them at this point.. Thanks, Paul -----Original Message----- From: Justin Shore [mailto:justin at justinshore.com] Sent: September-08-09 7:29 AM To: Rod Beck Cc: nanog at nanog.org Subject: Re: Network Ring Rod Beck wrote: > What is EAPS? A joke of a "standard" and something to be avoided at all costs. I would echo the last part about Extreme switches too. Justin ---------------------------------------------------------------------------- "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 dmm at 1-4-5.net Tue Sep 8 09:10:37 2009 From: dmm at 1-4-5.net (David Meyer) Date: Tue, 8 Sep 2009 07:10:37 -0700 Subject: [NANOG-announce] NANOG 47 dates of interest Message-ID: <20090908141037.GA27841@1-4-5.net> Folks, Just a brief reminder of upcoming dates of interest - The NANOG PC will be posting an updated agenda for NANOG 47 after our 09/08/2009 call - The registration fee for NANOG 47 increases to US$525 on 09/14/2009 - Nominations for the NANOG PC open today, 09/08/2009 - Voting for the 2009/2010 NANOG SC closes at 13:00 EDT on 10-21-09. See http://www.nanog.org/governance/elections/2009elections/ for additional details - Last but not least, the hotel group rate expires in 09/30/2009. See http://www.nanog.org/meetings/nanog47/hotel.php See you all in Dearborn. Dave _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From brunner at nic-naa.net Tue Sep 8 09:41:59 2009 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Tue, 08 Sep 2009 10:41:59 -0400 Subject: Colt outages? Message-ID: <4AA66D37.6090703@nic-naa.net> Anyone have news on this? I understand Colt has fixed London and are working on Dublin, Bruxelles and Geneva... but that's all I have. From tom.pipes at t6mail.com Tue Sep 8 09:57:58 2009 From: tom.pipes at t6mail.com (Tom Pipes) Date: Tue, 8 Sep 2009 09:57:58 -0500 (CDT) Subject: Repeated Blacklisting / IP reputation In-Reply-To: <27247188.263871252421864157.JavaMail.root@zimbra> Message-ID: <148476.263921252421878121.JavaMail.root@zimbra> Greetings, We obtained a direct assigned IP block 69.197.64.0/18 from ARIN in 2008. This block has been cursed (for lack of a better word) since we obtained it. It seems like every customer we have added has had repeated issues with being blacklisted by DUL and the cable carriers. (AOL, AT&T, Charter, etc). I understand there is a process to getting removed, but it seems as if these IPs had been used and abused by the previous owner. We have done our best to ensure these blocks conform to RFC standards, including the proper use of reverse DNS pointers. I can resolve the issue very easily by moving these customers over to our other direct assigned 66.254.192.0/19 block. In the last year I have done this numerous times and have had no further issues with them. My question: Is there some way to clear the reputation of these blocks up, or start over to prevent the amount of time we are spending with each customer troubleshooting unnecessary RBL and reputation blacklisting? I have used every opportunity to use the automated removal links from the SMTP rejections, and worked with the RBL operators directly. Most of what I get are cynical responses and promises that it will be fixed. If there is any question, we perform inbound and outbound scanning of all e-mail, even though we know that this appears to be something more relating to the block itself. Does anyone have any suggestions as to how we can clear this issue up? Comments on or off list welcome. Thanks, --- Tom Pipes T6 Broadband/ Essex Telcom Inc tom.pipes at t6mail.com From setient at gmail.com Tue Sep 8 10:16:33 2009 From: setient at gmail.com (Ronald Cotoni) Date: Tue, 08 Sep 2009 10:16:33 -0500 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <148476.263921252421878121.JavaMail.root@zimbra> References: <148476.263921252421878121.JavaMail.root@zimbra> Message-ID: <4AA67551.3050402@gmail.com> Tom Pipes wrote: > Greetings, > > > We obtained a direct assigned IP block 69.197.64.0/18 from ARIN in 2008. This block has been cursed (for lack of a better word) since we obtained it. It seems like every customer we have added has had repeated issues with being blacklisted by DUL and the cable carriers. (AOL, AT&T, Charter, etc). I understand there is a process to getting removed, but it seems as if these IPs had been used and abused by the previous owner. We have done our best to ensure these blocks conform to RFC standards, including the proper use of reverse DNS pointers. > > I can resolve the issue very easily by moving these customers over to our other direct assigned 66.254.192.0/19 block. In the last year I have done this numerous times and have had no further issues with them. > > My question: Is there some way to clear the reputation of these blocks up, or start over to prevent the amount of time we are spending with each customer troubleshooting unnecessary RBL and reputation blacklisting? > > I have used every opportunity to use the automated removal links from the SMTP rejections, and worked with the RBL operators directly. Most of what I get are cynical responses and promises that it will be fixed. > > If there is any question, we perform inbound and outbound scanning of all e-mail, even though we know that this appears to be something more relating to the block itself. > > Does anyone have any suggestions as to how we can clear this issue up? Comments on or off list welcome. > > Thanks, > > --- > Tom Pipes > T6 Broadband/ > Essex Telcom Inc > tom.pipes at t6mail.com > > > > Unfortunately, there is no real good way to get yourself completely delisted. We are experiencing that with a /18 we got from ARIN recently and it is basically the RBL's not updating or perhaps they are not checking the ownership of the ip's as compared to before. On some RBL's, we have IP addresses that have been listed since before the company I work for even existed. Amazing right? From mksmith at adhost.com Tue Sep 8 10:41:28 2009 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 8 Sep 2009 08:41:28 -0700 Subject: Datacenter recommendations - China and Latin America Message-ID: <17838240D9A5544AAA5FF95F8D52031606AFC270@ad-exh01.adhost.lan> Hello Everyone: Does anyone have any recommendations for data centers in China (PRC) and Latin America? The Latin America site doesn't have to be in any particular country within the region, although facilities with good network connectivity are obviously preferred. Regards, Mike -- Michael K. Smith - CISSP, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From mksmith at adhost.com Tue Sep 8 10:47:55 2009 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 8 Sep 2009 08:47:55 -0700 Subject: Datacenter recommendations - China and Latin America In-Reply-To: <17838240D9A5544AAA5FF95F8D52031606AFC270@ad-exh01.adhost.lan> References: <17838240D9A5544AAA5FF95F8D52031606AFC270@ad-exh01.adhost.lan> Message-ID: <17838240D9A5544AAA5FF95F8D52031606AFC277@ad-exh01.adhost.lan> Sorry to respond to my own message! Given the replies so far I think I should expand China to include Hong Kong. Regards, Mike -- Michael K. Smith - CISSP, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > -----Original Message----- > From: Michael K. Smith - Adhost [mailto:mksmith at adhost.com] > Sent: Tuesday, September 08, 2009 8:41 AM > To: nanog at nanog.org > Subject: Datacenter recommendations - China and Latin America > > Hello Everyone: > > Does anyone have any recommendations for data centers in China (PRC) > and > Latin America? The Latin America site doesn't have to be in any > particular country within the region, although facilities with good > network connectivity are obviously preferred. > > Regards, > > Mike > > -- > Michael K. Smith - CISSP, GISP > Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com > w: +1 (206) 404-9500 f: +1 (206) 404-9050 > PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > > From bbillon-ml at splio.fr Tue Sep 8 11:02:32 2009 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Tue, 08 Sep 2009 18:02:32 +0200 Subject: Datacenter recommendations - China and Latin America In-Reply-To: <17838240D9A5544AAA5FF95F8D52031606AFC277@ad-exh01.adhost.lan> References: <17838240D9A5544AAA5FF95F8D52031606AFC270@ad-exh01.adhost.lan> <17838240D9A5544AAA5FF95F8D52031606AFC277@ad-exh01.adhost.lan> Message-ID: <4AA68018.6000408@splio.fr> For Asia, I'd say Hong Kong (and personnaly Mega iAdvantage). Could be interesting thoughts on this previous thread: http://mailman.nanog.org/pipermail/nanog/2009-July/012161.html Mainland China may be fine for very special needs, but I'd advise to go to HK 95% of the time. Michael K. Smith - Adhost a ?crit : > Sorry to respond to my own message! Given the replies so far I think I > should expand China to include Hong Kong. > > Regards, > > Mike > > -- > Michael K. Smith - CISSP, GISP > Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com > w: +1 (206) 404-9500 f: +1 (206) 404-9050 > PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > > > >> -----Original Message----- >> From: Michael K. Smith - Adhost [mailto:mksmith at adhost.com] >> Sent: Tuesday, September 08, 2009 8:41 AM >> To: nanog at nanog.org >> Subject: Datacenter recommendations - China and Latin America >> >> Hello Everyone: >> >> Does anyone have any recommendations for data centers in China (PRC) >> and >> Latin America? The Latin America site doesn't have to be in any >> particular country within the region, although facilities with good >> network connectivity are obviously preferred. >> >> Regards, >> >> Mike >> >> -- >> Michael K. Smith - CISSP, GISP >> Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com >> w: +1 (206) 404-9500 f: +1 (206) 404-9050 >> PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) >> >> >> > > > From sronan at fattoc.com Tue Sep 8 11:29:14 2009 From: sronan at fattoc.com (Shane Ronan) Date: Tue, 8 Sep 2009 12:29:14 -0400 Subject: Datacenter recommendations - China and Latin America In-Reply-To: <4AA68018.6000408@splio.fr> References: <17838240D9A5544AAA5FF95F8D52031606AFC270@ad-exh01.adhost.lan> <17838240D9A5544AAA5FF95F8D52031606AFC277@ad-exh01.adhost.lan> <4AA68018.6000408@splio.fr> Message-ID: <97A02ABD-D175-4725-BC7C-EA8399A68BE8@fattoc.com> I'd recommend Equinix which has a site in Hong Kong which I would recommend over mainland China. http://www.equinix.com/locations/map/asiapacific/hongkong/ Shane On Sep 8, 2009, at 12:02 PM, Benjamin Billon wrote: > For Asia, I'd say Hong Kong (and personnaly Mega iAdvantage). > > Could be interesting thoughts on this previous thread: http://mailman.nanog.org/pipermail/nanog/2009-July/012161.html > > Mainland China may be fine for very special needs, but I'd advise to > go to HK 95% of the time. > > Michael K. Smith - Adhost a ?crit : >> Sorry to respond to my own message! Given the replies so far I >> think I >> should expand China to include Hong Kong. >> >> Regards, >> >> Mike >> >> -- >> Michael K. Smith - CISSP, GISP >> Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com >> w: +1 (206) 404-9500 f: +1 (206) 404-9050 >> PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) >> >> >> >>> -----Original Message----- >>> From: Michael K. Smith - Adhost [mailto:mksmith at adhost.com] >>> Sent: Tuesday, September 08, 2009 8:41 AM >>> To: nanog at nanog.org >>> Subject: Datacenter recommendations - China and Latin America >>> >>> Hello Everyone: >>> >>> Does anyone have any recommendations for data centers in China (PRC) >>> and >>> Latin America? The Latin America site doesn't have to be in any >>> particular country within the region, although facilities with good >>> network connectivity are obviously preferred. >>> >>> Regards, >>> >>> Mike >>> >>> -- >>> Michael K. Smith - CISSP, GISP >>> Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com >>> w: +1 (206) 404-9500 f: +1 (206) 404-9050 >>> PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) >>> >>> >>> >> >> >> From abalashov at evaristesys.com Tue Sep 8 11:35:01 2009 From: abalashov at evaristesys.com (Alex Balashov) Date: Tue, 08 Sep 2009 12:35:01 -0400 Subject: Datacenter recommendations - China and Latin America In-Reply-To: <97A02ABD-D175-4725-BC7C-EA8399A68BE8@fattoc.com> References: <17838240D9A5544AAA5FF95F8D52031606AFC270@ad-exh01.adhost.lan> <17838240D9A5544AAA5FF95F8D52031606AFC277@ad-exh01.adhost.lan> <4AA68018.6000408@splio.fr> <97A02ABD-D175-4725-BC7C-EA8399A68BE8@fattoc.com> Message-ID: <4AA687B5.3060507@evaristesys.com> Shane Ronan wrote: > I'd recommend Equinix which has a site in Hong Kong which I would > recommend over mainland China. > > http://www.equinix.com/locations/map/asiapacific/hongkong/ What is the Great Firewall relationship between Hong Kong and the mainland PRC, as compared to the mainland PRC vs. the rest of the world? -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 From jcurran at arin.net Tue Sep 8 12:43:39 2009 From: jcurran at arin.net (John Curran) Date: Tue, 8 Sep 2009 13:43:39 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AA67551.3050402@gmail.com> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> Message-ID: Folks - It appears that we have a real operational problem, in that ARIN does indeed reissue space that has been reclaimed/returned after a hold-down period, and but it appears that even once they are removed from the actual source RBL's, there are still ISP's who are manually updating these and hence block traffic much longer than necessary. I'm sure there's an excellent reason why these addresses stay blocked, but am unable to fathom what exactly that is... Could some folks from the appropriate networks explain why this is such a problem and/or suggest additional steps that ARIN or the receipts should be taking to avoid this situation? Thanks! /John John Curran President and CEO ARIN On Sep 8, 2009, at 11:16 AM, Ronald Cotoni wrote: > Tom Pipes wrote: >> Greetings, >> >> We obtained a direct assigned IP block 69.197.64.0/18 from ARIN in >> 2008. This block has been cursed (for lack of a better word) since >> we obtained it. It seems like every customer we have added has had >> repeated issues with being blacklisted by DUL and the cable >> carriers. (AOL, AT&T, Charter, etc). I understand there is a >> process to getting removed, but it seems as if these IPs had been >> used and abused by the previous owner. We have done our best to >> ensure these blocks conform to RFC standards, including the proper >> use of reverse DNS pointers. >> >> I can resolve the issue very easily by moving these customers over >> to our other direct assigned 66.254.192.0/19 block. In the last >> year I have done this numerous times and have had no further issues >> with them. >> >> My question: Is there some way to clear the reputation of these >> blocks up, or start over to prevent the amount of time we are >> spending with each customer troubleshooting unnecessary RBL and >> reputation blacklisting? >> I have used every opportunity to use the automated removal links >> from the SMTP rejections, and worked with the RBL operators >> directly. Most of what I get are cynical responses and promises >> that it will be fixed. >> If there is any question, we perform inbound and outbound scanning >> of all e-mail, even though we know that this appears to be >> something more relating to the block itself. >> >> Does anyone have any suggestions as to how we can clear this issue >> up? Comments on or off list welcome. >> >> Thanks, >> >> --- Tom Pipes T6 Broadband/ Essex Telcom Inc tom.pipes at t6mail.com >> >> > Unfortunately, there is no real good way to get yourself completely > delisted. We are experiencing that with a /18 we got from ARIN > recently and it is basically the RBL's not updating or perhaps they > are not checking the ownership of the ip's as compared to before. > On some RBL's, we have IP addresses that have been listed since > before the company I work for even existed. Amazing right? > From ops.lists at gmail.com Tue Sep 8 12:53:38 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 8 Sep 2009 23:23:38 +0530 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> Message-ID: John, its about the same situation you get when people use manually updated bogon filters. A much larger problem, I must admit .. having ISPs follow the maawg best practices might help, that - and attending MAAWG sessions (www.maawg.org -> Published Documents) That said most of the larger players already attend MAAWG - that leaves rural ISPs, small universities, corporate mailservers etc etc that dont have full time postmasters, and where you're more likely to run into this issue. If you see actual large carriers with outdated blocklist entries after they're removed from (say) the spamhaus pbl, then maybe MAAWG needs to come to nanog / arin meetings .. plenty of maawg types attend those that all that needs to be done is to free up a presentation slot or two. --srs On Tue, Sep 8, 2009 at 11:13 PM, John Curran wrote: > Folks - > > ? It appears that we have a real operational problem, in that ARIN > ? does indeed reissue space that has been reclaimed/returned after > ? a hold-down period, and but it appears that even once they are > ? removed from the actual source RBL's, there are still ISP's who > ? are manually updating these and hence block traffic much longer > ? than necessary. > > ? I'm sure there's an excellent reason why these addresses stay > ? blocked, but am unable to fathom what exactly that is... > ? Could some folks from the appropriate networks explain why > ? this is such a problem and/or suggest additional steps that > ? ARIN or the receipts should be taking to avoid this situation? > > Thanks! > /John > > John Curran > President and CEO > ARIN > > On Sep 8, 2009, at 11:16 AM, Ronald Cotoni wrote: > >> Tom Pipes wrote: >>> Greetings, >>> >>> We obtained a direct assigned IP block 69.197.64.0/18 from ARIN in >>> 2008. This block has been cursed (for lack of a better word) since >>> we obtained it. ?It seems like every customer we have added has had >>> repeated issues with being blacklisted by DUL and the cable >>> carriers. (AOL, AT&T, Charter, etc). ?I understand there is a >>> process to getting removed, but it seems as if these IPs had been >>> used and abused by the previous owner. ?We have done our best to >>> ensure these blocks conform to RFC standards, including the proper >>> use of reverse DNS pointers. >>> >>> I can resolve the issue very easily by moving these customers over >>> to our other direct assigned 66.254.192.0/19 block. ?In the last >>> year I have done this numerous times and have had no further issues >>> with them. >>> >>> My question: ?Is there some way to clear the reputation of these >>> blocks up, or start over to prevent the amount of time we are >>> spending with each customer troubleshooting unnecessary RBL and >>> reputation blacklisting? >>> I have used every opportunity to use the automated removal links >>> from the SMTP rejections, and worked with the RBL operators >>> directly. ?Most of what I get are cynical responses and promises >>> that it will be fixed. >>> If there is any question, we perform inbound and outbound scanning >>> of all e-mail, even though we know that this appears to be >>> something more relating to the block itself. >>> >>> Does anyone have any suggestions as to how we can clear this issue >>> up? ?Comments on or off list welcome. >>> >>> Thanks, >>> >>> --- Tom Pipes T6 Broadband/ Essex Telcom Inc tom.pipes at t6mail.com >>> >>> >> Unfortunately, there is no real good way to get yourself completely >> delisted. ?We are experiencing that with a /18 we got from ARIN >> recently and it is basically the RBL's not updating or perhaps they >> are not checking the ownership of the ip's as compared to before. >> On some RBL's, we have IP addresses that have been listed since >> before the company I work for even existed. ?Amazing right? >> > > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From jason at i6ix.com Tue Sep 8 12:59:59 2009 From: jason at i6ix.com (Jason Bertoch) Date: Tue, 08 Sep 2009 13:59:59 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> Message-ID: <4AA69B9F.1000500@i6ix.com> Suresh Ramasubramanian wrote: > That said most of the larger players already attend MAAWG - that > leaves rural ISPs, small universities, corporate mailservers etc etc > that dont have full time postmasters, and where you're more likely to > run into this issue. > I've found the opposite to hold true more often. Smaller organizations can use public blacklists for free, due to their low volume, and so have little incentive to run their own local blacklist. I've typically seen the larger organizations run their own blacklists and are much more difficult to contact for removal. From ops.lists at gmail.com Tue Sep 8 13:02:57 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 8 Sep 2009 23:32:57 +0530 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AA69B9F.1000500@i6ix.com> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <4AA69B9F.1000500@i6ix.com> Message-ID: MAAWG's changing that - and most of the large ISPs are maawg members. Things can get better, sure ... --srs On Tue, Sep 8, 2009 at 11:29 PM, Jason Bertoch wrote: > Suresh Ramasubramanian wrote: >> >> That said most of the larger players already attend MAAWG - that >> leaves rural ISPs, small universities, corporate mailservers etc etc >> that dont have full time postmasters, and where you're more likely to >> run into this issue. >> > > I've found the opposite to hold true more often. ?Smaller organizations can > use public blacklists for free, due to their low volume, and so have little > incentive to run their own local blacklist. ?I've typically seen the larger > organizations run their own blacklists and are much more difficult to > contact for removal. > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From tvest at eyeconomics.com Tue Sep 8 13:07:06 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Tue, 8 Sep 2009 14:07:06 -0400 Subject: Datacenter recommendations - China and Latin America In-Reply-To: <4AA687B5.3060507@evaristesys.com> References: <17838240D9A5544AAA5FF95F8D52031606AFC270@ad-exh01.adhost.lan> <17838240D9A5544AAA5FF95F8D52031606AFC277@ad-exh01.adhost.lan> <4AA68018.6000408@splio.fr> <97A02ABD-D175-4725-BC7C-EA8399A68BE8@fattoc.com> <4AA687B5.3060507@evaristesys.com> Message-ID: <17039594-994E-4B5A-8DCA-EBD50B0B47B8@eyeconomics.com> On Sep 8, 2009, at 12:35 PM, Alex Balashov wrote: > Shane Ronan wrote: > >> I'd recommend Equinix which has a site in Hong Kong which I would >> recommend over mainland China. >> http://www.equinix.com/locations/map/asiapacific/hongkong/ > > What is the Great Firewall relationship between Hong Kong and the > mainland PRC, as compared to the mainland PRC vs. the rest of the > world? Broadly speaking, the relationships are identical -- otherwise many/ most things that are currently in China would be in HK. TV > > -- > Alex Balashov - Principal > Evariste Systems > Web : http://www.evaristesys.com/ > Tel : (+1) (678) 954-0670 > Direct : (+1) (678) 954-0671 > From sethm at rollernet.us Tue Sep 8 13:07:14 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 08 Sep 2009 11:07:14 -0700 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> Message-ID: <4AA69D52.3060105@rollernet.us> Suresh Ramasubramanian wrote: > John, its about the same situation you get when people use manually > updated bogon filters. > > A much larger problem, I must admit .. having ISPs follow the maawg > best practices might help, that - and attending MAAWG sessions > (www.maawg.org -> Published Documents) > > That said most of the larger players already attend MAAWG - that > leaves rural ISPs, small universities, corporate mailservers etc etc > that dont have full time postmasters, and where you're more likely to > run into this issue. > I was always under the impression that smaller orgs were not allowed to join the MAAWG club. ~Seth From jay at west.net Tue Sep 8 13:13:51 2009 From: jay at west.net (Jay Hennigan) Date: Tue, 08 Sep 2009 11:13:51 -0700 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> Message-ID: <4AA69EDF.7040703@west.net> John Curran wrote: > Folks - > > It appears that we have a real operational problem, in that ARIN > does indeed reissue space that has been reclaimed/returned after > a hold-down period, and but it appears that even once they are > removed from the actual source RBL's, there are still ISP's who > are manually updating these and hence block traffic much longer > than necessary. > > I'm sure there's an excellent reason why these addresses stay > blocked, but am unable to fathom what exactly that is... > Could some folks from the appropriate networks explain why > this is such a problem and/or suggest additional steps that > ARIN or the receipts should be taking to avoid this situation? I don't think there is an excellent reason, more likely inertia and no real incentive to put forth the effort to proactively remove addresses. Many ISPs and organizations have their own private blocklists not associated with the widely known DNSBLs. Typically during or immediately after a spam run the mail administrator will manually add offending addresses or netblocks. Spamtrap hits may do this automatically. There isn't any real incentive for people to go back and remove addresses unless they're notified by their own customers that legitimate mail coming from those addresses is being blocked. Because these blocklists are individually maintained, there is no central registry or means to "clean them up" when an IP assignment changes. To make matters worse, some organizations may simply ACL the IP space so that the TCP connection is never made in the first place (bad, looks like a network problem rather than deliberate filtering), some may drop it during SMTP with no clear indication as to the reason (less bad, as there is at least a hint that it could be filtering), and some may actually accept the mail and then silently discard it (worst). In addition there are several DNSBLs with different policies regarding delisting. Some just time out after a period of time since abuse was detected. Some require action in the form of a delisting request. Some require a delisting request and a time period with no abuse. Some (the old SPEWS list) may not be easily reached or have well defined policies. In meatspace, once a neighborhood winds up with a reputation of being rife with drive-by shootings, gang activity and drug dealing it may take a long time after the last of the graffiti is gone before some cab drivers will go there. -- 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 jlewis at lewis.org Tue Sep 8 13:19:40 2009 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 8 Sep 2009 14:19:40 -0400 (EDT) Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> Message-ID: On Tue, 8 Sep 2009, John Curran wrote: > I'm sure there's an excellent reason why these addresses stay > blocked, but am unable to fathom what exactly that is... > Could some folks from the appropriate networks explain why > this is such a problem and/or suggest additional steps that > ARIN or the receipts should be taking to avoid this situation? Most small to midsize networks probably have a "block it and forget it" policy. The facts that the spammer moved on, the IPs eventually got returned to the RIR and reallocated to a different network go unnoticed until the new LIR/ISP notifies those blocking the addresses that the addresses have changed hands. Ideally, the network doing the blocking will know when they started blocking an IP, look at whois, and agree that the block no longer makes sense. I'm sure some will have no idea when or why they started blocking an IP, and might be reluctant to unblock it. This assumes you can actually get in touch with someone with the access and understanding of the issues to have a conversation about their blocking. Some networks make that nearly impossible. I ran into such situations early on when trying to contact networks about their outdated bogon filters when Atlantic.net got a slice of 69/8. This blocking (or variations of it) has been a problem for about a decade. http://www.michnet.net/mail.archives/nanog/2001-08/msg00448.html I don't think there is any blanket solution to this issue. Too many of the networks doing the blocking likely don't participate in any forum where the RIRs will be reach people who care and can do something. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From chort at smtps.net Tue Sep 8 13:33:43 2009 From: chort at smtps.net (Brian Keefer) Date: Tue, 8 Sep 2009 11:33:43 -0700 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AA69EDF.7040703@west.net> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <4AA69EDF.7040703@west.net> Message-ID: <10C91143-1452-4454-BFEB-7F901B240CCE@smtps.net> On Sep 8, 2009, at 11:13 AM, Jay Hennigan wrote: > John Curran wrote: >> I'm sure there's an excellent reason why these addresses stay >> blocked, but am unable to fathom what exactly that is... >> Could some folks from the appropriate networks explain why >> this is such a problem and/or suggest additional steps that >> ARIN or the receipts should be taking to avoid this situation? > > I don't think there is an excellent reason, more likely inertia and > no real incentive to put forth the effort to proactively remove > addresses. > > > In addition there are several DNSBLs with different policies > regarding delisting. Some just time out after a period of time > since abuse was detected. Some require action in the form of a > delisting request. Some require a delisting request and a time > period with no abuse. Some (the old SPEWS list) may not be easily > reached or have well defined policies. > > In meatspace, once a neighborhood winds up with a reputation of > being rife with drive-by shootings, gang activity and drug dealing > it may take a long time after the last of the graffiti is gone > before some cab drivers will go there. > > -- > Jay Hennigan - CCIE #7880 > I think this most accurately reflects the reality I see dealing with mostly enterprises and mid-to-large xSPs. A lot of mid-range enterprises out there have legacy "free" (often meaning "subscriptions aren't enforced") DNSBLs in place that were configured years ago as a desperate attempt to reduce e-mail load, before there were well-maintained alternatives. The problem is that these services usually don't have the resources to put a lot of advanced automation and sophisticated logic into place, so delisting is a huge hassle (and some times resembles extortion). There are some quality "free" services, such as Spamhaus (speaking personally), but they're few and far between. I've had better luck convincing customers (or customers of customers) to stop using the poorly-maintained legacy DNSBLs than I've had getting customers delisted from such services. YMMV. Brian Keefer Sr. Solutions Architect "Defend email. Protect data." From Valdis.Kletnieks at vt.edu Tue Sep 8 13:39:56 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 08 Sep 2009 14:39:56 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: Your message of "Tue, 08 Sep 2009 13:43:39 EDT." References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> Message-ID: <19276.1252435196@turing-police.cc.vt.edu> On Tue, 08 Sep 2009 13:43:39 EDT, John Curran said: > I'm sure there's an excellent reason why these addresses stay > blocked, but am unable to fathom what exactly that is... If I'm a smaller shop with limited clue, there's 3 likely colloraries: 1) Even a smallish spam blast is big enough to cause me operational difficulties, so I'm tempted to throw in a block to "fix" it. 2) Once the spammers have moved on, it's unlikely that I have enough customers trying to reach the blocked address space and complaining for me to fix it, and the people *in* that address space can't successfully complain because I've blocked it. 3) The damage to traffic is of consequence to the remote site, but isn't a revenue-impacting issue for *ME*. The third point is the biggie here. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From web at typo.org Tue Sep 8 13:44:44 2009 From: web at typo.org (Wayne E. Bouchard) Date: Tue, 8 Sep 2009 11:44:44 -0700 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AA67551.3050402@gmail.com> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> Message-ID: <20090908184444.GA68989@typo.org> On Tue, Sep 08, 2009 at 10:16:33AM -0500, Ronald Cotoni wrote: > Tom Pipes wrote: > >Greetings, > > > > > >We obtained a direct assigned IP block 69.197.64.0/18 from ARIN in 2008. > >This block has been cursed (for lack of a better word) since we obtained > >it. It seems like every customer we have added has had repeated issues > >with being blacklisted by DUL and the cable carriers. (AOL, AT&T, Charter, > >etc). I understand there is a process to getting removed, but it seems as > >if these IPs had been used and abused by the previous owner. We have done > >our best to ensure these blocks conform to RFC standards, including the > >proper use of reverse DNS pointers. > > > >I can resolve the issue very easily by moving these customers over to our > >other direct assigned 66.254.192.0/19 block. In the last year I have done > >this numerous times and have had no further issues with them. > > > >My question: Is there some way to clear the reputation of these blocks > >up, or start over to prevent the amount of time we are spending with each > >customer troubleshooting unnecessary RBL and reputation blacklisting? > >I have used every opportunity to use the automated removal links from the > >SMTP rejections, and worked with the RBL operators directly. Most of what > >I get are cynical responses and promises that it will be fixed. > >If there is any question, we perform inbound and outbound scanning of all > >e-mail, even though we know that this appears to be something more > >relating to the block itself. > > > >Does anyone have any suggestions as to how we can clear this issue up? > >Comments on or off list welcome. > > > >Thanks, > > > >--- > >Tom Pipes > >T6 Broadband/ > >Essex Telcom Inc > >tom.pipes at t6mail.com > > > > > > > > > Unfortunately, there is no real good way to get yourself completely > delisted. We are experiencing that with a /18 we got from ARIN recently > and it is basically the RBL's not updating or perhaps they are not > checking the ownership of the ip's as compared to before. On some > RBL's, we have IP addresses that have been listed since before the > company I work for even existed. Amazing right? This is not actually a new problem. ISPs have been fighting this for some time. When a dud customer spams from a given IP range and gets it placed in various RBLs, when that customer is booted or otherwise removed, that block will probably get reissued. The new customer then calls up and says, "my email isn't getting through." All it takes is a little investigation and the cause becomes clear. In my experience, there is absolutely no way to deal with this other than contacting the companies your customer is trying to email one by one. Not all of them will respond to you but when they are slow or do not act at all, quite often if the recipient on the other end calls them up and says, "WTF?" it generates more action. Sadly, I do not foresee this problem getting any easier. Best practices for the public or subscription RBLs should be to place a TTL on the entry of no more than, say, 90 days or thereabouts. Best practices for manual entry should be to either keep a list of what and when or periodically to simply blow the whole list away and start anew to get rid of stale entries. Of course, that is probably an unreal expectation. -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From jgreco at ns.sol.net Tue Sep 8 13:52:35 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 8 Sep 2009 13:52:35 -0500 (CDT) Subject: Repeated Blacklisting / IP reputation In-Reply-To: from "Jon Lewis" at Sep 08, 2009 02:19:40 PM Message-ID: <200909081852.n88IqZ2g090979@aurora.sol.net> > On Tue, 8 Sep 2009, John Curran wrote: > > I'm sure there's an excellent reason why these addresses stay > > blocked, but am unable to fathom what exactly that is... > > Could some folks from the appropriate networks explain why > > this is such a problem and/or suggest additional steps that > > ARIN or the receipts should be taking to avoid this situation? > > Most small to midsize networks probably have a "block it and forget it" > policy. The facts that the spammer moved on, the IPs eventually got > returned to the RIR and reallocated to a different network go unnoticed > until the new LIR/ISP notifies those blocking the addresses that the > addresses have changed hands. Ideally, the network doing the blocking > will know when they started blocking an IP, look at whois, and agree that > the block no longer makes sense. I'm sure some will have no idea when or > why they started blocking an IP, and might be reluctant to unblock it. > This assumes you can actually get in touch with someone with the access > and understanding of the issues to have a conversation about their > blocking. Some networks make that nearly impossible. I ran into such > situations early on when trying to contact networks about their outdated > bogon filters when Atlantic.net got a slice of 69/8. > > This blocking (or variations of it) has been a problem for about a decade. > > http://www.michnet.net/mail.archives/nanog/2001-08/msg00448.html > > I don't think there is any blanket solution to this issue. Too many of > the networks doing the blocking likely don't participate in any forum > where the RIRs will be reach people who care and can do something. It should be pretty clear that reused IP space is going to represent a problem. There is no mechanism for "LIR/ISP notif[cation to] those blocking the addresses that the addresses have changed hands." Even if there were, this would be subject to potential gaming by spammers, such as SWIP of a block to SpammerXCo, followed by an automatic unblock when the "ISP" unSWIP's it and SWIP's it to "EmailBlasterB" - of course, the same company. How do we manage this into the future? IPv6 shows some promise in terms of delegation of larger spaces, which could in turn suggest that reuse policies that discourage rapid reuse would be a best practice. However, that is more or less just acknowledging the status quo; networks are likely to continue blocking for various reasons and for random periods. A remote site being unable to communicate with us is not particularly important except to the extent that it ends up distressing users here; however, for larger sites, the blocked list could end up being significant. It seems like it *could* be useful to have a system to notify of network delegation changes, but it also seems like if this was particularly important to anyone, then someone would have found a trivial way to implement at least a poor man's version of it. For example, record the ASN of a blocked IP address and remove the block when the ASN changes... ... 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 jlewis at lewis.org Tue Sep 8 14:01:57 2009 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 8 Sep 2009 15:01:57 -0400 (EDT) Subject: Repeated Blacklisting / IP reputation In-Reply-To: <200909081852.n88IqZ2g090979@aurora.sol.net> References: <200909081852.n88IqZ2g090979@aurora.sol.net> Message-ID: On Tue, 8 Sep 2009, Joe Greco wrote: > It seems like it *could* be useful to have a system to notify of network > delegation changes, but it also seems like if this was particularly > important to anyone, then someone would have found a trivial way to > implement at least a poor man's version of it. For example, record > the ASN of a blocked IP address and remove the block when the ASN > changes... That too, would be easily gamed by spammers. Just get multiple ASN's and bounce your dirty IPs around between them to clean them. The IP space being a direct (RIR->LIR) allocation having been made after the blocking was initiated is a pretty clear sign that the space has actually changed hands, and seems like it would be fairly difficult (if at all possible) to game. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From sthaug at nethelp.no Tue Sep 8 14:04:45 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 08 Sep 2009 21:04:45 +0200 (CEST) Subject: Network Ring In-Reply-To: <4AA64018.7080006@justinshore.com> References: <20090907.095151.74706289.sthaug@nethelp.no> <1E8B940C5E21014AB8BE70B975D40EDB0162881C@bert.HiberniaAtlantic.local> <4AA64018.7080006@justinshore.com> Message-ID: <20090908.210445.74736190.sthaug@nethelp.no> > Rod Beck wrote: > > What is EAPS? > > A joke of a "standard" and something to be avoided at all costs. I > would echo the last part about Extreme switches too. Disagree. I don't believe anybody would claim EAPS is a "standard" just because an RFC has been published. In any case, EAPS is working quite well for us, with rapid L2 rerouting in ring based structures. And *much* simpler than RSTP/MST. Or VPLS, for that matter. As for Extreme switches - they have their strengths and weaknesses, just like any other product. We use lots of Summit X450/X450a, for L2 only, and have been generally reasonably happy with them. If I could buy a similarly featured product from Cisco, for a similar price, I might well choose Cisco. But at least in our case Cisco *doesn't* have a competitive product (case in point: ME3400 - too few ports, too few MAC addresses, funky licensing even if you just want to do simple QinQ). Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jlewis at lewis.org Tue Sep 8 14:08:38 2009 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 8 Sep 2009 15:08:38 -0400 (EDT) Subject: Repeated Blacklisting / IP reputation In-Reply-To: <20090908184444.GA68989@typo.org> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <20090908184444.GA68989@typo.org> Message-ID: On Tue, 8 Sep 2009, Wayne E. Bouchard wrote: > This is not actually a new problem. ISPs have been fighting this for > some time. When a dud customer spams from a given IP range and gets it > placed in various RBLs, when that customer is booted or otherwise > removed, that block will probably get reissued. The new customer then > calls up and says, "my email isn't getting through." All it takes is a The difference/issue here is that it's easy for you when turning down or turning up a customer to check the IP space being revoked/assigned in the various popular public DNSBLs, sparing your customers the headache of being assigned blacklisted IPs. Until your next customer starts using the space and can't send us email, you have no way of knowing that we null routed the subnet on our MX cluster. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jay at west.net Tue Sep 8 14:08:40 2009 From: jay at west.net (Jay Hennigan) Date: Tue, 08 Sep 2009 12:08:40 -0700 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AA69D52.3060105@rollernet.us> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <4AA69D52.3060105@rollernet.us> Message-ID: <4AA6ABB8.9000505@west.net> Seth Mattinen wrote: > I was always under the impression that smaller orgs were not allowed to > join the MAAWG club. They're allowed. At $4k/year minimum, up to $25K/year. By the way, among the members... Experian CheetahMail ExactTarget, Inc Responsys, Inc. Vertical Response, Inc Yesmail -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From jgreco at ns.sol.net Tue Sep 8 14:16:31 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 8 Sep 2009 14:16:31 -0500 (CDT) Subject: Repeated Blacklisting / IP reputation In-Reply-To: from "Jon Lewis" at Sep 08, 2009 03:01:57 PM Message-ID: <200909081916.n88JGVWR092502@aurora.sol.net> > On Tue, 8 Sep 2009, Joe Greco wrote: > > It seems like it *could* be useful to have a system to notify of network > > delegation changes, but it also seems like if this was particularly > > important to anyone, then someone would have found a trivial way to > > implement at least a poor man's version of it. For example, record > > the ASN of a blocked IP address and remove the block when the ASN > > changes... > > That too, would be easily gamed by spammers. Just get multiple ASN's and > bounce your dirty IPs around between them to clean them. The IP space > being a direct (RIR->LIR) allocation having been made after the blocking > was initiated is a pretty clear sign that the space has actually changed > hands, and seems like it would be fairly difficult (if at all possible) to > game. Right, but they'll only do that if they're aware of such a system and it is significant enough to make a dent in them. Further, it would be a mistake to assume that *just* changing ASN's would be sufficient. The act of changing ASN's could act as a trigger to re-whois ARIN for an update of ownership, for example. The fact is that the information to trigger a re-query of ownership upon a redelegation sort-of already exists, though it is clearly imperfect. My point was that if it was actually useful to "notice" when an IP delegation moved, someone would already have made up a system to do this somehow. So my best guess is that there isn't a really strong incentive to pursue some sort of notification system, because you could pretty much do it as it stands. ... 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 bmanning at vacation.karoshi.com Tue Sep 8 14:15:10 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 8 Sep 2009 19:15:10 +0000 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> Message-ID: <20090908191510.GB31380@vacation.karoshi.com.> there is a fundamental disconnect here. the IP space is neutral. it has no bias toward or against social behaviours. its a tool. the actual/real target here are the people who are using these tools to be antisocial. blacklisting IP space is always reactive and should only beused in emergency and as a -TEMPORARY- expedient. IMHO of course., YMMV. --bill On Tue, Sep 08, 2009 at 01:43:39PM -0400, John Curran wrote: > Folks - > > It appears that we have a real operational problem, in that ARIN > does indeed reissue space that has been reclaimed/returned after > a hold-down period, and but it appears that even once they are > removed from the actual source RBL's, there are still ISP's who > are manually updating these and hence block traffic much longer > than necessary. > > I'm sure there's an excellent reason why these addresses stay > blocked, but am unable to fathom what exactly that is... > Could some folks from the appropriate networks explain why > this is such a problem and/or suggest additional steps that > ARIN or the receipts should be taking to avoid this situation? > > Thanks! > /John > > John Curran > President and CEO > ARIN > > On Sep 8, 2009, at 11:16 AM, Ronald Cotoni wrote: > > > Tom Pipes wrote: > >> Greetings, > >> > >> We obtained a direct assigned IP block 69.197.64.0/18 from ARIN in > >> 2008. This block has been cursed (for lack of a better word) since > >> we obtained it. It seems like every customer we have added has had > >> repeated issues with being blacklisted by DUL and the cable > >> carriers. (AOL, AT&T, Charter, etc). I understand there is a > >> process to getting removed, but it seems as if these IPs had been > >> used and abused by the previous owner. We have done our best to > >> ensure these blocks conform to RFC standards, including the proper > >> use of reverse DNS pointers. > >> > >> I can resolve the issue very easily by moving these customers over > >> to our other direct assigned 66.254.192.0/19 block. In the last > >> year I have done this numerous times and have had no further issues > >> with them. > >> > >> My question: Is there some way to clear the reputation of these > >> blocks up, or start over to prevent the amount of time we are > >> spending with each customer troubleshooting unnecessary RBL and > >> reputation blacklisting? > >> I have used every opportunity to use the automated removal links > >> from the SMTP rejections, and worked with the RBL operators > >> directly. Most of what I get are cynical responses and promises > >> that it will be fixed. > >> If there is any question, we perform inbound and outbound scanning > >> of all e-mail, even though we know that this appears to be > >> something more relating to the block itself. > >> > >> Does anyone have any suggestions as to how we can clear this issue > >> up? Comments on or off list welcome. > >> > >> Thanks, > >> > >> --- Tom Pipes T6 Broadband/ Essex Telcom Inc tom.pipes at t6mail.com > >> > >> > > Unfortunately, there is no real good way to get yourself completely > > delisted. We are experiencing that with a /18 we got from ARIN > > recently and it is basically the RBL's not updating or perhaps they > > are not checking the ownership of the ip's as compared to before. > > On some RBL's, we have IP addresses that have been listed since > > before the company I work for even existed. Amazing right? > > > > From jcdill.lists at gmail.com Tue Sep 8 14:21:34 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Tue, 08 Sep 2009 12:21:34 -0700 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <4AA69FF9.6090407@gmail.com> Message-ID: <4AA6AEBE.1000000@gmail.com> John Curran wrote: > On Sep 8, 2009, at 2:18 PM, JC Dill wrote: > > > It seems simple and obvious that ARIN, RIPE, et. al. should > > determine the blacklist state of a reclaimed IP group and ensure > > that the IP group is usable before re-allocating it. > > > > When IPs are reclaimed, first check to see if the reclaimed IPs are > > on any readily checked RBL or private blacklist of major ISPs, > > corporations, universities, etc. If so, work with those groups to > > get the blocks removed *prior* to reissuing the IPs to a new > > entity. Before releasing the IPs to a new entity, double check that > > they are not being blocked (that any promises to remove them from > > a blacklist were actually fulfilled). Hold the IPs until you have > > determined that they aren't overly encumbered with prior blacklist > > blocks due to poor behavior of the previous entity. (The same > > should be done before allocating out of a new IP block, such as > > when you release the first set of IPs in a new /8.) > > In this case, it's not the RBL's that are the issue; the address > block in question isn't on them. It's the ISP's and other firms > using manual copies rather than actually following best practices. It's not that hard to make a list of the major ISPs, corporations, universities (entities with a large number of users), find willing contacts inside each organization (individual or role addresses you can email, and see if the email bounces, and who will reply if the email is received) and run some automated tests to see if the IPs are being blocked. In your follow-up email to me, you said you check "dozens" of RBLs - that is clearly insufficient - probably by an order of magnitude - of the entities you should check with. The number should be "hundreds". A reasonably cluefull intern can provide you with a suitable list in short order, probably less than 1 day, and find suitable contacts inside each organization in a similar time frame - it might take a week total to build a list of ~500 entities and associated email addresses. Because of employee turn-over the list will need to be updated, ~1-10 old addresses purged and replaced with new ones on a monthly basis. > > Why isn't this being done now? > > > > Issuing reclaimed IPs is a lot like selling a used car, except that > > the buyer has no way to "examine" the state of the IPs you will > > issue them beforehand. Therefore it's up to you (ARIN, RIPE, et. > > al.) to ensure that they are "just as good" as any other IP block. > > It is shoddy business to take someone's money and then sneakily > > give them tainted (used) goods and expect them to deal with > > cleaning up the mess that the prior owner made, especially when you > > charge the same rate for untainted goods! > > Not applicable in this case, as noted above. What do you mean, "not applicable"? You take the money and issue IPs. There is no way for the "buyer" to know before hand if the IPs are "tainted" (used) or new. It is up to you (ARIN) to ensure that the goods (IPs) are suitable for the intended use. My analogy is entirely applicable, and I'm amazed you think otherwise. > So, back to the question: could someone explain why they've got > copies of the RBL's in their network which don't get updated on any > reasonable refresh interval? (weekly? monthly?) The "why" really isn't at issue - it happens and it's going to keep happening. The question is what are you (ARIN) going to do about it? Give me the serenity to accept the things I cannot change, The courage to change the things I can, And the wisdom to know the difference. You (ARIN et. al.) don't have any ability to change the why. What you can change is how you go about determining if an IP block is suitable for reallocation or not, and what steps you take to repair IP blocks that aren't suitable for reallocation. jc - posted to NANOG since John indicated that he thought his reply to me was going to NANOG as well. From jgreco at ns.sol.net Tue Sep 8 14:34:10 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 8 Sep 2009 14:34:10 -0500 (CDT) Subject: Repeated Blacklisting / IP reputation In-Reply-To: <20090908191510.GB31380@vacation.karoshi.com.> from "bmanning@vacation.karoshi.com" at Sep 08, 2009 07:15:10 PM Message-ID: <200909081934.n88JYAS9093038@aurora.sol.net> > there is a fundamental disconnect here. the IP space is neutral. > it has no bias toward or against social behaviours. its a tool. > the actual/real target here are the people who are using these tools > to be antisocial. blacklisting IP space is always reactive and > should only beused in emergency and as a -TEMPORARY- expedient. > > IMHO of course., YMMV. Show me ONE major MTA which allows you to configure an expiration for an ACL entry. The problem with your opinion, and it's a fine opinion, and it's even a good opinion, is that it has very little relationship to the tools which are given to people in order to accomplish blocking. Kind of the question I was contemplating in my other message of minutes ago. If people were given an option to "block this IP for 30 minutes, 24 hours, 30 days, 12 months, 5 years, or forever" - I wonder how many people would just shrug and click "forever." This may lead to the discovery of another fundamental disconnect - or two. Sigh. ... 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 bmanning at vacation.karoshi.com Tue Sep 8 14:44:32 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 8 Sep 2009 19:44:32 +0000 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <200909081934.n88JYAS9093038@aurora.sol.net> References: <20090908191510.GB31380@vacation.karoshi.com.> <200909081934.n88JYAS9093038@aurora.sol.net> Message-ID: <20090908194432.GE31380@vacation.karoshi.com.> On Tue, Sep 08, 2009 at 02:34:10PM -0500, Joe Greco wrote: > > there is a fundamental disconnect here. the IP space is neutral. > > it has no bias toward or against social behaviours. its a tool. > > the actual/real target here are the people who are using these tools > > to be antisocial. blacklisting IP space is always reactive and > > should only beused in emergency and as a -TEMPORARY- expedient. > > > > IMHO of course., YMMV. > > Show me ONE major MTA which allows you to configure an expiration for > an ACL entry. call me old skool... VI works a treat and I'm told there is this thing called emacs ... but i remain dubious. > > The problem with your opinion, and it's a fine opinion, and it's even a > good opinion, is that it has very little relationship to the tools which > are given to people in order to accomplish blocking. Kind of the question > I was contemplating in my other message of minutes ago. if all you have is a hammer... folks need better tools. > If people were given an option to "block this IP for 30 minutes, 24 hours, > 30 days, 12 months, 5 years, or forever" - I wonder how many people would > just shrug and click "forever." which is their choice. please show me the mandate for accepting routes/packets from any/everywhere? me, i'd want the option to "block 192.0.2.0/24 as long as it is announced by AS 0 and the whois data points to RIAA as the registered contact" e.g. not just a temporal block. or - if traffic from 192.0.2.80 increases more than 65% in a 150 second interval, block the IP for 27 minutes. or - allow any/all traffic from 192.0.2.42 - regardless of the blocking on 192.0.2.0/24 the mind boggles. > This may lead to the discovery of another fundamental disconnect - or two. such is the course of human nature. > > Sigh. > > ... 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 justin at justinshore.com Tue Sep 8 14:48:03 2009 From: justin at justinshore.com (Justin Shore) Date: Tue, 08 Sep 2009 14:48:03 -0500 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AA69B9F.1000500@i6ix.com> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <4AA69B9F.1000500@i6ix.com> Message-ID: <4AA6B4F3.100@justinshore.com> Jason Bertoch wrote: > Suresh Ramasubramanian wrote: >> That said most of the larger players already attend MAAWG - that >> leaves rural ISPs, small universities, corporate mailservers etc etc >> that dont have full time postmasters, and where you're more likely to >> run into this issue. >> > I've found the opposite to hold true more often. Smaller organizations > can use public blacklists for free, due to their low volume, and so have > little incentive to run their own local blacklist. I've typically seen > the larger organizations run their own blacklists and are much more > difficult to contact for removal. Take for example GoDaddy's hosted email service. They are using a local, outdated copy of SORBS that has one of my personal servers listed in it. It was an open proxy for about week nearly 3 years ago and still they have it listed. The upside is that I've demonstrated GoDaddy's email incompetence to potential customers and gotten them to switch to our own mail services. Their loss, my gain. Justin From jgreco at ns.sol.net Tue Sep 8 14:50:02 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 8 Sep 2009 14:50:02 -0500 (CDT) Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AA6AEBE.1000000@gmail.com> from "JC Dill" at Sep 08, 2009 12:21:34 PM Message-ID: <200909081950.n88Jo2Dl094175@aurora.sol.net> > John Curran wrote: > > On Sep 8, 2009, at 2:18 PM, JC Dill wrote: > > > > > It seems simple and obvious that ARIN, RIPE, et. al. should > > > determine the blacklist state of a reclaimed IP group and ensure > > > that the IP group is usable before re-allocating it. > > > > > > When IPs are reclaimed, first check to see if the reclaimed IPs are > > > on any readily checked RBL or private blacklist of major ISPs, > > > corporations, universities, etc. If so, work with those groups to > > > get the blocks removed *prior* to reissuing the IPs to a new > > > entity. Before releasing the IPs to a new entity, double check that > > > they are not being blocked (that any promises to remove them from > > > a blacklist were actually fulfilled). Hold the IPs until you have > > > determined that they aren't overly encumbered with prior blacklist > > > blocks due to poor behavior of the previous entity. (The same > > > should be done before allocating out of a new IP block, such as > > > when you release the first set of IPs in a new /8.) > > > > In this case, it's not the RBL's that are the issue; the address > > block in question isn't on them. It's the ISP's and other firms > > using manual copies rather than actually following best practices. > > It's not that hard to make a list of the major ISPs, corporations, > universities (entities with a large number of users), find willing > contacts inside each organization (individual or role addresses you can > email, and see if the email bounces, and who will reply if the email is > received) and run some automated tests to see if the IPs are being > blocked. In your follow-up email to me, you said you check "dozens" of > RBLs - that is clearly insufficient - probably by an order of magnitude > - of the entities you should check with. The number should be > "hundreds". A reasonably cluefull intern can provide you with a > suitable list in short order, probably less than 1 day, and find > suitable contacts inside each organization in a similar time frame - it > might take a week total to build a list of ~500 entities and associated > email addresses. Because of employee turn-over the list will need to be > updated, ~1-10 old addresses purged and replaced with new ones on a > monthly basis. Really? And you expect all these organizations to do ... what? Hire an intern to be permanent liaison to ARIN? Answer queries to whether or not IP space X is currently blocked (potentially at one of hundreds or thousands of points in their system, which corporate security may not wish to share, or even give "some random intern" access to)? Process reports of new ARIN delegations? What are you thinking they're going to do? And why should they care enough to do it? > > > Why isn't this being done now? > > > > > > Issuing reclaimed IPs is a lot like selling a used car, except that > > > the buyer has no way to "examine" the state of the IPs you will > > > issue them beforehand. Therefore it's up to you (ARIN, RIPE, et. > > > al.) to ensure that they are "just as good" as any other IP block. > > > It is shoddy business to take someone's money and then sneakily > > > give them tainted (used) goods and expect them to deal with > > > cleaning up the mess that the prior owner made, especially when you > > > charge the same rate for untainted goods! > > > > Not applicable in this case, as noted above. > > What do you mean, "not applicable"? You take the money and issue IPs. > There is no way for the "buyer" to know before hand if the IPs are > "tainted" (used) or new. It is up to you (ARIN) to ensure that the > goods (IPs) are suitable for the intended use. My analogy is entirely > applicable, and I'm amazed you think otherwise. WOW. That's a hell of a statement. There is absolutely nothing that ARIN can do if I decide I'm going to have our servers block connections from networks ending in an odd bit. Nobody is in a position to ensure that ANY Internet connection or IP space is "suitable for the intended use." Welcome to the Internet. > > So, back to the question: could someone explain why they've got > > copies of the RBL's in their network which don't get updated on any > > reasonable refresh interval? (weekly? monthly?) > > The "why" really isn't at issue - it happens and it's going to keep > happening. The question is what are you (ARIN) going to do about it? > > Give me the serenity to accept the things I cannot change, > The courage to change the things I can, > And the wisdom to know the difference. > > You (ARIN et. al.) don't have any ability to change the why. What you > can change is how you go about determining if an IP block is suitable > for reallocation or not, and what steps you take to repair IP blocks > that aren't suitable for reallocation. So, in addition to just registering IP space, it's also their job to clean it up? I'm sorry, I agree that there's a problem, but this just sounds like it isn't feasible. ... 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 mksmith at adhost.com Tue Sep 8 14:57:25 2009 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 8 Sep 2009 12:57:25 -0700 Subject: Datacenter recommendations - China and Latin America [SUMMARY] In-Reply-To: <17039594-994E-4B5A-8DCA-EBD50B0B47B8@eyeconomics.com> References: <17838240D9A5544AAA5FF95F8D52031606AFC270@ad-exh01.adhost.lan> <17838240D9A5544AAA5FF95F8D52031606AFC277@ad-exh01.adhost.lan> <4AA68018.6000408@splio.fr><97A02ABD-D175-4725-BC7C-EA8399A68BE8@fattoc.com><4AA687B5.3060507@evaristesys.com> <17039594-994E-4B5A-8DCA-EBD50B0B47B8@eyeconomics.com> Message-ID: <17838240D9A5544AAA5FF95F8D52031606AFC2FE@ad-exh01.adhost.lan> Hello: Thank you to everyone that provided off-list recommendations. I've compiled the list of providers in no particular order. Regards, Mike Latin America - Securehost - http://www.securehost.com - Triara (Telmex) - http://www.triara.com/Datacenter.htm - KIO Networks - Xertix - Hortolandia - CyDC (Brazil Telecom) - http://www.cydc.com.br - ALOG - http://www.alog.com.br - Terremark - http://www.terremark.com.br - Locaweb (Brazil) China/Hong Kong - Telehouse Beijing - http://www.telehouse.com/globalfacilities.php#asia - Vianet - http://www.21vianet.com/en/index.jsp - Mega-Iadvantage - http://www.iadvantage.net/facilities/facilities_megai_main.html - Dailan - InterNAP (partnering with Equinix) - Equinix - http://www.equinix.com/locations/map/asiapacific/hongkong/ -- Michael K. Smith - CISSP, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From justin at justinshore.com Tue Sep 8 14:57:17 2009 From: justin at justinshore.com (Justin Shore) Date: Tue, 08 Sep 2009 14:57:17 -0500 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <20090908184444.GA68989@typo.org> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <20090908184444.GA68989@typo.org> Message-ID: <4AA6B71D.1080906@justinshore.com> Wayne E. Bouchard wrote: > Best practices for the public or subscription RBLs should be to place > a TTL on the entry of no more than, say, 90 days or thereabouts. Best > practices for manual entry should be to either keep a list of what and > when or periodically to simply blow the whole list away and start anew > to get rid of stale entries. Of course, that is probably an unreal > expectation. I've had to implement something similar for my RTBH trigger router. After manually-adding nearly 20,000 static routes of hosts that scanned for open proxies or attacked SSH daemons on my network I had to trim the block list considerably because many of my older PEs couldn't handle that many routes without problems. I already named each static with a reason for the block(SSH, Telnet, Proxy-scan, etc) but ended up prepending a date to that string as well: 20090908-SSH-Scan. That way I can parse the config later on and create config to negate everything that's older than 3-4 months. If one of those old IPs is still trying to get to me after 4 months then it will get readded the next time I process my logs entries. If they aren't trying to hit me then they'll no longer be consuming space in my RIB. Justin From setient at gmail.com Tue Sep 8 15:00:46 2009 From: setient at gmail.com (Ronald Cotoni) Date: Tue, 08 Sep 2009 15:00:46 -0500 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <200909081934.n88JYAS9093038@aurora.sol.net> References: <200909081934.n88JYAS9093038@aurora.sol.net> Message-ID: <4AA6B7EE.10106@gmail.com> Joe Greco wrote: >> there is a fundamental disconnect here. the IP space is neutral. >> it has no bias toward or against social behaviours. its a tool. >> the actual/real target here are the people who are using these tools >> to be antisocial. blacklisting IP space is always reactive and >> should only beused in emergency and as a -TEMPORARY- expedient. >> >> IMHO of course., YMMV. >> > > Show me ONE major MTA which allows you to configure an expiration for > an ACL entry. > > The problem with your opinion, and it's a fine opinion, and it's even a > good opinion, is that it has very little relationship to the tools which > are given to people in order to accomplish blocking. Kind of the question > I was contemplating in my other message of minutes ago. > > If people were given an option to "block this IP for 30 minutes, 24 hours, > 30 days, 12 months, 5 years, or forever" - I wonder how many people would > just shrug and click "forever." > > This may lead to the discovery of another fundamental disconnect - or two. > > Sigh. > > ... JG > A cron job/schedule task with a script that removes said line would most likely do wonderous things for you. I could see a comment before each listing with a time/date that you use some regex fu on to figure out how long it was there and how long it should be there for. Simple! You could also automate it with a web frontend for noobs so they don't have to manually edit configuration files. From abalashov at evaristesys.com Tue Sep 8 15:02:01 2009 From: abalashov at evaristesys.com (Alex Balashov) Date: Tue, 08 Sep 2009 16:02:01 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <200909081950.n88Jo2Dl094175@aurora.sol.net> References: <200909081950.n88Jo2Dl094175@aurora.sol.net> Message-ID: <4AA6B839.7020304@evaristesys.com> Joe Greco wrote: > I'm sorry, I agree that there's a problem, but this just sounds like it > isn't feasible. Some people suffer from the culturally ingrained inability to understand that certain kinds of problems just can't. Be. Solved. And/or they aren't worth solving under present circumstances. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 From jdfalk-lists at cybernothing.org Tue Sep 8 15:51:41 2009 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Tue, 08 Sep 2009 13:51:41 -0700 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AA69D52.3060105@rollernet.us> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <4AA69D52.3060105@rollernet.us> Message-ID: <4AA6C3DD.20307@cybernothing.org> Seth Mattinen wrote: > I was always under the impression that smaller orgs were not allowed to > join the MAAWG club. I've heard that, too, but have no idea where it comes from. It's not true; there's no size requirement or anything like that. http://www.maawg.org/ has the membership application and other info. -- J.D. Falk Co-Chair, Program Committee Messaging Anti-Abuse Working Group From lost at l-w.ca Tue Sep 8 16:01:59 2009 From: lost at l-w.ca (William Astle) Date: Tue, 08 Sep 2009 15:01:59 -0600 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AA6C3DD.20307@cybernothing.org> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <4AA69D52.3060105@rollernet.us> <4AA6C3DD.20307@cybernothing.org> Message-ID: <4AA6C647.9060405@l-w.ca> J.D. Falk wrote: > Seth Mattinen wrote: > >> I was always under the impression that smaller orgs were not allowed to >> join the MAAWG club. > > I've heard that, too, but have no idea where it comes from. It's not > true; there's no size requirement or anything like that. > > http://www.maawg.org/ has the membership application and other info. > The $4000/year minimum membership fee is a non-starter for small organizations who are already strapped for operating cash as it is. This is probably where the perception comes from. -- William Astle lost at l-w.ca From justin at justinshore.com Tue Sep 8 16:06:42 2009 From: justin at justinshore.com (Justin Shore) Date: Tue, 08 Sep 2009 16:06:42 -0500 Subject: Network Ring In-Reply-To: <20090908.210445.74736190.sthaug@nethelp.no> References: <20090907.095151.74706289.sthaug@nethelp.no> <1E8B940C5E21014AB8BE70B975D40EDB0162881C@bert.HiberniaAtlantic.local> <4AA64018.7080006@justinshore.com> <20090908.210445.74736190.sthaug@nethelp.no> Message-ID: <4AA6C762.2050805@justinshore.com> sthaug at nethelp.no wrote: >> Rod Beck wrote: >>> What is EAPS? >> A joke of a "standard" and something to be avoided at all costs. I >> would echo the last part about Extreme switches too. > > Disagree. I don't believe anybody would claim EAPS is a "standard" > just because an RFC has been published. Pannaway does. That was one of the very arguments I used against their product when they were brought in. They claimed that it was a standard because it had a RFC. I tried to explain the difference between an Information RFC and a Standards Track to no avail. Of course this also came from the Pannaway SE that gave me 3 quotes I repeat as often as possible to as many people as possible. He said: 1) that we didn't need to run an IGP across our network because we weren't big enough to need one. This was in response to my query about their lack of support for IS-IS. He said that he'd seen SP networks many times our size get by perfectly well with static routes. 2) that we didn't need QoS on our network if our links weren't saturated. I won't get into the holy war over serialization delay, micro bursts, and queuing here. It's been hashed out many times before on NANOG I'm sure. 3) that IPv6 was just a fad and that it would never be implemented in the US. I got our /32 in 2008 and am working on the deployment now. I'm certainly not breaking new ground here either. It may not be the most common thing in the US but it is picking up steam for everyone not running Pannaway products since they don't support IPv6 (the BASs and BARs that we ended up buying at least). > As for Extreme switches - they have their strengths and weaknesses, > just like any other product. We use lots of Summit X450/X450a, for > L2 only, and have been generally reasonably happy with them. If I > could buy a similarly featured product from Cisco, for a similar > price, I might well choose Cisco. But at least in our case Cisco > *doesn't* have a competitive product (case in point: ME3400 - too > few ports, too few MAC addresses, funky licensing even if you just > want to do simple QinQ). I don't have any experience with the ME3400 unfortunately. A mix of vendors isn't a bad thing if you have the knowledge, depth and time to keep up with each of them so you can support the device adequately (adequate staffing is involved here too). When one buys a budget switch just to save a few bucks they tend to get what they paid for and none of what they didn't (training, experience for their staff, printed third-party references, reliable online support groups for example). I'm in a situation right now where a vendor has proposed a basic L2 switch solution to redundantly connect 2 of our sites. They come in cheaper than the Cisco equivalent (4 4948-10GEs) but we also have absolutely no experience with that vendor. That means interopt testing, future finger pointing in the heat of an outage, double training staff, inevitable config errors and typos thanks to the differences between the vendor we're used to and the one that is being proposed for this one-off connection. The better fool-proof solution costs a bit more and I have to convince management not to save a short-term buck which costs of many long-term bucks. Sometimes you really do get what you pay for. Justin From tom.pipes at t6mail.com Tue Sep 8 15:58:47 2009 From: tom.pipes at t6mail.com (Tom Pipes) Date: Tue, 8 Sep 2009 15:58:47 -0500 (CDT) Subject: Repeated Blacklisting / IP reputation In-Reply-To: <30306967.268951252443449724.JavaMail.root@zimbra> Message-ID: <28880400.269001252443527011.JavaMail.root@zimbra> I am amazed with the amount of thoughtful comments I have seen, both on and off list. It really illustrates that people are willing to try to help out, but there is an overall lack of clear direction on how to improve things. Most of us seem to adopt that which has always just worked for us. Don't get me wrong, I'm sure there are a lot of improvements/mods going on with RBL operators in terms of the technology and how they choose who to block. I'm also certain that most of the carriers are doing their best to follow RFCs, use e-mail filtering, and perform deep packet inspection to keep themselves off of the lists. AND there seems to be some technologies that were meant to work, and cause their own sets of problems (example: allowing the end user to choose what is considered spam and blacklisting based on that). As was said before, it's not the "WHY" but rather how can we fix it if it's broke. The large debate seems to revolve around responsibility, or lack thereof. In our case, we are the small operator who sits in the sidelines hoping that someone larger than us, or more influential has an opinion. We participate in lists, hoping to make a difference and contribute, knowing that in a lot of cases, our opinion is just that: an opinion. I suppose that could spark a debate about joining organizations (who shall go nameless here), power to the people, etc. It seems as though a potential solution *may* revolve around ARIN/IANA having the ability to communicate an authoritative list of reassigned IP blocks back to the carriers. This could serve as a signal to remove a block from the RBL, but I'm sure there will be downfalls with doing this as well. In my specific case, I am left with a legacy block that I have to accept is going to be problematic. Simply contacting RBL operators is just not doing the trick. Most of the e-mails include links or at least an error code, but some carriers just seem to be blocking without an error, or even worse, an ACL... We will continue to remove these blocks as necessary, reassign IPs from other blocks where absolutely necessary, and ultimately hope the problem resolves itself over time. Thanks again for the very thoughtful and insightful comments, they are greatly appreciated. Regards, --- Tom Pipes T6 Broadband/ Essex Telcom Inc tom.pipes at t6mail.com ----- Original Message ----- From: "Tom Pipes" To: nanog at nanog.org Sent: Tuesday, September 8, 2009 9:57:58 AM GMT -06:00 US/Canada Central Subject: Repeated Blacklisting / IP reputation Greetings, We obtained a direct assigned IP block 69.197.64.0/18 from ARIN in 2008. This block has been cursed (for lack of a better word) since we obtained it. It seems like every customer we have added has had repeated issues with being blacklisted by DUL and the cable carriers. (AOL, AT&T, Charter, etc). I understand there is a process to getting removed, but it seems as if these IPs had been used and abused by the previous owner. We have done our best to ensure these blocks conform to RFC standards, including the proper use of reverse DNS pointers. I can resolve the issue very easily by moving these customers over to our other direct assigned 66.254.192.0/19 block. In the last year I have done this numerous times and have had no further issues with them. My question: Is there some way to clear the reputation of these blocks up, or start over to prevent the amount of time we are spending with each customer troubleshooting unnecessary RBL and reputation blacklisting? I have used every opportunity to use the automated removal links from the SMTP rejections, and worked with the RBL operators directly. Most of what I get are cynical responses and promises that it will be fixed. If there is any question, we perform inbound and outbound scanning of all e-mail, even though we know that this appears to be something more relating to the block itself. Does anyone have any suggestions as to how we can clear this issue up? Comments on or off list welcome. Thanks, --- Tom Pipes T6 Broadband/ Essex Telcom Inc tom.pipes at t6mail.com From justin at justinshore.com Tue Sep 8 16:12:16 2009 From: justin at justinshore.com (Justin Shore) Date: Tue, 08 Sep 2009 16:12:16 -0500 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AA6ABB8.9000505@west.net> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <4AA69D52.3060105@rollernet.us> <4AA6ABB8.9000505@west.net> Message-ID: <4AA6C8B0.8000605@justinshore.com> Jay Hennigan wrote: > By the way, among the members... > > Experian CheetahMail > ExactTarget, Inc > Responsys, Inc. > Vertical Response, Inc > Yesmail Have you been reading from my blacklist again, Jay? Justin From bbillon-ml at splio.fr Tue Sep 8 16:17:58 2009 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Tue, 08 Sep 2009 23:17:58 +0200 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AA6C647.9060405@l-w.ca> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <4AA69D52.3060105@rollernet.us> <4AA6C3DD.20307@cybernothing.org> <4AA6C647.9060405@l-w.ca> Message-ID: <4AA6CA06.2010103@splio.fr> ISPs can be invited and there are specific meetings for them (closed to other members). There're also whitepapers for ISP (and others). But I agree, hoping ALL the ISPs join MAAWG or even hear about it is utopian. -- Benjamin William Astle a ?crit : > J.D. Falk wrote: >> Seth Mattinen wrote: >> >>> I was always under the impression that smaller orgs were not allowed to >>> join the MAAWG club. >> >> I've heard that, too, but have no idea where it comes from. It's not >> true; there's no size requirement or anything like that. >> >> http://www.maawg.org/ has the membership application and other info. >> > > The $4000/year minimum membership fee is a non-starter for small > organizations who are already strapped for operating cash as it is. > This is probably where the perception comes from. > From bbillon-ml at splio.fr Tue Sep 8 16:20:29 2009 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Tue, 08 Sep 2009 23:20:29 +0200 Subject: Datacenter recommendations - China and Latin America In-Reply-To: <4AA687B5.3060507@evaristesys.com> References: <17838240D9A5544AAA5FF95F8D52031606AFC270@ad-exh01.adhost.lan> <17838240D9A5544AAA5FF95F8D52031606AFC277@ad-exh01.adhost.lan> <4AA68018.6000408@splio.fr> <97A02ABD-D175-4725-BC7C-EA8399A68BE8@fattoc.com> <4AA687B5.3060507@evaristesys.com> Message-ID: <4AA6CA9D.9070803@splio.fr> You could get a China Telecom link in HK as well as many others: sit astride the Great Firewall! > What is the Great Firewall relationship between Hong Kong and the > mainland PRC, as compared to the mainland PRC vs. the rest of the world? > From Michael_OReirdan at Cable.Comcast.com Tue Sep 8 16:25:04 2009 From: Michael_OReirdan at Cable.Comcast.com (O'Reirdan, Michael) Date: Tue, 8 Sep 2009 17:25:04 -0400 Subject: Repeated Blacklisting / IP reputation Message-ID: <45AEC6EF95942140888406588E1A660209452F64@PACDCEXCMB04.cable.comcast.com> MAAWG is has no size limitations as to members. Yes we do have a $4000 supporter membership. This has not proved a barrier to many organisations. Mike O'Reirdan Chairman, MAAWG ----- Original Message ----- From: Benjamin Billon To: nanog at nanog.org Sent: Tue Sep 08 17:17:58 2009 Subject: Re: Repeated Blacklisting / IP reputation ISPs can be invited and there are specific meetings for them (closed to other members). There're also whitepapers for ISP (and others). But I agree, hoping ALL the ISPs join MAAWG or even hear about it is utopian. -- Benjamin William Astle a ?crit : > J.D. Falk wrote: >> Seth Mattinen wrote: >> >>> I was always under the impression that smaller orgs were not allowed to >>> join the MAAWG club. >> >> I've heard that, too, but have no idea where it comes from. It's not >> true; there's no size requirement or anything like that. >> >> http://www.maawg.org/ has the membership application and other info. >> > > The $4000/year minimum membership fee is a non-starter for small > organizations who are already strapped for operating cash as it is. > This is probably where the perception comes from. > From tvest at eyeconomics.com Tue Sep 8 16:32:27 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Tue, 8 Sep 2009 17:32:27 -0400 Subject: Datacenter recommendations - China and Latin America [SUMMARY] In-Reply-To: <17838240D9A5544AAA5FF95F8D52031606AFC2FE@ad-exh01.adhost.lan> References: <17838240D9A5544AAA5FF95F8D52031606AFC270@ad-exh01.adhost.lan> <17838240D9A5544AAA5FF95F8D52031606AFC277@ad-exh01.adhost.lan> <4AA68018.6000408@splio.fr><97A02ABD-D175-4725-BC7C-EA8399A68BE8@fattoc.com><4AA687B5.3060507@evaristesys.com> <17039594-994E-4B5A-8DCA-EBD50B0B47B8@eyeconomics.com> <17838240D9A5544AAA5FF95F8D52031606AFC2FE@ad-exh01.adhost.lan> Message-ID: For those who have a real need for both hosting within the Chinese autonomous routing domain *and* good, English-friendly remote hands support, I would also recommend considering the Silk Road Technologies data center in Hangzhou: http://www.srt.com.cn/en/ TV On Sep 8, 2009, at 3:57 PM, Michael K. Smith - Adhost wrote: > Hello: > > Thank you to everyone that provided off-list recommendations. I've > compiled the list of providers in no particular order. > > Regards, > > Mike > > Latin America > > - Securehost - http://www.securehost.com > - Triara (Telmex) - http://www.triara.com/Datacenter.htm > - KIO Networks > - Xertix > - Hortolandia > - CyDC (Brazil Telecom) - http://www.cydc.com.br > - ALOG - http://www.alog.com.br > - Terremark - http://www.terremark.com.br > - Locaweb (Brazil) > > China/Hong Kong > > - Telehouse Beijing - http://www.telehouse.com/globalfacilities.php#asia > - Vianet - http://www.21vianet.com/en/index.jsp > - Mega-Iadvantage - > http://www.iadvantage.net/facilities/facilities_megai_main.html > - Dailan > - InterNAP (partnering with Equinix) > - Equinix - http://www.equinix.com/locations/map/asiapacific/hongkong/ > > > -- > Michael K. Smith - CISSP, GISP > Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com > w: +1 (206) 404-9500 f: +1 (206) 404-9050 > PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > > > From leo.vegoda at icann.org Tue Sep 8 11:37:35 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 8 Sep 2009 09:37:35 -0700 Subject: Block of AS Numbers allocated to APNIC Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The IANA AS Numbers registry has been updated to reflect the allocation of a block of AS Numbers to APNIC. 55296-56319 Assigned by APNIC whois.apnic.net 2009-09-02 The registry can be found at: http://www.iana.org/assignments/as-numbers/as-numbers.xml http://www.iana.org/assignments/as-numbers/as-numbers.xhtml http://www.iana.org/assignments/as-numbers/as-numbers.txt Regards, Leo Vegoda Number Resources Manager, IANA -----BEGIN PGP SIGNATURE----- Version: 9.10.0.500 wj4DBQFKpohJvBLymJnAzRwRAncHAJiRWENmmK+qwpvAZIaPrs/urIa/AJ9f1A05 PM9TJWxzbAxpSiXyIgzvfA== =MGZ2 -----END PGP SIGNATURE----- From lost at l-w.ca Tue Sep 8 17:25:29 2009 From: lost at l-w.ca (William Astle) Date: Tue, 08 Sep 2009 16:25:29 -0600 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <45AEC6EF95942140888406588E1A660209452F64@PACDCEXCMB04.cable.comcast.com> References: <45AEC6EF95942140888406588E1A660209452F64@PACDCEXCMB04.cable.comcast.com> Message-ID: <4AA6D9D9.6010500@l-w.ca> O'Reirdan, Michael wrote: > MAAWG is has no size limitations as to members. Yes we do have a $4000 supporter membership. This has not proved a barrier to many organisations. Likely because for the ones for whom it is a barrier, they look at the cost and don't even bother considering an initial contact. Thus, you never hear about it. Admittedly, most smaller organizations simply don't have the time to participate in even a handful of the $bignum industry organizations (whether they cost money or not) so that's likely a more substantial barrier. To be completely clear, it's not clear to me that an organization that cannot afford $4000/year would actually have the resources to participate in a meaningful way anyway. Which is to say that I do not necessarily disagree with the fee structure, and that is speaking from under my "small organization for whom the $4k/year is an insurmountable barrier" hat. All that said, I believe I have had my say sufficiently so I will not contribute further to the overall noise level on NANOG. > > Mike O'Reirdan > Chairman, MAAWG > > > ----- Original Message ----- > From: Benjamin Billon > To: nanog at nanog.org > Sent: Tue Sep 08 17:17:58 2009 > Subject: Re: Repeated Blacklisting / IP reputation > > ISPs can be invited and there are specific meetings for them (closed to > other members). > There're also whitepapers for ISP (and others). > > But I agree, hoping ALL the ISPs join MAAWG or even hear about it is > utopian. > > -- > Benjamin > > William Astle a ?crit : >> J.D. Falk wrote: >>> Seth Mattinen wrote: >>> >>>> I was always under the impression that smaller orgs were not allowed to >>>> join the MAAWG club. >>> I've heard that, too, but have no idea where it comes from. It's not >>> true; there's no size requirement or anything like that. >>> >>> http://www.maawg.org/ has the membership application and other info. >>> >> The $4000/year minimum membership fee is a non-starter for small >> organizations who are already strapped for operating cash as it is. >> This is probably where the perception comes from. >> > -- William Astle lost at l-w.ca From arnaud at pnzone.net Tue Sep 8 17:46:53 2009 From: arnaud at pnzone.net (Arnaud de Prelle) Date: Wed, 9 Sep 2009 00:46:53 +0200 Subject: Colt outages? In-Reply-To: <4AA66D37.6090703@nic-naa.net> References: <4AA66D37.6090703@nic-naa.net> Message-ID: <470D9E82-6C96-4E19-880D-542F46F61A2E@pnzone.net> On 08 Sep 2009, at 16:41, Eric Brunner-Williams wrote: > Anyone have news on this? I understand Colt has fixed London and are > working on Dublin, Bruxelles and Geneva... but that's all I have. > The only "interesting" news and comments I found about this outage were on TheRegister.co.uk website: http://www.theregister.co.uk/2009/09/08/colt_telecom_outage/ http://www.theregister.co.uk/2009/09/08/colt_telecom_outage/comments/ From ken.gilmour at gmail.com Tue Sep 8 20:00:51 2009 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Tue, 8 Sep 2009 19:00:51 -0600 Subject: Cable and Wireless Antigua Message-ID: <5b6f80200909081800g3f515e49y24ab5eb2fe8b2686@mail.gmail.com> Hi there, I have gone through all normal channels to try to get through to someone in Cable and Wireless Antigua (LIME). It seems difficult to get a fast response through normal channels (it can take up to 48 hours some times to get a response to a "network down" situation). Is there any senior admins who deal directly with the transit end on NANOG? I am having some difficulty getting a security issue dealt with. Thanks! Ken From tvest at eyeconomics.com Tue Sep 8 20:04:18 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Tue, 8 Sep 2009 21:04:18 -0400 Subject: Datacenter recommendations - China and Latin America In-Reply-To: <4AA6CA9D.9070803@splio.fr> References: <17838240D9A5544AAA5FF95F8D52031606AFC270@ad-exh01.adhost.lan> <17838240D9A5544AAA5FF95F8D52031606AFC277@ad-exh01.adhost.lan> <4AA68018.6000408@splio.fr> <97A02ABD-D175-4725-BC7C-EA8399A68BE8@fattoc.com> <4AA687B5.3060507@evaristesys.com> <4AA6CA9D.9070803@splio.fr> Message-ID: <96B0AE23-E28F-46EE-A43E-F6CB057E8445@eyeconomics.com> On Sep 8, 2009, at 5:20 PM, Benjamin Billon wrote: > You could get a China Telecom link in HK as well as many others: sit > astride the Great Firewall! From a cost, operational, and routing perspective, the same would be true if you got a CT link in Los Angeles or San Francisco. Since CT and CNC control all routes between China and everywhere else in the world-- including HK -- and the outsideCN-to-insideCN segment is going to be the most expensive and complicated element of any path between China and anywhere else, the choice of interconnect location with your preferred China-side service provider provider is largely going to be a matter of personal taste/local convenience. Don't get me wrong, I like Hong Kong too -- just trying to make sure that everyone understands the situation clearly... TV >> What is the Great Firewall relationship between Hong Kong and the >> mainland PRC, as compared to the mainland PRC vs. the rest of the >> world? From beckman at angryox.com Wed Sep 9 00:04:48 2009 From: beckman at angryox.com (Peter Beckman) Date: Wed, 9 Sep 2009 01:04:48 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <28880400.269001252443527011.JavaMail.root@zimbra> References: <28880400.269001252443527011.JavaMail.root@zimbra> Message-ID: How about a trial period from ARIN? You get your IP block, and you get 30 days to determine if it is "clean" or not. Do some testing, check the blacklists, do some magic to see if there are network-specific blacklists that might prevent your customers from sending or receiving email/web/other connections with that new IP block. If there are problems, go back to ARIN and show them your work and if they can verify your work (or are simply lazy) you get a different block. ARIN puts the block into another quiet period. Maybe they use the work you did to clean up the block, maybe they don't. Cleaning up a block of IPs previously used by shady characters has a real cost, both in time and money. The argument as I see it is who bears the responsibility and cost of that cleanup. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From sethm at rollernet.us Wed Sep 9 00:34:40 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 08 Sep 2009 22:34:40 -0700 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <28880400.269001252443527011.JavaMail.root@zimbra> Message-ID: <4AA73E70.7030907@rollernet.us> Peter Beckman wrote: > How about a trial period from ARIN? You get your IP block, and you get 30 > days to determine if it is "clean" or not. Do some testing, check the > blacklists, do some magic to see if there are network-specific blacklists > that might prevent your customers from sending or receiving email/web/other > connections with that new IP block. > > If there are problems, go back to ARIN and show them your work and if they > can verify your work (or are simply lazy) you get a different block. ARIN > puts the block into another quiet period. Maybe they use the work you did > to clean up the block, maybe they don't. > > Cleaning up a block of IPs previously used by shady characters has a real > cost, both in time and money. The argument as I see it is who bears the > responsibility and cost of that cleanup. > I encourage someone to write a policy proposal; I'd support it. They (the recipient) didn't have a darn thing to do with it becoming a wasteland and shouldn't bear the cost. Unlike bying a (insert your favorite object here), you can't inspect an IP block before purchase. I fear that "we don't guarantee routability" will rear its ugly head even if someone were to pen an awesome policy. I feel it's a poor position for a registry to take, though. They still get the money even if you can't use them, and uh oh, looks like you won't qualify for more until you use the unusable. Probably getting off topic for NANOG, like most threads that get this long. ~Seth From bmanning at vacation.karoshi.com Wed Sep 9 00:54:38 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 9 Sep 2009 05:54:38 +0000 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <28880400.269001252443527011.JavaMail.root@zimbra> Message-ID: <20090909055438.GC3368@vacation.karoshi.com.> sounds like domain tasting to me. --bill On Wed, Sep 09, 2009 at 01:04:48AM -0400, Peter Beckman wrote: > How about a trial period from ARIN? You get your IP block, and you get 30 > days to determine if it is "clean" or not. Do some testing, check the > blacklists, do some magic to see if there are network-specific blacklists > that might prevent your customers from sending or receiving email/web/other > connections with that new IP block. > > If there are problems, go back to ARIN and show them your work and if they > can verify your work (or are simply lazy) you get a different block. ARIN > puts the block into another quiet period. Maybe they use the work you did > to clean up the block, maybe they don't. > > Cleaning up a block of IPs previously used by shady characters has a real > cost, both in time and money. The argument as I see it is who bears the > responsibility and cost of that cleanup. > > Beckman > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman at angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- From jay at west.net Wed Sep 9 01:05:11 2009 From: jay at west.net (Jay Hennigan) Date: Tue, 08 Sep 2009 23:05:11 -0700 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <20090909055438.GC3368@vacation.karoshi.com.> References: <28880400.269001252443527011.JavaMail.root@zimbra> <20090909055438.GC3368@vacation.karoshi.com.> Message-ID: <4AA74597.1090205@west.net> bmanning at vacation.karoshi.com wrote: > sounds like domain tasting to me. Oops! Oh yeah. Spammer gets an allocation... "Well, if that netblock was clean before, it sure isn't now! May I please have another?" Lather, rinse, repeat. -- 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 bbillon-ml at splio.fr Wed Sep 9 03:11:35 2009 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Wed, 09 Sep 2009 10:11:35 +0200 Subject: Datacenter recommendations - China and Latin America In-Reply-To: <96B0AE23-E28F-46EE-A43E-F6CB057E8445@eyeconomics.com> References: <17838240D9A5544AAA5FF95F8D52031606AFC270@ad-exh01.adhost.lan> <17838240D9A5544AAA5FF95F8D52031606AFC277@ad-exh01.adhost.lan> <4AA68018.6000408@splio.fr> <97A02ABD-D175-4725-BC7C-EA8399A68BE8@fattoc.com> <4AA687B5.3060507@evaristesys.com> <4AA6CA9D.9070803@splio.fr> <96B0AE23-E28F-46EE-A43E-F6CB057E8445@eyeconomics.com> Message-ID: <4AA76337.6060609@splio.fr> > From a cost, operational, and routing perspective, the same would be > true if you got a CT link in Los Angeles or San Francisco. I can't be sure (didn't try myself, sorry) but I think CT links are more filtered from outside PRC (HK being included in PRC) > Since CT and CNC You mean China Unicom =) > control all routes between China and everywhere else in the world-- > including HK -- and the outsideCN-to-insideCN segment is going to be > the most expensive and complicated element of any path between China > and anywhere else, the choice of interconnect location with your > preferred China-side service provider provider is largely going to be > a matter of personal taste/local convenience. and when asking to go through the Great Firewall, you (I don't mean YOU, TV) should first focus on your objectives. Do you truly think that because you got a network foot inside Mainland China, your services will be easy to reach for all Chinese Netizens? From chaz at chaz6.com Wed Sep 9 03:38:07 2009 From: chaz at chaz6.com (Chris Hills) Date: Wed, 09 Sep 2009 10:38:07 +0200 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <200909081934.n88JYAS9093038@aurora.sol.net> References: <20090908191510.GB31380@vacation.karoshi.com.> <200909081934.n88JYAS9093038@aurora.sol.net> Message-ID: On 08/09/09 21:34, Joe Greco wrote: > Show me ONE major MTA which allows you to configure an expiration for > an ACL entry. This is fairly trivial to do with Exim by storing your acl entries in a database or directory with a field/attribute for expiry, and an appropriate router configuration. No doubt you could implement this using a small script for any MTA. The upside of using a db/ldap backend is that it makes it easy to inter-operate with other things like your nms. From tvest at eyeconomics.com Wed Sep 9 06:33:16 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Wed, 9 Sep 2009 07:33:16 -0400 Subject: Datacenter recommendations - China and Latin America In-Reply-To: <4AA76337.6060609@splio.fr> References: <17838240D9A5544AAA5FF95F8D52031606AFC270@ad-exh01.adhost.lan> <17838240D9A5544AAA5FF95F8D52031606AFC277@ad-exh01.adhost.lan> <4AA68018.6000408@splio.fr> <97A02ABD-D175-4725-BC7C-EA8399A68BE8@fattoc.com> <4AA687B5.3060507@evaristesys.com> <4AA6CA9D.9070803@splio.fr> <96B0AE23-E28F-46EE-A43E-F6CB057E8445@eyeconomics.com> <4AA76337.6060609@splio.fr> Message-ID: On Sep 9, 2009, at 4:11 AM, Benjamin Billon wrote: > >> From a cost, operational, and routing perspective, the same would >> be true if you got a CT link in Los Angeles or San Francisco. > I can't be sure (didn't try myself, sorry) but I think CT links are > more filtered from outside PRC (HK being included in PRC) Perhaps, but I believe that would only be consistently/reliably true for the smallish international intra-enterprise links of non-network services companies, e.g., between manufacturer-x's CN subsidiary and manufacturer-x's offshore corporate HQ. >> Since CT and CNC > You mean China Unicom =) Indeed -- thanks for the correction. >> control all routes between China and everywhere else in the world-- >> including HK -- and the outsideCN-to-insideCN segment is going to >> be the most expensive and complicated element of any path between >> China and anywhere else, the choice of interconnect location with >> your preferred China-side service provider provider is largely >> going to be a matter of personal taste/local convenience. > and when asking to go through the Great Firewall, you (I don't mean > YOU, TV) should first focus on your objectives. Do you truly think > that because you got a network foot inside Mainland China, your > services will be easy to reach for all Chinese Netizens? Exactly the right question. However (unless I am badly dated on these points also), the phrasing could be a little misleading, because: 1. You* will not get a layer-3 "network foot" inside China -- not one that's bigger than a LAN anyway, and certainly not one that's connected to anything outside China without first transiting CT or CUC (that's what I meant by "Chinese autonomous routing domain"). 2. You* will not get (or alternately, not want) to extend a layer-2 "network foot" inside China, because at best you'll get no further than the CT or CUC office closest to the landing station -- and that would put you in no different operational position (except perhaps much poorer) than if you interconnected in HK, LA, etc. Indirectly managed, locally hosted, and directly on-net with one of the two large access providers is the only formula that *might* make some kind of presence in China different from & better than trying to reach Chinese Internet users from across the border. But even that can be quite challenging to arrange and maintain over time... Nuff said (but would be grateful for other corrections/updates based on very recent firsthand experience), TV From jgreco at ns.sol.net Wed Sep 9 06:37:53 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 9 Sep 2009 06:37:53 -0500 (CDT) Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AA6B7EE.10106@gmail.com> from "Ronald Cotoni" at Sep 08, 2009 03:00:46 PM Message-ID: <200909091137.n89BbrT8069394@aurora.sol.net> > > Show me ONE major MTA which allows you to configure an expiration for > > an ACL entry. > > > > The problem with your opinion, and it's a fine opinion, and it's even a > > good opinion, is that it has very little relationship to the tools which > > are given to people in order to accomplish blocking. Kind of the question > > I was contemplating in my other message of minutes ago. > > > > If people were given an option to "block this IP for 30 minutes, 24 hours, > > 30 days, 12 months, 5 years, or forever" - I wonder how many people would > > just shrug and click "forever." > > > > This may lead to the discovery of another fundamental disconnect - or two. > > > > Sigh. > > > > ... JG > > A cron job/schedule task with a script that removes said line would most > likely do wonderous things for you. I could see a comment before each > listing with a time/date that you use some regex fu on to figure out how > long it was there and how long it should be there for. Simple! You > could also automate it with a web frontend for noobs so they don't have > to manually edit configuration files. You /COMPLETELY/ missed the point. If this was something that people felt was truly useful, then there would be support for something like this. I mean, we've only had about 15 years of spam-as-a-real-problem on the Internet. The perception by most admins is that when you block someone, you want to block them for a Really Long Time. If this wasn't true, then there would likely be an automatic feature built in to MTA ACL entries to expire. I didn't say you /couldn't/ do it. The problem is that the average spam spewer is a long-term thing, so when you ACL off a host, you've probably deemed the sender to be of no significant value to you, and you're not expecting that they're suddenly going to become whitehat in two weeks, or even six months. Therefore, there's no default support built into MTA's for this, because it /doesn't/ do anything "wonderous" for you. I would agree that in the best case, we would want a default behaviour of ACL removal when an IP block is reallocated by the RIR, but I don't see an easy way to get there as a default behaviour of an MTA. ... 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 Wed Sep 9 06:46:18 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 9 Sep 2009 06:46:18 -0500 (CDT) Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AA74597.1090205@west.net> from "Jay Hennigan" at Sep 08, 2009 11:05:11 PM Message-ID: <200909091146.n89BkIHI070307@aurora.sol.net> > bmanning at vacation.karoshi.com wrote: > > sounds like domain tasting to me. > > Oops! Oh yeah. Spammer gets an allocation... > > "Well, if that netblock was clean before, it sure isn't now! May I > please have another?" > > Lather, rinse, repeat. THAT would probably be easy enough to detect; RIR simply checks to see if new DNSBL entries had appeared, and refuses to trade in the block if any do. You may need a few more refinements too. I don't think it's technically unworkable, if tackled correctly. But it also leaves some questions, such as what ARIN is expected to do with the toxic wastelands left behind by spammers. ... 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 dlr at bungi.com Wed Sep 9 07:40:32 2009 From: dlr at bungi.com (Dave Rand) Date: Wed, 9 Sep 2009 05:40:32 -0700 Subject: Repeated Blacklisting / IP reputation In-Reply-To: Joe Greco's message on Sep 8, 14:34. Message-ID: [In the message entitled "Re: Repeated Blacklisting / IP reputation" on Sep 8, 14:34, Joe Greco writes:] > > there is a fundamental disconnect here. the IP space is neutral. > > it has no bias toward or against social behaviours. its a tool. > > the actual/real target here are the people who are using these tools > > to be antisocial. blacklisting IP space is always reactive and > > should only beused in emergency and as a -TEMPORARY- expedient. > > > > IMHO of course., YMMV. > > > If people were given an option to "block this IP for 30 minutes, 24 hours, > 30 days, 12 months, 5 years, or forever" - I wonder how many people would > just shrug and click "forever." > > This may lead to the discovery of another fundamental disconnect - or two. > IP address space is neutral, but the operators of the space either permit, or deny, the social behaviour which comes from these spaces. For what it's worth, I just completed a study of about 5 years of data on spam. I looked at 100,000,000 IP addresses which had sent me spam. The median duration of sending was 300 days. There was a pronounced peak at 2-3 years of about 30%. The vast majority was more than 30 days. "forever" is pretty close to right, based on current behaviour. -- From bbillon-ml at splio.fr Wed Sep 9 08:47:22 2009 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Wed, 09 Sep 2009 15:47:22 +0200 Subject: Datacenter recommendations - China and Latin America In-Reply-To: References: <17838240D9A5544AAA5FF95F8D52031606AFC270@ad-exh01.adhost.lan> <17838240D9A5544AAA5FF95F8D52031606AFC277@ad-exh01.adhost.lan> <4AA68018.6000408@splio.fr> <97A02ABD-D175-4725-BC7C-EA8399A68BE8@fattoc.com> <4AA687B5.3060507@evaristesys.com> <4AA6CA9D.9070803@splio.fr> <96B0AE23-E28F-46EE-A43E-F6CB057E8445@eyeconomics.com> <4AA76337.6060609@splio.fr> Message-ID: <4AA7B1EA.4050500@splio.fr> I've heard of several ISP "available" in Mainland China and offering IP transit services, but I when contacted they never confirmed they're providing the access to Mainland China Netizens, as, as far as I know, the only historical backbone in Mainland China is ChinaNet (owned by China Telecom), later split into ChinaNet in North China and CNC (now merged with China Unicom) in South China, for economical reason and competition purpose. For this reason, I don't believe private and foreign companies could have deploy their own and provide an alternative. Smaller ISP often cover the last miles, adding more risks of service disruption, latency, etc. Anyway, my point was: don't think that because you're "in" China, everyone can reach you. Don't go CDN either thinking it's a good solution*. China is complex, you may lose a lot of time and/or money deciding for a final solution at first sight. Define your current needs and plan out futures', and get good contacts there. Take your time and try out different providers. *I've heard about an interesting solution of testing and weighting (price, best time of efficiency, etc.) different CDN providers, you can contact me to know more about it From jmaimon at ttec.com Wed Sep 9 09:03:35 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 09 Sep 2009 10:03:35 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> Message-ID: <4AA7B5B7.3090309@ttec.com> John, ARIN's role as the entity engaged in legal contractual relationship with the previous owners of the space puts it in the position to insert enforceable contract clauses to deter and/or mitigate "graffiti" in allocations. Policy proposals probably are not required for this. Space originally from outside ARIN, thats another kettle of fish. ARIN is also in the position to refuse allocations for entities who dont clean up after themselves. Policy likely required. And finally, if this problem continues to worsen (as it likely will when greenfield becomes scarce), a viable business opportunity should emerge for reputable organizations to do cleanup on behalf of the new owners, for a reasonable fee/retainer and after suitable financial/contractual guarantees. Cost of business, efficiency of scale and all that. Perhaps the bill could even be sent to the previous owners. Operationally, I dont see how the problem can be mitigated solely by those who are already informed. Joe John Curran wrote: > Folks - > > It appears that we have a real operational problem, in that ARIN > does indeed reissue space that has been reclaimed/returned after > a hold-down period, and but it appears that even once they are > removed from the actual source RBL's, there are still ISP's who > are manually updating these and hence block traffic much longer > than necessary. > > I'm sure there's an excellent reason why these addresses stay > blocked, but am unable to fathom what exactly that is... > Could some folks from the appropriate networks explain why > this is such a problem and/or suggest additional steps that > ARIN or the receipts should be taking to avoid this situation? > > Thanks! > /John > > John Curran > President and CEO > ARIN > > On Sep 8, 2009, at 11:16 AM, Ronald Cotoni wrote: > >> Tom Pipes wrote: >>> Greetings, >>> >>> We obtained a direct assigned IP block 69.197.64.0/18 from ARIN in >>> 2008. This block has been cursed (for lack of a better word) since >>> we obtained it. It seems like every customer we have added has had >>> repeated issues with being blacklisted by DUL and the cable >>> carriers. From johnl at iecc.com Wed Sep 9 09:04:48 2009 From: johnl at iecc.com (John Levine) Date: 9 Sep 2009 14:04:48 -0000 Subject: You're still not important, was Repeated Blacklisting / IP reputation In-Reply-To: Message-ID: <20090909140448.3707.qmail@simone.iecc.com> >Cleaning up a block of IPs previously used by shady characters has a >real cost, both in time and money. The argument as I see it is who >bears the responsibility and cost of that cleanup. ... and as we all know the fundamental axiom of Internet economics is to foist of as many of your costs as possible on someone else. If you get a new chunk of IP space, you find that it's listed in a lot of private blacklists, and you're not able to get them to unlist you, the reasonable conclusion is that they DO NOT CARE that you can't send them mail. A way to get them to care is to get their own customers, i.e., the people to whom you are trying to send the mail, to complain to their mail managers. If that doesn't work, it either means that the managers are incompetent, or that the recipients also DO NOT CARE that you can't send them mail. I would guess that the latter situation occurs a lot more than the former. Telling people to time out their listings automatically is a non-starter, because they will find nearly all of them are still spamming or sending no mail at all, and an infinitesimal trickle switched to sending legit mail. Who's going to do that? Spam sucks, largely because spam is one of the most egregious cases of foisting off costs on others. If you get a toxic block, find a creative lawyer and sue the former assignee for fraudulent transfer or something. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. From jgreco at ns.sol.net Wed Sep 9 09:20:15 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 9 Sep 2009 09:20:15 -0500 (CDT) Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AA7B5B7.3090309@ttec.com> from "Joe Maimon" at Sep 09, 2009 10:03:35 AM Message-ID: <200909091420.n89EKFb7076223@aurora.sol.net> > John, > > ARIN's role as the entity engaged in legal contractual relationship with > the previous owners of the space puts it in the position to insert > enforceable contract clauses to deter and/or mitigate "graffiti" in > allocations. That's complicated. How do you define "graffiti"? Just for starters. Given that even a whitehat network can generate occasional complaints, and most commercial networks generate various levels of cruft, would you consider it "graffiti" if a block of IP space assigned to a hotel wifi network in Seattle got itself permanently ACL'ed by a college in Miami, when someone inadvertently omitted the port 25 filter, and as a result, the mail admins in Miami judged that the likelihood of ever receiving legitimate mail from there was about 0.0001%? How would you even know? > Policy proposals probably are not required for this. > > Space originally from outside ARIN, thats another kettle of fish. > > ARIN is also in the position to refuse allocations for entities who dont > clean up after themselves. Policy likely required. How exactly do you do that? Spammers don't mind submitting fraudulent applications. How does ARIN tell that SpamNetA is actually the same operation as FooIspB, even though they might be legally registered as different companies? > And finally, if this problem continues to worsen (as it likely will when > greenfield becomes scarce), a viable business opportunity should emerge > for reputable organizations to do cleanup on behalf of the new owners, > for a reasonable fee/retainer and after suitable financial/contractual > guarantees. > > Cost of business, efficiency of scale and all that. Perhaps the bill > could even be sent to the previous owners. That's likely to stand up in court. Not. > Operationally, I dont see how the problem can be mitigated solely by > those who are already informed. I agree that it's problematic. ... 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 frnkblk at iname.com Wed Sep 9 09:43:57 2009 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 9 Sep 2009 09:43:57 -0500 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AA69EDF.7040703@west.net> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <4AA69EDF.7040703@west.net> Message-ID: Right on point -- we have a long list of manually entered netblocks in our spam appliance's blacklist that we've accumulated over time. Besides the mistakes we've made, we've had to delist perhaps 5 over the last 2 years, none due to ARIN reallocations. Most times it's our customer calling our helpdesk and saying "I can't get an e-mail from so-and-so". There's a strong (time resource) disincentive for us to review netblocks and then delist them. Ideally our spam appliance vendor would show us a top ten of non-hit netblocks and we would remove them then (i.e. if no one has hit an IP in that range for a month, the spammer has probably moved on), or as another person suggested, just have the spam appliance age them out (change the action applied from "blocked" to "do nothing". One of the potential community-based approaches would be to have a hosted RBL, with a 'view' for each SP or enterprise. That is, each RBL would be unique, but if I trusted organization B, I could request to use their RBL entries, too. Rather than managing a manual list, it would be managed on the web with more management tools: - search by date added, size of netblock, hits, etc. - auto expiration/aging - notification if netblock assigned to a new owner - comparison against other RBLs (no use having it on my company's RBL is Spamhaus has added it) than an admin of a small operation would likely have. Contact info could be made available, mechanism to request delisting, etc. Frank -----Original Message----- From: Jay Hennigan [mailto:jay at west.net] Sent: Tuesday, September 08, 2009 1:14 PM To: John Curran Cc: nanog at nanog.org Subject: Re: Repeated Blacklisting / IP reputation John Curran wrote: > Folks - > > It appears that we have a real operational problem, in that ARIN > does indeed reissue space that has been reclaimed/returned after > a hold-down period, and but it appears that even once they are > removed from the actual source RBL's, there are still ISP's who > are manually updating these and hence block traffic much longer > than necessary. > > I'm sure there's an excellent reason why these addresses stay > blocked, but am unable to fathom what exactly that is... > Could some folks from the appropriate networks explain why > this is such a problem and/or suggest additional steps that > ARIN or the receipts should be taking to avoid this situation? I don't think there is an excellent reason, more likely inertia and no real incentive to put forth the effort to proactively remove addresses. Many ISPs and organizations have their own private blocklists not associated with the widely known DNSBLs. Typically during or immediately after a spam run the mail administrator will manually add offending addresses or netblocks. Spamtrap hits may do this automatically. There isn't any real incentive for people to go back and remove addresses unless they're notified by their own customers that legitimate mail coming from those addresses is being blocked. Because these blocklists are individually maintained, there is no central registry or means to "clean them up" when an IP assignment changes. To make matters worse, some organizations may simply ACL the IP space so that the TCP connection is never made in the first place (bad, looks like a network problem rather than deliberate filtering), some may drop it during SMTP with no clear indication as to the reason (less bad, as there is at least a hint that it could be filtering), and some may actually accept the mail and then silently discard it (worst). In addition there are several DNSBLs with different policies regarding delisting. Some just time out after a period of time since abuse was detected. Some require action in the form of a delisting request. Some require a delisting request and a time period with no abuse. Some (the old SPEWS list) may not be easily reached or have well defined policies. In meatspace, once a neighborhood winds up with a reputation of being rife with drive-by shootings, gang activity and drug dealing it may take a long time after the last of the graffiti is gone before some cab drivers will go there. -- 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 Skywing at valhallalegends.com Wed Sep 9 12:08:18 2009 From: Skywing at valhallalegends.com (Skywing) Date: Wed, 9 Sep 2009 12:08:18 -0500 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <28880400.269001252443527011.JavaMail.root@zimbra>, Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D60173755CACA6@caralain.haven.nynaeve.net> What's to stop spammers from doing this to cycle through blocks in rapid-fashion? This proposal seems easily abusable to me. - S ________________________________________ From: Peter Beckman [beckman at angryox.com] Sent: Tuesday, September 08, 2009 10:04 PM To: Tom Pipes Cc: nanog at nanog.org Subject: Re: Repeated Blacklisting / IP reputation How about a trial period from ARIN? You get your IP block, and you get 30 days to determine if it is "clean" or not. Do some testing, check the blacklists, do some magic to see if there are network-specific blacklists that might prevent your customers from sending or receiving email/web/other connections with that new IP block. If there are problems, go back to ARIN and show them your work and if they can verify your work (or are simply lazy) you get a different block. ARIN puts the block into another quiet period. Maybe they use the work you did to clean up the block, maybe they don't. Cleaning up a block of IPs previously used by shady characters has a real cost, both in time and money. The argument as I see it is who bears the responsibility and cost of that cleanup. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From sethm at rollernet.us Wed Sep 9 12:15:58 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 09 Sep 2009 10:15:58 -0700 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D60173755CACA6@caralain.haven.nynaeve.net> References: <28880400.269001252443527011.JavaMail.root@zimbra>, <982D8D05B6407A49AD506E6C3AC8E7D60173755CACA6@caralain.haven.nynaeve.net> Message-ID: <4AA7E2CE.8050307@rollernet.us> Skywing wrote: > What's to stop spammers from doing this to cycle through blocks in rapid-fashion? > > This proposal seems easily abusable to me. > Oh, I don't know, maybe ARIN staff can say no? The process is heavy with human interaction, there is nothing "rapid" about it, and bears no comparison to the automated process of registering a domain name. You'd know that if you ever had to make a request for a number resource from ARIN. ~Seth From martin at theicelandguy.com Wed Sep 9 14:13:44 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Wed, 9 Sep 2009 15:13:44 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AA7E2CE.8050307@rollernet.us> References: <28880400.269001252443527011.JavaMail.root@zimbra> <982D8D05B6407A49AD506E6C3AC8E7D60173755CACA6@caralain.haven.nynaeve.net> <4AA7E2CE.8050307@rollernet.us> Message-ID: On Wed, Sep 9, 2009 at 1:15 PM, Seth Mattinen wrote: > Skywing wrote: > > What's to stop spammers from doing this to cycle through blocks in > rapid-fashion? > > > > This proposal seems easily abusable to me. > > > > Oh, I don't know, maybe ARIN staff can say no? The process is heavy with > human interaction, there is nothing "rapid" about it, and bears no > comparison to the automated process of registering a domain name. You'd > know that if you ever had to make a request for a number resource from > ARIN. > The problem of tainted ipv4 allocations probably grows from here since at some point in the near future there isn't going to be much left in terms of "clean" space to allocate. We're running out of v4 addresses in case anyone forgot. Not sure that this is an ARIN problem more than an operational problem since RBL's are opt-in. An effort to identify RBL's that are behaving poorly is probably more interesting at this point, no? Best Regards, Marty > ~Seth > > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From jcurran at arin.net Wed Sep 9 15:27:27 2009 From: jcurran at arin.net (John Curran) Date: Wed, 9 Sep 2009 16:27:27 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <20090908212004.GA16994@gweep.net> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <20090908212004.GA16994@gweep.net> Message-ID: <3DD8491D-9A0F-431D-9031-D9495265564F@arin.net> On Sep 8, 2009, at 5:20 PM, Joe Provo wrote: > > On Tue, Sep 08, 2009 at 01:43:39PM -0400, John Curran wrote: > [snip] >> Could some folks from the appropriate networks explain why >> this is such a problem and/or suggest additional steps that >> ARIN or the receipts should be taking to avoid this situation? > > RSS feed of whois churn? Tighter whois:irr coupling headed toward > the ripe model such that irr-oriented tools can be applied to the > problem? Joe - The RSS feed for "as-issued" blocks exists today, so RBL & private list operators can practice good hygiene as desired: Announcement: Feed: Note that this is post-issuance, not as reclaimed/recovered because we do allow non-payment blocks to be recovered by coming current on payment, and thus it's not safe to presume that they're always issued to a new organization. With respect to moving towards tighter whois:IRR coupling, is there community desire for such in this region, and does that address this problem? e.g. Are blocks reissued in the RIPE region "cleaner" due to the tighter Whois:IRR linkage? Thanks! /John John Curran President and CEO ARIN From Valdis.Kletnieks at vt.edu Wed Sep 9 16:02:29 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 09 Sep 2009 17:02:29 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: Your message of "Wed, 09 Sep 2009 15:13:44 EDT." References: <28880400.269001252443527011.JavaMail.root@zimbra> <982D8D05B6407A49AD506E6C3AC8E7D60173755CACA6@caralain.haven.nynaeve.net> <4AA7E2CE.8050307@rollernet.us> Message-ID: <30682.1252530149@turing-police.cc.vt.edu> On Wed, 09 Sep 2009 15:13:44 EDT, Martin Hannigan said: > Not sure that this is an ARIN problem more than an operational problem since > RBL's are opt-in. An effort to identify RBL's that are behaving poorly is > probably more interesting at this point, no? I suspect the problem isn't poor RBLs, it's all the little one-off block lists out there. The NANOG lurker in the next cubicle informs me that we currently carry an astounding 52,274 block entries (to be fair, a large portion is due to our vendor's somewhat-lacking block list - if we decide a /24 is bad, but then want to whitelist 1 IP, we have to de-aggregate to 254 black entries instead). We get maybe 5-6 blocked e-mail complaints a day - which *still* represents better performance for our end users than if we didn't carry around that many blocks (for comparison, we get at least 3-4 times that many tickets a day for people who forgot their e-mail password and need a reset). And yes, it's *very* intentional that we have a business process in place that makes it trivially easy for one of our users to open a "I can't get e-mail from " and get it taken care of *very* quickly, but opening a "We can't send e-mail to your users" is a lot more challenging and time consuming (at least for the complaintant). Now, if we didn't have a dedicated, hard-working, and skeptical lurker in the next cubicle, our block list *would* be a mess.. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jcdill.lists at gmail.com Wed Sep 9 17:39:55 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Wed, 09 Sep 2009 15:39:55 -0700 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <200909081950.n88Jo2Dl094175@aurora.sol.net> References: <200909081950.n88Jo2Dl094175@aurora.sol.net> Message-ID: <4AA82EBB.9080708@gmail.com> Joe Greco wrote: >> John Curran wrote: >> >>> On Sep 8, 2009, at 2:18 PM, JC Dill wrote: >>> >>> >>>> It seems simple and obvious that ARIN, RIPE, et. al. should >>>> determine the blacklist state of a reclaimed IP group and ensure >>>> that the IP group is usable before re-allocating it. >>>> >>>> When IPs are reclaimed, first check to see if the reclaimed IPs are >>>> on any readily checked RBL or private blacklist of major ISPs, >>>> corporations, universities, etc. If so, work with those groups to >>>> get the blocks removed *prior* to reissuing the IPs to a new >>>> entity. Before releasing the IPs to a new entity, double check that >>>> they are not being blocked (that any promises to remove them from >>>> a blacklist were actually fulfilled). Hold the IPs until you have >>>> determined that they aren't overly encumbered with prior blacklist >>>> blocks due to poor behavior of the previous entity. (The same >>>> should be done before allocating out of a new IP block, such as >>>> when you release the first set of IPs in a new /8.) >>>> >>> In this case, it's not the RBL's that are the issue; the address >>> block in question isn't on them. It's the ISP's and other firms >>> using manual copies rather than actually following best practices. >>> >> It's not that hard to make a list of the major ISPs, corporations, >> universities (entities with a large number of users), find willing >> contacts inside each organization (individual or role addresses you can >> email, and see if the email bounces, and who will reply if the email is >> received) and run some automated tests to see if the IPs are being >> blocked. In your follow-up email to me, you said you check "dozens" of >> RBLs - that is clearly insufficient - probably by an order of magnitude >> - of the entities you should check with. The number should be >> "hundreds". A reasonably cluefull intern can provide you with a >> suitable list in short order, probably less than 1 day, and find >> suitable contacts inside each organization in a similar time frame - it >> might take a week total to build a list of ~500 entities and associated >> email addresses. Because of employee turn-over the list will need to be >> updated, ~1-10 old addresses purged and replaced with new ones on a >> monthly basis. >> > > Really? And you expect all these organizations to do ... what? Hire an > intern to be permanent liaison to ARIN? I'm expecting ARIN to spend a few staff-hours (utilizing low-cost labor such as an intern) to setup the list for ARIN to use to check the status of returned IPs, and spend a few more staff hours setting up an automated system to utilize the list prior to releasing reclaimed IPs for reallocation. If, when using the list they discover out-dated addresses, spend a moment to find an updated address for that sole network. Most of this can easily be automated once setup - the only things that need to be dealt with by hand would be purging the list of outdated contacts and finding new ones, which shouldn't take much time since it's not a very large list, and many of the contacts would (over time) become role accounts that don't become outdated as often or as easily as personal accounts. Most of this is done by ARIN, not by the organizations they contact. All each organization has to do is permit one employee or role account to be used for IP block testing, and reply to test emails. The effort to setup a role account and autoresponder is minimal. > Answer queries to whether or not > IP space X is currently blocked (potentially at one of hundreds or > thousands of points in their system, which corporate security may not > wish to share, or even give "some random intern" access to)? Process > reports of new ARIN delegations? What are you thinking they're going to > do? And why should they care enough to do it? > Because if they don't, they are needlessly blocking re-allocated IP addresses, potentially blocking their own users from receiving wanted email. Organizations could (and should) setup a role account and auto-responder for this purpose. >>>> Why isn't this being done now? >>>> >>>> Issuing reclaimed IPs is a lot like selling a used car, except that >>>> the buyer has no way to "examine" the state of the IPs you will >>>> issue them beforehand. Therefore it's up to you (ARIN, RIPE, et. >>>> al.) to ensure that they are "just as good" as any other IP block. >>>> It is shoddy business to take someone's money and then sneakily >>>> give them tainted (used) goods and expect them to deal with >>>> cleaning up the mess that the prior owner made, especially when you >>>> charge the same rate for untainted goods! >>>> >>> Not applicable in this case, as noted above. >>> >> What do you mean, "not applicable"? You take the money and issue IPs. >> There is no way for the "buyer" to know before hand if the IPs are >> "tainted" (used) or new. It is up to you (ARIN) to ensure that the >> goods (IPs) are suitable for the intended use. My analogy is entirely >> applicable, and I'm amazed you think otherwise. >> > > WOW. That's a hell of a statement. There is absolutely nothing that > ARIN can do if I decide I'm going to have our servers block connections > from networks ending in an odd bit. 100% correct. What they *can* do is determine IF the address is currently being blocked *before* they issue it to a new entity. > Nobody is in a position to ensure > that ANY Internet connection or IP space is "suitable for the intended > use." Welcome to the Internet. > They can (and IMHO should) determine the state it is in before they reallocate it. What happens next is obviously unpredictable but in reality an IP that isn't being blocked today and isn't being used (by anyone) is highly unlikely to be widely blocked between today and the day ARIN releases it for allocation to a new entity. They can hold IPs that are not suitable for re-allocation, or at least make the status of the IPs known to the new entity before asking the entity to take on the IP block, and perhaps offering a fee discount for "tainted" addresses. (Some users may not care if the IPs are "tainted", if, for instance they plan to use the IPs for a DUL pool. I have a friend who gets $5 off his cell phone bill because he has a phone number that starts with 666 - a number that many people prefer to avoid but which works fine for his purposes and he's quite happy to get the discount. :-) > >>> So, back to the question: could someone explain why they've got >>> copies of the RBL's in their network which don't get updated on any >>> reasonable refresh interval? (weekly? monthly?) >>> >> The "why" really isn't at issue - it happens and it's going to keep >> happening. The question is what are you (ARIN) going to do about it? >> >> Give me the serenity to accept the things I cannot change, >> The courage to change the things I can, >> And the wisdom to know the difference. >> >> You (ARIN et. al.) don't have any ability to change the why. What you >> can change is how you go about determining if an IP block is suitable >> for reallocation or not, and what steps you take to repair IP blocks >> that aren't suitable for reallocation. >> > > So, in addition to just registering IP space, it's also their job to clean > it up? > Who do you propose clean up the mess? The people who made the mess (spammers) won't clean it up. Someone has to clean it up. The IPs are in ARIN's possession now. Why should it become someone else's problem (the entity they allocate it to) to clean it up? They didn't do anything to taint the space, and they request (and expect) to get clean and usable IPs, not tainted IPs. ARIN shouldn't allocate previously allocated IPs until they know the IPs are not widely blocked. Or to *at the very least* ARIN should disclose what they know about the IP space before they make it someone else's problem, and give the requesting entity an option to request a new/clean/unused/unblocked IP block instead. > I'm sorry, I agree that there's a problem, but this just sounds like it > isn't feasible. IMHO passing the problem on to someone else is just plain wrong. It punishes an innocent party, and it doesn't scale. There are other options, better options. In commerce it is a violation of the UCC to knowingly or negligently sell the customer something that the seller knows (or should have known) doesn't serve the customer's stated purpose, and that the customer has no way of knowing (no way to do "due diligence" before completing the sale) is unsuitable for their needs. ARIN's IP registry probably doesn't fall under the aegis of the UCC, but that doesn't excuse the practice. I am not a lawyer, but it doesn't take a law degree to be able to tell right from wrong. Issuing previously-issued and tainted IPs to an entity that requested and is expecting untainted and usable IPs is clearly wrong. How ARIN plans to resolve this can be debated, but NOT solving this and just expecting someone else (the unlucky entity who is issued the tainted IPs) to solve it for them is not an honorable approach. Similarly, asking on NANOG "why do tainted IPs linger on blocklists" isn't going to solve the problem. ARIN can't change the why - what they can change is what ARIN does about it. There are better options - they can make an effort to clean up the IPs prior to reallocation; they can disclose the IP status before reallocation and give an option for a new IP block; or they can simply declare the IPs "toxic" and hold them rather than reallocate them. Giving the customer a dead parrot when they expected a live one (Beautiful Plumage!) is funny only in a Monty Python skit. http://www.youtube.com/watch?v=4vuW6tQ0218 http://www.readnews.com/funny/story3.html jc From jay at west.net Wed Sep 9 18:13:18 2009 From: jay at west.net (Jay Hennigan) Date: Wed, 09 Sep 2009 16:13:18 -0700 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AA82EBB.9080708@gmail.com> References: <200909081950.n88Jo2Dl094175@aurora.sol.net> <4AA82EBB.9080708@gmail.com> Message-ID: <4AA8368E.5040300@west.net> JC Dill wrote: > Joe Greco wrote: >> Answer queries to whether or not >> IP space X is currently blocked (potentially at one of hundreds or >> thousands of points in their system, which corporate security may not >> wish to share, or even give "some random intern" access to)? Process >> reports of new ARIN delegations? What are you thinking they're going to >> do? And why should they care enough to do it? >> > > Because if they don't, they are needlessly blocking re-allocated IP > addresses, potentially blocking their own users from receiving wanted > email. Organizations could (and should) setup a role account and > auto-responder for this purpose. Perhaps they should, but until there is sufficient pain from their own users complaining about it there is no financial motivation to do so, and therefore many will not. I would guess that there are thousands of individual blocklists to this day blocking some of Sanford Wallace's and AGIS's old netblocks. As for a role account, there is "postmaster". I would think that the best hope in the real world, rather than an autoresponder would be an RFC that clearly defines text accompanying an SMTP rejection notice triggered by a blocklist, detailing the blocklist and contact for removal. Perhaps encouraging those who code MTAs and DNSBL hooks into them to include such in the configuration files would be a good start. This still puts the onus on the sender or inheritor of the tainted netblock, but makes the search less painful and perhaps even somewhat able to be scripted. Note that this thread deals mostly with SMTP issues regarding DNSBLs, as those are the most common trouble point. We should also consider other forms of blocking/filtering of networks reclaimed from former virus/malware/DoS sources. -- 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 drc at virtualized.org Wed Sep 9 18:38:57 2009 From: drc at virtualized.org (David Conrad) Date: Wed, 9 Sep 2009 16:38:57 -0700 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <28880400.269001252443527011.JavaMail.root@zimbra> <982D8D05B6407A49AD506E6C3AC8E7D60173755CACA6@caralain.haven.nynaeve.net> <4AA7E2CE.8050307@rollernet.us> Message-ID: On Sep 9, 2009, at 12:13 PM, Martin Hannigan wrote: > The problem of tainted ipv4 allocations probably grows from here > since at > some point in the near future there isn't going to be much left in > terms of > "clean" space to allocate. We're running out of v4 addresses in case > anyone > forgot. Somewhat apropos to this discussion: http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/ Regards, -drc From brunner at nic-naa.net Wed Sep 9 20:30:56 2009 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 09 Sep 2009 21:30:56 -0400 Subject: colo space in vancouver, bc? Message-ID: <4AA856D0.70504@nic-naa.net> Hi, I've a project that needs approximately a rack, in the Vancouver, BC area. Suggestions? Eric From jcdill.lists at gmail.com Wed Sep 9 20:52:49 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Wed, 09 Sep 2009 18:52:49 -0700 Subject: RFC 1149 put into practice Message-ID: <4AA85BF1.6010902@gmail.com> http://news.yahoo.com/s/nm/20090909/od_nm/us_safrica_pigeon_2 JOHANNESBURG (Reuters) ? A South African information technology company on Wednesday proved it was faster for them to transmit data with a carrier pigeon than to send it using Telkom , the country's leading internet service provider. Internet speed and connectivity in Africa's largest economy are poor because of a bandwidth shortage. It is also expensive. Local news agency SAPA reported the 11-month-old pigeon, Winston, took one hour and eight minutes to fly the 80 km (50 miles) from Unlimited IT's offices near Pietermaritzburg to the coastal city of Durban with a data card was strapped to his leg. Including downloading, the transfer took two hours, six minutes and 57 seconds -- the time it took for only four percent of the data to be transferred using a Telkom line. SAPA said Unlimited IT performed the stunt after becoming frustrated with slow internet transmission times. The company has 11 call-centers around the country and regularly sends data to its other branches. Telkom could not immediately be reached for comment. Internet speed is expected to improve once a new 17,000 km underwater fiber optic cable linking southern and East Africa to other networks becomes operational before South Africa hosts the soccer World Cup next year. Local service providers are currently negotiating deals for more bandwidth. From ALanstein at FireEye.com Wed Sep 9 21:18:34 2009 From: ALanstein at FireEye.com (Alex Lanstein) Date: Wed, 9 Sep 2009 19:18:34 -0700 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <148476.263921252421878121.JavaMail.root@zimbra><4AA67551.3050402@gmail.com>, Message-ID: <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> Along the same lines, I noticed that the worst Actor in recent memory (McColo - AS26780) stopped paying their bills to ARIN and their addresses have been returned to the pool. It's my opinion that a very select number of CIDR blocks (another example being the ones belonging to Cernel/InternetPath/Atrivo/etc, if it were ever fully extinguished) are, and forever will be, completely toxic and unusable to any legitimate enterprise. Arguments could be made that industry blacklists can and should be more flexible, but from the considerably more innocuous case in this thread, that is apparently not the modus operandi I'm curious to hear ARIN's thoughts, as well as the general NANOG populous, on whether you think it would be beneficial/possible to allocate the former blocks to $internetgoodguys (Shadowserver, Cymru, REN-ISAC, etc) for sinkholing and distribution of the data. /Many/ infected bots remain stranded post-McColo; large amounts of infection intelligence could easily be generated by such a move, and seemingly, would hurt no one. Although I'm in favor of revocation of allocations, similar to what happens in the DNS space for "bad guys", this sort of move could obviously only happen if appropriate AUP sections were added into to the contracts (which I don't see happening). In the interm? This seems like a golden opportunity to gather some serious intel. Thoughts? Regards, Alex Lanstein ________________________________________ From: John Curran [jcurran at arin.net] Sent: Tuesday, September 08, 2009 1:43 PM To: nanog at nanog.org Subject: Re: Repeated Blacklisting / IP reputation Folks - It appears that we have a real operational problem, in that ARIN does indeed reissue space that has been reclaimed/returned after a hold-down period, and but it appears that even once they are removed from the actual source RBL's, there are still ISP's who are manually updating these and hence block traffic much longer than necessary. I'm sure there's an excellent reason why these addresses stay blocked, but am unable to fathom what exactly that is... Could some folks from the appropriate networks explain why this is such a problem and/or suggest additional steps that ARIN or the receipts should be taking to avoid this situation? Thanks! /John John Curran President and CEO ARIN On Sep 8, 2009, at 11:16 AM, Ronald Cotoni wrote: > Tom Pipes wrote: >> Greetings, >> >> We obtained a direct assigned IP block 69.197.64.0/18 from ARIN in >> 2008. This block has been cursed (for lack of a better word) since >> we obtained it. It seems like every customer we have added has had >> repeated issues with being blacklisted by DUL and the cable >> carriers. (AOL, AT&T, Charter, etc). I understand there is a >> process to getting removed, but it seems as if these IPs had been >> used and abused by the previous owner. We have done our best to >> ensure these blocks conform to RFC standards, including the proper >> use of reverse DNS pointers. >> >> I can resolve the issue very easily by moving these customers over >> to our other direct assigned 66.254.192.0/19 block. In the last >> year I have done this numerous times and have had no further issues >> with them. >> >> My question: Is there some way to clear the reputation of these >> blocks up, or start over to prevent the amount of time we are >> spending with each customer troubleshooting unnecessary RBL and >> reputation blacklisting? >> I have used every opportunity to use the automated removal links >> from the SMTP rejections, and worked with the RBL operators >> directly. Most of what I get are cynical responses and promises >> that it will be fixed. >> If there is any question, we perform inbound and outbound scanning >> of all e-mail, even though we know that this appears to be >> something more relating to the block itself. >> >> Does anyone have any suggestions as to how we can clear this issue >> up? Comments on or off list welcome. >> >> Thanks, >> >> --- Tom Pipes T6 Broadband/ Essex Telcom Inc tom.pipes at t6mail.com >> >> > Unfortunately, there is no real good way to get yourself completely > delisted. We are experiencing that with a /18 we got from ARIN > recently and it is basically the RBL's not updating or perhaps they > are not checking the ownership of the ip's as compared to before. > On some RBL's, we have IP addresses that have been listed since > before the company I work for even existed. Amazing right? > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From fergdawgster at gmail.com Wed Sep 9 21:37:01 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 9 Sep 2009 19:37:01 -0700 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> Message-ID: <6cd462c00909091937s59a7d354haa6bcd2f98f8ec8e@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Sep 9, 2009 at 7:18 PM, Alex Lanstein wrote: > Along the same lines, I noticed that the worst Actor in recent memory > (McColo - AS26780) stopped paying their bills to ARIN and their addresses > have been returned to the pool. > > It's my opinion that a very select number of CIDR blocks (another example > being the ones belonging to Cernel/InternetPath/Atrivo/etc, if it were > ever fully extinguished) are, and forever will be, completely toxic and > unusable to any legitimate enterprise. Arguments could be made that > industry blacklists can and should be more flexible, but from the > considerably more innocuous case in this thread, that is apparently not > the modus operandi > With regards to Cernel/Internet Path/UkrTelGrp, it needs to be "extinguished" first. :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFKqGZIq1pz9mNUZTMRAnE3AKCL76mNabIzAf5FCWRfqci3YW5QKACgtLNJ AXSIGuT1tIe0R+tm+VL/Flc= =NYQS -----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 devangnp at gmail.com Wed Sep 9 21:52:22 2009 From: devangnp at gmail.com (devang patel) Date: Wed, 9 Sep 2009 20:52:22 -0600 Subject: BGP Confederation over Route Reflector Message-ID: Hello, What are the advantages of BGP Confederation over Route Reflector? I mean when one should decide to deploy BGP Confederation over Route Reflector deployment? Thanks, Devang Patel From leo.vegoda at icann.org Wed Sep 9 22:30:02 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 9 Sep 2009 20:30:02 -0700 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> References: <148476.263921252421878121.JavaMail.root@zimbra><4AA67551.3050402@gmail.com>, <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> Message-ID: On Sep 9, 2009, at 7:18 PM, Alex Lanstein wrote: > Along the same lines, I noticed that the worst Actor in recent > memory (McColo - AS26780) stopped paying their bills to ARIN and > their addresses have been returned to the pool. > > It's my opinion that a very select number of CIDR blocks (another > example being the ones belonging to Cernel/InternetPath/Atrivo/etc, > if it were ever fully extinguished) are, and forever will be, > completely toxic and unusable to any legitimate enterprise. > Arguments could be made that industry blacklists can and should be > more flexible, but from the considerably more innocuous case in this > thread, that is apparently not the modus operandi Putting these addresses back into use does not mean that they have to be allocated to networks where they'll number mail servers. ARIN staff is doubtless aware of the history of these blocks and will presumably do their best to allocate them to networks that aren't intended to host mail servers. Regards, Leo From martin at theicelandguy.com Wed Sep 9 22:41:26 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Wed, 9 Sep 2009 23:41:26 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> Message-ID: On Wed, Sep 9, 2009 at 11:30 PM, Leo Vegoda wrote: > On Sep 9, 2009, at 7:18 PM, Alex Lanstein wrote: > > > Along the same lines, I noticed that the worst Actor in recent > > memory (McColo - AS26780) stopped paying their bills to ARIN and > > their addresses have been returned to the pool. > > > > It's my opinion that a very select number of CIDR blocks (another > > example being the ones belonging to Cernel/InternetPath/Atrivo/etc, > > if it were ever fully extinguished) are, and forever will be, > > completely toxic and unusable to any legitimate enterprise. > > Arguments could be made that industry blacklists can and should be > > more flexible, but from the considerably more innocuous case in this > > thread, that is apparently not the modus operandi > > Putting these addresses back into use does not mean that they have to > be allocated to networks where they'll number mail servers. ARIN staff > is doubtless aware of the history of these blocks and will presumably > do their best to allocate them to networks that aren't intended to > host mail servers. > > Regards, > > Leo > > Not sure when ICANN got into the business of economic bailouts, but the mechanism that ICANN has defined seems patently unfair. Determining who is worthy of allocations based on a class without community input into a policy debate is "bad". ObOps: Chasing down all of this grunge ain't cheap or fair. Best, Martin -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From marka at isc.org Wed Sep 9 22:48:18 2009 From: marka at isc.org (Mark Andrews) Date: Thu, 10 Sep 2009 13:48:18 +1000 Subject: Repeated Blacklisting / IP reputation In-Reply-To: Your message of "Wed, 09 Sep 2009 20:30:02 MST." References: <148476.263921252421878121.JavaMail.root@zimbra><4AA67551.3050402@gmail.com>, <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> Message-ID: <200909100348.n8A3mIfm062626@drugs.dv.isc.org> In message , Leo Vegoda writes: > On Sep 9, 2009, at 7:18 PM, Alex Lanstein wrote: > > > Along the same lines, I noticed that the worst Actor in recent =20 > > memory (McColo - AS26780) stopped paying their bills to ARIN and =20 > > their addresses have been returned to the pool. > > > > It's my opinion that a very select number of CIDR blocks (another =20 > > example being the ones belonging to Cernel/InternetPath/Atrivo/etc, =20 > > if it were ever fully extinguished) are, and forever will be, =20 > > completely toxic and unusable to any legitimate enterprise. =20 > > Arguments could be made that industry blacklists can and should be =20 > > more flexible, but from the considerably more innocuous case in this =20 > > thread, that is apparently not the modus operandi > > Putting these addresses back into use does not mean that they have to =20 > be allocated to networks where they'll number mail servers. ARIN staff =20 > is doubtless aware of the history of these blocks and will presumably =20 > do their best to allocate them to networks that aren't intended to =20 > host mail servers. > > Regards, > > Leo What a load of rubbish. How is ARIN or any RIR/LIR supposed to know the intent of use? Push has come to shove and those that have incorrectly treated address assignment as immutable will need to correct their ways (excluding legacy assignments). This will be painful for some. Note we all could start using IPv6 and avoid this problem altogether. There is nothing stopping us using IPv6 especially for MTA's. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jvargas at crypticstudios.com Thu Sep 10 02:53:48 2009 From: jvargas at crypticstudios.com (Jake Vargas) Date: Thu, 10 Sep 2009 00:53:48 -0700 Subject: Traffic Shaping on ISPs Message-ID: Hi Nanog, We have recently introduced a MMORPG (online game) to the Internet. We currently are receiving many complaints from UK (and a few EU) customers of sudden traffic loss or slowness which makes the game unplayable. The complaints come through like clockwork from 6:00PM to 11:59PM (GMT). Our chief complaint customers originate from British Telecom who equate to an aggregate estimate of 200Mbps during said hours. Is there any advice, known traffic shaping bucket or predictive traffic shaping of sorts that could be impeding our customers use over our ports TCP/7000-7500? Would our traffic be considered P2P traffic and throttled once inside their ASN (or even outside)? Understandably ISPs would want to protect the precious bandwidth and IP services. We are based in US but I am at a wits end on route shifting over our major ISP connections and finding no resolution. Is there anyone who has experienced cross-the-pond issues such as this and had had luck in finding a resolution or at least an answer? (Maybe a form to fill out for cut-through allowance/whitelist for our prefix and port range, if such a thing existed?). Much obliged, Jake From mcalpha at mcalpha.net Thu Sep 10 03:50:53 2009 From: mcalpha at mcalpha.net (Lasse Schmidt) Date: Thu, 10 Sep 2009 10:50:53 +0200 Subject: Traffic Shaping on ISPs In-Reply-To: References: Message-ID: <001201ca31f3$d092dc60$71b89520$@net> Hi Jake While I cannot confirm officially, there is a lot of rumors, that several larger UK ISP's are throttling traffic at that time period. I am not sure who to contact, but the individual ISP's to solve this, from your point, maybe another NANOG'er knows. Lasse -----Original Message----- From: Jake Vargas [mailto:jvargas at crypticstudios.com] Sent: 10. september 2009 09:54 To: 'nanog at nanog.org' Subject: Traffic Shaping on ISPs Hi Nanog, We have recently introduced a MMORPG (online game) to the Internet. We currently are receiving many complaints from UK (and a few EU) customers of sudden traffic loss or slowness which makes the game unplayable. The complaints come through like clockwork from 6:00PM to 11:59PM (GMT). Our chief complaint customers originate from British Telecom who equate to an aggregate estimate of 200Mbps during said hours. Is there any advice, known traffic shaping bucket or predictive traffic shaping of sorts that could be impeding our customers use over our ports TCP/7000-7500? Would our traffic be considered P2P traffic and throttled once inside their ASN (or even outside)? Understandably ISPs would want to protect the precious bandwidth and IP services. We are based in US but I am at a wits end on route shifting over our major ISP connections and finding no resolution. Is there anyone who has experienced cross-the-pond issues such as this and had had luck in finding a resolution or at least an answer? (Maybe a form to fill out for cut-through allowance/whitelist for our prefix and port range, if such a thing existed?). Much obliged, Jake __________ Information from ESET Smart Security, version of virus signature database 4412 (20090909) __________ The message was checked by ESET Smart Security. http://www.eset.com __________ Information from ESET Smart Security, version of virus signature database 4412 (20090909) __________ The message was checked by ESET Smart Security. http://www.eset.com From rens at autempspourmoi.be Thu Sep 10 04:05:45 2009 From: rens at autempspourmoi.be (Rens) Date: Thu, 10 Sep 2009 11:05:45 +0200 Subject: Wireless STM-1 link Message-ID: <9138BEE0A93342EBB729FA81440C6B06@EU.corp.clearwire.com> Hi all, I'm encountering a problem with a wireless STM-1 link which has a switch connected at each end. The wireless link has Gigabit Ethernet interfaces and so have my switches. When I ping between the 2 switches via that wireless link I'm getting a lot of pings that are lost. The wireless link is not saturated but I'm thinking it could have to do something with the gigabit interfaces and only having 155Mbps on the link itself? All ideas welcome. Regards, Rens From adam at wispring.com Thu Sep 10 04:44:43 2009 From: adam at wispring.com (Adam Goodman) Date: Thu, 10 Sep 2009 12:44:43 +0300 Subject: Wireless STM-1 link In-Reply-To: <9138BEE0A93342EBB729FA81440C6B06@EU.corp.clearwire.com> References: <9138BEE0A93342EBB729FA81440C6B06@EU.corp.clearwire.com> Message-ID: Sounds like this might be an Ethernet negotiaton problem -------- Sent from my phone On Sep 10, 2009, at 12:05 PM, "Rens" wrote: > Hi all, > > > > I'm encountering a problem with a wireless STM-1 link which has a > switch > connected at each end. > > The wireless link has Gigabit Ethernet interfaces and so have my > switches. > > > > When I ping between the 2 switches via that wireless link I'm > getting a lot > of pings that are lost. > > The wireless link is not saturated but I'm thinking it could have to > do > something with the gigabit interfaces and only having 155Mbps on the > link > itself? > > > > All ideas welcome. > > > > Regards, > > > > Rens > From jvargas at crypticstudios.com Thu Sep 10 04:49:04 2009 From: jvargas at crypticstudios.com (Jake Vargas) Date: Thu, 10 Sep 2009 02:49:04 -0700 Subject: Traffic Shaping on ISPs In-Reply-To: <001201ca31f3$d092dc60$71b89520$@net> References: <001201ca31f3$d092dc60$71b89520$@net> Message-ID: > While I cannot confirm officially, there is a lot of rumors, that several > larger UK ISP's are throttling traffic at that time period. > I am not sure who to contact, but the individual ISP's to solve this, from > your point, maybe another NANOG'er knows. Hi Lasse, Thanks for the reply. We wrote an app to reveal troubles. Just to satisfy any curiosity and get some facts out, I will provide a real world example (1 of many) from a direct test of one of our BT sourced customers (this is from a 08-29 test at ~22:04 hours GMT): Date IP RTT Port ActualRecv NicSent NicRecv 090829 22:04:24 86.128.0.0/10 103.5 80 199 13 214 090829 22:04:24 86.128.0.0/10 103.5 80 199 13 214 090829 22:04:24 86.128.0.0/10 103.5 443 200 12 215 090829 22:04:24 86.128.0.0/10 103.5 443 199 12 214 090829 22:04:24 86.128.0.0/10 103.5 7255 2 2 5 090829 22:04:24 86.128.0.0/10 103.5 7255 3 1 4 090829 22:04:24 86.128.0.0/10 103.5 7003 3 2 5 090829 22:04:24 86.128.0.0/10 103.5 7003 4 1 5 090829 22:04:24 86.128.0.0/10 103.5 7202 27 3 32 090829 22:04:24 86.128.0.0/10 103.5 7202 24 2 29 090829 22:04:24 86.128.0.0/10 103.5 7499 27 3 32 090829 22:04:24 86.128.0.0/10 103.5 7499 25 2 31 090829 22:04:24 86.128.0.0/10 103.5 80 195 13 206 Idle NIC bandwidth Send: 0 KB/sec Recv: 0 KB/sec To remove any doubt we also measured idle bandwidth utilization on the NIC when the test wasn't run to remove any other culprit such as torrent download, A/V streaming and etc in the background. In this case, 0/0 on idle use. All results are in KBytes I withheld the actual IP address of this test and replaced it from the source prefix. We have quite a few iterations of similar results from other source addresses from this prefix alone. All appear to exhibit the same issue. I've already written British Telecom and they never replied. From rens at autempspourmoi.be Thu Sep 10 04:55:40 2009 From: rens at autempspourmoi.be (Rens) Date: Thu, 10 Sep 2009 11:55:40 +0200 Subject: Wireless STM-1 link In-Reply-To: References: <9138BEE0A93342EBB729FA81440C6B06@EU.corp.clearwire.com> Message-ID: All the interfaces are forced to 1Gbps and full duplex. Maybe I should give some extra info. All the traffic seems to pass ok via that link but I have seen that often OSPF adjacencies go down/up , I suspect that the HELLO packets are being dropped that pass via that link. That's why I started to look a little deeper and do some ping tests. -----Original Message----- From: Adam Goodman [mailto:adam at wispring.com] Sent: jeudi 10 septembre 2009 11:45 To: Rens Cc: Subject: Re: Wireless STM-1 link Sounds like this might be an Ethernet negotiaton problem -------- Sent from my phone On Sep 10, 2009, at 12:05 PM, "Rens" wrote: > Hi all, > > > > I'm encountering a problem with a wireless STM-1 link which has a > switch > connected at each end. > > The wireless link has Gigabit Ethernet interfaces and so have my > switches. > > > > When I ping between the 2 switches via that wireless link I'm > getting a lot > of pings that are lost. > > The wireless link is not saturated but I'm thinking it could have to > do > something with the gigabit interfaces and only having 155Mbps on the > link > itself? > > > > All ideas welcome. > > > > Regards, > > > > Rens > From astrodog at gmail.com Thu Sep 10 05:45:04 2009 From: astrodog at gmail.com (Astrodog) Date: Thu, 10 Sep 2009 05:45:04 -0500 Subject: Traffic Shaping on ISPs In-Reply-To: References: <001201ca31f3$d092dc60$71b89520$@net> Message-ID: <2fd864e0909100345x16a456bbxd6a1a51436cce263@mail.gmail.com> BT/Virgin throttling information: http://www.theregister.co.uk/2009/02/11/virgin_media_throttle_extension/ http://www.theregister.co.uk/2008/08/07/bt_samknows_bandwidth_throttling/ http://news.bbc.co.uk/2/hi/technology/8077839.stm http://www.telegraph.co.uk/technology/news/5431052/BT-admits-limiting-download-speeds-and-throttling-iPlayer-traffic.html It looks like the throttling window lines up fairly well with the times you're seeing problems. Now, if that's the throttling, or just BT's network being oversubscribed... who knows. Good luck getting your problem cleared up. ---- Harrison Grundy On Thu, Sep 10, 2009 at 4:49 AM, Jake Vargas wrote: >> While I cannot confirm officially, there is a lot of rumors, that several >> larger UK ISP's are throttling traffic at that time period. >> I am not sure who to contact, but the individual ISP's to solve this, from >> your point, maybe another NANOG'er knows. > > Hi Lasse, > > Thanks for the reply. We wrote an app to reveal troubles. > > Just to satisfy any curiosity and get some facts out, I will provide a real world example (1 of many) from a direct test of one of our BT sourced customers (this is from a 08-29 test at ~22:04 hours GMT): > > Date ? ? ? ? ? ? ? ? ? ?IP ? ? ? ? ? ? ? ? ? ? ?RTT ? ? Port ? ?ActualRecv ? ? ?NicSent NicRecv > 090829 22:04:24 86.128.0.0/10 ? 103.5 ? 80 ? ? ?199 ? ? 13 ? ? ?214 > 090829 22:04:24 86.128.0.0/10 ? ? ? ? ? 103.5 ? 80 ? ? ?199 ? ? 13 ? ? ?214 > 090829 22:04:24 86.128.0.0/10 ? ? ? ? ? 103.5 ? 443 ? ? 200 ? ? 12 ? ? ?215 > 090829 22:04:24 86.128.0.0/10 ? ? ? ? ? 103.5 ? 443 ? ? 199 ? ? 12 ? ? ?214 > 090829 22:04:24 86.128.0.0/10 ? ? ? ? ? 103.5 ? 7255 ? ?2 ? ? ? 2 ? ? ? 5 > 090829 22:04:24 86.128.0.0/10 ? ? ? ? ? 103.5 ? 7255 ? ?3 ? ? ? 1 ? ? ? 4 > 090829 22:04:24 86.128.0.0/10 ? ? ? ? ? 103.5 ? 7003 ? ?3 ? ? ? 2 ? ? ? 5 > 090829 22:04:24 86.128.0.0/10 ? ? ? ? ? 103.5 ? 7003 ? ?4 ? ? ? 1 ? ? ? 5 > 090829 22:04:24 86.128.0.0/10 ? ? ? ? ? 103.5 ? 7202 ? ?27 ? ? ?3 ? ? ? 32 > 090829 22:04:24 86.128.0.0/10 ? ? ? ? ? 103.5 ? 7202 ? ?24 ? ? ?2 ? ? ? 29 > 090829 22:04:24 86.128.0.0/10 ? ? ? ? ? 103.5 ? 7499 ? ?27 ? ? ?3 ? ? ? 32 > 090829 22:04:24 86.128.0.0/10 ? ? ? ? ? 103.5 ? 7499 ? ?25 ? ? ?2 ? ? ? 31 > 090829 22:04:24 86.128.0.0/10 ? ? ? ? ? 103.5 ? 80 ? ? ?195 ? ? 13 ? ? ?206 > Idle NIC bandwidth ?Send: ? ? 0 KB/sec ? Recv: ? ? 0 KB/sec > > To remove any doubt we also measured idle bandwidth utilization on the NIC when the test wasn't run to remove any other culprit such as torrent download, A/V streaming and etc in the background. In this case, 0/0 on idle use. All results are in KBytes > > I withheld the actual IP address of this test and replaced it from the source prefix. We have quite a few iterations of similar results from other source addresses from this prefix alone. All appear to exhibit the same issue. > > I've already written British Telecom and they never replied. > > > From josh.cheney at gmail.com Thu Sep 10 05:47:25 2009 From: josh.cheney at gmail.com (Josh Cheney) Date: Thu, 10 Sep 2009 06:47:25 -0400 Subject: Wireless STM-1 link In-Reply-To: References: <9138BEE0A93342EBB729FA81440C6B06@EU.corp.clearwire.com> Message-ID: <4AA8D93D.8050609@gmail.com> I'm assuming that you have checked all of the wireless parameters (noise floor, signal strength, jitter, etc)? I've seen behavior like this on links where the noise floor has risen to the point where the true signal cannot be distinguished from background noise. Josh Rens wrote: > All the interfaces are forced to 1Gbps and full duplex. > > Maybe I should give some extra info. > All the traffic seems to pass ok via that link but I have seen that often > OSPF adjacencies go down/up , I suspect that the HELLO packets are being > dropped that pass via that link. > > That's why I started to look a little deeper and do some ping tests. > > -----Original Message----- > From: Adam Goodman [mailto:adam at wispring.com] > Sent: jeudi 10 septembre 2009 11:45 > To: Rens > Cc: > Subject: Re: Wireless STM-1 link > > Sounds like this might be an Ethernet negotiaton problem > > -------- > Sent from my phone > > On Sep 10, 2009, at 12:05 PM, "Rens" wrote: > >> Hi all, >> >> >> >> I'm encountering a problem with a wireless STM-1 link which has a >> switch >> connected at each end. >> >> The wireless link has Gigabit Ethernet interfaces and so have my >> switches. >> >> >> >> When I ping between the 2 switches via that wireless link I'm >> getting a lot >> of pings that are lost. >> >> The wireless link is not saturated but I'm thinking it could have to >> do >> something with the gigabit interfaces and only having 155Mbps on the >> link >> itself? >> >> >> >> All ideas welcome. >> >> >> >> Regards, >> >> >> >> Rens >> > > -- Josh Cheney josh.cheney at gmail.com http://www.joshcheney.com From rens at autempspourmoi.be Thu Sep 10 06:03:16 2009 From: rens at autempspourmoi.be (Rens) Date: Thu, 10 Sep 2009 13:03:16 +0200 Subject: Wireless STM-1 link In-Reply-To: <4AA8D93D.8050609@gmail.com> References: <9138BEE0A93342EBB729FA81440C6B06@EU.corp.clearwire.com> <4AA8D93D.8050609@gmail.com> Message-ID: Yes all the radio RF levels are 100% ok. -----Original Message----- From: Josh Cheney [mailto:josh.cheney at gmail.com] Sent: jeudi 10 septembre 2009 12:47 To: Rens Cc: 'Adam Goodman'; nanog at nanog.org Subject: Re: Wireless STM-1 link I'm assuming that you have checked all of the wireless parameters (noise floor, signal strength, jitter, etc)? I've seen behavior like this on links where the noise floor has risen to the point where the true signal cannot be distinguished from background noise. Josh Rens wrote: > All the interfaces are forced to 1Gbps and full duplex. > > Maybe I should give some extra info. > All the traffic seems to pass ok via that link but I have seen that often > OSPF adjacencies go down/up , I suspect that the HELLO packets are being > dropped that pass via that link. > > That's why I started to look a little deeper and do some ping tests. > > -----Original Message----- > From: Adam Goodman [mailto:adam at wispring.com] > Sent: jeudi 10 septembre 2009 11:45 > To: Rens > Cc: > Subject: Re: Wireless STM-1 link > > Sounds like this might be an Ethernet negotiaton problem > > -------- > Sent from my phone > > On Sep 10, 2009, at 12:05 PM, "Rens" wrote: > >> Hi all, >> >> >> >> I'm encountering a problem with a wireless STM-1 link which has a >> switch >> connected at each end. >> >> The wireless link has Gigabit Ethernet interfaces and so have my >> switches. >> >> >> >> When I ping between the 2 switches via that wireless link I'm >> getting a lot >> of pings that are lost. >> >> The wireless link is not saturated but I'm thinking it could have to >> do >> something with the gigabit interfaces and only having 155Mbps on the >> link >> itself? >> >> >> >> All ideas welcome. >> >> >> >> Regards, >> >> >> >> Rens >> > > -- Josh Cheney josh.cheney at gmail.com http://www.joshcheney.com From arievayner at gmail.com Thu Sep 10 07:57:12 2009 From: arievayner at gmail.com (Arie Vayner) Date: Thu, 10 Sep 2009 15:57:12 +0300 Subject: Wireless STM-1 link In-Reply-To: References: <9138BEE0A93342EBB729FA81440C6B06@EU.corp.clearwire.com> Message-ID: <20b13c6b0909100557v23281a80k5875103e7fb30954@mail.gmail.com> Rens, Does not sound like the symptoms for what I want to write about, but this is something you need to consider in any way: When you run sub-rate links (i.e. 1GE interface with really 155Mbps as the service) you need to make sure that you do not try to push more traffic than the link can take. This is mostly relevant for traffic bursts, which happen all the time with IP traffic. So even if on average you do not use the bandwidth, still you have short bursts whenever you start a transaction (like a file transfer etc). In order to avoid packets being dropped due to this burst on the link, the 1GE equipment before the link should be doing egress shaping to the rate (sometimes even it is good to choose a rate slightly lower then the actual rate) of the link. This would make sure that the network equipment manages the packet drops (if you have a child QOS policy) and you do not get random tail drops of the burst. This means that you need to choose the right network device that actually supports egress shaping. Be aware that many L2/L3 switches do not support this. Arie On Thu, Sep 10, 2009 at 12:55 PM, Rens wrote: > All the interfaces are forced to 1Gbps and full duplex. > > Maybe I should give some extra info. > All the traffic seems to pass ok via that link but I have seen that often > OSPF adjacencies go down/up , I suspect that the HELLO packets are being > dropped that pass via that link. > > That's why I started to look a little deeper and do some ping tests. > > -----Original Message----- > From: Adam Goodman [mailto:adam at wispring.com] > Sent: jeudi 10 septembre 2009 11:45 > To: Rens > Cc: > Subject: Re: Wireless STM-1 link > > Sounds like this might be an Ethernet negotiaton problem > > -------- > Sent from my phone > > On Sep 10, 2009, at 12:05 PM, "Rens" wrote: > > > Hi all, > > > > > > > > I'm encountering a problem with a wireless STM-1 link which has a > > switch > > connected at each end. > > > > The wireless link has Gigabit Ethernet interfaces and so have my > > switches. > > > > > > > > When I ping between the 2 switches via that wireless link I'm > > getting a lot > > of pings that are lost. > > > > The wireless link is not saturated but I'm thinking it could have to > > do > > something with the gigabit interfaces and only having 155Mbps on the > > link > > itself? > > > > > > > > All ideas welcome. > > > > > > > > Regards, > > > > > > > > Rens > > > > > From fweimer at bfk.de Thu Sep 10 08:03:40 2009 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 10 Sep 2009 13:03:40 +0000 Subject: Wireless STM-1 link In-Reply-To: (rens@autempspourmoi.be's message of "Thu\, 10 Sep 2009 11\:55\:40 +0200") References: <9138BEE0A93342EBB729FA81440C6B06@EU.corp.clearwire.com> Message-ID: <82fxavdk9f.fsf@mid.bfk.de> > All the interfaces are forced to 1Gbps and full duplex. This takes the interface out of spec, IIRC. Try with auto-negotation enabled. -- 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 rens at autempspourmoi.be Thu Sep 10 08:10:10 2009 From: rens at autempspourmoi.be (Rens) Date: Thu, 10 Sep 2009 15:10:10 +0200 Subject: Wireless STM-1 link In-Reply-To: <82fxavdk9f.fsf@mid.bfk.de> References: <9138BEE0A93342EBB729FA81440C6B06@EU.corp.clearwire.com> <82fxavdk9f.fsf@mid.bfk.de> Message-ID: <2C5239E3137A40669BE1860678696B20@EU.corp.clearwire.com> I have tried both actually, forced and auto, same issue -----Original Message----- From: Florian Weimer [mailto:fweimer at bfk.de] Sent: jeudi 10 septembre 2009 15:04 To: Rens Cc: nanog at nanog.org Subject: Re: Wireless STM-1 link > All the interfaces are forced to 1Gbps and full duplex. This takes the interface out of spec, IIRC. Try with auto-negotation enabled. -- 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 daffy at daffy.za.net Thu Sep 10 08:14:23 2009 From: daffy at daffy.za.net (Kieran Murphy) Date: Thu, 10 Sep 2009 14:14:23 +0100 Subject: Wireless STM-1 link In-Reply-To: <2C5239E3137A40669BE1860678696B20@EU.corp.clearwire.com> References: <9138BEE0A93342EBB729FA81440C6B06@EU.corp.clearwire.com> <82fxavdk9f.fsf@mid.bfk.de> <2C5239E3137A40669BE1860678696B20@EU.corp.clearwire.com> Message-ID: Whats the utilization of the link at the time that you're seeing problems? On Thu, Sep 10, 2009 at 2:10 PM, Rens wrote: > I have tried both actually, forced and auto, same issue > > -----Original Message----- > From: Florian Weimer [mailto:fweimer at bfk.de] > Sent: jeudi 10 septembre 2009 15:04 > To: Rens > Cc: nanog at nanog.org > Subject: Re: Wireless STM-1 link > > > All the interfaces are forced to 1Gbps and full duplex. > > This takes the interface out of spec, IIRC. Try with auto-negotation > enabled. > > -- > 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 rens at autempspourmoi.be Thu Sep 10 08:18:03 2009 From: rens at autempspourmoi.be (Rens) Date: Thu, 10 Sep 2009 15:18:03 +0200 Subject: Wireless STM-1 link In-Reply-To: References: <9138BEE0A93342EBB729FA81440C6B06@EU.corp.clearwire.com> <82fxavdk9f.fsf@mid.bfk.de> <2C5239E3137A40669BE1860678696B20@EU.corp.clearwire.com> Message-ID: <22F3CB2ADB5141CDAFA0626010920D87@EU.corp.clearwire.com> Between 20 & 80 Mbps, no real relation between the problem and the time of a day/higher/lower traffic _____ From: Kieran Murphy [mailto:daffy at daffy.za.net] Sent: jeudi 10 septembre 2009 15:14 To: Rens Cc: Florian Weimer; nanog at nanog.org Subject: Re: Wireless STM-1 link Whats the utilization of the link at the time that you're seeing problems? On Thu, Sep 10, 2009 at 2:10 PM, Rens wrote: I have tried both actually, forced and auto, same issue -----Original Message----- From: Florian Weimer [mailto:fweimer at bfk.de] Sent: jeudi 10 septembre 2009 15:04 To: Rens Cc: nanog at nanog.org Subject: Re: Wireless STM-1 link > All the interfaces are forced to 1Gbps and full duplex. This takes the interface out of spec, IIRC. Try with auto-negotation enabled. -- 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 Stephen.Bailey at uk.fujitsu.com Thu Sep 10 08:21:35 2009 From: Stephen.Bailey at uk.fujitsu.com (Bailey Stephen) Date: Thu, 10 Sep 2009 14:21:35 +0100 Subject: IPSEC-VRF MIB Message-ID: Hey all, I am looking to monitor the number of active IPSEC tunnels terminating in a given VRF via SNMP I can use the following command on the device (Cisco 3845 - 12.4(22)T).... Vpn#show crypto mib ipsec flowmib global vrf test-vrf vrf test-vrf Active Tunnels: 2 ... Is there anyway I can get this ActiveTunnels value via SNMP and MIBs? I can do an SNMP walk and get the GlobalActiveTunnels, but I need the number of active tunnels in a VRF Any help would be appreciated Cheers Stephen Bailey FUJITSU Fujitsu Services Limited, Registered in England no 96056, Registered Office 22 Baker Street, London, W1U 3BW This e-mail is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu Services does not guarantee that this e-mail has not been intercepted and amended or that it is virus-free. From darkmoon at vt.edu Thu Sep 10 08:52:42 2009 From: darkmoon at vt.edu (Dave Martin) Date: Thu, 10 Sep 2009 09:52:42 -0400 Subject: Repeated Blacklisting / IP reputation Message-ID: <20090910135242.GB31665@vt.edu> On Wed, Sep 09, 2009 at 04:13:18PM -0700, Jay Hennigan wrote: > JC Dill wrote: > As for a role account, there is "postmaster". I would think that the > best hope in the real world, rather than an autoresponder would be an > RFC that clearly defines text accompanying an SMTP rejection notice > triggered by a blocklist, detailing the blocklist and contact for > removal. Perhaps encouraging those who code MTAs and DNSBL hooks into > them to include such in the configuration files would be a good start. That would be very useful. Many of those small lists return 'Unknown user' rather than an actual blacklist message. A url where one could get reason (meaning headers) for the block would be even better. If they don't admit that it's a block, it's hard to do much more than tell the user to contact the recipient via some other channel and have *them* contact their support system. -- Dave ----- Nobody believed that I could build a space station here. So I built it anyway. It sank into the vortex. So I built another one. It sank into the vortex. The third station burned down, fell over then sank into the vortex. The fourth station just vanished. And the fifth station, THAT stayed! From reichert at numachi.com Thu Sep 10 09:12:03 2009 From: reichert at numachi.com (Brian Reichert) Date: Thu, 10 Sep 2009 10:12:03 -0400 Subject: Wireless STM-1 link In-Reply-To: References: <9138BEE0A93342EBB729FA81440C6B06@EU.corp.clearwire.com> Message-ID: <20090910141203.GU49696@numachi.com> On Thu, Sep 10, 2009 at 11:55:40AM +0200, Rens wrote: > All the interfaces are forced to 1Gbps and full duplex. I thought that with 1000T, you need to keep autonegotiation in place: http://etherealmind.com/2008/07/15/ethernet-autonegotiation-works-why-how-standard-should-be-set/ "A major problem is that many people are also hard setting Gigabit Ethernet , and this is causing major problems. Gigabit Ethernet must have auto-negotiation ENABLED to allow negotiation of master / slave PHY relationship for clocking at the physical layer. Without negotiation the line clock will not establish correctly and physical layers problems can result." Further: http://en.wikipedia.org/wiki/Autonegotiation "The debatable portions of the autonegotiation specifications were eliminated by the 1998 version of IEEE 802.3. In 1999, the negotiation protocol was significantly extended by IEEE 802.3ab, which specified the protocol for gigabit Ethernet, making autonegotiation mandatory for 1000BASE-T gigabit Ethernet over copper." Note the 'mandatory'... -- Brian Reichert 55 Crystal Ave. #286 Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large From feamster at cc.gatech.edu Thu Sep 10 09:19:04 2009 From: feamster at cc.gatech.edu (Nick Feamster) Date: Thu, 10 Sep 2009 10:19:04 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <28880400.269001252443527011.JavaMail.root@zimbra> References: <30306967.268951252443449724.JavaMail.root@zimbra> <28880400.269001252443527011.JavaMail.root@zimbra> Message-ID: <79fb092a0909100719q76e17779y63beb906a8bcc99c@mail.gmail.com> Hi Tom (and NANOG), You may be interested in an alternative approach, motivated by the very problem you are facing (see below). Our system, SNARE, develops IP reputation automatically based on a combination of network features. We'll discuss the pros and cons of this approach at MAAWG. The additional information that SNARE provides might be helpful. -Nick Detecting Spammers with SNARE: Spatio-temporal Network-level Automatic Reputation Engine Shuang Hao, Nadeem Ahmed Syed, Nick Feamster, Alexander Gray, Sven Krasser Usenix Security '09, Montreal, Canada, August 2009 Users and network administrators need ways to filter email messages based primarily on the reputation of the sender. Unfortunately, conventional mechanisms for sender reputation -- notably, IP blacklists -- are cumbersome to maintain and evadable. This paper investigates ways to infer the reputation of an email sender based solely on network-level features, without looking at the contents of a message. First, we study first-order properties of network-level features that may help distinguish spammers from legitimate senders. We examine features that can be ascertained without ever looking at a packet's contents, such as the distance in IP space to other email senders or the geographic distance between sender and receiver. We derive features that are lightweight, since they do not require seeing a large amount of email from a single IP address and can be gleaned without looking at an email's contents -- many such features are apparent from even a single packet. Second, we incorporate these features into a classification algorithm and evaluate the classifier's ability to automatically classify email senders as spammers or legitimate senders. We build an automated reputation engine, SNARE, based on these features using labeled data from a deployed commercial spam-filtering system. We demonstrate that SNARE can achieve comparable accuracy to existing static IP blacklists: about a 70% detection rate for less than a 0.3% false positive rate. Third, we show how SNARE can be integrated into existing blacklists, essentially as a first-pass filter. http://gtnoise.net/pub/index.php?detail=14 On Tue, Sep 8, 2009 at 4:58 PM, Tom Pipes wrote: > I am amazed with the amount of thoughtful comments I have seen, both on and off list. It really illustrates that people are willing to try to help out, but there is an overall lack of clear direction on how to improve things. ?Most of us seem to adopt that which has always just worked for us. Don't get me wrong, I'm sure there are a lot of improvements/mods going on with RBL operators in terms of the technology and how they choose who to block. ?I'm also certain that most of the carriers are doing their best to follow RFCs, use e-mail filtering, and perform deep packet inspection to keep themselves off of the lists. AND there seems to be some technologies that were meant to work, and cause their own sets of problems (example: ?allowing the end user to choose what is considered spam and blacklisting based on that). ?As was said before, it's not the "WHY" but rather how can we fix it if it's broke. > > The large debate seems to revolve around responsibility, or lack thereof. In our case, we are the small operator who sits in the sidelines hoping that someone larger than us, or more influential has an opinion. ?We participate in lists, hoping to make a difference and contribute, knowing that in a lot of cases, our opinion is just that: ?an opinion. ?I suppose that could spark a debate about joining organizations (who shall go nameless here), power to the people, etc. > > It seems as though a potential solution *may* revolve around ARIN/IANA having the ability to communicate an authoritative list of reassigned IP blocks back to the carriers. ?This could serve as a signal to remove a block from the RBL, but I'm sure there will be downfalls with doing this as well. > > In my specific case, I am left with a legacy block that I have to accept is going to be problematic. Simply contacting RBL operators is just not doing the trick. Most of the e-mails include links or at least an error code, but some carriers just seem to be blocking without an error, or even worse, an ACL... > > We will continue to remove these blocks as necessary, reassign IPs from other blocks where absolutely necessary, and ultimately hope the problem resolves itself over time. > > Thanks again for the very thoughtful and insightful comments, they are greatly appreciated. > > Regards, > > > --- > Tom Pipes > T6 Broadband/ > Essex Telcom Inc > tom.pipes at t6mail.com > > > ----- Original Message ----- > From: "Tom Pipes" > To: nanog at nanog.org > Sent: Tuesday, September 8, 2009 9:57:58 AM GMT -06:00 US/Canada Central > Subject: Repeated Blacklisting / IP reputation > > Greetings, > > > We obtained a direct assigned IP block 69.197.64.0/18 from ARIN in 2008. This block has been cursed (for lack of a better word) since we obtained it. It seems like every customer we have added has had repeated issues with being blacklisted by DUL and the cable carriers. (AOL, AT&T, Charter, etc). I understand there is a process to getting removed, but it seems as if these IPs had been used and abused by the previous owner. We have done our best to ensure these blocks conform to RFC standards, including the proper use of reverse DNS pointers. > > I can resolve the issue very easily by moving these customers over to our other direct assigned 66.254.192.0/19 block. In the last year I have done this numerous times and have had no further issues with them. > > My question: Is there some way to clear the reputation of these blocks up, or start over to prevent the amount of time we are spending with each customer troubleshooting unnecessary RBL and reputation blacklisting? > > I have used every opportunity to use the automated removal links from the SMTP rejections, and worked with the RBL operators directly. Most of what I get are cynical responses and promises that it will be fixed. > > If there is any question, we perform inbound and outbound scanning of all e-mail, even though we know that this appears to be something more relating to the block itself. > > Does anyone have any suggestions as to how we can clear this issue up? Comments on or off list welcome. > > Thanks, > > --- > Tom Pipes > T6 Broadband/ > Essex Telcom Inc > tom.pipes at t6mail.com > > > > From jason at i6ix.com Thu Sep 10 09:25:42 2009 From: jason at i6ix.com (Jason Bertoch) Date: Thu, 10 Sep 2009 10:25:42 -0400 Subject: IPSEC-VRF MIB In-Reply-To: References: Message-ID: <4AA90C66.90404@i6ix.com> Bailey Stephen wrote: > I am looking to monitor the number of active IPSEC tunnels terminating > in a given VRF via SNMP > > > Vpn#show crypto mib ipsec flowmib global vrf test-vrf > > vrf test-vrf > > Active Tunnels: 2 > > ... > > > Is there anyway I can get this ActiveTunnels value via SNMP and MIBs? > Have you asked around on the Cacti forums? From beckman at angryox.com Thu Sep 10 09:26:57 2009 From: beckman at angryox.com (Peter Beckman) Date: Thu, 10 Sep 2009 10:26:57 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <200909100348.n8A3mIfm062626@drugs.dv.isc.org> References: <148476.263921252421878121.JavaMail.root@zimbra><4AA67551.3050402@gmail.com>, <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> <200909100348.n8A3mIfm062626@drugs.dv.isc.org> Message-ID: On Thu, 10 Sep 2009, Mark Andrews wrote: > What a load of rubbish. How is ARIN or any RIR/LIR supposed to > know the intent of use? Why don't we just blacklist everything and only whitelist those we know are good? Because the cost of determining who is good and who is not has a great cost. If you buy an IP block, regardless of your intent, that IP block should not have the ill-will of the previous owner passed on with it. If the previous owner sucked, the new owner should have the chance to use that IP block without restriction until they prove that they suck, at which point it will be blocked again. That system seems to work well enough: blacklist blocks when they start do be evil, according to your own (you being the neteng in charge) definition of evil. ARIN needs to be impartial. If they are going to sell the block, they should do their best to make a coordinated effort to make sure the block is as unencumbered as possible. I get that there is a sense that ARIN needs to do more due dilligence to determine if the receiving party is worthy of that block, but I'm not aware of the process, and from the grumblings it doesn't seem like fun. > Note we all could start using IPv6 and avoid this problem altogether. Because as we know IPv6 space is inexhaustable. Just like IPv4 was when it began its life. ;-) That won't avoid the problem, it will simply put the problem off until it rears its head again. I'm sure that IPv6 space will be more easily gotten until problems arise, and in a few years (maybe decades, we can put this problem on our children's shoulders), we'll be back where we are now -- getting recycled IP space that is blocked or encumbered due to bad previous owners. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From Stephen.Bailey at uk.fujitsu.com Thu Sep 10 09:30:17 2009 From: Stephen.Bailey at uk.fujitsu.com (Bailey Stephen) Date: Thu, 10 Sep 2009 15:30:17 +0100 Subject: IPSEC-VRF MIB In-Reply-To: <4AA90C66.90404@i6ix.com> References: <4AA90C66.90404@i6ix.com> Message-ID: Will give it a go also, cheers Ste Bailey FUJITSU -----Original Message----- From: Jason Bertoch [mailto:jason at i6ix.com] Sent: 10 September 2009 15:26 To: nanog at nanog.org Subject: Re: IPSEC-VRF MIB Bailey Stephen wrote: > I am looking to monitor the number of active IPSEC tunnels terminating > in a given VRF via SNMP > > > Vpn#show crypto mib ipsec flowmib global vrf test-vrf > > vrf test-vrf > > Active Tunnels: 2 > > ... > > > Is there anyway I can get this ActiveTunnels value via SNMP and MIBs? > Have you asked around on the Cacti forums? From bbillon-ml at splio.fr Thu Sep 10 09:42:13 2009 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Thu, 10 Sep 2009 16:42:13 +0200 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <148476.263921252421878121.JavaMail.root@zimbra><4AA67551.3050402@gmail.com>, <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> <200909100348.n8A3mIfm062626@drugs.dv.isc.org> Message-ID: <4AA91045.9040208@splio.fr> > Why don't we just blacklist everything and only whitelist those we know > are good? > >> Note we all could start using IPv6 and avoid this problem altogether. > Yeah. When ISP will start receiving SMTP traffic in IPv6, they could start to accept whitelisted senders only. "IPv6 emails == clean" Utopian thought? From bmanning at vacation.karoshi.com Thu Sep 10 09:44:05 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 10 Sep 2009 14:44:05 +0000 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AA91045.9040208@splio.fr> References: <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> <200909100348.n8A3mIfm062626@drugs.dv.isc.org> <4AA91045.9040208@splio.fr> Message-ID: <20090910144405.GA16755@vacation.karoshi.com.> On Thu, Sep 10, 2009 at 04:42:13PM +0200, Benjamin Billon wrote: > > > Why don't we just blacklist everything and only whitelist those we know > > are good? > > > >>Note we all could start using IPv6 and avoid this problem altogether. > > > Yeah. When ISP will start receiving SMTP traffic in IPv6, they could > start to accept whitelisted senders only. > > "IPv6 emails == clean" > > Utopian thought? abt 8 years too late... --bill From kloch at kl.net Thu Sep 10 09:59:59 2009 From: kloch at kl.net (Kevin Loch) Date: Thu, 10 Sep 2009 10:59:59 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AA91045.9040208@splio.fr> References: <148476.263921252421878121.JavaMail.root@zimbra><4AA67551.3050402@gmail.com>, <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> <200909100348.n8A3mIfm062626@drugs.dv.isc.org> <4AA91045.9040208@splio.fr> Message-ID: <4AA9146F.4010807@kl.net> Benjamin Billon wrote: > >> Why don't we just blacklist everything and only whitelist those we know >> are good? >> >>> Note we all could start using IPv6 and avoid this problem altogether. >> > Yeah. When ISP will start receiving SMTP traffic in IPv6, they could > start to accept whitelisted senders only. > > "IPv6 emails == clean" > > Utopian thought? Are you not receiving SMTP traffic via IPv6 yet? Received: from s0.nanog.org ([IPv6:2001:48a8:6880:95::20]) - Kevin From beckman at angryox.com Thu Sep 10 10:02:27 2009 From: beckman at angryox.com (Peter Beckman) Date: Thu, 10 Sep 2009 11:02:27 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AA91045.9040208@splio.fr> References: <148476.263921252421878121.JavaMail.root@zimbra><4AA67551.3050402@gmail.com>, <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> <200909100348.n8A3mIfm062626@drugs.dv.isc.org> <4AA91045.9040208@splio.fr> Message-ID: On Thu, 10 Sep 2009, Benjamin Billon wrote: > >> Why don't we just blacklist everything and only whitelist those we know >> are good? >> >>> Note we all could start using IPv6 and avoid this problem altogether. >> > Yeah. When ISP will start receiving SMTP traffic in IPv6, they could start to > accept whitelisted senders only. > > "IPv6 emails == clean" > > Utopian thought? My statement about blacklisting everything was sarcastic. Clearly blacklisting everything and whitelisting individual blocks is not a viable, reasonable nor cost-effective option. Clearly I also suck at conveying sarcasm via email. :-) Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From bbillon-ml at splio.fr Thu Sep 10 10:03:47 2009 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Thu, 10 Sep 2009 17:03:47 +0200 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AA9146F.4010807@kl.net> References: <148476.263921252421878121.JavaMail.root@zimbra><4AA67551.3050402@gmail.com>, <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> <200909100348.n8A3mIfm062626@drugs.dv.isc.org> <4AA91045.9040208@splio.fr> <4AA9146F.4010807@kl.net> Message-ID: <4AA91553.7040208@splio.fr> You're not Hotmail =) From Valdis.Kletnieks at vt.edu Thu Sep 10 10:21:48 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 10 Sep 2009 11:21:48 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: Your message of "Wed, 09 Sep 2009 20:30:02 PDT." References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> Message-ID: <245637.1252596108@turing-police.cc.vt.edu> On Wed, 09 Sep 2009 20:30:02 PDT, Leo Vegoda said: > Putting these addresses back into use does not mean that they have to > be allocated to networks where they'll number mail servers. ARIN staff > is doubtless aware of the history of these blocks and will presumably > do their best to allocate them to networks that aren't intended to > host mail servers. Those streaming video servers in that returned /24 are going to work *real* well talking to a network that implemented the block as a null route rather than a port-25 block. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From buraglio at illinois.edu Thu Sep 10 10:33:01 2009 From: buraglio at illinois.edu (Buraglio, Nicholas D) Date: Thu, 10 Sep 2009 10:33:01 -0500 Subject: BGP Confederation over Route Reflector In-Reply-To: References: Message-ID: <15D7FD88-869C-46B1-A5EB-C941E08C97F6@illinois.edu> Lots of things can be used to determine how you decide to set up your BGP peers. https://www.juniper.net/customers/csc/documentation/techdocs/downloads/pdf/350010.pdf has a decent amount of information on some of the differences that can help you decide how to set up your peerings. nb --- Nick Buraglio Network Engineer, CITES, University of Illinois GPG key 0x2E5B44F4 Phone: 217.244.6428 buraglio at illinois.edu On Sep 9, 2009, at 9:52 PM, devang patel wrote: > Hello, > What are the advantages of BGP Confederation over Route Reflector? I > mean > when one should decide to deploy BGP Confederation over Route > Reflector > deployment? > > Thanks, > Devang Patel > From kloch at kl.net Thu Sep 10 10:33:14 2009 From: kloch at kl.net (Kevin Loch) Date: Thu, 10 Sep 2009 11:33:14 -0400 Subject: Wireless STM-1 link In-Reply-To: <20090910141203.GU49696@numachi.com> References: <9138BEE0A93342EBB729FA81440C6B06@EU.corp.clearwire.com> <20090910141203.GU49696@numachi.com> Message-ID: <4AA91C3A.3020603@kl.net> Brian Reichert wrote: > On Thu, Sep 10, 2009 at 11:55:40AM +0200, Rens wrote: >> All the interfaces are forced to 1Gbps and full duplex. > > I thought that with 1000T, you need to keep autonegotiation in place: > > http://etherealmind.com/2008/07/15/ethernet-autonegotiation-works-why-how-standard-should-be-set/ > > "A major problem is that many people are also hard setting > Gigabit Ethernet , and this is causing major problems. Gigabit > Ethernet must have auto-negotiation ENABLED to allow negotiation > of master / slave PHY relationship for clocking at the physical > layer. Without negotiation the line clock will not establish > correctly and physical layers problems can result." > > Further: > > http://en.wikipedia.org/wiki/Autonegotiation > > "The debatable portions of the autonegotiation specifications were > eliminated by the 1998 version of IEEE 802.3. In 1999, the negotiation > protocol was significantly extended by IEEE 802.3ab, which specified the > protocol for gigabit Ethernet, making autonegotiation mandatory for > 1000BASE-T gigabit Ethernet over copper." > > Note the 'mandatory'... > I'm in the "it's not 1996 anymore, let autonegotiation do it's job" camp. I occasionally see folks who religiously "lock down" all ports only to create the very duplex mismatches they are trying to avoid. Engineers, equipment, port positions and operating systems can change over time defeating even the best laid plans for total port control. - Kevin From kenny.sallee at gmail.com Thu Sep 10 11:06:01 2009 From: kenny.sallee at gmail.com (Kenny Sallee) Date: Thu, 10 Sep 2009 09:06:01 -0700 Subject: Wireless STM-1 link In-Reply-To: References: <9138BEE0A93342EBB729FA81440C6B06@EU.corp.clearwire.com> Message-ID: <4a80ecce0909100906h591d5e46k15f249cc7cc3b688@mail.gmail.com> On Thu, Sep 10, 2009 at 2:55 AM, Rens wrote: > All the interfaces are forced to 1Gbps and full duplex. > > Maybe I should give some extra info. > All the traffic seems to pass ok via that link but I have seen that often > OSPF adjacencies go down/up , I suspect that the HELLO packets are being > dropped that pass via that link. > > That's why I started to look a little deeper and do some ping tests. > > -----Original Message----- > From: Adam Goodman [mailto:adam at wispring.com] > Sent: jeudi 10 septembre 2009 11:45 > To: Rens > Cc: > Subject: Re: Wireless STM-1 link > > Sounds like this might be an Ethernet negotiaton problem > > -------- > Sent from my phone > Seems everyone has focused on GE as the problem. You can quickly rule that out by looking at interface error counters and doing PING tests from the wireless router/device to something on the local network on both sides. If OSPF is flapping because of missed HELLO packets then I'm thinking you have a problem with either saturation on the link or actual wireless issues. When PING does work what do the times look like? I'd look at static routing for a bit (if practical) or changing your OSPF HELLO intervals to see if that does anything. Here's a good link on troubleshooting OSPF adjacency changes: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094050.shtml From mike-nanog at tiedyenetworks.com Thu Sep 10 11:35:25 2009 From: mike-nanog at tiedyenetworks.com (Mike) Date: Thu, 10 Sep 2009 09:35:25 -0700 Subject: Wireless STM-1 link In-Reply-To: <4a80ecce0909100906h591d5e46k15f249cc7cc3b688@mail.gmail.com> References: <9138BEE0A93342EBB729FA81440C6B06@EU.corp.clearwire.com> <4a80ecce0909100906h591d5e46k15f249cc7cc3b688@mail.gmail.com> Message-ID: <4AA92ACD.5000708@tiedyenetworks.com> Kenny Sallee wrote: > Seems everyone has focused on GE as the problem. You can quickly rule that > out by looking at interface error counters and doing PING tests from the > wireless router/device to something on the local network on both sides. If > OSPF is flapping because of missed HELLO packets then I'm thinking you have > a problem with either saturation on the link or actual wireless issues. > When PING does work what do the times look like? I'd look at static routing > for a bit (if practical) or changing your OSPF HELLO intervals to see if > that does anything. Here's a good link on troubleshooting > OSPF adjacency changes: > http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094050.shtml > I'd like to second the above. Wireless can, and often does, suffer from isses that other media such as copper and fiber media do not, and you need to be looking closely at the device's RF statistics (combined with your own monitoring of link rssi, error blocks, retrans, and others... you are monitoring and graphing this, yes?). Some of the variations you can expect in wireless include - Interference (if using unliscensed band gear - do NOT assume your little corner of the world doesn't have anyone else using the band occasionally!) Thermal inversion fade Water build up - especially inside of antennas and antenna elements, this can take your -36 rssi and make it drop to -86 and then all of a sudden come back in the space of 30 seconds. This can be the hardest problem to find - look at your connectors, the seal up job, anywhere they would have had to seal would be a place of penetration. Birds, trucks, anything causing occasional multipath reflections or blockage between the two sides Also it is my direct experience that wireless devices from all manufacturers also are more bug ridden and usually have far more exotic corner cases where their gear just does the wrong thing occasionally. Corrupt frames at the RF layer may not be detected due to various mac layer defeciencies, with the result being incorrect reassembly and framing of the junk as an ethernet frame and even including a valid fcs in the ethernet header but corrupt junk in the packet itself. Sometimes the RF device's own bridging tables get corrupted as a result, causing you to lose connectivity as bridge entries are relearned. There's all kinds of stuff that can go wrong here that is not your ordinary every day cisco 4-byte asn bug variety. My advice only is, be suspecious and be a good detective. Mike- From jgreco at ns.sol.net Thu Sep 10 11:39:30 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 10 Sep 2009 11:39:30 -0500 (CDT) Subject: Repeated Blacklisting / IP reputation In-Reply-To: from "Peter Beckman" at Sep 10, 2009 10:26:57 AM Message-ID: <200909101639.n8AGdUb9075593@aurora.sol.net> > Because the cost of determining who is good and who is not has a great > cost. If you buy an IP block, regardless of your intent, that IP block > should not have the ill-will of the previous owner passed on with it. Might as well be the end of discussion, right there, then, because what you're suggesting suggests no grasp of the real world. > If > the previous owner sucked, the new owner should have the chance to use > that IP block without restriction until they prove that they suck, at > which point it will be blocked again. That system seems to work well > enough: blacklist blocks when they start do be evil, according to your own > (you being the neteng in charge) definition of evil. What you just described doesn't implement what you claim, at all. ... 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 pstewart at nexicomgroup.net Thu Sep 10 11:39:52 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Thu, 10 Sep 2009 12:39:52 -0400 Subject: Wireless STM-1 link In-Reply-To: <4AA92ACD.5000708@tiedyenetworks.com> References: <9138BEE0A93342EBB729FA81440C6B06@EU.corp.clearwire.com> <4a80ecce0909100906h591d5e46k15f249cc7cc3b688@mail.gmail.com> <4AA92ACD.5000708@tiedyenetworks.com> Message-ID: I totally agree with everything that Mike has posted here... one thing I wanted to add is that a wireless link is only as good as it's engineered. We have many rock solid wireless links in use here - with proper engineering and ongoing maintenance we very rarely have issues. We do have some links that were not engineered to proper levels (sometimes where a business decision overrode a technical decision for example) and they do have blips every so often. Maintenance is so important after a link is established as stuff breaks, wears down, leaks, and moves. Paul -----Original Message----- From: Mike [mailto:mike-nanog at tiedyenetworks.com] Sent: September-10-09 12:35 PM To: nanog at nanog.org Subject: Re: Wireless STM-1 link Kenny Sallee wrote: > Seems everyone has focused on GE as the problem. You can quickly rule that > out by looking at interface error counters and doing PING tests from the > wireless router/device to something on the local network on both sides. If > OSPF is flapping because of missed HELLO packets then I'm thinking you have > a problem with either saturation on the link or actual wireless issues. > When PING does work what do the times look like? I'd look at static routing > for a bit (if practical) or changing your OSPF HELLO intervals to see if > that does anything. Here's a good link on troubleshooting > OSPF adjacency changes: > http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009 4050.shtml > I'd like to second the above. Wireless can, and often does, suffer from isses that other media such as copper and fiber media do not, and you need to be looking closely at the device's RF statistics (combined with your own monitoring of link rssi, error blocks, retrans, and others... you are monitoring and graphing this, yes?). Some of the variations you can expect in wireless include - Interference (if using unliscensed band gear - do NOT assume your little corner of the world doesn't have anyone else using the band occasionally!) Thermal inversion fade Water build up - especially inside of antennas and antenna elements, this can take your -36 rssi and make it drop to -86 and then all of a sudden come back in the space of 30 seconds. This can be the hardest problem to find - look at your connectors, the seal up job, anywhere they would have had to seal would be a place of penetration. Birds, trucks, anything causing occasional multipath reflections or blockage between the two sides Also it is my direct experience that wireless devices from all manufacturers also are more bug ridden and usually have far more exotic corner cases where their gear just does the wrong thing occasionally. Corrupt frames at the RF layer may not be detected due to various mac layer defeciencies, with the result being incorrect reassembly and framing of the junk as an ethernet frame and even including a valid fcs in the ethernet header but corrupt junk in the packet itself. Sometimes the RF device's own bridging tables get corrupted as a result, causing you to lose connectivity as bridge entries are relearned. There's all kinds of stuff that can go wrong here that is not your ordinary every day cisco 4-byte asn bug variety. My advice only is, be suspecious and be a good detective. Mike- ---------------------------------------------------------------------------- "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 jason.iannone at gmail.com Thu Sep 10 12:20:52 2009 From: jason.iannone at gmail.com (Jason Iannone) Date: Thu, 10 Sep 2009 11:20:52 -0600 Subject: BGP Confederation over Route Reflector In-Reply-To: <15D7FD88-869C-46B1-A5EB-C941E08C97F6@illinois.edu> References: <15D7FD88-869C-46B1-A5EB-C941E08C97F6@illinois.edu> Message-ID: I would say confeds are more appropriate for larger ibgp networks. You can have reflectors inside confederations. See the BGP chapter of the JNCIP book. On Thu, Sep 10, 2009 at 9:33 AM, Buraglio, Nicholas D wrote: > Lots of things can be used to determine how you decide to set up your > BGP peers. ?https://www.juniper.net/customers/csc/documentation/techdocs/downloads/pdf/350010.pdf > ?has a decent amount of information on some of the differences that > can help you decide how to set up your peerings. > > nb > > --- > Nick Buraglio > Network Engineer, CITES, University of Illinois > GPG key 0x2E5B44F4 > Phone: 217.244.6428 > buraglio at illinois.edu > > On Sep 9, 2009, at 9:52 PM, devang patel wrote: > >> Hello, >> What are the advantages of BGP Confederation over Route Reflector? I >> mean >> when one should decide to deploy BGP Confederation over Route >> Reflector >> deployment? >> >> Thanks, >> Devang Patel >> > > > From jcurran at arin.net Thu Sep 10 14:57:59 2009 From: jcurran at arin.net (John Curran) Date: Thu, 10 Sep 2009 15:57:59 -0400 Subject: ARIN XXIV follows NANOG 47 in Dearborn, MI References: <4AA932F6.4030602@arin.net> Message-ID: <1E07AAFF-329C-4FC9-B238-0514F1FDFE00@arin.net> Folks - Just a reminder - ARIN XXIV will follow NANOG 47, starting with a joint program session on Wednesday on IPv6. If you will be staying for the ARIN meeting on Thursday and Friday, please refer to for logistics & registration information asap! Thanks! /John John Curran President and CEO ARIN From drc at virtualized.org Thu Sep 10 15:21:10 2009 From: drc at virtualized.org (David Conrad) Date: Thu, 10 Sep 2009 13:21:10 -0700 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> Message-ID: <117F0F10-01CD-4356-B02B-F3137E6E6340@virtualized.org> On Sep 9, 2009, at 8:41 PM, Martin Hannigan wrote: > Not sure when ICANN got into the business of economic bailouts, ?? > but the mechanism that ICANN has defined seems patently unfair. RFC 2777 is unfair? Or are you unhappy that LACNIC and AfriNIC have 2 /8s from the least tainted pools? Regards, -drc From scott at dwc-computer.com Thu Sep 10 16:17:00 2009 From: scott at dwc-computer.com (Scott Spencer) Date: Thu, 10 Sep 2009 15:17:00 -0600 Subject: WS-X6148A-GE-TX performance question Message-ID: Are the X6148A cards dedicated 1 gb/s uplink for each port ( shared 32 Gb/s bus , as long as each port is it's own 1 gb/s still to the 32gb/s bus and not shared with 7 other ports, so effectively just 125Mb/s per port then if all used at full/even capacity) ? I can't really find anything much on X6148A internal architecture online, but it would seem that each port gets its own 1gb/s link to the card/backplane, and that the bottleneck then is the 32gb/s backplane (which is fine, as long as it's not 1 gb/s per each set of 8 ports!). Best regards, Scott Spencer Data Center Asset Recovery/Remarketing Manager Duane Whitlow & Co. Inc. Nationwide Toll Free: 800.977.7473. Direct: 972.865.1395 Fax: 972.931.3340 scott at dwc-computer.com www.dwc-it.com Sales of new and used Cisco/Juniper/F5/Foundry/Brocade/Sun/IBM/Dell/Liebert and more ~ From bblackford at gmail.com Thu Sep 10 16:39:30 2009 From: bblackford at gmail.com (Bill Blackford) Date: Thu, 10 Sep 2009 14:39:30 -0700 Subject: WS-X6148A-GE-TX performance question In-Reply-To: References: Message-ID: <680a83090909101439t36cc0596w3af1863117a1fd56@mail.gmail.com> There was a good thread on Cisco-nsp regarding this exact subject recently. My recollection is that both X6148 and X6148A have just 6 1GB ASICs. Therefore the over subscription rate is 8:1. The biggest difference between these LC's is that X6148A will support large MTU whereas X6148 will not. -b On Thu, Sep 10, 2009 at 2:17 PM, Scott Spencer wrote: > Are the X6148A cards dedicated 1 gb/s uplink for each port ( shared 32 > Gb/s > bus , as long as each port is it's own 1 gb/s still to the 32gb/s bus and > not shared with 7 other ports, so effectively just 125Mb/s per port then if > all used at full/even capacity) ? > > I can't really find anything much on X6148A internal architecture online, > but it would seem that each port gets its own 1gb/s link to the > card/backplane, and that the bottleneck then is the 32gb/s backplane (which > is fine, as long as it's not 1 gb/s per each set of 8 ports!). > > > Best regards, > > Scott Spencer > Data Center Asset Recovery/Remarketing Manager > Duane Whitlow & Co. Inc. > Nationwide Toll Free: 800.977.7473. Direct: 972.865.1395 Fax: > 972.931.3340 > scott at dwc-computer.com > www.dwc-it.com > Sales of new and used Cisco/Juniper/F5/Foundry/Brocade/Sun/IBM/Dell/Liebert > and more ~ > > -- Bill Blackford Network Engineer From martin at theicelandguy.com Thu Sep 10 16:45:59 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Thu, 10 Sep 2009 17:45:59 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <117F0F10-01CD-4356-B02B-F3137E6E6340@virtualized.org> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> <117F0F10-01CD-4356-B02B-F3137E6E6340@virtualized.org> Message-ID: On Thu, Sep 10, 2009 at 4:21 PM, David Conrad wrote: > On Sep 9, 2009, at 8:41 PM, Martin Hannigan wrote: > >> Not sure when ICANN got into the business of economic bailouts, >> > > ?? > The blog posting implies it: "AfriNIC and LACNIC have fewest IPv4 /8s and service the regions with the most developing economies. We decided that those RIRs should have four of the easiest to use /8s reserved for them." There is also a possible unintended consequence. If v4 address space markets do end up being legitimized (I do believe that they will FWIW) ICANN is in effect declaring one class of space more valuable than another an arbitrarily assigning that value. > but the mechanism that ICANN has defined seems patently unfair. >> > > RFC 2777 is unfair? Or are you unhappy that LACNIC and AfriNIC have 2 /8s > from the least tainted pools? > I don't have a comment on the RFC. There is currently a global policy that the RIR's and ICANN agreed to that defines the allocation of /8's from IANA to RIR's. That policy doesnt include a set-aside and I think that arbitrarily adding one is not in the spirit of cooperation. I think that it's "good" that ICANN is being proactive, but I also think that it's "bad" that they chose this to be proactive about. It's possible that not everything is above the table as well. I think that the perception is reality here though. ICANN has arbitrarily created process that impacts RIR's unequally. To me, that's unfair. Question is -- do a few /8's really matter? In the end game, I think that they do all considered. Best, Marty -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From tim at broadlinenetworks.com Thu Sep 10 16:46:56 2009 From: tim at broadlinenetworks.com (Tim Lampman) Date: Thu, 10 Sep 2009 17:46:56 -0400 Subject: WS-X6148A-GE-TX performance question In-Reply-To: References: Message-ID: <4AA973D0.7060702@broadlinenetworks.com> http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/release/notes/OL_4164.html#wp2563293 Scott Spencer wrote: > Are the X6148A cards dedicated 1 gb/s uplink for each port ( shared 32 Gb/s > bus , as long as each port is it's own 1 gb/s still to the 32gb/s bus and > not shared with 7 other ports, so effectively just 125Mb/s per port then if > all used at full/even capacity) ? > > I can't really find anything much on X6148A internal architecture online, > but it would seem that each port gets its own 1gb/s link to the > card/backplane, and that the bottleneck then is the 32gb/s backplane (which > is fine, as long as it's not 1 gb/s per each set of 8 ports!). > > > Best regards, > > Scott Spencer > Data Center Asset Recovery/Remarketing Manager > Duane Whitlow & Co. Inc. > Nationwide Toll Free: 800.977.7473. Direct: 972.865.1395 Fax: 972.931.3340 > scott at dwc-computer.com > www.dwc-it.com > Sales of new and used Cisco/Juniper/F5/Foundry/Brocade/Sun/IBM/Dell/Liebert > and more ~ > > > -- Tim Lampman Co-Owner/CTO *Broadline Networks Inc.* 57 Colborne Street West, Brantford, ON, N3T 1K6 *c.* 905-746-3114 www.broadlinenetworks.com | tim at broadlinenetworks.com From Sam.Crooks at experian.com Thu Sep 10 16:58:52 2009 From: Sam.Crooks at experian.com (Crooks, Sam) Date: Thu, 10 Sep 2009 16:58:52 -0500 Subject: WS-X6148A-GE-TX performance question In-Reply-To: <680a83090909101439t36cc0596w3af1863117a1fd56@mail.gmail.com> References: <680a83090909101439t36cc0596w3af1863117a1fd56@mail.gmail.com> Message-ID: the other difference between WS-X6148-GE-TX and WS-X6148A-GE-TX is the A has better QoS queuing potential (more hardware queues available) and a lower list price... As I recall, there are 6 ethernet controllers with 8 ports on each... (8:1 oversubscription among the adjacent ports in a port group which use the same ethernet controller). The card is a Classic card, so the whole card is limited to 32 Gbps to the backplane, which given the oversubscription ratio, shouldn't be much of an issue... > -----Original Message----- > From: Bill Blackford [mailto:bblackford at gmail.com] > Sent: Thursday, September 10, 2009 4:40 PM > To: Scott Spencer > Cc: nanog at nanog.org > Subject: Re: WS-X6148A-GE-TX performance question > > There was a good thread on Cisco-nsp regarding this exact > subject recently. > My recollection is that both X6148 and X6148A have just 6 1GB ASICs. > Therefore the over subscription rate is 8:1. The biggest > difference between these LC's is that X6148A will support > large MTU whereas X6148 will not. > > -b > > > On Thu, Sep 10, 2009 at 2:17 PM, Scott Spencer > wrote: > > > Are the X6148A cards dedicated 1 gb/s uplink for each port > ( shared > > 32 Gb/s bus , as long as each port is it's own 1 gb/s still to the > > 32gb/s bus and not shared with 7 other ports, so effectively just > > 125Mb/s per port then if all used at full/even capacity) ? > > > > I can't really find anything much on X6148A internal architecture > > online, but it would seem that each port gets its own 1gb/s link to > > the card/backplane, and that the bottleneck then is the 32gb/s > > backplane (which is fine, as long as it's not 1 gb/s per > each set of 8 ports!). > > > > > > Best regards, > > > > Scott Spencer > > Data Center Asset Recovery/Remarketing Manager Duane Whitlow & Co. > > Inc. > > Nationwide Toll Free: 800.977.7473. Direct: 972.865.1395 Fax: > > 972.931.3340 > > scott at dwc-computer.com > > www.dwc-it.com Sales of new and used > > Cisco/Juniper/F5/Foundry/Brocade/Sun/IBM/Dell/Liebert > > and more ~ > > > > > > > -- > Bill Blackford > Network Engineer > From dholmes at mwdh2o.com Thu Sep 10 17:15:32 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Thu, 10 Sep 2009 15:15:32 -0700 Subject: WS-X6148A-GE-TX performance question In-Reply-To: References: <680a83090909101439t36cc0596w3af1863117a1fd56@mail.gmail.com> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E099D0A4F@usmsxt104.mwd.h2o> Cisco recommends both cards for access-layer use, principally as wiring closet aggregation for desktop users. Cisco recommends 65xx or 67xx line cards for backbone (read deterministic) connections, which means that only 65xx devices with sup720s, or older switch fabric modules can be used for deterministic network design. Note that Etherchannel limitations apply to both cards. Also running one port in a group of 8 at line rate ( for example using that port as a SPAN destination for a VLAN where traffic exceeds 1 Gbps) will cause drops on the other ports in the group. (see http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186a 0080094714.shtml ) -----Original Message----- From: Crooks, Sam [mailto:Sam.Crooks at experian.com] Sent: Thursday, September 10, 2009 2:59 PM To: Bill Blackford; Scott Spencer Cc: nanog at nanog.org Subject: RE: WS-X6148A-GE-TX performance question the other difference between WS-X6148-GE-TX and WS-X6148A-GE-TX is the A has better QoS queuing potential (more hardware queues available) and a lower list price... As I recall, there are 6 ethernet controllers with 8 ports on each... (8:1 oversubscription among the adjacent ports in a port group which use the same ethernet controller). The card is a Classic card, so the whole card is limited to 32 Gbps to the backplane, which given the oversubscription ratio, shouldn't be much of an issue... > -----Original Message----- > From: Bill Blackford [mailto:bblackford at gmail.com] > Sent: Thursday, September 10, 2009 4:40 PM > To: Scott Spencer > Cc: nanog at nanog.org > Subject: Re: WS-X6148A-GE-TX performance question > > There was a good thread on Cisco-nsp regarding this exact > subject recently. > My recollection is that both X6148 and X6148A have just 6 1GB ASICs. > Therefore the over subscription rate is 8:1. The biggest > difference between these LC's is that X6148A will support > large MTU whereas X6148 will not. > > -b > > > On Thu, Sep 10, 2009 at 2:17 PM, Scott Spencer > wrote: > > > Are the X6148A cards dedicated 1 gb/s uplink for each port > ( shared > > 32 Gb/s bus , as long as each port is it's own 1 gb/s still to the > > 32gb/s bus and not shared with 7 other ports, so effectively just > > 125Mb/s per port then if all used at full/even capacity) ? > > > > I can't really find anything much on X6148A internal architecture > > online, but it would seem that each port gets its own 1gb/s link to > > the card/backplane, and that the bottleneck then is the 32gb/s > > backplane (which is fine, as long as it's not 1 gb/s per > each set of 8 ports!). > > > > > > Best regards, > > > > Scott Spencer > > Data Center Asset Recovery/Remarketing Manager Duane Whitlow & Co. > > Inc. > > Nationwide Toll Free: 800.977.7473. Direct: 972.865.1395 Fax: > > 972.931.3340 > > scott at dwc-computer.com > > www.dwc-it.com Sales of new and used > > Cisco/Juniper/F5/Foundry/Brocade/Sun/IBM/Dell/Liebert > > and more ~ > > > > > > > -- > Bill Blackford > Network Engineer > From m.hallgren at free.fr Thu Sep 10 17:17:36 2009 From: m.hallgren at free.fr (Michael Hallgren) Date: Fri, 11 Sep 2009 00:17:36 +0200 Subject: BGP Confederation over Route Reflector In-Reply-To: References: <15D7FD88-869C-46B1-A5EB-C941E08C97F6@illinois.edu> Message-ID: <1252621056.4787.6.camel@home> Le jeudi 10 septembre 2009 ? 11:20 -0600, Jason Iannone a ?crit : > I would say confeds are more appropriate for larger ibgp networks. > You can have reflectors inside confederations. See the BGP chapter of > the JNCIP book. I'd say, the choice is much dependent on the "political" topology within your AS. The more inter-regional routing policing you feel that you need, the more you'd be looking at a confed. architecture. mh > > On Thu, Sep 10, 2009 at 9:33 AM, Buraglio, Nicholas D > wrote: > > Lots of things can be used to determine how you decide to set up your > > BGP peers. https://www.juniper.net/customers/csc/documentation/techdocs/downloads/pdf/350010.pdf > > has a decent amount of information on some of the differences that > > can help you decide how to set up your peerings. > > > > nb > > > > --- > > Nick Buraglio > > Network Engineer, CITES, University of Illinois > > GPG key 0x2E5B44F4 > > Phone: 217.244.6428 > > buraglio at illinois.edu > > > > On Sep 9, 2009, at 9:52 PM, devang patel wrote: > > > >> Hello, > >> What are the advantages of BGP Confederation over Route Reflector? I > >> mean > >> when one should decide to deploy BGP Confederation over Route > >> Reflector > >> deployment? > >> > >> Thanks, > >> Devang Patel > >> > > > > > > > -- michael hallgren, mh2198-ripe From nick at foobar.org Thu Sep 10 17:51:03 2009 From: nick at foobar.org (Nick Hilliard) Date: Thu, 10 Sep 2009 23:51:03 +0100 Subject: WS-X6148A-GE-TX performance question In-Reply-To: References: Message-ID: <4AA982D7.5050606@foobar.org> On 10/09/2009 22:17, Scott Spencer wrote: > I can't really find anything much on X6148A internal architecture online, > but it would seem that each port gets its own 1gb/s link to the > card/backplane, and that the bottleneck then is the 32gb/s backplane (which > is fine, as long as it's not 1 gb/s per each set of 8 ports!). Sadly, it is 1Gb per each set of 8 ports. The WS-X6148-GE-TX line card has its uses, just not in the data center. To recap on the thread a couple of weeks ago: - no storm control - no port security - 1G aggregate traffic for each group of 8 ports (i.e. think of it as 6 x gigabit ethernet hubs with shared input buffers connected into a 32G backplane) - 2 ports per etherchannel It's not a service provider blade and doesn't belong in a data center switch setup. Don't be disappointed by this: it was designed to be an aggregation blade for enterprise desktop usage and is quite useful in that context. Nick From bh05gc at myblackberry.com Thu Sep 10 18:40:51 2009 From: bh05gc at myblackberry.com (BH) Date: Thu, 10 Sep 2009 19:40:51 -0400 Subject: FOSS WAN Acceleration Software Message-ID: Hello, I was wondering if anyone had experience or could recommend free open source WAN Accelerators/Optimizers. There seems to be only one FOSS project called TrafficSqueezer but development has stopped and the project is still in an Alpha stage. I am not interested in the offerings of Cisco (WAAS) or Riverbed (StealHead) or any other appliance based solution. Thank-you in advance for any and all replies. -- BH From leo.vegoda at icann.org Thu Sep 10 18:46:52 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 10 Sep 2009 16:46:52 -0700 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <200909100348.n8A3mIfm062626@drugs.dv.isc.org> Message-ID: On 09/09/2009 8:48, "Mark Andrews" wrote: [...] > What a load of rubbish. How is ARIN or any RIR/LIR supposed to > know the intent of use? In my limited experience, requesting address space from ARIN involved describing what I would be doing with it. YMMV. Leo From surfer at mauigateway.com Thu Sep 10 19:12:46 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 10 Sep 2009 17:12:46 -0700 Subject: Repeated Blacklisting / IP reputation Message-ID: <20090910171246.9BBD5F80@resin16.mta.everyone.net> --- leo.vegoda at icann.org wrote: In my limited experience, requesting address space from ARIN involved describing what I would be doing with it. YMMV. ----------------------------------------- That's the easy part of the process. Proof of what you did with what you already have assigned to you is the hard part. scott From feldman at twincreeks.net Fri Sep 11 00:11:59 2009 From: feldman at twincreeks.net (Steve Feldman) Date: Thu, 10 Sep 2009 22:11:59 -0700 Subject: [NANOG-announce] 2009 NANOG charter amendments Message-ID: <56DDEDC5-981C-4F60-9E0D-52C4ABFD5F8D@twincreeks.net> The NANOG charter is the document which governs the operation of NANOG, and the relationship between the community and NANOG's hosting organization, Merit Network. The current text is at http://www.nanog.org/governance/charter/ . During the NANOG annual election, voters are given the opportunity to decide on amendments to the NANOG charter. Typically, the amendment process has been used to remedy oversights, modify processes with the benefit of experience, and to correct and tighten language. This year, the election is being held during the NANOG meeting October 18-21 in Dearborn, MI. There are two ways to put an amendment on the ballot: - Vote by a majority of the Steering Committee - A petition signed by at least 30 eligible voters, and submitted by September 28, 2009. See http://www.nanog.org/governance/elections/2009elections/2009charteramend.php for more details on the process. As amendments are proposed, they will be added to that page. If you have any suggestions for amendments, or would like to comment on NANOG governance in general, please join the discussion on the nanog-futures list, or contact the Steering Committee or any of its members directly. Steve Feldman (for the Steering Committee) _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From john at vanoppen.com Fri Sep 4 17:06:04 2009 From: john at vanoppen.com (John van Oppen) Date: Fri, 4 Sep 2009 15:06:04 -0700 Subject: as702 looking glass? References: <20090904133726.D35511@mp2.macomnet.net> <20090904191850.M59154@rsle.net> Message-ID: No BGP looking glass but there is a traceroute gateway in AS702: http://zelfservice.nl.uu.net/netwerk/pops/trace.uunet John van Oppen Spectrum Networks LLC Direct: 206.973.8302 Main: 206.973.8300 Website: http://spectrumnetworks.us -----Original Message----- From: R. Scott Evans [mailto:nanog at rsle.net] Sent: Friday, September 04, 2009 12:21 PM To: nanog at nanog.org Subject: Re: as702 looking glass? On Fri, 4 Sep 2009 13:38:56 +0400 (MSD), Serg Shubenkov wrote > Folks, > > Does anyone know if Verizon (AS702) has a publicly accessable looking > glass? > > -- > Serg Shubenkov it's been 2 years since I last inquired, but the answer then was: "Date: Fri, 17 Aug 2007 17:37:09 +0000 (GMT) From: help4u at verizonbusiness.com Subject: (2007081704481) BGP routes Hi there, I am afraid we do not have a public looking glass..." From chanty_kh at yahoo.com Fri Sep 11 02:29:23 2009 From: chanty_kh at yahoo.com (ty chan) Date: Fri, 11 Sep 2009 00:29:23 -0700 (PDT) Subject: Network Ring In-Reply-To: <6bb5f5b10909070615qf0fbdcdo195aba4fa08ffc82@mail.gmail.com> References: <354013.26624.qm@web52309.mail.re2.yahoo.com> <6bb5f5b10909070615qf0fbdcdo195aba4fa08ffc82@mail.gmail.com> Message-ID: <22349.4707.qm@web52302.mail.re2.yahoo.com> Does anyone have best practise for implementing those technologies ? I am currently doing a testing LAB with CISCO REP since i have a few Metro on hand. It works quite well in my LAB. There is one Request Time Out if the link break BUT it is physical layer not REP :) ________________________________ From: Rubens Kuhl To: ty chan Cc: nanog at nanog.org Sent: Monday, September 7, 2009 8:15:23 PM Subject: Re: Network Ring My vote goes to proprietary ring protection from the vendor you choose: - EAPS (Extreme) - REP (Cisco) - MRP (Foundry/Brocade) - EPSR (Allied Telesis) Although EAPS is implemented in all Extreme switches, select models from the other vendors implement ring protection, but these models also do other things you might want your network to have (QinQ, per-VLAN controls). Rubens On Mon, Sep 7, 2009 at 1:14 AM, ty chan wrote: > Dear all, > > I am in process of planning ring network to cover 15 POPs in City. Some technologies are chosen for consideration like SDH(Huawei), PVRST+(Cisco), RSTP(Zyxel), EAPS (extreme network) and MPLS(VPLS). The purpose is to provide L2 Ethernet connectivities from POPs to central point (DC) and ring protection. > > I know you all are in those network for years. can you give me some advises? > > Best regards, > chanty > From william.allen.simpson at gmail.com Fri Sep 11 04:43:07 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Fri, 11 Sep 2009 05:43:07 -0400 Subject: SA pigeon 'faster than broadband' Message-ID: <4AAA1BAB.5000707@gmail.com> http://newsvote.bbc.co.uk/mpapps/pagetools/print/news.bbc.co.uk/2/hi/africa/8248056.stm?ad=1 Update needed for RFC 1149 (1 April 1990), A Standard for the Transmission of IP Datagrams on Avian Carriers From joelja at bogus.com Thu Sep 10 06:23:21 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 10 Sep 2009 04:23:21 -0700 Subject: Route table prefix monitoring In-Reply-To: <19A6566FA5D52A44B7F7027F7E88BEE7DF65FD@OBT-W-EVS3P.dvuadmin.net> References: <19A6566FA5D52A44B7F7027F7E88BEE7DF65FD@OBT-W-EVS3P.dvuadmin.net> Message-ID: <4AA8E1A9.8030602@bogus.com> Olsen, Jason wrote: > Howdy all, > What I'm left thinking is that it would have been great if we'd had a > snapshot of our core routing table as it stood hours or even days prior > to this event occurring, so that I could compare it with our current > "broken" state, so the team could have seen that subnet in the core > table and what the next hop was for the prefix. Are there any tools > that people are using to track when/what prefixes are added/withdrawn > from their routing tables, or to pull the routing table as a whole at > regular intervals for storage/comparison purposes? It looks like > there's a plugin for NAGIOS, but I'm looking for suggestions on any > other tools (commercial, open source, home grown) that we might take a > look at. For reference, we are running Cisco as well as Juniper kit. Periodic table dumps, or even a log of the updates from a quagga router inside your infrastructure could provide this information. That in a nutshell is what routeviews and other collectors do for the dfz routing table. > > > Feel free to drop me your thoughts off-list. > > > > Thank you for any insight ahead of time, > > > > -Jason "Feren" Olsen > From joelja at bogus.com Fri Sep 11 06:13:20 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 11 Sep 2009 04:13:20 -0700 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <148476.263921252421878121.JavaMail.root@zimbra><4AA67551.3050402@gmail.com>, <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> <200909100348.n8A3mIfm062626@drugs.dv.isc.org> Message-ID: <4AAA30D0.6010506@bogus.com> Peter Beckman wrote: > On Thu, 10 Sep 2009, Mark Andrews wrote: > >> What a load of rubbish. How is ARIN or any RIR/LIR supposed to >> know the intent of use? > > Why don't we just blacklist everything and only whitelist those we know > are good? > > Because the cost of determining who is good and who is not has a great > cost. If you buy an IP block, regardless of your intent, that IP block > should not have the ill-will of the previous owner passed on with it. You don't buy ip blocks or at least not from ARIN. Among other things that ARIN does not guarantee is routability. > If > the previous owner sucked, the new owner should have the chance to use > that IP block without restriction until they prove that they suck, at > which point it will be blocked again. That system seems to work well > enough: blacklist blocks when they start do be evil, according to your own > (you being the neteng in charge) definition of evil. > > ARIN needs to be impartial. If they are going to sell the block, they > should do their best to make a coordinated effort to make sure the block > is as unencumbered as possible. I get that there is a sense that ARIN > needs to do more due dilligence to determine if the receiving party is > worthy of that block, but I'm not aware of the process, and from the > grumblings it doesn't seem like fun. > >> Note we all could start using IPv6 and avoid this problem altogether. > > Because as we know IPv6 space is inexhaustable. Just like IPv4 was when > it began its life. ;-) > > That won't avoid the problem, it will simply put the problem off until it > rears its head again. I'm sure that IPv6 space will be more easily gotten > until problems arise, and in a few years (maybe decades, we can put this > problem on our children's shoulders), we'll be back where we are now -- > getting recycled IP space that is blocked or encumbered due to bad > previous owners. > > Beckman > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman at angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- > From joelja at bogus.com Fri Sep 11 06:14:26 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 11 Sep 2009 04:14:26 -0700 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AA91045.9040208@splio.fr> References: <148476.263921252421878121.JavaMail.root@zimbra><4AA67551.3050402@gmail.com>, <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> <200909100348.n8A3mIfm062626@drugs.dv.isc.org> <4AA91045.9040208@splio.fr> Message-ID: <4AAA3112.1000208@bogus.com> Benjamin Billon wrote: > >> Why don't we just blacklist everything and only whitelist those we know >> are good? >> >>> Note we all could start using IPv6 and avoid this problem altogether. >> > Yeah. When ISP will start receiving SMTP traffic in IPv6, they could > start to accept whitelisted senders only. I've been reciveving smtp traffic including spam on ipv6 since 2001. > "IPv6 emails == clean" > > Utopian thought? > From wnagele at ripe.net Fri Sep 11 08:16:30 2009 From: wnagele at ripe.net (Wolfgang Nagele) Date: Fri, 11 Sep 2009 15:16:30 +0200 Subject: NAP MIA peering problems Message-ID: <4AAA4DAE.1090901@ripe.net> Hi, Anybody seeing peerings down at NAP Miami (198.32.124.0/23)? Regards, Wolfgang From robert at ufl.edu Fri Sep 11 08:18:36 2009 From: robert at ufl.edu (Robert D. Scott) Date: Fri, 11 Sep 2009 09:18:36 -0400 Subject: NAP MIA peering problems In-Reply-To: <4AAA4DAE.1090901@ripe.net> References: <4AAA4DAE.1090901@ripe.net> Message-ID: <011101ca32e2$5eff0750$1cfd15f0$@edu> Major DC power issues at the NOTA. Robert D. Scott Robert at ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Phone Tree University of Florida 352-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell -----Original Message----- From: Wolfgang Nagele [mailto:wnagele at ripe.net] Sent: Friday, September 11, 2009 9:17 AM To: nanog at nanog.org Subject: NAP MIA peering problems Hi, Anybody seeing peerings down at NAP Miami (198.32.124.0/23)? Regards, Wolfgang From wnagele at ripe.net Fri Sep 11 08:18:35 2009 From: wnagele at ripe.net (Wolfgang Nagele) Date: Fri, 11 Sep 2009 15:18:35 +0200 Subject: NAP MIA peering problems In-Reply-To: <4AAA4DAE.1090901@ripe.net> References: <4AAA4DAE.1090901@ripe.net> Message-ID: <4AAA4E2B.2080008@ripe.net> Hi, > Anybody seeing peerings down at NAP Miami (198.32.124.0/23)? Just recovered. Outage lasted about 1 hour. Regards, Wolfgang From ABass at arise.com Fri Sep 11 08:24:27 2009 From: ABass at arise.com (Allen Bass) Date: Fri, 11 Sep 2009 09:24:27 -0400 Subject: NAP MIA peering problems In-Reply-To: <4AAA4E2B.2080008@ripe.net> References: <4AAA4DAE.1090901@ripe.net> <4AAA4E2B.2080008@ripe.net> Message-ID: Yes AT&T is having a major outage affecting both data and voice. * * * * * Allen Bass Manager, Technology Operations Arise Virtual Solutions Inc. 3450 Lakeside Drive, Suite 620 Miramar, Florida 33027 www.arise.com -----Original Message----- From: Wolfgang Nagele [mailto:wnagele at ripe.net] Sent: Friday, September 11, 2009 9:19 AM To: nanog at nanog.org Subject: Re: NAP MIA peering problems Hi, > Anybody seeing peerings down at NAP Miami (198.32.124.0/23)? Just recovered. Outage lasted about 1 hour. Regards, Wolfgang From darcy at druid.net Fri Sep 11 08:28:45 2009 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Fri, 11 Sep 2009 09:28:45 -0400 Subject: SA pigeon 'faster than broadband' In-Reply-To: <4AAA1BAB.5000707@gmail.com> References: <4AAA1BAB.5000707@gmail.com> Message-ID: <20090911092845.a4dc6fa4.darcy@druid.net> On Fri, 11 Sep 2009 05:43:07 -0400 William Allen Simpson wrote: > > http://newsvote.bbc.co.uk/mpapps/pagetools/print/news.bbc.co.uk/2/hi/africa/8248056.stm?ad=1 Twenty five years ago we said "Never underestimate the bandwidth of a station wagon full of mag tapes hurtling down the highway." The tapes have got smaller as has the station wagon which has also grown wings and a self-directing control system. That's progress. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From jeff-kell at utc.edu Fri Sep 11 08:36:34 2009 From: jeff-kell at utc.edu (Jeff Kell) Date: Fri, 11 Sep 2009 09:36:34 -0400 Subject: SA pigeon 'faster than broadband' In-Reply-To: <4AAA1BAB.5000707@gmail.com> References: <4AAA1BAB.5000707@gmail.com> Message-ID: <4AAA5262.1090806@utc.edu> William Allen Simpson wrote: > > http://newsvote.bbc.co.uk/mpapps/pagetools/print/news.bbc.co.uk/2/hi/africa/8248056.stm?ad=1 > > > Update needed for RFC 1149 (1 April 1990), > A Standard for the Transmission of IP Datagrams on Avian Carriers Truly practical with today's storage media... if the Wiki story is correct, it was a 4Gb memory stick (http://en.wikipedia.org/wiki/Sneakernet under "Usage Examples"). There was the old "Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway. ?Tanenbaum, Andrew S." but then a pigeon would have trouble hauling 9-track tapes :-) Jeff From mike at mtcc.com Fri Sep 11 09:00:34 2009 From: mike at mtcc.com (Michael Thomas) Date: Fri, 11 Sep 2009 07:00:34 -0700 Subject: SA pigeon 'faster than broadband' In-Reply-To: <4AAA5262.1090806@utc.edu> References: <4AAA1BAB.5000707@gmail.com> <4AAA5262.1090806@utc.edu> Message-ID: <4AAA5802.5010109@mtcc.com> On 09/11/2009 06:36 AM, Jeff Kell wrote: > William Allen Simpson wrote: >> >> http://newsvote.bbc.co.uk/mpapps/pagetools/print/news.bbc.co.uk/2/hi/africa/8248056.stm?ad=1 >> >> >> Update needed for RFC 1149 (1 April 1990), >> A Standard for the Transmission of IP Datagrams on Avian Carriers > > Truly practical with today's storage media... if the Wiki story is > correct, it was a 4Gb memory stick > (http://en.wikipedia.org/wiki/Sneakernet under "Usage Examples"). There > was the old "Never underestimate the bandwidth of a station wagon full > of tapes hurtling down the highway. ?Tanenbaum, Andrew S." but then a > pigeon would have trouble hauling 9-track tapes :-) Heck, your average sheet of paper with your average laser printer is about 5Mb. And that's random access, not some crufty sequential seeking tape :) Mike From smb at cs.columbia.edu Fri Sep 11 09:07:24 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri, 11 Sep 2009 10:07:24 -0400 Subject: SA pigeon 'faster than broadband' In-Reply-To: <4AAA5262.1090806@utc.edu> References: <4AAA1BAB.5000707@gmail.com> <4AAA5262.1090806@utc.edu> Message-ID: <20090911100724.01310422@cs.columbia.edu> On Fri, 11 Sep 2009 09:36:34 -0400 Jeff Kell wrote: > William Allen Simpson wrote: > > > > http://newsvote.bbc.co.uk/mpapps/pagetools/print/news.bbc.co.uk/2/hi/africa/8248056.stm?ad=1 > > > > > > Update needed for RFC 1149 (1 April 1990), > > A Standard for the Transmission of IP Datagrams on Avian Carriers > > Truly practical with today's storage media... if the Wiki story is > correct, it was a 4Gb memory stick > (http://en.wikipedia.org/wiki/Sneakernet under "Usage Examples"). > There was the old "Never underestimate the bandwidth of a station > wagon full of tapes hurtling down the highway. ?Tanenbaum, Andrew S." > but then a pigeon would have trouble hauling 9-track tapes :-) > I don't know when Andy Tanenbaum said it, but I first heard it in 1969, referring to the Taconic Parkway in New York.... --Steve Bellovin, http://www.cs.columbia.edu/~smb From xbanchon at telconet.net Fri Sep 11 08:11:28 2009 From: xbanchon at telconet.net (Xavier Banchon) Date: Fri, 11 Sep 2009 13:11:28 +0000 Subject: NAP of Americas Message-ID: <1287261629-1252674693-cardhu_decombobulator_blackberry.rim.net-1022245406-@bda258.bisx.prod.on.blackberry> Hi Fellows, Does anyone have issues with Internet connection through NAP of Americas? Kind Regards, Xavier Enviado desde mi BlackBerry de Movistar From david at gower.net Fri Sep 11 09:37:50 2009 From: david at gower.net (David Gower) Date: Fri, 11 Sep 2009 09:37:50 -0500 Subject: Blacklist Message-ID: <310D96EBC64E4E33B3CF6397955D5F81@gower.priv> We are an ISP and one of our users webmail account was hacked into (poor passwd). Spam was sent out from it. We are black listed on Hotmail. I can't find anyway to get off their list. Who do I contact? Thanks David Gower President Gower Computer Support, Inc. 903 597-9220 From Philipp.Reis at telekom.de Fri Sep 11 09:33:49 2009 From: Philipp.Reis at telekom.de (Philipp.Reis at telekom.de) Date: Fri, 11 Sep 2009 16:33:49 +0200 Subject: AW: NAP of Americas In-Reply-To: <1287261629-1252674693-cardhu_decombobulator_blackberry.rim.net-1022245406-@bda258.bisx.prod.on.blackberry> References: <1287261629-1252674693-cardhu_decombobulator_blackberry.rim.net-1022245406-@bda258.bisx.prod.on.blackberry> Message-ID: <81B0126711674E4EB750A77E89D3957E032F028E@S4DE8DSAAHA.west.t-com.de> We do have problems since 13:27 CET BR Philipp -----Urspr?ngliche Nachricht----- Von: Xavier Banchon [mailto:xbanchon at telconet.net] Gesendet: Freitag, 11. September 2009 15:11 An: nanog at nanog.org Betreff: NAP of Americas Hi Fellows, Does anyone have issues with Internet connection through NAP of Americas? Kind Regards, Xavier Enviado desde mi BlackBerry de Movistar From elmi at 4ever.de Fri Sep 11 09:37:53 2009 From: elmi at 4ever.de (Elmar K. Bins) Date: Fri, 11 Sep 2009 16:37:53 +0200 Subject: NAP of Americas In-Reply-To: <1287261629-1252674693-cardhu_decombobulator_blackberry.rim.net-1022245406-@bda258.bisx.prod.on.blackberry> References: <1287261629-1252674693-cardhu_decombobulator_blackberry.rim.net-1022245406-@bda258.bisx.prod.on.blackberry> Message-ID: <20090911143753.GY43828@ronin.4ever.de> xbanchon at telconet.net (Xavier Banchon) wrote: > Does anyone have issues with Internet connection through NAP of Americas? Yes - there's obviously been some failure on the DC power, which took the peering grid down (and a few ISPs, too). Session's have come up again around an hour ago. Btw - anyone there and not peering with 31529 (.de ccTLD service), please drop me an email. It's pretty hard to get a list of participants... Cheers, Elmar. From nenolod at systeminplace.net Fri Sep 11 09:46:01 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Fri, 11 Sep 2009 09:46:01 -0500 Subject: Blacklist In-Reply-To: <310D96EBC64E4E33B3CF6397955D5F81@gower.priv> References: <310D96EBC64E4E33B3CF6397955D5F81@gower.priv> Message-ID: <1252680361.11494.13.camel@petrie> On Fri, 2009-09-11 at 09:37 -0500, David Gower wrote: > We are an ISP and one of our users webmail account was hacked into (poor passwd). Spam was sent out from it. We are black listed on Hotmail. I can't find anyway to get off their list. Who do I contact? http://postmaster.live.com/ - it is listed in their bounce messages, even... -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-866-519-6149 http://www.systeminplace.net/ Follow us on Twitter: http://www.twitter.com/systeminplace From warren at kumari.net Fri Sep 11 09:57:25 2009 From: warren at kumari.net (Warren Kumari) Date: Fri, 11 Sep 2009 10:57:25 -0400 Subject: Route table prefix monitoring In-Reply-To: <4AA8E1A9.8030602@bogus.com> References: <19A6566FA5D52A44B7F7027F7E88BEE7DF65FD@OBT-W-EVS3P.dvuadmin.net> <4AA8E1A9.8030602@bogus.com> Message-ID: <24A4610F-79C1-4A3E-A639-6C29DCE00D54@kumari.net> On Sep 10, 2009, at 7:23 AM, Joel Jaeggli wrote: > > > Olsen, Jason wrote: >> Howdy all, > >> What I'm left thinking is that it would have been great if we'd had a >> snapshot of our core routing table as it stood hours or even days >> prior >> to this event occurring, so that I could compare it with our current >> "broken" state, so the team could have seen that subnet in the core >> table and what the next hop was for the prefix. Are there any tools >> that people are using to track when/what prefixes are added/withdrawn >> from their routing tables, or to pull the routing table as a whole at >> regular intervals for storage/comparison purposes? It looks like >> there's a plugin for NAGIOS, but I'm looking for suggestions on any >> other tools (commercial, open source, home grown) that we might >> take a >> look at. For reference, we are running Cisco as well as Juniper kit. > > Periodic table dumps, or even a log of the updates from a quagga > router > inside your infrastructure could provide this information. That in a > nutshell is what routeviews and other collectors do for the dfz > routing > table. There is also an Internet draft for the BGP Monitoring Protocol (hhttp://tools.ietf.org/html/draft-ietf-grow-bmp-02) . This draft provides for a method whereby the BGP speakers export their received updates to a central collector. This allows you to get route views in (more) real time, with no more screen scraping (and probably much lower CPU as well). Personally I think its an awesome idea and is something that we have need for a long long time (over the years I must have written 7-8 screen scrapers to get BGP RIB info, and they always suck). Draft Abstract: This document proposes a simple protocol, BMP, which can be used to monitor BGP sessions. BMP is intended to provide a more convenient interface for obtaining route views for research purpose than the screen-scraping approach in common use today. The design goals are to keep BMP simple, useful, easily implemented, and minimally service-affecting. BMP is not suitable for use as a routing protocol. W > >> >> >> Feel free to drop me your thoughts off-list. >> >> >> >> Thank you for any insight ahead of time, >> >> >> >> -Jason "Feren" Olsen >> > > For every complex problem, there is a solution that is simple, neat, and wrong. -- H. L. Mencken From sergevautour at yahoo.ca Fri Sep 11 10:30:30 2009 From: sergevautour at yahoo.ca (Serge Vautour) Date: Fri, 11 Sep 2009 08:30:30 -0700 (PDT) Subject: Dedicated Route Reflectors Message-ID: <342977.61377.qm@web53611.mail.re2.yahoo.com> Hello, We're in the process of planning for an MPLS network that will use BGP for signaling between PEs. This will be a BGP free Core (i.e. no BGP on the P routers). What are folks doing for iBGP in this case? Full Mesh? Full Mesh the Main POP PEs and Route Reflect to some outlining PEs? Are folks using dedicated/centralized Route Reflectors (redundant of course)? What about using some of the P routers as the Centralized Route Reflectors? The boxes aren't doing much from a Control Plane perspective, why not use them as Route Reflectors. Any comments would be appreciated. Thanks, Serge __________________________________________________________________ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ From dholmes at mwdh2o.com Fri Sep 11 12:26:36 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Fri, 11 Sep 2009 10:26:36 -0700 Subject: Network Ring In-Reply-To: <22349.4707.qm@web52302.mail.re2.yahoo.com> References: <354013.26624.qm@web52309.mail.re2.yahoo.com><6bb5f5b10909070615qf0fbdcdo195aba4fa08ffc82@mail.gmail.com> <22349.4707.qm@web52302.mail.re2.yahoo.com> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E099D0B90@usmsxt104.mwd.h2o> An additional requirement often overlooked by Metro Ethernet architects is to ensure that layer 3 multicast stateful protocols are implemented in the carrier equipment. In order to ensure that PIM (S,G) stateful packets are not flooded out all ports in customers' geographically-dispersed switches, PIM snooping must be implemented in the carrier's equipment. Otherwise, the carriers' Metro Ethernet service operates like a 1990's-style shared hub incorrectly flooding (S,G) packets. For customers that have constant 10+ Mbps (S,G) multicast streams, the absence of PIM snooping effectively renders 10+ Mbps ports useless. -----Original Message----- From: ty chan [mailto:chanty_kh at yahoo.com] Sent: Friday, September 11, 2009 12:29 AM To: Rubens Kuhl Cc: nanog at nanog.org Subject: Re: Network Ring Does anyone have best practise for implementing those technologies ? I am currently doing a testing LAB with CISCO REP since i have a few Metro on hand. It works quite well in my LAB. There is one Request Time Out if the link break BUT it is physical layer not REP :) ________________________________ From: Rubens Kuhl To: ty chan Cc: nanog at nanog.org Sent: Monday, September 7, 2009 8:15:23 PM Subject: Re: Network Ring My vote goes to proprietary ring protection from the vendor you choose: - EAPS (Extreme) - REP (Cisco) - MRP (Foundry/Brocade) - EPSR (Allied Telesis) Although EAPS is implemented in all Extreme switches, select models from the other vendors implement ring protection, but these models also do other things you might want your network to have (QinQ, per-VLAN controls). Rubens On Mon, Sep 7, 2009 at 1:14 AM, ty chan wrote: > Dear all, > > I am in process of planning ring network to cover 15 POPs in City. Some technologies are chosen for consideration like SDH(Huawei), PVRST+(Cisco), RSTP(Zyxel), EAPS (extreme network) and MPLS(VPLS). The purpose is to provide L2 Ethernet connectivities from POPs to central point (DC) and ring protection. > > I know you all are in those network for years. can you give me some advises? > > Best regards, > chanty > From cscora at apnic.net Fri Sep 11 13:11:45 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 12 Sep 2009 04:11:45 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200909111811.n8BIBjMt002645@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 12 Sep, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 295211 Prefixes after maximum aggregation: 139476 Deaggregation factor: 2.12 Unique aggregates announced to Internet: 147649 Total ASes present in the Internet Routing Table: 32157 Prefixes per ASN: 9.18 Origin-only ASes present in the Internet Routing Table: 27945 Origin ASes announcing only one prefix: 13653 Transit ASes present in the Internet Routing Table: 4212 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: 24 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 422 Unregistered ASNs in the Routing Table: 115 Number of 32-bit ASNs allocated by the RIRs: 266 Prefixes from 32-bit ASNs in the Routing Table: 120 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 231 Number of addresses announced to Internet: 2104209216 Equivalent to 125 /8s, 107 /16s and 175 /24s Percentage of available address space announced: 56.8 Percentage of allocated address space announced: 65.0 Percentage of available address space allocated: 87.3 Percentage of address space in use by end-sites: 78.8 Total number of prefixes smaller than registry allocations: 141055 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 70468 Total APNIC prefixes after maximum aggregation: 24950 APNIC Deaggregation factor: 2.82 Prefixes being announced from the APNIC address blocks: 66937 Unique aggregates announced from the APNIC address blocks: 30456 APNIC Region origin ASes present in the Internet Routing Table: 3784 APNIC Prefixes per ASN: 17.69 APNIC Region origin ASes announcing only one prefix: 1037 APNIC Region transit ASes present in the Internet Routing Table: 588 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 458005344 Equivalent to 27 /8s, 76 /16s and 155 /24s Percentage of available APNIC address space announced: 78.0 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: 124876 Total ARIN prefixes after maximum aggregation: 66495 ARIN Deaggregation factor: 1.88 Prefixes being announced from the ARIN address blocks: 99443 Unique aggregates announced from the ARIN address blocks: 38338 ARIN Region origin ASes present in the Internet Routing Table: 13222 ARIN Prefixes per ASN: 7.52 ARIN Region origin ASes announcing only one prefix: 5117 ARIN Region transit ASes present in the Internet Routing Table: 1294 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 707359360 Equivalent to 42 /8s, 41 /16s and 114 /24s Percentage of available ARIN address space announced: 62.0 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: 68016 Total RIPE prefixes after maximum aggregation: 39994 RIPE Deaggregation factor: 1.70 Prefixes being announced from the RIPE address blocks: 61886 Unique aggregates announced from the RIPE address blocks: 41336 RIPE Region origin ASes present in the Internet Routing Table: 13459 RIPE Prefixes per ASN: 4.60 RIPE Region origin ASes announcing only one prefix: 7025 RIPE Region transit ASes present in the Internet Routing Table: 2027 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 397595456 Equivalent to 23 /8s, 178 /16s and 211 /24s Percentage of available RIPE address space announced: 79.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 25/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: 25363 Total LACNIC prefixes after maximum aggregation: 6220 LACNIC Deaggregation factor: 4.08 Prefixes being announced from the LACNIC address blocks: 23699 Unique aggregates announced from the LACNIC address blocks: 13207 LACNIC Region origin ASes present in the Internet Routing Table: 1177 LACNIC Prefixes per ASN: 20.14 LACNIC Region origin ASes announcing only one prefix: 379 LACNIC Region transit ASes present in the Internet Routing Table: 191 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 21 Number of LACNIC addresses announced to Internet: 66365952 Equivalent to 3 /8s, 244 /16s and 170 /24s Percentage of available LACNIC address space announced: 65.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: 6131 Total AfriNIC prefixes after maximum aggregation: 1561 AfriNIC Deaggregation factor: 3.93 Prefixes being announced from the AfriNIC address blocks: 4483 Unique aggregates announced from the AfriNIC address blocks: 1517 AfriNIC Region origin ASes present in the Internet Routing Table: 320 AfriNIC Prefixes per ASN: 14.01 AfriNIC Region origin ASes announcing only one prefix: 95 AfriNIC Region transit ASes present in the Internet Routing Table: 68 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 12306688 Equivalent to 0 /8s, 187 /16s and 201 /24s Percentage of available AfriNIC address space announced: 36.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 1729 6982 427 Korea Telecom (KIX) 17488 1542 137 102 Hathway IP Over Cable Interne 4755 1258 292 143 TATA Communications formerly 9583 1097 87 533 Sify Limited 4134 1006 18167 389 CHINANET-BACKBONE 18101 959 201 32 Reliance Infocom Ltd Internet 7545 842 198 99 TPG Internet Pty Ltd 9829 811 625 18 BSNL National Internet Backbo 4808 766 1534 183 CNCGROUP IP network: China169 23577 763 33 648 Korea Telecom (ATM-MPLS) 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 4173 3626 313 bellsouth.net, inc. 4323 1927 1049 389 Time Warner Telecom 1785 1739 714 138 PaeTec Communications, Inc. 7018 1526 5909 1059 AT&T WorldNet Services 20115 1479 1477 674 Charter Communications 6478 1405 282 249 AT&T Worldnet Services 2386 1292 654 939 AT&T Data Communications Serv 3356 1226 10980 439 Level 3 Communications, LLC 11492 1120 208 12 Cable One 22773 1099 2604 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 489 92 199 Evolva Telecom 3292 448 1901 395 TDC Tele Danmark 12479 426 578 6 Uni2 Autonomous System 702 425 1821 343 UUNET - Commercial IP service 35805 386 40 5 United Telecom of Georgia 9198 375 138 12 Kazakhtelecom Data Network Ad 8866 358 110 23 Bulgarian Telecommunication C 3320 354 7067 303 Deutsche Telekom AG 3301 350 1412 309 TeliaNet Sweden 3215 347 3121 111 France Telecom Transpac 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 1495 2899 243 UniNet S.A. de C.V. 10620 1013 226 97 TVCABLE BOGOTA 28573 707 620 61 NET Servicos de Comunicao S.A 7303 635 336 93 Telecom Argentina Stet-France 22047 542 302 14 VTR PUNTO NET S.A. 11830 476 310 58 Instituto Costarricense de El 11172 441 99 69 Servicios Alestra S.A de C.V 7738 424 858 29 Telecomunicacoes da Bahia S.A 6471 421 96 31 ENTEL CHILE S.A. 3816 401 191 79 Empresa Nacional de Telecomun 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 992 188 7 TEDATA 24863 947 96 57 LINKdotNET AS number 20858 296 34 6 EgyNet 3741 275 856 236 The Internet Solution 2018 207 180 142 Tertiary Education Network 6713 175 166 16 Itissalat Al-MAGHRIB 29571 139 14 6 Ci Telecom Autonomous system 24835 131 46 9 RAYA Telecom - Egypt 33776 123 7 11 Starcomms Nigeria Limited 5536 122 8 13 Internet Egypt Network 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 4173 3626 313 bellsouth.net, inc. 4323 1927 1049 389 Time Warner Telecom 1785 1739 714 138 PaeTec Communications, Inc. 4766 1729 6982 427 Korea Telecom (KIX) 17488 1542 137 102 Hathway IP Over Cable Interne 7018 1526 5909 1059 AT&T WorldNet Services 8151 1495 2899 243 UniNet S.A. de C.V. 20115 1479 1477 674 Charter Communications 6478 1405 282 249 AT&T Worldnet Services 2386 1292 654 939 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 1785 1739 1601 PaeTec Communications, Inc. 4323 1927 1538 Time Warner Telecom 17488 1542 1440 Hathway IP Over Cable Interne 4766 1729 1302 Korea Telecom (KIX) 8151 1495 1252 UniNet S.A. de C.V. 6478 1405 1156 AT&T Worldnet Services 4755 1258 1115 TATA Communications formerly 11492 1120 1108 Cable One 18566 1062 1052 Covad Communications 22773 1099 1033 Cox Communications, Inc. 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 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.176.0/22 36981 >>UNKNOWN<< 41.223.189.0/24 26452 Local Communications Networks 43.245.0.0/16 7502 Internetwork Kyoto 43.245.96.0/20 7502 Internetwork Kyoto 43.245.112.0/20 7502 Internetwork Kyoto 43.245.192.0/20 7502 Internetwork Kyoto 43.245.208.0/20 7502 Internetwork Kyoto 43.245.224.0/20 7502 Internetwork Kyoto 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:62 /12:174 /13:350 /14:627 /15:1192 /16:10662 /17:4823 /18:8391 /19:17402 /20:20778 /21:20625 /22:26667 /23:26514 /24:154117 /25:942 /26:1080 /27:575 /28:151 /29:8 /30:9 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2705 4173 bellsouth.net, inc. 4766 1408 1729 Korea Telecom (KIX) 17488 1291 1542 Hathway IP Over Cable Interne 1785 1206 1739 PaeTec Communications, Inc. 11492 1047 1120 Cable One 18566 1043 1062 Covad Communications 4323 969 1927 Time Warner Telecom 9583 949 1097 Sify Limited 10620 919 1013 TVCABLE BOGOTA 8452 914 992 TEDATA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:214 12:2143 13:7 15:21 16:3 17:5 20:36 24:1129 32:52 34:2 38:603 40:97 41:1719 43:1 44:2 47:24 52:6 55:2 56:2 57:25 58:606 59:610 60:458 61:962 62:1081 63:2009 64:3623 65:2392 66:3414 67:1761 68:980 69:2749 70:569 71:154 72:1682 73:2 74:1734 75:179 76:321 77:873 78:582 79:380 80:918 81:807 82:525 83:435 84:641 85:1028 86:379 87:680 88:383 89:1469 90:49 91:2536 92:399 93:1149 94:1168 95:1087 96:167 97:268 98:262 99:30 109:3 110:191 111:430 112:131 113:154 114:246 115:312 116:1135 117:572 118:329 119:772 120:122 121:652 122:1259 123:767 124:1050 125:1355 128:222 129:214 130:129 131:420 132:75 133:9 134:173 135:42 136:224 137:164 138:172 139:84 140:432 141:125 142:382 143:335 144:380 145:49 146:390 147:162 148:533 149:212 150:206 151:187 152:210 153:155 154:2 155:282 156:168 157:306 158:112 159:350 160:291 161:164 162:270 163:164 164:276 165:528 166:474 167:368 168:708 169:167 170:475 171:42 172:2 173:408 174:310 175:1 178:1 180:22 182:1 186:147 187:150 188:940 189:604 190:2973 192:5773 193:4251 194:3286 195:2756 196:1145 198:3548 199:3353 200:5188 201:1297 202:7833 203:8278 204:3894 205:2195 206:2391 207:2721 208:3942 209:3396 210:2542 211:1108 212:1582 213:1655 214:170 215:33 216:4281 217:1308 218:411 219:427 220:1110 221:442 222:322 End of report From surfer at mauigateway.com Fri Sep 11 13:54:02 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 11 Sep 2009 11:54:02 -0700 Subject: SA pigeon 'faster than broadband' Message-ID: <20090911115402.A670B0C9@resin13.mta.everyone.net> --- william.allen.simpson at gmail.com wrote: From: William Allen Simpson http://newsvote.bbc.co.uk/mpapps/pagetools/print/news.bbc.co.uk/2/hi/africa/8248056.stm?ad=1 Update needed for RFC 1149 (1 April 1990), A Standard for the Transmission of IP Datagrams on Avian Carriers ---------------------------------------------------- Note this part, though. ""Several recommendations have, in the past, been made to the customer but none of these have, to date, been accepted," Telkom's Troy Hector told South Africa's Sapa news agency in an e-mail." It would be nice to know what those recommendations were... scott From drew.weaver at thenap.com Fri Sep 11 13:59:45 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Fri, 11 Sep 2009 14:59:45 -0400 Subject: Intelligent network monitoring systems (commercial/open source, what have you) Message-ID: Howdy, Can anyone suggest a network monitoring system that knows the difference between a cisco 1701 and a GSR 12810/6500, etc? What I mean is, many times these days there are several different sub systems you have to monitor inside of a router/switch and not just interface utilization, the "CPU", and the "RAM". Statistics such as CEF utilization, fabric utilization, PFC/DFC, various line card statistics, etc? Can anyone recommend anything other than "customize MRTG a lot" that we can use to get a better look into these systems? thanks, -Drew From charles at thewybles.com Fri Sep 11 14:07:20 2009 From: charles at thewybles.com (Charles Wyble) Date: Fri, 11 Sep 2009 12:07:20 -0700 Subject: Intelligent network monitoring systems (commercial/open source, what have you) In-Reply-To: References: Message-ID: <4AAA9FE8.9080105@thewybles.com> Most of these threads usually result in telling the poster to RTFM with a link to it :) I'm too lazy to link the manual. :) c-nsp has extensive archives with lots of questions about various specific SNMP mibs that weren't immediately evident from RTFM. It all comes down to SNMP to the best of my knowledge. Drew Weaver wrote: > Howdy, > > Can anyone suggest a network monitoring system that knows the difference between a cisco 1701 and a GSR 12810/6500, etc? > > What I mean is, many times these days there are several different sub systems you have to monitor inside of a router/switch and not just interface utilization, the "CPU", and the "RAM". > > Statistics such as CEF utilization, fabric utilization, PFC/DFC, various line card statistics, etc? > > Can anyone recommend anything other than "customize MRTG a lot" that we can use to get a better look into these systems? > > thanks, > -Drew > > From drew.weaver at thenap.com Fri Sep 11 14:08:44 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Fri, 11 Sep 2009 15:08:44 -0400 Subject: Intelligent network monitoring systems (commercial/open source, what have you) In-Reply-To: <4AAA9FE8.9080105@thewybles.com> References: <4AAA9FE8.9080105@thewybles.com> Message-ID: Ah, I was mainly interested in an Orion like system that actually has all of that kind of worked-in. Thanks for the heads up. -Drew -----Original Message----- From: Charles Wyble [mailto:charles at thewybles.com] Sent: Friday, September 11, 2009 3:07 PM To: Drew Weaver Cc: NANOG list Subject: Re: Intelligent network monitoring systems (commercial/open source, what have you) Most of these threads usually result in telling the poster to RTFM with a link to it :) I'm too lazy to link the manual. :) c-nsp has extensive archives with lots of questions about various specific SNMP mibs that weren't immediately evident from RTFM. It all comes down to SNMP to the best of my knowledge. Drew Weaver wrote: > Howdy, > > Can anyone suggest a network monitoring system that knows the difference between a cisco 1701 and a GSR 12810/6500, etc? > > What I mean is, many times these days there are several different sub systems you have to monitor inside of a router/switch and not just interface utilization, the "CPU", and the "RAM". > > Statistics such as CEF utilization, fabric utilization, PFC/DFC, various line card statistics, etc? > > Can anyone recommend anything other than "customize MRTG a lot" that we can use to get a better look into these systems? > > thanks, > -Drew > > From nenolod at systeminplace.net Fri Sep 11 14:10:13 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Fri, 11 Sep 2009 14:10:13 -0500 Subject: Intelligent network monitoring systems (commercial/open source, what have you) In-Reply-To: References: Message-ID: <1252696213.14857.4.camel@petrie> On Fri, 2009-09-11 at 14:59 -0400, Drew Weaver wrote: > Howdy, > > Can anyone suggest a network monitoring system that knows the difference between a cisco 1701 and a GSR 12810/6500, etc? > > What I mean is, many times these days there are several different sub systems you have to monitor inside of a router/switch and not just interface utilization, the "CPU", and the "RAM". > > Statistics such as CEF utilization, fabric utilization, PFC/DFC, various line card statistics, etc? > > Can anyone recommend anything other than "customize MRTG a lot" that we can use to get a better look into these systems? We use Cacti for this purpose, but it still requires creating custom datasources for the vendor-specific SNMP MIBs. William -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-866-519-6149 http://www.systeminplace.net/ Follow us on Twitter: http://www.twitter.com/systeminplace From brandon.galbraith at gmail.com Fri Sep 11 14:12:19 2009 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Fri, 11 Sep 2009 14:12:19 -0500 Subject: Intelligent network monitoring systems (commercial/open source, what have you) In-Reply-To: <4AAA9FE8.9080105@thewybles.com> References: <4AAA9FE8.9080105@thewybles.com> Message-ID: <366100670909111212t2ba3af0bx29c6c25f65690640@mail.gmail.com> On Fri, Sep 11, 2009 at 2:07 PM, Charles Wyble wrote: > > It all comes down to SNMP to the best of my knowledge. > > True. While you don't want the MRTG answer, I'd suggest looking at Cacti. There's a large library of device profiles people have put together so as to prevent you from having to hunt down MIBs/OIDs for devices. If you have a database of your devices, it's fairly trivial to import them into Cacti once you have the device profiles (I use a shell script and curl). -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From lesmith at ecsis.net Fri Sep 11 14:12:35 2009 From: lesmith at ecsis.net (Larry Smith) Date: Fri, 11 Sep 2009 14:12:35 -0500 Subject: Intelligent network monitoring systems (commercial/open source, what have you) In-Reply-To: References: Message-ID: <200909111412.35597.lesmith@ecsis.net> On Fri September 11 2009 13:59, Drew Weaver wrote: > Howdy, > > Can anyone suggest a network monitoring system that knows the difference > between a cisco 1701 and a GSR 12810/6500, etc? > > What I mean is, many times these days there are several different sub > systems you have to monitor inside of a router/switch and not just > interface utilization, the "CPU", and the "RAM". > > Statistics such as CEF utilization, fabric utilization, PFC/DFC, various > line card statistics, etc? > > Can anyone recommend anything other than "customize MRTG a lot" that we can > use to get a better look into these systems? > > thanks, > -Drew Have you looked at OpenNMS ?? -- Larry Smith lesmith at ecsis.net From charles at thewybles.com Fri Sep 11 14:17:22 2009 From: charles at thewybles.com (Charles Wyble) Date: Fri, 11 Sep 2009 12:17:22 -0700 Subject: Intelligent network monitoring systems (commercial/open source, what have you) In-Reply-To: References: <4AAA9FE8.9080105@thewybles.com> Message-ID: <4AAAA242.3050701@thewybles.com> Drew Weaver wrote: > Ah, I was mainly interested in an Orion like system that actually has all of that kind of worked-in. Yeah I got that. I am not aware of anything that does that. Not to say it doesn't exist, but if it does it's somewhat well hidden. http://www.frank4dd.com/howto/nagios/cisco-patch-update-monitoring.htm looks interesting and has come up in several searches I've done in the past when needing to monitor cisco kit. I'm guessing CiscoWorks might have what you are looking for? I've never been happy with the big commercial NMS products. NAGIOS(with SNMP plugin)+mrtg/cacti+smokeping has served me and many of my colleagues very well. There is alerting and trending which must be taken into consideration. Alerting is pretty easy, especially with giving nagios knowledge of hierarchy (if a switch or router stops responding you don't get alerts for all the servers attached/downstream of it). You can easily automate the setup with things like nmap2nagios and other tools. Trending (which it seems is your primary concern) is harder. Zabbix has some cool SLA reporting and dashboards. I seem to recall a FLOSS NMS thread a few months ago on here, or maybe it was c-nsp. Dunno. Are you primarily concerned with monitoring, or with trending/capacity planning? > > Thanks for the heads up. > -Drew > -----Original Message----- From charles at thewybles.com Fri Sep 11 14:18:28 2009 From: charles at thewybles.com (Charles Wyble) Date: Fri, 11 Sep 2009 12:18:28 -0700 Subject: Intelligent network monitoring systems (commercial/open source, what have you) In-Reply-To: <1252696213.14857.4.camel@petrie> References: <1252696213.14857.4.camel@petrie> Message-ID: <4AAAA284.30203@thewybles.com> > > We use Cacti for this purpose, but it still requires creating custom > datasources for the vendor-specific SNMP MIBs. > +1 for cacti. I think pretty much everything requires bringing in the mibs and setting up mappings etc. I've used Nagios/Cacti/Ganglia/MRTG. From chaim.rieger at gmail.com Fri Sep 11 14:23:25 2009 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Fri, 11 Sep 2009 12:23:25 -0700 Subject: Intelligent network monitoring systems (commercial/open source, what have you) In-Reply-To: References: Message-ID: <4AAAA3AD.9040202@gmail.com> Drew Weaver wrote: > Howdy, > > Can anyone suggest a network monitoring system that knows the difference between a cisco 1701 and a GSR 12810/6500, etc? > > What I mean is, many times these days there are several different sub systems you have to monitor inside of a router/switch and not just interface utilization, the "CPU", and the "RAM". > > Statistics such as CEF utilization, fabric utilization, PFC/DFC, various line card statistics, etc? > > Can anyone recommend anything other than "customize MRTG a lot" that we can use to get a better look into these systems? > Netdisco and zabbix both have decent auto-discovery built in. zabbix will auto build a template for you which you can then deploy to your devices. From Ray.Sanders at VillageVoiceMedia.com Fri Sep 11 14:23:21 2009 From: Ray.Sanders at VillageVoiceMedia.com (Ray Sanders) Date: Fri, 11 Sep 2009 12:23:21 -0700 Subject: Intelligent network monitoring systems (commercial/open source, what have you) In-Reply-To: References: <4AAA9FE8.9080105@thewybles.com> Message-ID: <1252697001.4029.10.camel@ray-desktop> If you are interested in an Orion-Like system, but can't foot the bill for it, maybe look at IpMonitor. Solarwinds acquired IpMonitor a while back, so their sales reps will try to sell you on Orion. I've had many years of good luck with it (IpMonitor) and Solarwinds seems to be handling the software pretty well. On Fri, 2009-09-11 at 15:08 -0400, Drew Weaver wrote: > Ah, I was mainly interested in an Orion like system that actually has all of that kind of worked-in. > > Thanks for the heads up. > -Drew > -----Original Message----- > From: Charles Wyble [mailto:charles at thewybles.com] > Sent: Friday, September 11, 2009 3:07 PM > To: Drew Weaver > Cc: NANOG list > Subject: Re: Intelligent network monitoring systems (commercial/open source, what have you) > > Most of these threads usually result in telling the poster to RTFM with > a link to it :) I'm too lazy to link the manual. :) > > c-nsp has extensive archives with lots of questions about various > specific SNMP mibs that weren't immediately evident from RTFM. > > It all comes down to SNMP to the best of my knowledge. > > Drew Weaver wrote: > > Howdy, > > > > Can anyone suggest a network monitoring system that knows the difference between a cisco 1701 and a GSR 12810/6500, etc? > > > > What I mean is, many times these days there are several different sub systems you have to monitor inside of a router/switch and not just interface utilization, the "CPU", and the "RAM". > > > > Statistics such as CEF utilization, fabric utilization, PFC/DFC, various line card statistics, etc? > > > > Can anyone recommend anything other than "customize MRTG a lot" that we can use to get a better look into these systems? > > > > thanks, > > -Drew > > > > > -- "Prediction is very difficult, especially about the future." Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344 From herrin-nanog at dirtside.com Fri Sep 11 15:13:44 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Fri, 11 Sep 2009 16:13:44 -0400 Subject: SA pigeon 'faster than broadband' In-Reply-To: <20090911115402.A670B0C9@resin13.mta.everyone.net> References: <20090911115402.A670B0C9@resin13.mta.everyone.net> Message-ID: <3c3e3fca0909111313s5067d88cgbcadd8c1ead2c01e@mail.gmail.com> On Fri, Sep 11, 2009 at 2:54 PM, Scott Weeks wrote: > Note this part, though. > > ""Several recommendations have, in the past, been made to the > customer but none of these have, to date, been accepted," Telkom's > Troy Hector told South Africa's Sapa news agency in an e-mail." > > It would be nice to know what those recommendations were... "Buy a business-grade service like a T1" instead of ADSL perhaps? >From tfa (emphasis mine): "in the same time [2 hours] the **ADSL** had sent 4% of the [4GB memory stick] data." 4% of 4 gigs in 2 hours puts their ADSL _upload_speed_ in the ballpark of: 4,000,000,000 bytes * 0.04 * 8 bits per byte / 2 hours / 60 minutes per hour / 60 seconds per minute ~= 180,000 bits per second 180kbps is more or less middle-of-the-road for ADSL. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From drc at virtualized.org Fri Sep 11 15:23:57 2009 From: drc at virtualized.org (David Conrad) Date: Fri, 11 Sep 2009 13:23:57 -0700 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> <117F0F10-01CD-4356-B02B-F3137E6E6340@virtualized.org> Message-ID: <7FAB4415-3E5C-4D5B-B068-F6583D95193B@virtualized.org> Marty, On Sep 10, 2009, at 2:45 PM, Martin Hannigan wrote: >>> Not sure when ICANN got into the business of economic bailouts, >> ?? > > The blog posting implies it: > > "AfriNIC and LACNIC have fewest IPv4 /8s and service the regions > with the most developing economies. We decided that those RIRs > should have four of the easiest to use /8s reserved for them." The "economies" term used here is essentially synonymous with "countries". The decision IANA made (which is, of course, always reversible until the last /8s are allocated) is in keeping with RIR practices regarding treatment of LACNIC and AfriNIC in global allocation issues. > There is also a possible unintended consequence. If v4 address space > markets do end up being legitimized (I do believe that they will > FWIW) ICANN is in effect declaring one class of space more valuable > than another an arbitrarily assigning that value. ICANN is not declaring value of anything. All we are doing is trying to distribute the remaining /8s in a way that can be publicly verified that we have no bias in how /8s are allocated at the same time as trying to minimize the pain experienced by the recipients the /8s. >> Or are you unhappy that LACNIC and AfriNIC have 2 /8s from the >> least tainted pools? > There is currently a global policy that the RIR's and ICANN agreed > to that defines the allocation of /8's from IANA to RIR's. That > policy doesnt include a set-aside and I think that arbitrarily > adding one is not in the spirit of cooperation. The global policy for IPv4 address allocation does not specify how IANA selects the addresses it assigns to the RIRs. IANA has used different algorithms in the past. What IANA is doing now is described in the blog posting I referenced. > It's possible that not everything is above the table as well. Actually, no. The whole point in publishing the algorithm IANA is using in allocating /8s is to allow anyone to verify for themselves we are following that algorithm. > I think that the perception is reality here though. ICANN has > arbitrarily created process that impacts RIR's unequally. To me, > that's unfair. As stated, we followed existing RIR practices regarding treatment of LACNIC and AfriNIC. Oddly, the RIR CEOs were happy with the algorithm when we asked them about it. > Question is -- do a few /8's really matter? Sure. An they'll matter more as the IPv4 pool approaches exhaustion. That's why IANA has published the algorithm by which allocations are made. The goal is to forestall (or at least help defend from) the inevitable accusations of evil doing folks accuse ICANN of all the time (e.g., your message). Regards, -drc From Andrew.Claybaugh at securian.com Fri Sep 11 15:54:40 2009 From: Andrew.Claybaugh at securian.com (Andrew.Claybaugh at securian.com) Date: Fri, 11 Sep 2009 15:54:40 -0500 Subject: Multi-homed implementation and BGP convergence time Message-ID: Hello - my company currently has two connections with a single tier 1 ISP. We are using the AS from our ISP at this time. In the next month we will be implementing a third connection with a second tier 1 ISP, so we will now be using our own AS number on all three routers. My question is when we implement the new connection and update our existing connections to use are own AS number, how much downtime will there be? So far the second ISP has only said that it could be hours for BGP to fully converge. We are looking for more detail about how long the outage will be and how widespread. Will it be relatively short to our customers that are on one of the ISPs we are directly connected to? Is downtime less for customers on other tier 1 ISPs versus tier 2, etc. ISPs? We will only be receiving a default route on each of the three connections. Our routers will be advertising a small number of routes - 6 to 8. Thank you. Andy Claybaugh From surfer at mauigateway.com Fri Sep 11 16:07:44 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 11 Sep 2009 14:07:44 -0700 Subject: Multi-homed implementation and BGP convergence time Message-ID: <20090911140744.A6708E3F@resin13.mta.everyone.net> --- Andrew.Claybaugh at securian.com wrote: From: Andrew.Claybaugh at securian.com own AS number, how much downtime will there be? So far the second ISP has only said that it could be hours for BGP to fully converge. We are looking for more detail about how long the outage will be and how widespread. --------------------------------------------------- 1) Hire someone that has done this before. There're many things to be aware of. 2) Get a different provider. Anyone that said it "could be hours for BGP to fully converge" is misleading you. Especially, if you're a new customer to them. That's a bad omen for things to come. This can be done with very minimal impact. scott From jay at west.net Fri Sep 11 16:17:07 2009 From: jay at west.net (Jay Hennigan) Date: Fri, 11 Sep 2009 14:17:07 -0700 Subject: Multi-homed implementation and BGP convergence time In-Reply-To: References: Message-ID: <4AAABE53.6040103@west.net> Andrew.Claybaugh at securian.com wrote: > Hello - my company currently has two connections with a single tier 1 ISP. > We are using the AS from our ISP at this time. In the next month we will > be implementing a third connection with a second tier 1 ISP, so we will now > be using our own AS number on all three routers. My question is when we > implement the new connection and update our existing connections to use are > own AS number, how much downtime will there be? So far the second ISP has > only said that it could be hours for BGP to fully converge. We are looking > for more detail about how long the outage will be and how widespread. It should not take several hours. Typically less than 15 minutes. I would suggest that you first ensure that your networks and ASN are in the routing registries. Then schedule a downtime with your present ISP and begin advertising using your ASN. If you're not presently speaking BGP with your existing ISP, set that up first advertising your network(s) with your own ASN. > Will it be relatively short to our customers that are on one of the ISPs we > are directly connected to? Is downtime less for customers on other tier 1 > ISPs versus tier 2, etc. ISPs? There may be a short downtime when you switch to originating from your own ASN. With sufficient clue on your part and that of your current ISP, and assuming that either of the two connections can handle all of your traffic, you may be able to eliminate most or all of it. Adding the second ISP won't result in significant downtime especially if you're just taking default routes and your routers don't need to build large BGP tables. "Tier 1", "tier 2" etc. are terms used primarily by salespeople, and don't have a lot to do with technical matters. > We will only be receiving a default route on each of the three connections. > Our routers will be advertising a small number of routes - 6 to 8. -- 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 nick at foobar.org Fri Sep 11 16:21:18 2009 From: nick at foobar.org (Nick Hilliard) Date: Fri, 11 Sep 2009 22:21:18 +0100 Subject: SA pigeon 'faster than broadband' In-Reply-To: <3c3e3fca0909111313s5067d88cgbcadd8c1ead2c01e@mail.gmail.com> References: <20090911115402.A670B0C9@resin13.mta.everyone.net> <3c3e3fca0909111313s5067d88cgbcadd8c1ead2c01e@mail.gmail.com> Message-ID: <4AAABF4E.3080402@foobar.org> On 11/09/2009 21:13, William Herrin wrote: > 180kbps is more or less middle-of-the-road for ADSL. In terms of technology, it's about as close to bottom of the range as you can get. The south african incumbent, Telkom, have three different products, described here: http://www.telkom.co.za/products_services/dsl/cost_dsl_cost.html I love the product names: their 128k/384k product is called "FastDSL". Their top-of-the-range, gold plated product is a 512k/4M trailblazer service called "FastestDSL". The irony of it all... There is hope for telecoms in ZA, though - there's been several major changes to the ZA telecoms scene over the last year. A court ruling in august last year effectively opened up the telecoms market so that any company could get a generic telecoms license (VANS - value-added network service). The court case was fought tooth and nail by the ministry of communications who seemed desperate to protect the telkom / neotel duopoly. This was possibly related to the fact that Telkom is 39.8% owned by the ZA government and is something of a money-spinner. But in a major step forward for the country, the high court in Jo'burg disagreed that licenses should be restricted and refused leave to appeal after the ruling. There are now ~600 VANS license holders in south africa, up from 2 last year. The second event was that the ZA minister of communications for the last 10 years, Ivy Matsepe-Casaburri, retired from her position as minister due to natural causes. As usual for controversial figures, there were different points of view expressed on her life's work. One - typically held by government and other official figures - praised her role in communications, saying that "with her incisive intellect she has made an invaluable contribution to the development of policy in various fields, including information and communication technology." Another point of view from the industry put things slightly differently: > http://blogs.timeslive.co.za/patternrecognition/2009/04/07/ivy-matsepe-casaburri-has-died/ Last, but not least, the Seacom cable linking ZA to Marseille, Mumbai and a bunch of countries up the east coast of Africa - a cable which Matsepe-Casaburri did her best to prevent from landing in south africa - is nearing completion. This will take away Telkom's monopoly on international connectivity, which is the second major step after market liberalisation required to actually improve the industry's infrastructure. So, good news all around. Let's hope that IP over carrier pigeon will soon become a thing of the past. Nick From dmm at 1-4-5.net Fri Sep 11 16:35:27 2009 From: dmm at 1-4-5.net (David Meyer) Date: Fri, 11 Sep 2009 14:35:27 -0700 Subject: [NANOG-announce] Tentative NANOG47 Agenda available! Message-ID: <20090911213527.GA17476@1-4-5.net> Folks, The tentative agenda for NANOG47 is now available. See http://www.nanog.org/meetings/nanog47/agenda.php. Looking forward to seeing you all in Dearborn. Dave (for the NANOG PC) _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From cidr-report at potaroo.net Fri Sep 11 17:00:02 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 11 Sep 2009 22:00:02 GMT Subject: BGP Update Report Message-ID: <200909112200.n8BM02fo085798@wattle.apnic.net> BGP Update Report Interval: 03-Sep-09 -to- 10-Sep-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9198 98231 9.2% 474.5 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - AS18101 17532 1.6% 18.2 -- RIL-IDC Reliance Infocom Ltd Internet Data Centre, 3 - AS35805 15727 1.5% 40.7 -- UTG-AS United Telecom AS 4 - AS8452 12112 1.1% 12.1 -- TEDATA TEDATA 5 - AS7643 10681 1.0% 8.4 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 6 - AS17974 10057 0.9% 23.8 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 7 - AS8151 9846 0.9% 10.9 -- Uninet S.A. de C.V. 8 - AS11769 7462 0.7% 414.6 -- MOBILENETICS-LA-GW1 - Mobilenetics Corporation 9 - AS29255 7215 0.7% 78.4 -- ZAJIL-AS ZAJIL Autonomous Number in Saudi Arabia 10 - AS12479 6460 0.6% 30.6 -- UNI2-AS Uni2 Autonomous System 11 - AS4795 6386 0.6% 24.5 -- INDOSATM2-ID INDOSATM2 ASN 12 - AS17488 6348 0.6% 5.5 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 13 - AS4755 6119 0.6% 5.0 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 14 - AS5050 6047 0.6% 1209.4 -- PSC-EXT - Pittsburgh Supercomputing Center 15 - AS4249 5697 0.5% 32.9 -- LILLY-AS - Eli Lilly and Company 16 - AS13124 5660 0.5% 18.7 -- IBGC IBGC Autonomous system of Inter-Bg-Com Ltd. 17 - AS30969 5397 0.5% 337.3 -- TAN-NET TransAfrica Networks 18 - AS41313 5165 0.5% 1033.0 -- NOVATEL-AS Novatel Bulgaria 19 - AS19806 4856 0.5% 539.6 -- VIRTELA-NET-VGBLON2 Virtela Communications 20 - AS9829 4816 0.5% 9.8 -- BSNL-NIB National Internet Backbone TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS17136 2278 0.2% 2278.0 -- SPANGROUP-UTI - Span Manufacturing Ltd. 2 - AS47640 1435 0.1% 1435.0 -- TRICOMPAS Tricomp Sp. z. o. o. 3 - AS49517 2540 0.2% 1270.0 -- TEIKHOS-AS Teikhos 4 - AS5050 6047 0.6% 1209.4 -- PSC-EXT - Pittsburgh Supercomputing Center 5 - AS19398 2088 0.2% 1044.0 -- INDENET - Indenet.net 6 - AS41313 5165 0.5% 1033.0 -- NOVATEL-AS Novatel Bulgaria 7 - AS22739 1616 0.1% 808.0 -- BYU-H - Brigham Young University Hawaii 8 - AS12333 694 0.1% 694.0 -- DFINET DFi Service SA 9 - AS17819 2570 0.2% 642.5 -- ASN-EQUINIX-AP Equinix Asia Pacific 10 - AS4628 1799 0.2% 599.7 -- ASN-PACIFIC-INTERNET-IX Pacific Internet Ltd 11 - AS19806 4856 0.5% 539.6 -- VIRTELA-NET-VGBLON2 Virtela Communications 12 - AS26414 518 0.1% 518.0 -- LVCINT - LVC International, LLC 13 - AS9198 98231 9.2% 474.5 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 14 - AS31630 458 0.0% 458.0 -- GENELEC-INET-AS Information Engineering Company GENELEC 15 - AS37909 915 0.1% 457.5 -- WAKHOK-NET Wakkanai Hokusei Gakuen University 16 - AS45326 2528 0.2% 421.3 -- BBTS-AS-AP Broad Band Telecom Services Ltd 17 - AS11613 418 0.0% 418.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 18 - AS11769 7462 0.7% 414.6 -- MOBILENETICS-LA-GW1 - Mobilenetics Corporation 19 - AS28691 408 0.0% 408.0 -- EUROCDN-AS Legend Software - Welnet service 20 - AS44194 397 0.0% 397.0 -- FREIFUNK-BERLIN-AS Freifunk Berlin TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 88.204.221.0/24 10730 0.9% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - 95.59.1.0/24 10697 0.9% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 3 - 95.59.3.0/24 10374 0.9% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 4 - 95.59.8.0/23 10373 0.9% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 5 - 95.59.2.0/23 10373 0.9% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 6 - 95.59.4.0/22 10373 0.9% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 7 - 89.218.218.0/23 10357 0.9% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 8 - 89.218.220.0/23 10357 0.9% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - 92.46.244.0/23 10346 0.9% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 10 - 72.23.246.0/24 6021 0.5% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 11 - 84.1.45.0/24 5137 0.5% AS41313 -- NOVATEL-AS Novatel Bulgaria 12 - 192.12.120.0/24 2636 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 13 - 196.27.104.0/21 2572 0.2% AS30969 -- TAN-NET TransAfrica Networks 14 - 196.27.108.0/22 2561 0.2% AS30969 -- TAN-NET TransAfrica Networks 15 - 85.60.208.0/21 2428 0.2% AS12479 -- UNI2-AS Uni2 Autonomous System 16 - 206.210.121.0/24 2278 0.2% AS17136 -- SPANGROUP-UTI - Span Manufacturing Ltd. 17 - 85.60.208.0/22 2249 0.2% AS12479 -- UNI2-AS Uni2 Autonomous System 18 - 24.121.124.0/24 2143 0.2% AS25994 -- NPG-001 - NPG Cable, INC 19 - 208.31.3.0/24 2086 0.2% AS19398 -- INDENET - Indenet.net 20 - 203.120.166.0/23 1765 0.1% AS4628 -- ASN-PACIFIC-INTERNET-IX Pacific Internet Ltd 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 Sep 11 17:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 11 Sep 2009 22:00:00 GMT Subject: The Cidr Report Message-ID: <200909112200.n8BM00bk085786@wattle.apnic.net> This report has been generated at Fri Sep 11 21:11:39 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 04-09-09 301651 184977 05-09-09 301959 184945 06-09-09 301579 185149 07-09-09 301813 185299 08-09-09 302016 185233 09-09-09 302039 185192 10-09-09 301942 185552 11-09-09 302098 186405 AS Summary 32291 Number of ASes in routing system 13754 Number of ASes announcing only one prefix 4310 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 89613568 Largest address span announced by an AS (/32s) AS27064: DNIC-ASBLK-27032-27159 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 11Sep09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 302217 186263 115954 38.4% All ASes AS6389 4172 328 3844 92.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4310 1764 2546 59.1% TWTC - tw telecom holdings, inc. AS4766 1837 545 1292 70.3% KIXS-AS-KR Korea Telecom AS17488 1542 287 1255 81.4% HATHWAY-NET-AP Hathway IP Over Cable Internet AS18566 1062 10 1052 99.1% COVAD - Covad Communications Co. AS22773 1099 71 1028 93.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8151 1495 571 924 61.8% Uninet S.A. de C.V. AS4755 1257 436 821 65.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS19262 1044 236 808 77.4% VZGNI-TRANSIT - Verizon Internet Services Inc. AS6478 1405 632 773 55.0% ATT-INTERNET3 - AT&T WorldNet Services AS8452 992 264 728 73.4% TEDATA TEDATA AS18101 959 290 669 69.8% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS3356 1227 606 621 50.6% LEVEL3 Level 3 Communications AS1785 1739 1118 621 35.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS4804 680 68 612 90.0% MPX-AS Microplex PTY LTD AS10620 1013 428 585 57.7% TV Cable S.A. AS4808 766 213 553 72.2% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7303 636 95 541 85.1% Telecom Argentina S.A. AS11492 1120 584 536 47.9% CABLEONE - CABLE ONE, INC. AS9498 637 107 530 83.2% BBIL-AP BHARTI Airtel Ltd. AS22047 542 16 526 97.0% VTR BANDA ANCHA S.A. AS4134 1006 535 471 46.8% CHINANET-BACKBONE No.31,Jin-rong Street AS17676 564 127 437 77.5% GIGAINFRA Softbank BB Corp. AS7018 1494 1058 436 29.2% ATT-INTERNET4 - AT&T WorldNet Services AS7011 1017 592 425 41.8% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4780 567 146 421 74.3% SEEDNET Digital United Inc. AS7545 860 443 417 48.5% TPG-INTERNET-AP TPG Internet Pty Ltd AS5668 787 373 414 52.6% AS-5668 - CenturyTel Internet Holdings, Inc. AS4668 695 285 410 59.0% LGNET-AS-KR LG CNS AS7738 424 29 395 93.2% Telecomunicacoes da Bahia S.A. Total 36948 12257 24691 66.8% Top 30 total Possible Bogus Routes 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.176.0/22 AS36981 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 43.245.0.0/16 AS7502 IP-KYOTO Internetwork Kyoto 43.245.96.0/20 AS7502 IP-KYOTO Internetwork Kyoto 43.245.112.0/20 AS7502 IP-KYOTO Internetwork Kyoto 43.245.192.0/20 AS7502 IP-KYOTO Internetwork Kyoto 43.245.208.0/20 AS7502 IP-KYOTO Internetwork Kyoto 43.245.224.0/20 AS7502 IP-KYOTO Internetwork Kyoto 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 64.72.112.0/20 AS19166 64.247.160.0/20 AS10937 IIS - Island Internet Services 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 74.120.160.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.161.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.162.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.163.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.164.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.165.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.166.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.167.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.168.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.169.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.170.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.171.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.172.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.173.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.174.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 74.120.175.0/24 AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc. 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.8.64.0/18 AS19166 96.8.127.0/24 AS19166 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 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 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.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.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 / iLink Telecom 195.225.58.0/24 AS6714 ATOMNET ATOM SA 196.1.130.0/24 AS3741 IS 196.1.131.0/24 AS3741 IS 196.1.132.0/24 AS3741 IS 196.1.133.0/24 AS3741 IS 196.6.108.0/24 AS5713 SAIX-NET 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.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.0.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 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.134.0/24 AS3541 ITSDN-U4 - 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.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.84.10.0/23 AS9308 CHINA-ABITCOOL Abitcool(China) Inc. 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS2764 AAPT AAPT Limited 202.124.195.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 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.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 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.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 M-LINK Wind International Services SA (previously known as M-LINK) 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.34.37.0/24 AS38818 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.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/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.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.138.167.0/24 AS18990 AIRBAND-DALLAS - Airband Communications, 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.166.112.0/20 AS10937 IIS - Island Internet Services 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.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.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.217.224.0/19 AS6130 AIS-WEST - American Internet Services, LLC. 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 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 217.78.71.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.72.0/24 AS12491 IPPLANET-AS Gilat Satcom 217.78.73.0/24 AS12491 IPPLANET-AS Gilat Satcom 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 dholmes at mwdh2o.com Fri Sep 11 17:08:17 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Fri, 11 Sep 2009 15:08:17 -0700 Subject: SA pigeon 'faster than broadband' In-Reply-To: <4AAABF4E.3080402@foobar.org> References: <20090911115402.A670B0C9@resin13.mta.everyone.net><3c3e3fca0909111313s5067d88cgbcadd8c1ead2c01e@mail.gmail.com> <4AAABF4E.3080402@foobar.org> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E099D0C5B@usmsxt104.mwd.h2o> This says more about current ADSL technology not really being "broadband" than it does about South Africa's telecommunications infrastructure. Doing the arithmetic, my Southern California AT&T 384/1.5 ADSL connection would take approximately 23 hours to transmit 32 Gb (4 GB x 8) with the 384 Kbps upload speed. The referenced BBC article says that the South African link took 2 hours to transmit 4% of the 32 Gb, but assuming wire speed my ADSL connection would transmit 8% of 32 Gb in that same 2 hour time span. The BBC article does not mention the ADSL upload speed, but my feeling is that the slow transfer rate has much more to do with ADSL than South Africa's government. -----Original Message----- From: Nick Hilliard [mailto:nick at foobar.org] Sent: Friday, September 11, 2009 2:21 PM To: William Herrin Cc: nanog at merit.edu Subject: Re: SA pigeon 'faster than broadband' On 11/09/2009 21:13, William Herrin wrote: > 180kbps is more or less middle-of-the-road for ADSL. In terms of technology, it's about as close to bottom of the range as you can get. The south african incumbent, Telkom, have three different products, described here: http://www.telkom.co.za/products_services/dsl/cost_dsl_cost.html I love the product names: their 128k/384k product is called "FastDSL". Their top-of-the-range, gold plated product is a 512k/4M trailblazer service called "FastestDSL". The irony of it all... There is hope for telecoms in ZA, though - there's been several major changes to the ZA telecoms scene over the last year. A court ruling in august last year effectively opened up the telecoms market so that any company could get a generic telecoms license (VANS - value-added network service). The court case was fought tooth and nail by the ministry of communications who seemed desperate to protect the telkom / neotel duopoly. This was possibly related to the fact that Telkom is 39.8% owned by the ZA government and is something of a money-spinner. But in a major step forward for the country, the high court in Jo'burg disagreed that licenses should be restricted and refused leave to appeal after the ruling. There are now ~600 VANS license holders in south africa, up from 2 last year. The second event was that the ZA minister of communications for the last 10 years, Ivy Matsepe-Casaburri, retired from her position as minister due to natural causes. As usual for controversial figures, there were different points of view expressed on her life's work. One - typically held by government and other official figures - praised her role in communications, saying that "with her incisive intellect she has made an invaluable contribution to the development of policy in various fields, including information and communication technology." Another point of view from the industry put things slightly differently: > http://blogs.timeslive.co.za/patternrecognition/2009/04/07/ivy-matsepe-c asaburri-has-died/ Last, but not least, the Seacom cable linking ZA to Marseille, Mumbai and a bunch of countries up the east coast of Africa - a cable which Matsepe-Casaburri did her best to prevent from landing in south africa - is nearing completion. This will take away Telkom's monopoly on international connectivity, which is the second major step after market liberalisation required to actually improve the industry's infrastructure. So, good news all around. Let's hope that IP over carrier pigeon will soon become a thing of the past. Nick From dholmes at mwdh2o.com Fri Sep 11 17:25:48 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Fri, 11 Sep 2009 15:25:48 -0700 Subject: Multi-homed implementation and BGP convergence time In-Reply-To: References: Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E099D0C60@usmsxt104.mwd.h2o> The time should be measured in seconds for your BGP advertised prefixes to propagate to most of the Internet. It may take longer for some isolated ISP's to receive the routes. If you use the longest prefix method to advertise to your preferred ISP, a convergence to the backup ISP (where shorter prefixes are advertised) may take 30 seconds or so max. Converging back to the preferred ISP should take a few seconds max. -----Original Message----- From: Andrew.Claybaugh at securian.com [mailto:Andrew.Claybaugh at securian.com] Sent: Friday, September 11, 2009 1:55 PM To: nanog at nanog.org Subject: Multi-homed implementation and BGP convergence time Hello - my company currently has two connections with a single tier 1 ISP. We are using the AS from our ISP at this time. In the next month we will be implementing a third connection with a second tier 1 ISP, so we will now be using our own AS number on all three routers. My question is when we implement the new connection and update our existing connections to use are own AS number, how much downtime will there be? So far the second ISP has only said that it could be hours for BGP to fully converge. We are looking for more detail about how long the outage will be and how widespread. Will it be relatively short to our customers that are on one of the ISPs we are directly connected to? Is downtime less for customers on other tier 1 ISPs versus tier 2, etc. ISPs? We will only be receiving a default route on each of the three connections. Our routers will be advertising a small number of routes - 6 to 8. Thank you. Andy Claybaugh From surfer at mauigateway.com Fri Sep 11 17:29:00 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 11 Sep 2009 15:29:00 -0700 Subject: SA pigeon 'faster than broadband' Message-ID: <20090911152900.A6709CA4@resin13.mta.everyone.net> --- nick at foobar.org wrote: So, good news all around. Let's hope that IP over carrier pigeon will soon become a thing of the past. ------------------------------------- 4GB = 32Gb 32Gb in 2 hours is 4.45Mbps. That's a pretty good DSL upstream bandwidth. scott From richard at bennett.com Fri Sep 11 17:37:15 2009 From: richard at bennett.com (Richard Bennett) Date: Fri, 11 Sep 2009 15:37:15 -0700 Subject: SA pigeon 'faster than broadband' In-Reply-To: <20090911152900.A6709CA4@resin13.mta.everyone.net> References: <20090911152900.A6709CA4@resin13.mta.everyone.net> Message-ID: <4AAAD11B.4020703@bennett.com> If this news had come out a little earlier, some pigeon breeding programs may have qualified for broadband stimulus grants. Edible, self-replicating IP carriers are pretty special anyhow. Scott Weeks wrote: > --- nick at foobar.org wrote: > So, good news all around. Let's hope that IP over carrier pigeon will > soon become a thing of the past. > ------------------------------------- > > > 4GB = 32Gb > > 32Gb in 2 hours is 4.45Mbps. That's a pretty good DSL upstream bandwidth. > > scott > > > > > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From christopher.p.hart at gmail.com Fri Sep 11 17:42:28 2009 From: christopher.p.hart at gmail.com (Christopher Hart) Date: Fri, 11 Sep 2009 15:42:28 -0700 Subject: SA pigeon 'faster than broadband' In-Reply-To: <4AAAD11B.4020703@bennett.com> References: <20090911152900.A6709CA4@resin13.mta.everyone.net> <4AAAD11B.4020703@bennett.com> Message-ID: "Edible, self-replicating IP carriers are pretty special anyhow." Mainstream IPv6 Here we come! ;) On Fri, Sep 11, 2009 at 3:37 PM, Richard Bennett wrote: > If this news had come out a little earlier, some pigeon breeding programs > may have qualified for broadband stimulus grants. Edible, self-replicating > IP carriers are pretty special anyhow. > > > Scott Weeks wrote: > >> --- nick at foobar.org wrote: >> So, good news all around. Let's hope that IP over carrier pigeon will >> soon become a thing of the past. >> ------------------------------------- >> >> >> 4GB = 32Gb >> >> 32Gb in 2 hours is 4.45Mbps. That's a pretty good DSL upstream bandwidth. >> >> scott >> >> >> >> >> >> > > -- > Richard Bennett > Research Fellow > Information Technology and Innovation Foundation > Washington, DC > > > -- Respectfully, Chris Hart Systems Administrator Extrameasures, LLC. 8910 University Center Lane, Suite 475 San Diego, CA 92122 Office - 858.546.1052 x32 Fax - 858.546.1057 From martin at theicelandguy.com Fri Sep 11 17:52:38 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Fri, 11 Sep 2009 18:52:38 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <7FAB4415-3E5C-4D5B-B068-F6583D95193B@virtualized.org> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> <117F0F10-01CD-4356-B02B-F3137E6E6340@virtualized.org> <7FAB4415-3E5C-4D5B-B068-F6583D95193B@virtualized.org> Message-ID: On Fri, Sep 11, 2009 at 4:23 PM, David Conrad wrote: > Marty, > > > It's possible that not everything is above the table as well. >> > > Actually, no. The whole point in publishing the algorithm IANA is using in > allocating /8s is to allow anyone to verify for themselves we are following > that algorithm. > Sorry, poor wording on my part. See below. > > I think that the perception is reality here though. ICANN has arbitrarily >> created process that impacts RIR's unequally. To me, that's unfair. >> > > As stated, we followed existing RIR practices regarding treatment of LACNIC > and AfriNIC. Oddly, the RIR CEOs were happy with the algorithm when we > asked them about it. > I honestly don't think that it's up to them to create a set-aside either, hence my comment about behind the scenes activities. I appreciate you detailing that, but I honestly don't think it matters since as you mentioned you get accused of this all of the time. I would expect that ICANN would not only follow the rules, but safeguard them as well. Numbering policy usually goes to the members of each of the RIR communities, just as the IANA to RIR policy did. The algorithm itself is great. The set-aside is the problem. I'd be happy with the algorithm and all of the space. It would be more fair to us all and not appear as a cost shifting or potential windfall. Best, -M< -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From sethm at rollernet.us Fri Sep 11 17:53:34 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 11 Sep 2009 15:53:34 -0700 Subject: Multi-homed implementation and BGP convergence time In-Reply-To: <4AAABE53.6040103@west.net> References: <4AAABE53.6040103@west.net> Message-ID: <4AAAD4EE.9030502@rollernet.us> Jay Hennigan wrote: > > "Tier 1", "tier 2" etc. are terms used primarily by salespeople, and > don't have a lot to do with technical matters. > Sure it does. If you're multihoming it will increase your AS path length. ~Seth From sethm at rollernet.us Fri Sep 11 17:54:37 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 11 Sep 2009 15:54:37 -0700 Subject: Multi-homed implementation and BGP convergence time In-Reply-To: References: Message-ID: <4AAAD52D.7000706@rollernet.us> Andrew.Claybaugh at securian.com wrote: > Hello - my company currently has two connections with a single tier 1 ISP. > We are using the AS from our ISP at this time. In the next month we will > be implementing a third connection with a second tier 1 ISP, so we will now > be using our own AS number on all three routers. My question is when we > implement the new connection and update our existing connections to use are > own AS number, how much downtime will there be? So far the second ISP has > only said that it could be hours for BGP to fully converge. We are looking > for more detail about how long the outage will be and how widespread. Hours? No way. It's more like minutes. > Will it be relatively short to our customers that are on one of the ISPs we > are directly connected to? Is downtime less for customers on other tier 1 > ISPs versus tier 2, etc. ISPs? Doesn't matter. > We will only be receiving a default route on each of the three connections. > Our routers will be advertising a small number of routes - 6 to 8. > I strongly encourage you to reconsider and take more than a default if you're multihoming and your routers have enough memory. Remember to create a full mesh on your BGP routers. And as already said, if you're totally new to BGP and multihoming, hire someone with experience in such matters to set it up. ~Seth From pavel-subscriptions at pavel.pro Fri Sep 11 18:17:20 2009 From: pavel-subscriptions at pavel.pro (Pavel Stan) Date: Sat, 12 Sep 2009 02:17:20 +0300 Subject: Dedicated Route Reflectors In-Reply-To: <342977.61377.qm@web53611.mail.re2.yahoo.com> References: <342977.61377.qm@web53611.mail.re2.yahoo.com> Message-ID: <4AAADA80.7080508@pavel.pro> Hi there The RR vs Full Mesh depends on what how you would like to balance your exit/peering points across the network. If you have, say, 3 border routers in 3 different regions, you should need at least 3 RRs if you want each region having it's own preference for the external routes. I would advise Full Mesh if the equipments can manage the number of iBGP sessions and update-groups are quite fast this days, also the management overhead is not much of an issue as "advertised". About keeping the P routers as RR, I think that is will load the FIB with useless external routes, and keeping them in a VRF is not quite OK, depending on the used platform. Pavel. Serge Vautour wrote: > Hello, > > We're in the process of planning for an MPLS network that will use BGP for signaling between PEs. This will be a BGP free Core (i.e. no BGP on the P routers). What are folks doing for iBGP in this case? Full Mesh? Full Mesh the Main POP PEs and Route Reflect to some outlining PEs? Are folks using dedicated/centralized Route Reflectors (redundant of course)? What about using some of the P routers as the Centralized Route Reflectors? The boxes aren't doing much from a Control Plane perspective, why not use them as Route Reflectors. > > Any comments would be appreciated. > > Thanks, > Serge > > > > __________________________________________________________________ > Looking for the perfect gift? Give the gift of Flickr! > > http://www.flickr.com/gift/ > > From kloch at kl.net Fri Sep 11 18:19:22 2009 From: kloch at kl.net (Kevin Loch) Date: Fri, 11 Sep 2009 19:19:22 -0400 Subject: Multi-homed implementation and BGP convergence time In-Reply-To: <4AAAD4EE.9030502@rollernet.us> References: <4AAABE53.6040103@west.net> <4AAAD4EE.9030502@rollernet.us> Message-ID: <4AAADAFA.3060805@kl.net> Seth Mattinen wrote: > Jay Hennigan wrote: >> "Tier 1", "tier 2" etc. are terms used primarily by salespeople, and >> don't have a lot to do with technical matters. >> > > Sure it does. If you're multihoming it will increase your AS path length. There is no general correlation between AS path length and whether or not a network pays to exchange traffic. There is a noticeable correlation between cost and local-preference, as-path prepending, metric setting and other ways networks control how they send you traffic. This is affected by peering selectivity as well as transit prices. - Kevin From jejs+lists at sahala.org Fri Sep 11 18:41:54 2009 From: jejs+lists at sahala.org (joshua sahala) Date: Fri, 11 Sep 2009 17:41:54 -0600 Subject: Dedicated Route Reflectors In-Reply-To: <342977.61377.qm@web53611.mail.re2.yahoo.com> References: <342977.61377.qm@web53611.mail.re2.yahoo.com> Message-ID: On 11 Sep, 2009, at 09:30, Serge Vautour wrote: > Hello, > > We're in the process of planning for an MPLS network that will use > BGP for signaling between PEs. This will be a BGP free Core (i.e. no > BGP on the P routers). What are folks doing for iBGP in this case? > Full Mesh? Full Mesh the Main POP PEs and Route Reflect to some > outlining PEs? Are folks using dedicated/centralized Route > Reflectors (redundant of course)? What about using some of the P > routers as the Centralized Route Reflectors? The boxes aren't doing > much from a Control Plane perspective, why not use them as Route > Reflectors. serge, you can, and probably should, segment your mpls signalling ibgp from your internet/peering ibgp. in other words, on your pe, you configure ipv4/ipv6 bgp sessions to your peering/transit routers, then you configure mp-bgp sessions to three or four mpls vpn route reflectors. the mpls route reflectors do not participate in the actual routing of any packets (they don't set next-hop-self, only the pe routers would), their only function is to reflect the vpn signalling between disparate pe boxen. similarly, if you have a very large number of pe routers, you can setup three or four boxes to reflect internet/customer routes...these boxes also would not route any packets, they would just reflect the non-mpls bgp sessions (they don't set next-hop-self, only the pe/ transit/peering router do). alternately, if you have local transit/peering routers at every pe site, then you can mesh all the transit/peering routers and have the local pe routers be rr clients of that site's transit/peering routers hth /joshua From glen.kent at gmail.com Fri Sep 11 19:35:27 2009 From: glen.kent at gmail.com (Glen Kent) Date: Sat, 12 Sep 2009 06:05:27 +0530 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> <4A8C2FCE.3070200@foobar.org> Message-ID: <92c950310909111735x1790e134mf9c4fe8d28032c41@mail.gmail.com> I seem to get the impression that isis is preferred in the core. Any reasons why folks dont prefer to go with ospf? Glen On Thu, Aug 20, 2009 at 3:36 PM, Randy Bush wrote: >> Unless you want your customers to have very substantial control over >> your internal network, don't use an SPF IGP like ospf or is-is. > with your customer ^ > > i know that's what you meant, but i thought it worth making it very > explicit. > > practice safe routing, do not share blood with customer. > > is-is in core with ibgp, and well-filtered ebgp (and packet filters a la > bcp 38) to customers. > > randy > > From randy at psg.com Fri Sep 11 20:23:04 2009 From: randy at psg.com (Randy Bush) Date: Fri, 11 Sep 2009 18:23:04 -0700 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: <92c950310909111735x1790e134mf9c4fe8d28032c41@mail.gmail.com> References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> <4A8C2FCE.3070200@foobar.org> <92c950310909111735x1790e134mf9c4fe8d28032c41@mail.gmail.com> Message-ID: > I seem to get the impression that isis is preferred in the core. Any > reasons why folks dont prefer to go with ospf? a bit harder to attack clnp (is-is) than ip (ospf) is-is a bit simpler to configure, though you can get a sick as you want. but don't. a bit simpler to code, so worked and was stable when ospf was far flakier than it is now. randy From Stefan.Fouant at neustar.biz Fri Sep 11 20:37:07 2009 From: Stefan.Fouant at neustar.biz (Fouant, Stefan) Date: Fri, 11 Sep 2009 21:37:07 -0400 Subject: OSPF vs IS-IS vs PrivateAS eBGP Message-ID: <01B071CE08A7514CB72950074134151AE288DF@STNTEXCH12.cis.neustar.com> I can tell you one reason IS-IS has been traditionally preferred over OSPFv2 is due to it's use of TLVs, which makes IS-IS highly extensible and easy to support new features. I remember when we first rolled out MPLS code on our core routers at UUnet, support for traffic engineering extensions made it into IS-IS long before OSPFv2 due to the ease with which the developers could augment the protocol. Opaque LSAs in OSPF have made this situation a bit more bearable, but other things like OSPFv2s tight integration and reliance on IPv4 addressing for proper operation cause other issues, therefore support for things like IPv6 requires an updated protocol - OSPFv3. If you are running IPv4 and IPv6 in your network you'll need to run both OSPFv2 and OSPFv3. IS-IS on the other hand, since it is CLNS based and not coupled with IPv4 for transport can support IPv4, IPv6, and whatever new protocol we'll be using whenever we run out of the trillions of IP space that IPv6 will provide. Sorry for the typos and the top-posting, as I'm on my crackberry. Stefan Fouant Neustar, Inc. / Principal Engineer 46000 Center Oak Plaza Sterling, VA 20166 Office: +1.571.434.5656 ? Mobile: +1.202.210.2075 ? GPG ID: 0xB5E3803D ? stefan.fouant at neustar.biz ----- Original Message ----- From: Glen Kent To: Randy Bush Cc: nanog at nanog.org Sent: Fri Sep 11 20:35:27 2009 Subject: Re: OSPF vs IS-IS vs PrivateAS eBGP I seem to get the impression that isis is preferred in the core. Any reasons why folks dont prefer to go with ospf? Glen On Thu, Aug 20, 2009 at 3:36 PM, Randy Bush wrote: >> Unless you want your customers to have very substantial control over >> your internal network, don't use an SPF IGP like ospf or is-is. > with your customer ^ > > i know that's what you meant, but i thought it worth making it very > explicit. > > practice safe routing, do not share blood with customer. > > is-is in core with ibgp, and well-filtered ebgp (and packet filters a la > bcp 38) to customers. > > randy > > From cordmacleod at gmail.com Fri Sep 11 20:49:59 2009 From: cordmacleod at gmail.com (Cord MacLeod) Date: Fri, 11 Sep 2009 18:49:59 -0700 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com> <4A8C2FCE.3070200@foobar.org> <92c950310909111735x1790e134mf9c4fe8d28032c41@mail.gmail.com> Message-ID: On Sep 11, 2009, at 6:23 PM, Randy Bush wrote: >> I seem to get the impression that isis is preferred in the core. Any >> reasons why folks dont prefer to go with ospf? > > a bit harder to attack clnp (is-is) than ip (ospf) > > is-is a bit simpler to configure, though you can get a sick as you > want. but don't. > > a bit simpler to code, so worked and was stable when ospf was far > flakier than it is now. I'd also add that ISIS supports IPv6 through the addition of TLVs whereas OSPF was redesigned into OSPFv3. Personally I like ISIS due to it's simplicity and use it for router loopback advertisement only. From sethm at rollernet.us Fri Sep 11 20:59:15 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 11 Sep 2009 18:59:15 -0700 Subject: Multi-homed implementation and BGP convergence time In-Reply-To: <4AAADAFA.3060805@kl.net> References: <4AAABE53.6040103@west.net> <4AAAD4EE.9030502@rollernet.us> <4AAADAFA.3060805@kl.net> Message-ID: <4AAB0073.6020908@rollernet.us> Kevin Loch wrote: > Seth Mattinen wrote: >> Jay Hennigan wrote: >>> "Tier 1", "tier 2" etc. are terms used primarily by salespeople, and >>> don't have a lot to do with technical matters. >>> >> >> Sure it does. If you're multihoming it will increase your AS path length. > > There is no general correlation between AS path length and whether > or not a network pays to exchange traffic. That has nothing to do with what I was trying to say. When one mixes shorter/longer paths, you will generally see most of your traffic come in via the shorter path. It's like if I were to multihome with the local cable co (who has Level3 as an upstream) with a connection to Level3 myself. It's not likely that traffic inbound to me is going to choose the longer route unless the shorter one is down, and it's pointless as a backup because a regional outage affecting Level3 may kill the cable co's link to them as well. ~Seth From Stefan.Fouant at neustar.biz Sat Sep 12 09:48:46 2009 From: Stefan.Fouant at neustar.biz (Fouant, Stefan) Date: Sat, 12 Sep 2009 10:48:46 -0400 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com><4A8C2FCE.3070200@foobar.org> <92c950310909111735x1790e134mf9c4fe8d28032c41@mail.gmail.com> Message-ID: <01B071CE08A7514CB72950074134151A013EA474@STNTEXCH12.cis.neustar.com> > -----Original Message----- > From: Cord MacLeod [mailto:cordmacleod at gmail.com] > Sent: Friday, September 11, 2009 9:50 PM > To: North American Network Operators Group > Subject: Re: OSPF vs IS-IS vs PrivateAS eBGP > > I'd also add that ISIS supports IPv6 through the addition of TLVs > whereas OSPF was redesigned into OSPFv3. > > Personally I like ISIS due to it's simplicity and use it for router > loopback advertisement only. Cord, so you've piqued my interest. Are you saying you run ISIS for loopback recursion, but another protocol for everything else? -- Stefan Fouant From cordmacleod at gmail.com Sat Sep 12 14:37:09 2009 From: cordmacleod at gmail.com (Cord MacLeod) Date: Sat, 12 Sep 2009 12:37:09 -0700 Subject: OSPF vs IS-IS vs PrivateAS eBGP In-Reply-To: <01B071CE08A7514CB72950074134151A013EA474@STNTEXCH12.cis.neustar.com> References: <580af3b90908190812q72a55910w910b9e07327a9e2@mail.gmail.com><4A8C2FCE.3070200@foobar.org> <92c950310909111735x1790e134mf9c4fe8d28032c41@mail.gmail.com> <01B071CE08A7514CB72950074134151A013EA474@STNTEXCH12.cis.neustar.com> Message-ID: On Sep 12, 2009, at 7:48 AM, Fouant, Stefan wrote: >> -----Original Message----- >> From: Cord MacLeod [mailto:cordmacleod at gmail.com] >> Sent: Friday, September 11, 2009 9:50 PM >> To: North American Network Operators Group >> Subject: Re: OSPF vs IS-IS vs PrivateAS eBGP >> >> I'd also add that ISIS supports IPv6 through the addition of TLVs >> whereas OSPF was redesigned into OSPFv3. >> >> Personally I like ISIS due to it's simplicity and use it for router >> loopback advertisement only. > > Cord, so you've piqued my interest. Are you saying you run ISIS for > loopback recursion, but another protocol for everything else? Correct. I use ISIS in level 2 only to announce my loopbacks, then BGP for everything else. From cloos at jhcloos.com Sat Sep 12 16:05:57 2009 From: cloos at jhcloos.com (James Cloos) Date: Sat, 12 Sep 2009 17:05:57 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <200909081934.n88JYAS9093038@aurora.sol.net> (Joe Greco's message of "Tue, 8 Sep 2009 14:34:10 -0500 (CDT)") References: <200909081934.n88JYAS9093038@aurora.sol.net> Message-ID: >>>>> "Joe" == Joe Greco writes: Joe> Show me ONE major MTA which allows you to configure an expiration Joe> for an ACL entry. Any MTA which supports using an sql db as its backend. Postfix is a fine example. You just define the table and the query to either have an until column, or have a column with the timestamp of when the entry was added and have the query ignore rows which are older than some given time. And with postfix, using its sql proxy capability, using a sql backend is fully performant. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From jgreco at ns.sol.net Sat Sep 12 16:10:37 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 12 Sep 2009 16:10:37 -0500 (CDT) Subject: Repeated Blacklisting / IP reputation In-Reply-To: from "James Cloos" at Sep 12, 2009 05:05:57 PM Message-ID: <200909122110.n8CLAbpE046363@aurora.sol.net> > >>>>> "Joe" == Joe Greco writes: > Joe> Show me ONE major MTA which allows you to configure an expiration > Joe> for an ACL entry. > > Any MTA which supports using an sql db as its backend. Postfix is a > fine example. > > You just define the table and the query to either have an until column, > or have a column with the timestamp of when the entry was added and have > the query ignore rows which are older than some given time. > > And with postfix, using its sql proxy capability, using a sql backend is > fully performant. So, you agree, MTA's do not implement this functionality. It's obviously possible to make it happen through shell scripting, database tricks, etc., but the point was that if this was commonly desired, then MTA's would be supporting it directly. It isn't commonly desired, most people just block "forever." It never ceases to amaze me how technical people so often easily miss the point. :-) ... 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 cloos at jhcloos.com Sat Sep 12 19:16:42 2009 From: cloos at jhcloos.com (James Cloos) Date: Sat, 12 Sep 2009 20:16:42 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <200909122110.n8CLAbpE046363@aurora.sol.net> (Joe Greco's message of "Sat, 12 Sep 2009 16:10:37 -0500 (CDT)") References: <200909122110.n8CLAbpE046363@aurora.sol.net> Message-ID: >>>>> "Joe" == Joe Greco writes: Joe> So, you agree, MTA's do not implement this functionality. It's Joe> obviously possible to make it happen through shell scripting, Joe> database tricks, No, I do not agree. The sql backend is part of the MTA; features added by offering a sql backend for tables of this sort (I'd use a cidr access restriction in postfix) are still features of the MTA. And actually using the power of sql when using sql is not a trick; rather it is the /point/. IOW, the MTA is the sum of its parts; when using sql lookups the db is part of the MTA. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From jgreco at ns.sol.net Sat Sep 12 19:53:32 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 12 Sep 2009 19:53:32 -0500 (CDT) Subject: Repeated Blacklisting / IP reputation In-Reply-To: from "James Cloos" at Sep 12, 2009 08:16:42 PM Message-ID: <200909130053.n8D0rW8I054755@aurora.sol.net> > >>>>> "Joe" == Joe Greco writes: > > Joe> So, you agree, MTA's do not implement this functionality. It's > Joe> obviously possible to make it happen through shell scripting, > Joe> database tricks, > > No, I do not agree. > > The sql backend is part of the MTA; features added by offering a sql > backend for tables of this sort (I'd use a cidr access restriction > in postfix) are still features of the MTA. > > And actually using the power of sql when using sql is not a trick; > rather it is the /point/. > > IOW, the MTA is the sum of its parts; when using sql lookups the db > is part of the MTA. By that argument, anything else that you install that augments the functionality of your MTA in some manner is "part" of your MTA. Since DSPAM hooks into Postfix, clearly Postfix offers Bayesian filtering, and since ClamAV hooks in, clearly Postfix offers spam filtering, and since you can use LogReport to manage its logs, clearly Postfix offers reporting via an HTTP interface, and since I find it convenient to have a shell on a mail server, when I install tcsh or zsh, that's also an offering by Postfix. No. You show me a line in Postfix's ACL code that reads to the effect of if (expiryfield < time(NULL)) { accept_message; } and then that's PART of the MTA. Otherwise, it's an add-on of some sort. Given that the point I was making was about capabilities *included* in the MTA, and given that I *said* you could add on such functions, it's kind of silly to try to confuse the issue in this manner. In other words, if it doesn't compile out of the box with it, that's what I was talking about, and that's the point. No add-ons, no enhancements. We already know that something can be *added* to help the MTA implement such a feature; that's obvious to everyone. However, it isn't commonly done, and dlr posted stats indicating that a significant percentage of spam-spewing IP addresses would continue to do so for *years*. As a result, mail admins typically throw IP's in ACL's for something that approaches *forever*. The point was that MTA's don't support anything else by default, that such a feature isn't in demand, and that the spam database analysis supports this as a not entirely unreasonable state of affairs. Further, since it is relatively unlikely, statistically speaking, that any particular IP address I'm not interested in playing semantic games about "what constitutes an MTA." I *am* interested in the general problem of outdated rules of any sort that block access to reallocated IP space; this is a real operational problem, both to recipients of such space, and to sites who have blocked such space. My tentative conclusion is that there is no realistic solution to the overall problem. Even within a single autonomous system, there usually isn't a comprehensive single unified method for denying access to services; you might have separate lists for IP in general (bogons), access to mail systems (DNSBL's and local rules derived from bad experiences), rules for access to various devices and services, rules added to block syn floods from/to, etc., etc., etc. And all of the systems to implement these rules are more or less disjoint. The concept of "virgin" IPv4 space is going to be a memory soon. ... 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 francois at menards.ca Sat Sep 12 20:35:00 2009 From: francois at menards.ca (Francois Menard) Date: Sat, 12 Sep 2009 21:35:00 -0400 Subject: Advertising BGP-4 from two islands Message-ID: <36966F25-03F7-42B7-A3D7-7A876D235764@menards.ca> I have an opportunity to launch services in a remote marke, where I cannot extend my backbone to. However, this market is big enough that I can afford to put a Cisco 7201 over there and peer in BGP-4. Do you have any advice as to what may happen if I advertise different blocks from the same AS number, from two different locations, one of which I do not have my own transport facilities to... F. From Stefan.Fouant at neustar.biz Sat Sep 12 21:01:49 2009 From: Stefan.Fouant at neustar.biz (Fouant, Stefan) Date: Sat, 12 Sep 2009 22:01:49 -0400 Subject: Advertising BGP-4 from two islands Message-ID: <01B071CE08A7514CB72950074134151AE288E3@STNTEXCH12.cis.neustar.com> This is considered a normal and accepted practice, and there are many companies out there that do just this sort of thing. From the perpective of everyone else outside your AS everything will be perfectly fine. The only thing you'll need to be aware of is that your islands will not be able to see each others routes due to AS Path loop prevention mechanisms inherent in BGP, since they will see routes received with your AS in the AS Path and will assume some type of loop is taking place. You can get around this by configuring AS loop support on your routers. My apologies for the top-posting, I'm using my BB. Stefan Fouant Neustar, Inc. / Principal Engineer 46000 Center Oak Plaza Sterling, VA 20166 Office: +1.571.434.5656 ? Mobile: +1.202.210.2075 ? GPG ID: 0xB5E3803D ? stefan.fouant at neustar.biz ----- Original Message ----- From: Francois Menard To: nanog at nanog.org Sent: Sat Sep 12 21:35:00 2009 Subject: Advertising BGP-4 from two islands I have an opportunity to launch services in a remote marke, where I cannot extend my backbone to. However, this market is big enough that I can afford to put a Cisco 7201 over there and peer in BGP-4. Do you have any advice as to what may happen if I advertise different blocks from the same AS number, from two different locations, one of which I do not have my own transport facilities to... F. From frnkblk at iname.com Sat Sep 12 23:08:16 2009 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 12 Sep 2009 23:08:16 -0500 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AA82EBB.9080708@gmail.com> References: <200909081950.n88Jo2Dl094175@aurora.sol.net> <4AA82EBB.9080708@gmail.com> Message-ID: With scarcity of IPv4 addresses, organizations are more desperate than ever to receive an allocation. If anything, there's more of a disincentive than ever before for ARIN to spend time on netblock sanitization. I do think that ARIN should inform the new netblock owner if it was previously owned or not. But if ARIN tried to start cleaning up a netblock before releasing it, there would be no end to it. How could they check against the probably hundreds of thousands private blocklist? Frank -----Original Message----- From: JC Dill [mailto:jcdill.lists at gmail.com] Sent: Wednesday, September 09, 2009 5:40 PM To: NANOG list Subject: Re: Repeated Blacklisting / IP reputation They can (and IMHO should) determine the state it is in before they reallocate it. What happens next is obviously unpredictable but in reality an IP that isn't being blocked today and isn't being used (by anyone) is highly unlikely to be widely blocked between today and the day ARIN releases it for allocation to a new entity. They can hold IPs that are not suitable for re-allocation, or at least make the status of the IPs known to the new entity before asking the entity to take on the IP block, and perhaps offering a fee discount for "tainted" addresses. (Some users may not care if the IPs are "tainted", if, for instance they plan to use the IPs for a DUL pool. I have a friend who gets $5 off his cell phone bill because he has a phone number that starts with 666 - a number that many people prefer to avoid but which works fine for his purposes and he's quite happy to get the discount. :-) ARIN shouldn't allocate previously allocated IPs until they know the IPs are not widely blocked. Or to *at the very least* ARIN should disclose what they know about the IP space before they make it someone else's problem, and give the requesting entity an option to request a new/clean/unused/unblocked IP block instead. jc From joelja at bogus.com Sat Sep 12 23:49:42 2009 From: joelja at bogus.com (joel jaeggli) Date: Sat, 12 Sep 2009 21:49:42 -0700 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <200909081950.n88Jo2Dl094175@aurora.sol.net> <4AA82EBB.9080708@gmail.com> Message-ID: <4AAC79E6.5040802@bogus.com> Frank Bulk wrote: > With scarcity of IPv4 addresses, organizations are more desperate than ever > to receive an allocation. Factual evidence that pi allocation is in fact hard to obtain would be required to support that statement. The fact of the matter is if you have a legitimate application congruent with current policy you'll get your addresses just like you would last year. Now if your business is contingent on the availability of pi addressing resources obviously you have a fiduciary responsibility to address that problem in short order. > If anything, there's more of a disincentive than > ever before for ARIN to spend time on netblock sanitization. This whole thread seems to be about shifting (I.E. by externalizing) the costs of remediation. presumably the entities responsible for the poor reputation aren't likely to pay... So heck, why not ARIN? perhaps because it's absurd on the face of it? how much do my fees go up in order to indemnify ARIN against the cost of a possible future cleanup? how many more staff do they need? Do I have to buy prefix reputation insurance as contingent requirement for a new direct assignment? > I do think that ARIN should inform the new netblock owner if it was > previously owned or not. We've got high quality data extending back through a least 1997 on what prefixes have been advertised in the DFZ, and of course from the ip reputation standpoint it doesn't so much matter if something was assigned, but rather whether it was ever used. one assumes moreover that beyond a certain point in the not too distant future it all will have been previously assigned (owned is the wrong word). > But if ARIN tried to start cleaning up a netblock > before releasing it, there would be no end to it. How could they check > against the probably hundreds of thousands private blocklist? Note that they can't insure routability either, though as a community we've gotten used to testing for stale bogon filters. > Frank > > -----Original Message----- > From: JC Dill [mailto:jcdill.lists at gmail.com] > Sent: Wednesday, September 09, 2009 5:40 PM > To: NANOG list > Subject: Re: Repeated Blacklisting / IP reputation > > > > They can (and IMHO should) determine the state it is in before they > reallocate it. What happens next is obviously unpredictable but in > reality an IP that isn't being blocked today and isn't being used (by > anyone) is highly unlikely to be widely blocked between today and the > day ARIN releases it for allocation to a new entity. > > They can hold IPs that are not suitable for re-allocation, or at least > make the status of the IPs known to the new entity before asking the > entity to take on the IP block, and perhaps offering a fee discount for > "tainted" addresses. (Some users may not care if the IPs are "tainted", > if, for instance they plan to use the IPs for a DUL pool. I have a > friend who gets $5 off his cell phone bill because he has a phone number > that starts with 666 - a number that many people prefer to avoid but > which works fine for his purposes and he's quite happy to get the > discount. :-) > > > > > ARIN shouldn't allocate previously allocated IPs until they know the IPs > are not widely blocked. Or to *at the very least* ARIN should disclose > what they know about the IP space before they make it someone else's > problem, and give the requesting entity an option to request a > new/clean/unused/unblocked IP block instead. > > > > jc > > > > From kmedcalf at dessus.com Sun Sep 13 00:38:36 2009 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sun, 13 Sep 2009 01:38:36 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <200909130053.n8D0rW8I054755@aurora.sol.net> Message-ID: <42ea58942ce1f54187a596375dfa6f49@mail.dessus.com> > and then that's PART of the MTA. Otherwise, it's an add-on > of some sort. > Given that the point I was making was about capabilities *included* in > the MTA, and given that I *said* you could add on such functions, it's > kind of silly to try to confuse the issue in this manner. CommuniGate Pro supports time limited blacklisting, at least for Ips it blacklists itself based on protocol violations & c. From herrin-nanog at dirtside.com Sun Sep 13 01:22:32 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Sun, 13 Sep 2009 02:22:32 -0400 Subject: Advertising BGP-4 from two islands In-Reply-To: <36966F25-03F7-42B7-A3D7-7A876D235764@menards.ca> References: <36966F25-03F7-42B7-A3D7-7A876D235764@menards.ca> Message-ID: <3c3e3fca0909122322h16ebf308meaaff631e1e7afae@mail.gmail.com> On Sat, Sep 12, 2009 at 9:35 PM, Francois Menard wrote: > I have an opportunity to launch services in a remote marke, where I cannot > extend my backbone to. > > However, this market is big enough that I can afford to put a Cisco 7201 > over there and peer in BGP-4. > > Do you have any advice as to what may happen if I advertise different blocks > from the same AS number, from two different locations, one of which I do not > have my own transport facilities to... This probably qualifies as a "unique routing policy" under ARIN NRPM section 5. That allows you to get another AS number. You could also get a small block of staticly-routed IPs from your ISPs in each location and use them to anchor a VPN (e.g. a GRE tunnel). That'd have the effect of extending your backbone. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From patrick at ianai.net Sun Sep 13 05:39:30 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 13 Sep 2009 06:39:30 -0400 Subject: Advertising BGP-4 from two islands In-Reply-To: <3c3e3fca0909122322h16ebf308meaaff631e1e7afae@mail.gmail.com> References: <36966F25-03F7-42B7-A3D7-7A876D235764@menards.ca> <3c3e3fca0909122322h16ebf308meaaff631e1e7afae@mail.gmail.com> Message-ID: <13312F59-FD7E-405F-A697-7500690280A6@ianai.net> On Sep 13, 2009, at 2:22 AM, William Herrin wrote: > On Sat, Sep 12, 2009 at 9:35 PM, Francois > Menard wrote: >> I have an opportunity to launch services in a remote marke, where I >> cannot >> extend my backbone to. >> >> However, this market is big enough that I can afford to put a Cisco >> 7201 >> over there and peer in BGP-4. >> >> Do you have any advice as to what may happen if I advertise >> different blocks >> from the same AS number, from two different locations, one of which >> I do not >> have my own transport facilities to... > > This probably qualifies as a "unique routing policy" under ARIN NRPM > section 5. That allows you to get another AS number. Why burn an ASN? There is no need. With "neighbor $FOO allowas-in", you can even see your own prefixes. > You could also get a small block of staticly-routed IPs from your ISPs > in each location and use them to anchor a VPN (e.g. a GRE tunnel). > That'd have the effect of extending your backbone. Another useful suggestion. Hell, don't even need GRE tunnels - who said all your IP space had to be in your personal ASN? -- TTFN, patrick From jcurran at arin.net Sun Sep 13 06:43:49 2009 From: jcurran at arin.net (John Curran) Date: Sun, 13 Sep 2009 07:43:49 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> <117F0F10-01CD-4356-B02B-F3137E6E6340@virtualized.org> <7FAB4415-3E5C-4D5B-B068-F6583D95193B@virtualized.org> Message-ID: On Sep 11, 2009, at 6:52 PM, Martin Hannigan wrote: > > I honestly don't think that it's up to them to create a set-aside > either, > hence my comment about behind the scenes activities. I appreciate you > detailing that, but I honestly don't think it matters since as you > mentioned > you get accused of this all of the time. I would expect that ICANN > would not > only follow the rules, but safeguard them as well. The RIR CEO's told the IANA to use their best judgement in making the /8 assignments. This is exactly what happens with each assignment today in any case, and would have been the same result without that feedback to IANA, i.e., what would normally have been a behind the scenes implementation issue has now been publicly detailed, and I, for one, thank the IANA for their clear and timely communications on this matter. > Numbering policy usually goes to the members of each of the RIR > communities, > just as the IANA to RIR policy did. The algorithm itself is great. The > set-aside is the problem. This is not formation of global Internet numbering policy, it's implementation of the existing policy regarding IANA to RIR /8 block assignments. Regardless, the global nature of the Internet means that we'll all deal with connectivity issues with these blocks once they're allocated. Any and all efforts that the networking community can take now to get these blocks cleaned up now would be most helpful. /John John Curran President and CEO ARIN From morrowc.lists at gmail.com Sun Sep 13 11:42:53 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 13 Sep 2009 12:42:53 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> Message-ID: <75cb24520909130942l26a6027aic868cedf823cc12f@mail.gmail.com> On Wed, Sep 9, 2009 at 11:30 PM, Leo Vegoda wrote: > On Sep 9, 2009, at 7:18 PM, Alex Lanstein wrote: > >> Along the same lines, I noticed that the worst Actor in recent >> memory (McColo - AS26780) stopped paying their bills to ARIN and >> their addresses have been returned to the pool. >> >> It's my opinion that a very select number of CIDR blocks (another >> example being the ones belonging to Cernel/InternetPath/Atrivo/etc, >> if it were ever fully extinguished) are, and forever will be, >> completely toxic and unusable to any legitimate enterprise. >> Arguments could be made that industry blacklists can and should be >> more flexible, but from the considerably more innocuous case in this >> thread, that is apparently not the modus operandi > > Putting these addresses back into use does not mean that they have to > be allocated to networks where they'll number mail servers. ARIN staff > is doubtless aware of the history of these blocks and will presumably > do their best to allocate them to networks that aren't intended to > host mail servers. to quote bmanning.. they may even be put into service on a network that is not 'the internet'. Though I think Alex's idea isn't without merit, perhaps as a stage between 'de-allocate from non-payer' and 'allocate to new payer'. (perhaps only for blocks meeting some set of criteria, yet to be determined/discussed) -Chris From morrowc.lists at gmail.com Sun Sep 13 11:45:03 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 13 Sep 2009 12:45:03 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <200909100348.n8A3mIfm062626@drugs.dv.isc.org> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> <200909100348.n8A3mIfm062626@drugs.dv.isc.org> Message-ID: <75cb24520909130945k2821dd36ud22941cb1ac334eb@mail.gmail.com> On Wed, Sep 9, 2009 at 11:48 PM, Mark Andrews wrote: > Note we all could start using IPv6 and avoid this problem altogether. > There is nothing stopping us using IPv6 especially for MTA's. that'd solve the spam problem... for a while at least. (no ipv6 traffic == no spam) -Chris (yes, I'm yanking mark's chain some) From mylists at battleop.com Sun Sep 13 19:28:05 2009 From: mylists at battleop.com (Richey) Date: Sun, 13 Sep 2009 20:28:05 -0400 Subject: OT: CLEC Mailing List Message-ID: <000901ca34d2$3b419250$b1c4b6f0$@com> I am looking for a CLEC related mailing list. I looked through the archives and it looks like ISP-CLEC is dead. Does anyone know of a mailing list that picked up the slack? Richey From truman at suspicious.org Sun Sep 13 19:40:45 2009 From: truman at suspicious.org (Truman Boyes) Date: Mon, 14 Sep 2009 10:40:45 +1000 Subject: Dedicated Route Reflectors In-Reply-To: <342977.61377.qm@web53611.mail.re2.yahoo.com> References: <342977.61377.qm@web53611.mail.re2.yahoo.com> Message-ID: Hi, I have seen networks use the control plane of large P routers to reflect their inet-vpn routes. Keep in mind that when reflecting inet- vpn routes, the next-hops need to be "reachable". So quite possibly you will need some policy to resolve the MPLS next-hops. Internet / VPN / and now IPv6 peers have different growth rates, so you may benefit in having different "types of route reflectors" for different address families. In a small PE deployment (say, 5-50) PE nodes, you can deploy the route reflection on your P routers. Create some redundancy, and have your PE nodes peer with 2-3 of them. It keeps the configuration much smaller that having to define all the neighbours in a full mesh. When you have lots of routes and PEs, you can start to have dedicated RRs for different address families. Truman On 12/09/2009, at 1:30 AM, Serge Vautour wrote: > Hello, > > We're in the process of planning for an MPLS network that will use > BGP for signaling between PEs. This will be a BGP free Core (i.e. no > BGP on the P routers). What are folks doing for iBGP in this case? > Full Mesh? Full Mesh the Main POP PEs and Route Reflect to some > outlining PEs? Are folks using dedicated/centralized Route > Reflectors (redundant of course)? What about using some of the P > routers as the Centralized Route Reflectors? The boxes aren't doing > much from a Control Plane perspective, why not use them as Route > Reflectors. > > Any comments would be appreciated. > > Thanks, > Serge > > > > > __________________________________________________________________ > Looking for the perfect gift? Give the gift of Flickr! > > http://www.flickr.com/gift/ > From scott at sberkman.net Sun Sep 13 20:21:20 2009 From: scott at sberkman.net (Scott Berkman) Date: Sun, 13 Sep 2009 21:21:20 -0400 Subject: CLEC Mailing List In-Reply-To: <000901ca34d2$3b419250$b1c4b6f0$@com> References: <000901ca34d2$3b419250$b1c4b6f0$@com> Message-ID: <011601ca34d9$aafc27c0$00f47740$@net> Take a look at http://www.voiceops.org/ -Scott -----Original Message----- From: Richey [mailto:mylists at battleop.com] Sent: Sunday, September 13, 2009 8:28 PM To: nanog at nanog.org Subject: OT: CLEC Mailing List I am looking for a CLEC related mailing list. I looked through the archives and it looks like ISP-CLEC is dead. Does anyone know of a mailing list that picked up the slack? Richey From abalashov at evaristesys.com Sun Sep 13 20:25:39 2009 From: abalashov at evaristesys.com (Alex Balashov) Date: Sun, 13 Sep 2009 21:25:39 -0400 Subject: CLEC Mailing List In-Reply-To: <011601ca34d9$aafc27c0$00f47740$@net> References: <000901ca34d2$3b419250$b1c4b6f0$@com> <011601ca34d9$aafc27c0$00f47740$@net> Message-ID: <4AAD9B93.9040201@evaristesys.com> Scott Berkman wrote: > I am looking for a CLEC related mailing list. I looked through the archives > and it looks like ISP-CLEC is dead. Does anyone know of a mailing list > that picked up the slack? It's not exactly the same crowd, but it's a highly usable and sufficiently overlapping substitute. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 From andy at nosignal.org Mon Sep 14 03:52:35 2009 From: andy at nosignal.org (Andy Davidson) Date: Mon, 14 Sep 2009 09:52:35 +0100 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <28880400.269001252443527011.JavaMail.root@zimbra> Message-ID: <922114A5-A4AD-4939-B678-DD338F1FDBDE@nosignal.org> On 9 Sep 2009, at 06:04, Peter Beckman wrote: > How about a trial period from ARIN? You get your IP block, and you > get 30 days to determine if it is "clean" or not. The reuse issue is possibly decades away in v6 land. The reuse issue can't really be solved for v4 in a year or two. Sounds like a waste of time to develop this idea further IMO. A From tjc at ecs.soton.ac.uk Mon Sep 14 05:27:39 2009 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Mon, 14 Sep 2009 11:27:39 +0100 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <75cb24520909130945k2821dd36ud22941cb1ac334eb@mail.gmail.com> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> <200909100348.n8A3mIfm062626@drugs.dv.isc.org> <75cb24520909130945k2821dd36ud22941cb1ac334eb@mail.gmail.com> <20090914102739.GI24159@login.ecs.soton.ac.uk> Message-ID: On Sun, Sep 13, 2009 at 12:45:03PM -0400, Christopher Morrow wrote: > On Wed, Sep 9, 2009 at 11:48 PM, Mark Andrews wrote: > > > > > Note we all could start using IPv6 and avoid this problem altogether. > > There is nothing stopping us using IPv6 especially for MTA's. > > that'd solve the spam problem... for a while at least. (no ipv6 > traffic == no spam) 30% of our incoming IPv6 SMTP connections are spam. -- Tim From rsk at gsp.org Mon Sep 14 05:49:49 2009 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 14 Sep 2009 06:49:49 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <20090908184444.GA68989@typo.org> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <20090908184444.GA68989@typo.org> Message-ID: <20090914104948.GA28451@gsp.org> On Tue, Sep 08, 2009 at 11:44:44AM -0700, Wayne E. Bouchard wrote: > Best practices for the public or subscription RBLs should be to place > a TTL on the entry of no more than, say, 90 days or thereabouts. But there's no reason to do so, and a number of reasons not to, including the very high probabilityXXXXXXXXXcertainty that spammers would use this to rotate through multiple allocations at 91-day intervals. Best practice is to identify blocks that are owned (or effectively owned) by spammers and blacklist them until a need arises *on the receiving side* to remove those blocks. Yes, this is unfortunate, and draconian, and any number of other things, but the ISPs responsible for this situation should probably have considered this inevitable result before they decided to host well-known spammers that 60 seconds of due diligence would have identified, and subsequently to turn a blind eye to the abuse emanating from their networks. For example: Ron Guilmette has recently pointed out that notorious spammer Scott Richter has apparently hijacked *another* /16 block -- 150.230.0.0/16. I've dropped that block into various local blacklists, and in some cases, various local firewalls. The entry is essentially permanent, because there's no reason for me to make it otherwise. Perhaps one day ARIN will yank it back, along with all his other blocks, and blacklist him for life; but (a) I doubt it and (b) I'm not willing to wait. The best course of action for me is to just consider it scorched earth and move on. ---Rsk From jcurran at arin.net Mon Sep 14 06:05:52 2009 From: jcurran at arin.net (John Curran) Date: Mon, 14 Sep 2009 07:05:52 -0400 Subject: Hijacked Blocks (was: Repeated Blacklisting / IP reputation) In-Reply-To: <20090914104948.GA28451@gsp.org> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <20090908184444.GA68989@typo.org> <20090914104948.GA28451@gsp.org> Message-ID: <4C56255D-0D8A-449A-9BC8-3013CBDE92CC@arin.net> On Sep 14, 2009, at 6:49 AM, Rich Kulawiec wrote: > ... > For example: Ron Guilmette has recently pointed out that notorious > spammer > Scott Richter has apparently hijacked *another* /16 block -- > 150.230.0.0/16. > I've dropped that block into various local blacklists, and in some > cases, > various local firewalls. The entry is essentially permanent, because > there's no reason for me to make it otherwise. Perhaps one day ARIN > will yank it back, along with all his other blocks, and blacklist him > for life; but (a) I doubt it and (b) I'm not willing to wait. The > best > course of action for me is to just consider it scorched earth and > move on. To the extent that you're aware of a fraudulently transferred address block, please report it to . Thanks! /John John Curran President and CEO ARIN From hiersd at gmail.com Mon Sep 14 08:08:14 2009 From: hiersd at gmail.com (David Hiers) Date: Mon, 14 Sep 2009 06:08:14 -0700 Subject: OT: CLEC Mailing List In-Reply-To: <000901ca34d2$3b419250$b1c4b6f0$@com> References: <000901ca34d2$3b419250$b1c4b6f0$@com> Message-ID: <2873f3700909140608m6eebb2acs536b419ded998f2b@mail.gmail.com> If a topic has anything to do with operating a voice network, VoiceOps is a good place for it. www.voiceops.org VoiceOps covers voice over IP, TDM, TSOT, whatever... David On Sun, Sep 13, 2009 at 5:28 PM, Richey wrote: > I am looking for a CLEC related mailing list. I looked through the archives > and it looks like ISP-CLEC is dead. ? Does anyone know of a mailing list > that picked up the slack? > > > > Richey > > > > > > From morrowc.lists at gmail.com Mon Sep 14 09:41:04 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 14 Sep 2009 10:41:04 -0400 Subject: Hijacked Blocks (was: Repeated Blacklisting / IP reputation) In-Reply-To: <4C56255D-0D8A-449A-9BC8-3013CBDE92CC@arin.net> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <20090908184444.GA68989@typo.org> <20090914104948.GA28451@gsp.org> <4C56255D-0D8A-449A-9BC8-3013CBDE92CC@arin.net> Message-ID: <75cb24520909140741w6dfd0913vb33ef893ffa56682@mail.gmail.com> On Mon, Sep 14, 2009 at 7:05 AM, John Curran wrote: > On Sep 14, 2009, at 6:49 AM, Rich Kulawiec wrote: >> ... >> For example: Ron Guilmette has recently pointed out that notorious >> spammer >> Scott Richter has apparently hijacked *another* /16 block -- >> 150.230.0.0/16. oh lokoie, announced by mzima, wasn't mzima also announcing some /16 'shared' (or borrowed or rented or....) from a community in Florida until recently? >> there's no reason for me to make it otherwise. ?Perhaps one day ARIN >> will yank it back, along with all his other blocks, and blacklist him how is ARIN to know that there was some mischief going on here? (aside from someone telling them, did you Rich?) >> for life; but (a) I doubt it and (b) I'm not willing to wait. ?The I asked about this once, for another spammer. I think there was discussion of 'how do we know that personX is a 'spammer'? or bad enough to 'never allocate space to ever again'? There was also the normal ARIN comment about: "If the community supports this sort of action, they ought to bring forth policy that says so." The end of the discussion was along the lines of: "Yes, we know this guy is bad news, but he always comes to us with the proper paperwork and numbers, there's nothing in the current policy set to deny him address resources. Happily though he never pays his bill after the first 12 months so we just reclaim whatever resources are allocated then." (yes, comments about more address space ending up on BL's were made, and that he probably doesn't pay because after the first 3 months the address space is 'worthless' to him...) How should this get fixed? Is it possible to make policy to address this sort of problem? -chris From hannigan at gmail.com Mon Sep 14 10:14:08 2009 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 14 Sep 2009 11:14:08 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <148476.263921252421878121.JavaMail.root@zimbra> <60B0F2124D07B942988329B5B7CA393D010FA10708@mail2.FireEye.com> <117F0F10-01CD-4356-B02B-F3137E6E6340@virtualized.org> <7FAB4415-3E5C-4D5B-B068-F6583D95193B@virtualized.org> Message-ID: <2d106eb50909140814r6e13e43ia0a965e2fe6f904e@mail.gmail.com> On Sun, Sep 13, 2009 at 7:43 AM, John Curran wrote: > On Sep 11, 2009, at 6:52 PM, Martin Hannigan wrote: > > > > I honestly don't think that it's up to them to create a set-aside > > either, > > hence my comment about behind the scenes activities. I appreciate you > > detailing that, but I honestly don't think it matters since as you > > mentioned > > you get accused of this all of the time. I would expect that ICANN > > would not > > only follow the rules, but safeguard them as well. > > > [ clip ] > what would normally have been a behind the scenes implementation issue > has now > been publicly detailed, and I, for one, thank the IANA for their clear > and > timely communications on this matter. > I do as well. ICANN does good work in this area and I would not want to appear as though I am saying otherwise. > > > Numbering policy usually goes to the members of each of the RIR > > communities, > > just as the IANA to RIR policy did. The algorithm itself is great. The > > set-aside is the problem. > > This is not formation of global Internet numbering policy, it's > implementation > of the existing policy regarding IANA to RIR /8 block assignments. > Regardless, > the global nature of the Internet means that we'll all deal with > connectivity > issues with these blocks once they're allocated. Any and all efforts > that the > networking community can take now to get these blocks cleaned up now > would be > most helpful. > > Well, ok then :-). I agree to disagree. Anything that affects the flow or quality of IPv4 address space is a policy issue in my mind, especially when a justification for an action is linked to a social issue. I know that it was said that ICANN didn't really mean it when they said that they created this action with "developing economies" in mind, at least not in the way that it is defined[1], but it's hard to say after the fact. Best Regards, Marty 1. http://en.wikipedia.org/wiki/Developing_economies From cmarlatt at rxsec.com Mon Sep 14 10:58:14 2009 From: cmarlatt at rxsec.com (Chris Marlatt) Date: Mon, 14 Sep 2009 11:58:14 -0400 Subject: Hijacked Blocks In-Reply-To: <75cb24520909140741w6dfd0913vb33ef893ffa56682@mail.gmail.com> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <20090908184444.GA68989@typo.org> <20090914104948.GA28451@gsp.org> <4C56255D-0D8A-449A-9BC8-3013CBDE92CC@arin.net> <75cb24520909140741w6dfd0913vb33ef893ffa56682@mail.gmail.com> Message-ID: <4AAE6816.5060209@rxsec.com> Christopher Morrow wrote: > The end of the discussion was along the lines of: "Yes, we know this > guy is bad news, but he always comes to us with the proper paperwork > and numbers, there's nothing in the current policy set to deny him > address resources. Happily though he never pays his bill after the > first 12 months so we just reclaim whatever resources are allocated > then." (yes, comments about more address space ending up on BL's were > made, and that he probably doesn't pay because after the first 3 > months the address space is 'worthless' to him...) > > How should this get fixed? Is it possible to make policy to address > this sort of problem? > > -chris > If this is the case one could argue that ARIN should be reserving this "worthless" address space to be used when they receive similar requests in the future. There's no reason personX should get fresh, clean address space when they make additional requests. Regards, Chris From mruiz at telwestservices.com Mon Sep 14 11:05:01 2009 From: mruiz at telwestservices.com (Michael Ruiz) Date: Mon, 14 Sep 2009 11:05:01 -0500 Subject: Message-ID: <9F285BFE1D7757499D9FF095B4EE347D0444E7F3@tw-xchange01.TWC.local> I am having difficulty maintaining my BGP session from my 6509 with Sup-7203bxls to a 7206 VXR NPE-400. The session bounces every 3 minutes. I do have other IBGP sessions that are established with no problems, however, this is the only IBGP peer that is bouncing regularly. cr1.AUSTTXEE#show ip bgp neighbors 67.214.64.100 BGP state = Established, up for 00:02:54 Last read 00:00:53, last write 00:02:54, hold time is 180, keepalive interval is 60 seconds Keepalives are temporarily in throttle due to closed TCP window Neighbor capabilities: Route refresh: advertised and received(new) Address family IPv4 Unicast: advertised and received Message statistics: What does exactly the message mean and how do I stabilize this? Any help will be appreciated. Michael Ruiz Network Engineer Office 210-448-0040 Cell 512-744-3826 mruiz at telwestservices.com "I don't measure a man's success by how high he climbs but how high he bounces when he hits bottom." - General George S. Patton Jr. How am I doing? Please email my Director of Engineering Jared Martin with any feedback at: jmartin at telwestservices.com -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2943 bytes Desc: image001.jpg URL: From morrowc.lists at gmail.com Mon Sep 14 11:39:53 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 14 Sep 2009 12:39:53 -0400 Subject: Hijacked Blocks In-Reply-To: <4AAE6816.5060209@rxsec.com> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <20090908184444.GA68989@typo.org> <20090914104948.GA28451@gsp.org> <4C56255D-0D8A-449A-9BC8-3013CBDE92CC@arin.net> <75cb24520909140741w6dfd0913vb33ef893ffa56682@mail.gmail.com> <4AAE6816.5060209@rxsec.com> Message-ID: <75cb24520909140939u2557ca3fp2e86de3974062df0@mail.gmail.com> On Mon, Sep 14, 2009 at 11:58 AM, Chris Marlatt wrote: > Christopher Morrow wrote: >> The end of the discussion was along the lines of: "Yes, we know this >> guy is bad news, but he always comes to us with the proper paperwork >> and numbers, there's nothing in the current policy set to deny him >> address resources. Happily though he never pays his bill after the >> first 12 months so we just reclaim whatever resources are allocated >> then." ?(yes, comments about more address space ending up on BL's were >> made, and that he probably doesn't pay because after the first 3 >> months the address space is 'worthless' to him...) >> >> How should this get fixed? Is it possible to make policy to address >> this sort of problem? >> >> -chris >> > > If this is the case one could argue that ARIN should be reserving this > "worthless" address space to be used when they receive similar requests > in the future. There's no reason personX should get fresh, clean address > space when they make additional requests. That implies some process changes inside ARIN (I think) and effectively saving 'your old space' for some period of time in escrow for you. This doesn't sound unreasonable, perhaps you put forth some policy verbiage on ppml? -chris From marla.azinger at frontiercorp.com Mon Sep 14 12:29:09 2009 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Mon, 14 Sep 2009 13:29:09 -0400 Subject: Hijacked Blocks In-Reply-To: <75cb24520909140939u2557ca3fp2e86de3974062df0@mail.gmail.com> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <20090908184444.GA68989@typo.org> <20090914104948.GA28451@gsp.org> <4C56255D-0D8A-449A-9BC8-3013CBDE92CC@arin.net> <75cb24520909140741w6dfd0913vb33ef893ffa56682@mail.gmail.com> <4AAE6816.5060209@rxsec.com> <75cb24520909140939u2557ca3fp2e86de3974062df0@mail.gmail.com> Message-ID: <2E2FECEBAE57CC4BAACDE67638305F1048510F3C68@ROCH-EXCH1.corp.pvt> I haven't followed this entire string. Are you saying ARIN is repeatedly handing out address space to known abusers? If that's the case then yes, some form of policy should be worked on. If on the administrative level ARIN is not researching returned blocks for abuse complaints and working to clean them up, then...I suppose policy could be proposed. I'm just not sure if that's really where the brunt of assignments to abusers is happening. >From experience I learned the most effective place for abuse stopping is at the network level. Back in 2001 my network had serious problems with this. Making a sale was more important than ensuring abuse didn't occur. However, I worked to install a policy that required customer review before assigning them address space. If public records showed abuse (which was really easy to find) or public records showed a business model that would be really only something leading to abuse complaints then engineering had the veto power to not permit the potential customer onto our network. We managed to go from allot of abuse to essentially zero in 1 year. Then we worked to clean up the damaged blocks. Granted, if a network or company goes out of business they wont care if the addresses are clean when they return them to ARIN. So maybe this is where some proposal could focus. Also, if this is a case where an entity is able to qualify for direct ARIN allocations and they are habitual at turning over because their business is essentially abusing the network, then policy could focus there as well. Its easy to create a new company name, but from experience the owners name still stays the same for the most part, so a review of the company before allocation would catch that. In reality, we would all benefit if policy to stop it before it happens and policy to clean it up before reissuing existed at the registry and the network level. It would be interesting to see what legal and staff would have to say about taking those types of measures. Controlling this type of abuse and the clean up of it is one of the older arguments for not permitting just anyone direct allocations from ARIN. Abuse and clean up is better managed and cared for at the larger Network levels. Im not looking to open a debate on this last comment. ;o) Its just something that popped into my head as to one of the explanations for why specific levels of qualifications for direct allocations from ARIN existed with IPv4. My 2cents. sorry if it seemed long Cheers, Marla Azinger Frontier Communications Sr Data Engineer -----Original Message----- From: Christopher Morrow [mailto:morrowc.lists at gmail.com] Sent: Monday, September 14, 2009 9:40 AM To: Chris Marlatt Cc: John Curran; nanog at nanog.org Subject: Re: Hijacked Blocks On Mon, Sep 14, 2009 at 11:58 AM, Chris Marlatt wrote: > Christopher Morrow wrote: >> The end of the discussion was along the lines of: "Yes, we know this >> guy is bad news, but he always comes to us with the proper paperwork >> and numbers, there's nothing in the current policy set to deny him >> address resources. Happily though he never pays his bill after the >> first 12 months so we just reclaim whatever resources are allocated >> then." (yes, comments about more address space ending up on BL's >> were made, and that he probably doesn't pay because after the first 3 >> months the address space is 'worthless' to him...) >> >> How should this get fixed? Is it possible to make policy to address >> this sort of problem? >> >> -chris >> > > If this is the case one could argue that ARIN should be reserving this > "worthless" address space to be used when they receive similar > requests in the future. There's no reason personX should get fresh, > clean address space when they make additional requests. That implies some process changes inside ARIN (I think) and effectively saving 'your old space' for some period of time in escrow for you. This doesn't sound unreasonable, perhaps you put forth some policy verbiage on ppml? -chris From nanog2 at ADNS.NET Mon Sep 14 12:32:16 2009 From: nanog2 at ADNS.NET (John Palmer (NANOG Acct)) Date: Mon, 14 Sep 2009 13:32:16 -0400 (EDT) Subject: Rack Space in Chicago area Message-ID: I may be in need of rack space in the Chicago area - the closer to downtown, the better. I have need for about 24U of space and enough AC for 4 - 2U servers, 3 - 1U servers, 2 hubs and a 3640 router. Would need connectivity (100MB ethernet) and someone that can do a BGP session with us for 3 network blocks. Timeframe would be end of year, early January. Please contact me off-list at this address. Thanks John Palmer American Webmasters, Inc. From marla.azinger at frontiercorp.com Mon Sep 14 12:35:20 2009 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Mon, 14 Sep 2009 13:35:20 -0400 Subject: Hijacked Blocks In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F1048510F3C68@ROCH-EXCH1.corp.pvt> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <20090908184444.GA68989@typo.org> <20090914104948.GA28451@gsp.org> <4C56255D-0D8A-449A-9BC8-3013CBDE92CC@arin.net> <75cb24520909140741w6dfd0913vb33ef893ffa56682@mail.gmail.com> <4AAE6816.5060209@rxsec.com> <75cb24520909140939u2557ca3fp2e86de3974062df0@mail.gmail.com> <2E2FECEBAE57CC4BAACDE67638305F1048510F3C68@ROCH-EXCH1.corp.pvt> Message-ID: <2E2FECEBAE57CC4BAACDE67638305F1048510F3C85@ROCH-EXCH1.corp.pvt> FYI- I have forwarded this conversation to ARIN ppml as this is now a topic for that mailing list more than NANOG. Cheers Marla Azinger ARIN AC VC -----Original Message----- From: Azinger, Marla [mailto:marla.azinger at frontiercorp.com] Sent: Monday, September 14, 2009 10:29 AM To: Christopher Morrow; Chris Marlatt Cc: John Curran; nanog at nanog.org Subject: RE: Hijacked Blocks I haven't followed this entire string. Are you saying ARIN is repeatedly handing out address space to known abusers? If that's the case then yes, some form of policy should be worked on. If on the administrative level ARIN is not researching returned blocks for abuse complaints and working to clean them up, then...I suppose policy could be proposed. I'm just not sure if that's really where the brunt of assignments to abusers is happening. >From experience I learned the most effective place for abuse stopping is at the network level. Back in 2001 my network had serious problems with this. Making a sale was more important than ensuring abuse didn't occur. However, I worked to install a policy that required customer review before assigning them address space. If public records showed abuse (which was really easy to find) or public records showed a business model that would be really only something leading to abuse complaints then engineering had the veto power to not permit the potential customer onto our network. We managed to go from allot of abuse to essentially zero in 1 year. Then we worked to clean up the damaged blocks. Granted, if a network or company goes out of business they wont care if the addresses are clean when they return them to ARIN. So maybe this is where some proposal could focus. Also, if this is a case where an entity is able to qualify for direct ARIN allocations and they are habitual at turning over because their business is essentially abusing the network, then policy could focus there as well. Its easy to create a new company name, but from experience the owners name still stays the same for the most part, so a review of the company before allocation would catch that. In reality, we would all benefit if policy to stop it before it happens and policy to clean it up before reissuing existed at the registry and the network level. It would be interesting to see what legal and staff would have to say about taking those types of measures. Controlling this type of abuse and the clean up of it is one of the older arguments for not permitting just anyone direct allocations from ARIN. Abuse and clean up is better managed and cared for at the larger Network levels. Im not looking to open a debate on this last comment. ;o) Its just something that popped into my head as to one of the explanations for why specific levels of qualifications for direct allocations from ARIN existed with IPv4. My 2cents. sorry if it seemed long Cheers, Marla Azinger Frontier Communications Sr Data Engineer -----Original Message----- From: Christopher Morrow [mailto:morrowc.lists at gmail.com] Sent: Monday, September 14, 2009 9:40 AM To: Chris Marlatt Cc: John Curran; nanog at nanog.org Subject: Re: Hijacked Blocks On Mon, Sep 14, 2009 at 11:58 AM, Chris Marlatt wrote: > Christopher Morrow wrote: >> The end of the discussion was along the lines of: "Yes, we know this >> guy is bad news, but he always comes to us with the proper paperwork >> and numbers, there's nothing in the current policy set to deny him >> address resources. Happily though he never pays his bill after the >> first 12 months so we just reclaim whatever resources are allocated >> then." (yes, comments about more address space ending up on BL's >> were made, and that he probably doesn't pay because after the first 3 >> months the address space is 'worthless' to him...) >> >> How should this get fixed? Is it possible to make policy to address >> this sort of problem? >> >> -chris >> > > If this is the case one could argue that ARIN should be reserving this > "worthless" address space to be used when they receive similar > requests in the future. There's no reason personX should get fresh, > clean address space when they make additional requests. That implies some process changes inside ARIN (I think) and effectively saving 'your old space' for some period of time in escrow for you. This doesn't sound unreasonable, perhaps you put forth some policy verbiage on ppml? -chris From adrian.minta at gmail.com Mon Sep 14 12:37:12 2009 From: adrian.minta at gmail.com (Adrian Minta) Date: Mon, 14 Sep 2009 20:37:12 +0300 Subject: Hijacked Blocks In-Reply-To: <4C56255D-0D8A-449A-9BC8-3013CBDE92CC@arin.net> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <20090908184444.GA68989@typo.org> <20090914104948.GA28451@gsp.org> <4C56255D-0D8A-449A-9BC8-3013CBDE92CC@arin.net> Message-ID: <4AAE7F48.4040203@gmail.com> In Europe RIPE has a nice database. Hijacking is not possible since most ISP's use filters based on RIPE Database. Why ARIN don't use a similar tool ? From swmike at swm.pp.se Mon Sep 14 12:39:12 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 14 Sep 2009 19:39:12 +0200 (CEST) Subject: In-Reply-To: <9F285BFE1D7757499D9FF095B4EE347D0444E7F3@tw-xchange01.TWC.local> References: <9F285BFE1D7757499D9FF095B4EE347D0444E7F3@tw-xchange01.TWC.local> Message-ID: On Mon, 14 Sep 2009, Michael Ruiz wrote: > I am having difficulty maintaining my BGP session from my 6509 with > Sup-7203bxls to a 7206 VXR NPE-400. The session bounces every 3 > minutes. I do have other IBGP sessions that are established with no > problems, however, this is the only IBGP peer that is bouncing > regularly. > > What does exactly the message mean and how do I stabilize this? Any > help will be appreciated. This is most likely an MTU problem. Your SYN/SYN+ACK goes thru, but then the first fullsize MSS packet is sent, and it's not getting to the destination. 3 minutes is the dead timer for keepalives, which are not getting thru either because of the stalled TCP session. -- Mikael Abrahamsson email: swmike at swm.pp.se From dotis at mail-abuse.org Mon Sep 14 12:40:33 2009 From: dotis at mail-abuse.org (Douglas Otis) Date: Tue, 15 Sep 2009 01:40:33 +0800 Subject: Repeated Blacklisting / IP reputation, replaced by registered use In-Reply-To: <4AAC79E6.5040802@bogus.com> References: <200909081950.n88Jo2Dl094175@aurora.sol.net> <4AA82EBB.9080708@gmail.com> <4AAC79E6.5040802@bogus.com> Message-ID: <4AAE8011.1040207@mail-abuse.org> On 9/13/09 12:49 PM, joel jaeggli wrote: > Frank Bulk wrote: [] >> If anything, there's more of a disincentive than ever before for >> ARIN to spend time on netblock sanitization. > > This whole thread seems to be about shifting (I.E. by externalizing) > the costs of remediation. presumably the entities responsible for the > poor reputation aren't likely to pay... So heck, why not ARIN? > perhaps because it's absurd on the face of it? how much do my fees go > up in order to indemnify ARIN against the cost of a possible future > cleanup? how many more staff do they need? Do I have to buy prefix > reputation insurance as contingent requirement for a new direct > assignm Perhaps ICANN could require registries establish a clearing-house, where at no cost, those assigned a network would register their intent to initiate bulk traffic, such as email, from specific addresses. Such a use registry would make dealing with compromised systems more tractable. >> I do think that ARIN should inform the new netblock owner if it was >> previously owned or not. > > We've got high quality data extending back through a least 1997 on > what prefixes have been advertised in the DFZ, and of course from the > ip reputation standpoint it doesn't so much matter if something was > assigned, but rather whether it was ever used. one assumes moreover > that beyond a certain point in the not too distant future it all will > have been previously assigned (owned is the wrong word). > >> But if ARIN tried to start cleaning up a netblock before releasing >> it, there would be no end to it. How could they check against the >> probably hundreds of thousands private blocklist? > > Note that they can't insure routability either, though as a community > we've gotten used to testing for stale bogon filters. The issues created by IPv4 space churn is likely to be dwarfed by eventual adoption of IPv6. Registering intent to initiate bulk traffic, such as with SMTP, could help consolidate the administration of filters, since abuse is often from addresses that network administrators did not intend. A clearing-house approach could reduce the costs of administering filters and better insure against unintentional impediments. This approach should also prove more responsive than depending upon filters embedded within various types of network equipment. By limiting registration to those controlling the network, this provides a low cost means to control use of address space without the need to impose expensive and problematic layer 7 filters that are better handled by the applications. The size of the registered use list is likely to be several orders of magnitude smaller than the typical block list. Exceptions to the use list will be even smaller still. This registry would also supplant the guesswork involved with divining meaning of reverse DNS labels. -Doug From swmike at swm.pp.se Mon Sep 14 12:41:41 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 14 Sep 2009 19:41:41 +0200 (CEST) Subject: Hijacked Blocks In-Reply-To: <4AAE7F48.4040203@gmail.com> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <20090908184444.GA68989@typo.org> <20090914104948.GA28451@gsp.org> <4C56255D-0D8A-449A-9BC8-3013CBDE92CC@arin.net> <4AAE7F48.4040203@gmail.com> Message-ID: On Mon, 14 Sep 2009, Adrian Minta wrote: > Hijacking is not possible since most ISP's use filters based on RIPE > Database. This is not true. Some filter, but most don't. -- Mikael Abrahamsson email: swmike at swm.pp.se From lee at asgard.org Mon Sep 14 13:15:09 2009 From: lee at asgard.org (Lee Howard) Date: Mon, 14 Sep 2009 14:15:09 -0400 Subject: Hijacked Blocks In-Reply-To: <75cb24520909140939u2557ca3fp2e86de3974062df0@mail.gmail.com> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <20090908184444.GA68989@typo.org> <20090914104948.GA28451@gsp.org> <4C56255D-0D8A-449A-9BC8-3013CBDE92CC@arin.net> <75cb24520909140741w6dfd0913vb33ef893ffa56682@mail.gmail.com> <4AAE6816.5060209@rxsec.com> <75cb24520909140939u2557ca3fp2e86de3974062df0@mail.gmail.com> Message-ID: <000001ca3567$4ddc3060$e9949120$@org> > > If this is the case one could argue that ARIN should be reserving this > > "worthless" address space to be used when they receive similar requests > > in the future. There's no reason personX should get fresh, clean address > > space when they make additional requests. > > That implies some process changes inside ARIN (I think) and > effectively saving 'your old space' for some period of time in escrow > for you. This doesn't sound unreasonable, perhaps you put forth some > policy verbiage on ppml? Several people have suggested several kinds of things ARIN could or should do. If you have a suggestion that would change ARIN internal operations, but doesn't really affect who gets numbers, or how many integers, you can easily make a suggestion to ARIN: https://www.arin.net/app/suggestion/ If you want to see certain parties get more, fewer, or different numbers, you can propose a policy: https://www.arin.net/participate/how_to_participate.html Seriously, both of these processes are lightweight. There's a form asking for contact info, then just explain your idea, and why it's a good idea. You should subscribe to arin-ppml at arin.net, too, but you don't have to. If you're not sure which way to go, or you want somebody to help shape the right words to do what you want, or any other kind of help understanding or shepherding your proposal through, you can email any of the members of the ARIN Advisory Council: https://www.arin.net/about_us/ac.html If you would rather kick your idea around in person before submitting it in writing, you can bring it up at the ARIN Open Policy Hour, 5:30 Tuesday of NANOG/ARIN, or just catch an Advisory Council member at ARIN. The ARIN community has tried to make it as easy as possible to propose changes and participate, but a message to NANOG may not be quite enough. Lee From lee at asgard.org Mon Sep 14 13:24:10 2009 From: lee at asgard.org (Lee Howard) Date: Mon, 14 Sep 2009 14:24:10 -0400 Subject: Repeated Blacklisting / IP reputation, replaced by registered use In-Reply-To: <4AAE8011.1040207@mail-abuse.org> References: <200909081950.n88Jo2Dl094175@aurora.sol.net> <4AA82EBB.9080708@gmail.com> <4AAC79E6.5040802@bogus.com> <4AAE8011.1040207@mail-abuse.org> Message-ID: <000101ca3568$8e63b350$ab2b19f0$@org> > -----Original Message----- > From: Douglas Otis [mailto:dotis at mail-abuse.org] > Sent: Monday, September 14, 2009 1:41 PM > To: joel jaeggli > Cc: NANOG list > Subject: Re: Repeated Blacklisting / IP reputation, replaced by registered use > > On 9/13/09 12:49 PM, joel jaeggli wrote: > > Frank Bulk wrote: > [] > >> If anything, there's more of a disincentive than ever before for > >> ARIN to spend time on netblock sanitization. > > > > This whole thread seems to be about shifting (I.E. by externalizing) > > the costs of remediation. presumably the entities responsible for the > > poor reputation aren't likely to pay... So heck, why not ARIN? > > perhaps because it's absurd on the face of it? how much do my fees go > > up in order to indemnify ARIN against the cost of a possible future > > cleanup? how many more staff do they need? Do I have to buy prefix > > reputation insurance as contingent requirement for a new direct > > assignm > > Perhaps ICANN could require registries establish a clearing-house, where > at no cost, those assigned a network would register their intent to > initiate bulk traffic, such as email, from specific addresses. Such a > use registry would make dealing with compromised systems more tractable. If they would just comply with RFC 3514, such a registry would be unnecessary. > > This registry would also supplant the guesswork involved with divining > meaning of reverse DNS labels. We could standardize a string to be used in rDNS of dynamic pools, if you want. Lee From drc at virtualized.org Mon Sep 14 13:44:25 2009 From: drc at virtualized.org (David Conrad) Date: Mon, 14 Sep 2009 11:44:25 -0700 Subject: Repeated Blacklisting / IP reputation, replaced by registered use In-Reply-To: <4AAE8011.1040207@mail-abuse.org> References: <200909081950.n88Jo2Dl094175@aurora.sol.net> <4AA82EBB.9080708@gmail.com> <4AAC79E6.5040802@bogus.com> <4AAE8011.1040207@mail-abuse.org> Message-ID: <09A94A95-480E-419B-A84A-582903DA599C@virtualized.org> On Sep 14, 2009, at 10:40 AM, Douglas Otis wrote: > Perhaps ICANN could require registries establish a clearing-house, > where at no cost, those assigned a network would register their > intent to initiate bulk traffic, such as email, from specific > addresses. ICANN can't require the RIRs do anything outside of what is specifically mentioned in global addressing policies. If you think this would be valuable and that it would make sense as a global addressing policy, then you should propose it in the RIR policy forums, get consensus amongst the five RIRs and have them forward it to ICANN as a global policy. Regards, -drc From marla.azinger at frontiercorp.com Mon Sep 14 13:50:20 2009 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Mon, 14 Sep 2009 14:50:20 -0400 Subject: Repeated Blacklisting / IP reputation, replaced by registered use In-Reply-To: <09A94A95-480E-419B-A84A-582903DA599C@virtualized.org> References: <200909081950.n88Jo2Dl094175@aurora.sol.net> <4AA82EBB.9080708@gmail.com> <4AAC79E6.5040802@bogus.com> <4AAE8011.1040207@mail-abuse.org> <09A94A95-480E-419B-A84A-582903DA599C@virtualized.org> Message-ID: <2E2FECEBAE57CC4BAACDE67638305F1048510F3DD3@ROCH-EXCH1.corp.pvt> Another one that could be discussed at the ARIN policy bof. Also, Im forwarding this to the ARIN ppml for any further discussion. Cheers Marla -----Original Message----- From: David Conrad [mailto:drc at virtualized.org] Sent: Monday, September 14, 2009 11:44 AM To: Douglas Otis Cc: NANOG list Subject: Re: Repeated Blacklisting / IP reputation, replaced by registered use On Sep 14, 2009, at 10:40 AM, Douglas Otis wrote: > Perhaps ICANN could require registries establish a clearing-house, > where at no cost, those assigned a network would register their intent > to initiate bulk traffic, such as email, from specific addresses. ICANN can't require the RIRs do anything outside of what is specifically mentioned in global addressing policies. If you think this would be valuable and that it would make sense as a global addressing policy, then you should propose it in the RIR policy forums, get consensus amongst the five RIRs and have them forward it to ICANN as a global policy. Regards, -drc From justin at justinshore.com Mon Sep 14 13:58:57 2009 From: justin at justinshore.com (Justin Shore) Date: Mon, 14 Sep 2009 13:58:57 -0500 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <200909081950.n88Jo2Dl094175@aurora.sol.net> <4AA82EBB.9080708@gmail.com> Message-ID: <4AAE9271.2040006@justinshore.com> Frank Bulk wrote: > With scarcity of IPv4 addresses, organizations are more desperate than ever > to receive an allocation. If anything, there's more of a disincentive than > ever before for ARIN to spend time on netblock sanitization. > > I do think that ARIN should inform the new netblock owner if it was > previously owned or not. But if ARIN tried to start cleaning up a netblock > before releasing it, there would be no end to it. How could they check > against the probably hundreds of thousands private blocklist? They could implement a process by which they announce to a mailing list of DNSBL providers that a given assignment has been returned to the RIR and that it should be cleansed from all DNSBLs. At this point the RIR has done their due diligence for notifying the blacklist community of the change and the onus is on the DNSBL maintainers to update their records. Of course this does nothing to cleanse the assignment in the hundreds of thousands of MTAs around the world. However this could be a good reason to not blacklist locally (or indefinitely at least) and to instead rely on a DNSBL maintained by people responsible for wiping returned assignments from their records when RIRs give the word. I suppose the mailing list could even be expanded to include mailing list admins if need be so that they could also receive the info and wipe their own internal DNSBLs. The list should be an announcement-only list with only the RIRs being able to post to it in a common and defined format. The announcement should be made as soon as the assignment is returned to the RIR, allowing for the cool off period of time for personal blacklists to catch up to the official ones. I would think that would be a fairly simple process to implement. It's not fool-proof by any means but it's better than doing nothing. It's a thought. Justin From bburke at merit.edu Mon Sep 14 14:42:13 2009 From: bburke at merit.edu (Betty Burke) Date: Mon, 14 Sep 2009 15:42:13 -0400 (EDT) Subject: [NANOG-announce] NANOG SC Nominations Message-ID: <2104207268.1758631252957333245.JavaMail.root@crono> Last Call!! SC Candidate nominations close midnight EST 9-14-09 Current Candidates posted at http://nanog.org/governance/elections/2009elections/2009sc_candidates.php Send those additional nominations to nominations at nanog.org! Look forward to seeing you in Dearborn, Michigan, October 18-21, 2009 for NANOG47!!! Betty Merit Network Inc. NANOG Community Project Manager NANOG47 Sponsorship opportunities still available, information found at http://nanog.org/meetings/nanog47/sponsorships.php _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From davidu at everydns.net Mon Sep 14 15:37:18 2009 From: davidu at everydns.net (David Ulevitch) Date: Mon, 14 Sep 2009 13:37:18 -0700 Subject: Verizon Wireless (AS22394) network engineering contact needed Message-ID: <4AAEA97E.7020505@everydns.net> I'm having some trouble reaching a capable network engineer who runs Verizon Wireless (AS22394). The contact on the ARIN address space I have issues with does indeed pick up the phone but is not someone who is aware of what BGP is. Additionally, VZW is not listed on the NOC contacts page hosted by our friend Jared. If someone could put me in touch with a warm body, I'd be much obliged. Thanks, David From brwatters at absfoc.com Mon Sep 14 15:16:43 2009 From: brwatters at absfoc.com (Brian R. Watters) Date: Mon, 14 Sep 2009 13:16:43 -0700 (PDT) Subject: Verizon Wireless (AS22394) network engineering contact needed In-Reply-To: <4AAEA97E.7020505@everydns.net> References: <4AAEA97E.7020505@everydns.net> Message-ID: <0a4101ca357c$53f78e30$fbe6aa90$@com> Stacey, I will reply to these folks .. -- Brian Watters Director American Broadband Family of Companies 5718 East Shields Ave Fresno, CA. 93727 brwatters at absfoc.com http://www.americanbroadbandservice.com tel:559-420-0205 fax:559-272-5266 toll free:866-827-4638 -----Original Message----- From: David Ulevitch [mailto:davidu at everydns.net] Sent: Monday, September 14, 2009 1:37 PM To: NANOG list Subject: Verizon Wireless (AS22394) network engineering contact needed I'm having some trouble reaching a capable network engineer who runs Verizon Wireless (AS22394). The contact on the ARIN address space I have issues with does indeed pick up the phone but is not someone who is aware of what BGP is. Additionally, VZW is not listed on the NOC contacts page hosted by our friend Jared. If someone could put me in touch with a warm body, I'd be much obliged. Thanks, David From randy at psg.com Mon Sep 14 15:47:59 2009 From: randy at psg.com (Randy Bush) Date: Tue, 15 Sep 2009 05:47:59 +0900 Subject: Hijacked Blocks In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F1048510F3C68@ROCH-EXCH1.corp.pvt> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <20090908184444.GA68989@typo.org> <20090914104948.GA28451@gsp.org> <4C56255D-0D8A-449A-9BC8-3013CBDE92CC@arin.net> <75cb24520909140741w6dfd0913vb33ef893ffa56682@mail.gmail.com> <4AAE6816.5060209@rxsec.com> <75cb24520909140939u2557ca3fp2e86de3974062df0@mail.gmail.com> <2E2FECEBAE57CC4BAACDE67638305F1048510F3C68@ROCH-EXCH1.corp.pvt> Message-ID: > I haven't followed this entire string. Are you saying ARIN is repeatedly handing out address space to known abusers? If that's the case then yes, some form of policy should be worked on. i might walk more slowly and with a bit less self-righteousness. this is not a simple area. are we sure we want the rirs to become the net content police? how are they to judge? e.g., prudent isps act against a customer when there is a court order, not when the net gossip says they're bad actors. i.e., the decision of who is a bad actor is passed on to the society's normal judicial process. randy From morrowc.lists at gmail.com Mon Sep 14 16:02:50 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 14 Sep 2009 17:02:50 -0400 Subject: Hijacked Blocks In-Reply-To: References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <20090908184444.GA68989@typo.org> <20090914104948.GA28451@gsp.org> <4C56255D-0D8A-449A-9BC8-3013CBDE92CC@arin.net> <75cb24520909140741w6dfd0913vb33ef893ffa56682@mail.gmail.com> <4AAE6816.5060209@rxsec.com> <75cb24520909140939u2557ca3fp2e86de3974062df0@mail.gmail.com> <2E2FECEBAE57CC4BAACDE67638305F1048510F3C68@ROCH-EXCH1.corp.pvt> Message-ID: <75cb24520909141402g5b67dc55odbda691b2709440d@mail.gmail.com> On Mon, Sep 14, 2009 at 4:47 PM, Randy Bush wrote: >> I haven't followed this entire string. ?Are you saying ARIN is repeatedly handing out address space to known abusers? ?If that's the case then yes, some form of policy should be worked on. > > i might walk more slowly and with a bit less self-righteousness. ?this > is not a simple area. ?are we sure we want the rirs to become the net > content police? ?how are they to judge? that was part of my set of points... but if there is a feeling (in the community) that ARIN should be doing something differently, bitching about it on nanog-l or ppml isn't helping. What does help is following the proper process for ARIN policies or suggestions. > e.g., prudent isps act against a customer when there is a court order, > not when the net gossip says they're bad actors. ?i.e., the decision of > who is a bad actor is passed on to the society's normal judicial > process. It's worked out so well so far, yea.... though there are at least 2 things being discussed: 1) not allocating to known offendors (even those who've been through the court system and had judgements against them, which would be following your proposed path) 2) dealing with rbl'd netblocks once they are returned to ARIN and the re-allocated to 'new' people. Both really do, to not just be this same discussion in 12 more moons, need either a policy proposal through ARIN or suggestion to the arin-suggest system. As an aside, what happens to things in APNIC/AFRINIC/RIPE in these circumstances? Say what will happen to: 85.255.112.0/20 in RIPE-land, or 116.50.8.0/20 in APNIC-land? -Chris From randy at psg.com Mon Sep 14 16:12:41 2009 From: randy at psg.com (Randy Bush) Date: Tue, 15 Sep 2009 06:12:41 +0900 Subject: Hijacked Blocks In-Reply-To: <75cb24520909141402g5b67dc55odbda691b2709440d@mail.gmail.com> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <20090908184444.GA68989@typo.org> <20090914104948.GA28451@gsp.org> <4C56255D-0D8A-449A-9BC8-3013CBDE92CC@arin.net> <75cb24520909140741w6dfd0913vb33ef893ffa56682@mail.gmail.com> <4AAE6816.5060209@rxsec.com> <75cb24520909140939u2557ca3fp2e86de3974062df0@mail.gmail.com> <2E2FECEBAE57CC4BAACDE67638305F1048510F3C68@ROCH-EXCH1.corp.pvt> <75cb24520909141402g5b67dc55odbda691b2709440d@mail.gmail.com> Message-ID: > 1) not allocating to known offendors (even those who've been through > the court system and had judgements against them, which would be > following your proposed path) [ i made no proposal. i was just a bit scared by the instant "we need to DO SOMETHING" reaction. ] but what you say seems somewhat prudent, at least leaving the judgement where it normally is. > 2) dealing with rbl'd netblocks once they are returned to ARIN and the > re-allocated to 'new' people. tough one. those 'bad' blocks will seem less and less bad over time. but can we not expect the hostfolk at the rirs to kinda order the available queue on this, as well as other appropriate attributes? i.e. is this not more process than policy? i am not saying all is well here. i am just trying to move slowly and pretend to think while on my first cuppa. randy From morrowc.lists at gmail.com Mon Sep 14 16:27:06 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 14 Sep 2009 17:27:06 -0400 Subject: Hijacked Blocks In-Reply-To: References: <148476.263921252421878121.JavaMail.root@zimbra> <20090914104948.GA28451@gsp.org> <4C56255D-0D8A-449A-9BC8-3013CBDE92CC@arin.net> <75cb24520909140741w6dfd0913vb33ef893ffa56682@mail.gmail.com> <4AAE6816.5060209@rxsec.com> <75cb24520909140939u2557ca3fp2e86de3974062df0@mail.gmail.com> <2E2FECEBAE57CC4BAACDE67638305F1048510F3C68@ROCH-EXCH1.corp.pvt> <75cb24520909141402g5b67dc55odbda691b2709440d@mail.gmail.com> Message-ID: <75cb24520909141427j5d68f1edv89c4ed2dad8dfc91@mail.gmail.com> On Mon, Sep 14, 2009 at 5:12 PM, Randy Bush wrote: >> 1) not allocating to known offendors (even those who've been through >> the court system and had judgements against them, which would be >> following your proposed path) > > [ i made no proposal. ?i was just a bit scared by the instant "we need > to DO SOMETHING" reaction. ] Oh yea, so I think after reading the 60+ messages on this thread I got to the end saying: o Yes, there is some sort of ongoing problem. o No, this isn't simple to solve. o The 'bad actors' here have the ability to fuzz several variables, more than ARIN Staff could deal with (sanely) I think. o There has to be a reason this hasn't made it past where we are in the discussion today previously. >?but what you say seems somewhat prudent, > at least leaving the judgement where it normally is. I don't have lots of faith in the global judicial system working on this in a sane fashion either, I was just saying ARIN/RIPE/APNIC have (and continue to) allocate blocks to known criminals (ones judged by some court system to have actually broken a law). Part of this problem also is that what's illegal in $COUNTRY1 is legal in $COUNTRY2 (or even inside the US by county or state, weee!) So what 'law breaking' should an RIR follow/adhere to? (See point 4 above) >> 2) dealing with rbl'd netblocks once they are returned to ARIN and the >> re-allocated to 'new' people. > > tough one. ?those 'bad' blocks will seem less and less bad over time. > but can we not expect the hostfolk at the rirs to kinda order the > available queue on this, as well as other appropriate attributes? ?i.e. > is this not more process than policy? Sure things are less bad over time, once they are removed from 'bad actor control', but unless the myriad of 'nutcases' that run BL's hear from someone the 'trust' (or will listen to or whatever it takes) things stay on the BL. Additionally, RBL's for 'spam' (smtp) are only the tip of the iceberg here... route-filters, as-filters, firewall rules, null routes, dns-blackholes... > i am not saying all is well here. ?i am just trying to move slowly and > pretend to think while on my first cuppa. gotcha -chris From randy at psg.com Mon Sep 14 16:45:08 2009 From: randy at psg.com (Randy Bush) Date: Tue, 15 Sep 2009 06:45:08 +0900 Subject: Hijacked Blocks In-Reply-To: <75cb24520909141427j5d68f1edv89c4ed2dad8dfc91@mail.gmail.com> References: <148476.263921252421878121.JavaMail.root@zimbra> <20090914104948.GA28451@gsp.org> <4C56255D-0D8A-449A-9BC8-3013CBDE92CC@arin.net> <75cb24520909140741w6dfd0913vb33ef893ffa56682@mail.gmail.com> <4AAE6816.5060209@rxsec.com> <75cb24520909140939u2557ca3fp2e86de3974062df0@mail.gmail.com> <2E2FECEBAE57CC4BAACDE67638305F1048510F3C68@ROCH-EXCH1.corp.pvt> <75cb24520909141402g5b67dc55odbda691b2709440d@mail.gmail.com> <75cb24520909141427j5d68f1edv89c4ed2dad8dfc91@mail.gmail.com> Message-ID: >> tough one. ?those 'bad' blocks will seem less and less bad over time. > Sure things are less bad over time, once they are removed from 'bad > actor control' actually, i meant as ipv4 scarcity worsens on the other side of the coin, olaf maennel and i did a bunch of work so that rirs, specifically arin who paid for it, could locate filtering ASs/routers to have some tools to be able to remove blockage that is no longer appropriate. randy From jmamodio at gmail.com Mon Sep 14 16:52:26 2009 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 14 Sep 2009 16:52:26 -0500 Subject: Hijacked Blocks In-Reply-To: <75cb24520909141427j5d68f1edv89c4ed2dad8dfc91@mail.gmail.com> References: <148476.263921252421878121.JavaMail.root@zimbra> <4C56255D-0D8A-449A-9BC8-3013CBDE92CC@arin.net> <75cb24520909140741w6dfd0913vb33ef893ffa56682@mail.gmail.com> <4AAE6816.5060209@rxsec.com> <75cb24520909140939u2557ca3fp2e86de3974062df0@mail.gmail.com> <2E2FECEBAE57CC4BAACDE67638305F1048510F3C68@ROCH-EXCH1.corp.pvt> <75cb24520909141402g5b67dc55odbda691b2709440d@mail.gmail.com> <75cb24520909141427j5d68f1edv89c4ed2dad8dfc91@mail.gmail.com> Message-ID: <202705b0909141452x7d787898k42f3648683fc70f3@mail.gmail.com> Be careful about what you are asking for. >> i am not saying all is well here. ?i am just trying to move slowly and >> pretend to think while on my first cuppa. I agree with Randy that this is a reasonable approach. In the transition from the old IANA to FrICANNstein and the separation of numbers and names, some illuminated minds mixed the Kool-Aid with the concept that in the role of technical coordinator to "guarantee the security and stability of the Internet" everything goes ... And now we have a bunch of IGFers claiming for regulation and control developing policies that may have serious consequences, more when the same entity developing the policy is the one that implements it, and its only accountable to itself and also acts as the tax collector agency. I don't believe anyone is denying that there is an issue, but Randy's call for prudence is well founded. My .02 From pshem.k at gmail.com Mon Sep 14 19:35:15 2009 From: pshem.k at gmail.com (Pshem Kowalczyk) Date: Tue, 15 Sep 2009 12:35:15 +1200 Subject: Dedicated Route Reflectors In-Reply-To: <342977.61377.qm@web53611.mail.re2.yahoo.com> References: <342977.61377.qm@web53611.mail.re2.yahoo.com> Message-ID: <20fe625b0909141735i2a11b12erf8b5f70a093f85df@mail.gmail.com> Hi, There are multiple ways you can solve that problem. We do the following: 1. Each region has its own ibgp cluster with 2 route reflectors (usually the P nodes, since they seem to have abundance of CPU power and not much to do with it). 2. All route reflectors (across regions) are fully meshed. We thought a bit about creating two 'super' route servers, but then then number of adjecencies is not that big ( we only have a few regions ). Regarding internet traffic - we keep the Internet in a VPN, all PEs that host that VPN are fully meshed and advertise only a default to the common route reflectors (in their corresponding regions). Each internet PE uses different RD, so there are multiple default routes present in the regions. kind regards Pshem 2009/9/12 Serge Vautour : > Hello, > > We're in the process of planning for an MPLS network that will use BGP for signaling between PEs. This will be a BGP free Core (i.e. no BGP on the P routers). What are folks doing for iBGP in this case? Full Mesh? Full Mesh the Main POP PEs and Route Reflect to some outlining PEs? Are folks using dedicated/centralized Route Reflectors (redundant of course)? What about using some of the P routers as the Centralized Route Reflectors? The boxes aren't doing much from a Control Plane perspective, why not use them as Route Reflectors. > > Any comments would be appreciated. > > Thanks, > Serge > > > > ? ? ?__________________________________________________________________ > Looking for the perfect gift? Give the gift of Flickr! > > http://www.flickr.com/gift/ > > From martin at theicelandguy.com Mon Sep 14 21:21:42 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Mon, 14 Sep 2009 22:21:42 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: <4AAE9271.2040006@justinshore.com> References: <200909081950.n88Jo2Dl094175@aurora.sol.net> <4AA82EBB.9080708@gmail.com> <4AAE9271.2040006@justinshore.com> Message-ID: On Mon, Sep 14, 2009 at 2:58 PM, Justin Shore wrote: > Frank Bulk wrote: > >> With scarcity of IPv4 addresses, organizations are more desperate than >> ever >> to receive an allocation. If anything, there's more of a disincentive >> than >> ever before for ARIN to spend time on netblock sanitization. >> >> I do think that ARIN should inform the new netblock owner if it was >> previously owned or not. But if ARIN tried to start cleaning up a >> netblock >> before releasing it, there would be no end to it. How could they check >> against the probably hundreds of thousands private blocklist? >> > > They could implement a process by which they announce to a mailing list of > DNSBL providers that a given assignment has been returned to the RIR and > that it should be cleansed from all DNSBLs. > You mean like this? http://lists.arin.net/pipermail/arin-issued/2009-September/000270.html -M< From michiel at klaver.it Tue Sep 15 04:57:58 2009 From: michiel at klaver.it (Michiel Klaver) Date: Tue, 15 Sep 2009 11:57:58 +0200 Subject: Repeated Blacklisting / IP reputation, replaced by registered use In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F1048510F3C85@ROCH-EXCH1.corp.pvt> References: <148476.263921252421878121.JavaMail.root@zimbra> <4AA67551.3050402@gmail.com> <20090908184444.GA68989@typo.org> <20090914104948.GA28451@gsp.org> <4C56255D-0D8A-449A-9BC8-3013CBDE92CC@arin.net> <75cb24520909140741w6dfd0913vb33ef893ffa56682@mail.gmail.com> <4AAE6816.5060209@rxsec.com> <75cb24520909140939u2557ca3fp2e86de3974062df0@mail.gmail.com> <2E2FECEBAE57CC4BAACDE67638305F1048510F3C68@ROCH-EXCH1.corp.pvt> <2E2FECEBAE57CC4BAACDE67638305F1048510F3C85@ROCH-EXCH1.corp.pvt> Message-ID: <4AAF6526.9000904@klaver.it> I think ARIN is no party to contact all RBL's and do any cleanup of 'contaminated' address space. The only steps ARIN might do are: - When requesting address space, one should be able to indicate whether receiving previous used address space would be unwanted or not. - When assigning address space, ARIN should notify receivers if it's re-used or virgin address space. - When address space got returned to ARIN and there is evidence of abuse, they have to mark that address space as 'contaminated' and only re-assign that space to new end-users who have indicated to have no problem with that. With kind regards, Michiel Klaver IT Professional From martin at theicelandguy.com Tue Sep 15 07:37:12 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Tue, 15 Sep 2009 08:37:12 -0400 Subject: Repeated Blacklisting / IP reputation In-Reply-To: References: <200909081950.n88Jo2Dl094175@aurora.sol.net> <4AA82EBB.9080708@gmail.com> <4AAE9271.2040006@justinshore.com> Message-ID: Well, I haven't even had coffee yet and... Get the removals: curl -ls http://lists.arin.net/pipermail/arin-issued/2009-September/000270.html | grep Remove | grep -v "
"

Get the additions:

mahannig$ curl -ls
http://lists.arin.net/pipermail/arin-issued/2009-September/000270.html |
grep Add | grep -v "
"


I'm sure someone else could write something far more elegant, but elegance
isn't always required. :-)

Best,

Marty


On Mon, Sep 14, 2009 at 10:21 PM, Martin Hannigan
wrote:

>
>
> On Mon, Sep 14, 2009 at 2:58 PM, Justin Shore wrote:
>
>> Frank Bulk wrote:
>>
>>> With scarcity of IPv4 addresses, organizations are more desperate than
>>> ever
>>> to receive an allocation.  If anything, there's more of a disincentive
>>> than
>>> ever before for ARIN to spend time on netblock sanitization.
>>>
>>> I do think that ARIN should inform the new netblock owner if it was
>>> previously owned or not.  But if ARIN tried to start cleaning up a
>>> netblock
>>> before releasing it, there would be no end to it.  How could they check
>>> against the probably hundreds of thousands private blocklist?
>>>
>>
>> They could implement a process by which they announce to a mailing list of
>> DNSBL providers that a given assignment has been returned to the RIR and
>> that it should be cleansed from all DNSBLs.
>>
>
>
> You mean like this?
>
> http://lists.arin.net/pipermail/arin-issued/2009-September/000270.html
>
>
>
> -M<
>
>
>



-- 
Martin Hannigan                               martin at theicelandguy.com
p: +16178216079
Power, Network, and Costs Consulting for Iceland Datacenters and Occupants


From Shawn.Somers at gmail.com  Tue Sep 15 10:01:48 2009
From: Shawn.Somers at gmail.com (Shawn Somers)
Date: Tue, 15 Sep 2009 08:01:48 -0700
Subject: Repeated Blacklisting / IP reputation
In-Reply-To: 
References: 
Message-ID: <4AAFAC5C.8040008@gmail.com>

I'd be more than happy to see this, with the added caveat that anyone 
that returned address space to ARIN that was subsequently marked as 
'contaminated', should undergo a review process when attempting to 
obtain new address space. Charge them for the review process

  Anyone that intentionally uses address space in a manner that they 
know will cause it to become contaminated should be denied on any 
further address space requests.


Another option, is to hit them where it matters. Assign fines and fees 
for churning address space and returning it as contaminated. Set the 
fee's on a sliding scale based on the amount of contamination and churn. 
the more contamination, the higher the fee.

Shawn Somers

Michiel Klaver wrote:
---------
> 
> Message: 3
> Date: Tue, 15 Sep 2009 11:57:58 +0200
> From: Michiel Klaver 
> Subject: RE: Repeated Blacklisting / IP reputation, replaced by
> 	registered use
> To: "Azinger, Marla" , 	John Curran
> 	, "nanog at nanog.org" 
> Message-ID: <4AAF6526.9000904 at klaver.it>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> I think ARIN is no party to contact all RBL's and do any cleanup of 
> 'contaminated' address space. The only steps ARIN might do are:
> 
> - When requesting address space, one should be able to indicate whether 
> receiving previous used address space would be unwanted or not.
> 
> - When assigning address space, ARIN should notify receivers if it's 
> re-used or virgin address space.
> 
> - When address space got returned to ARIN and there is evidence of 
> abuse, they have to mark that address space as 'contaminated' and only 
> re-assign that space to new end-users who have indicated to have no 
> problem with that.
> 
> 
> 
> With kind regards,
> 
> Michiel Klaver
> IT Professional




From jgreco at ns.sol.net  Tue Sep 15 10:28:35 2009
From: jgreco at ns.sol.net (Joe Greco)
Date: Tue, 15 Sep 2009 10:28:35 -0500 (CDT)
Subject: Repeated Blacklisting / IP reputation
In-Reply-To: <4AAFAC5C.8040008@gmail.com> from "Shawn Somers" at Sep 15,
	2009 08:01:48 AM
Message-ID: <200909151528.n8FFSa9G040238@aurora.sol.net>

> I'd be more than happy to see this, with the added caveat that anyone 
> that returned address space to ARIN that was subsequently marked as 
> 'contaminated', should undergo a review process when attempting to 
> obtain new address space. Charge them for the review process
> 
>   Anyone that intentionally uses address space in a manner that they 
> know will cause it to become contaminated should be denied on any 
> further address space requests.
> 
> Another option, is to hit them where it matters. Assign fines and fees 
> for churning address space and returning it as contaminated. Set the 
> fee's on a sliding scale based on the amount of contamination and churn. 
> the more contamination, the higher the fee.

It would be problematic in some dimensions, but it seems that perhaps
allowing them to return space in exchange for a larger block is part of
the problem, and maybe part of the answer would be to make them retain
the block and only allocate an additional block.  Route table growth and
all that, of course.  An alternative could be to delegate them a larger
"contaminated" block and allow them to incur the expense of cleaning it
up(*).


* And I say that kind of tongue-in-cheek, since I don't really believe it
  to be easy to clean up a block once it is contaminated, due to the sheer
  number of local blocks, etc., which may exist.

... 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 justin at justinshore.com  Tue Sep 15 11:17:49 2009
From: justin at justinshore.com (Justin Shore)
Date: Tue, 15 Sep 2009 11:17:49 -0500
Subject: Repeated Blacklisting / IP reputation
In-Reply-To: 
References: <200909081950.n88Jo2Dl094175@aurora.sol.net>	
	<4AA82EBB.9080708@gmail.com>	
		
	<4AAE9271.2040006@justinshore.com>	
	
	
Message-ID: <4AAFBE2D.9060407@justinshore.com>

Martin Hannigan wrote:
> 
> Well, I haven't even had coffee yet and...
> 
> Get the removals:
> 
> curl -ls 
> http://lists.arin.net/pipermail/arin-issued/2009-September/000270.html | 
> grep Remove | grep -v "
"
> 
> Get the additions:
> 
> mahannig$ curl -ls 
> http://lists.arin.net/pipermail/arin-issued/2009-September/000270.html | 
> grep Add | grep -v "
"

That appears to be it.  I've also been told that there is a RSS feed of 
the same thing.  My understanding is that a posting is made to the 
mailing list or RSS feed when a new subnet is assigned.  I'd like to see 
them do something with the assignment is first returned to ARIN, not 
months later when the assignment is ready to be handed out again.  I 
think the extra time would help those people that download copies of the 
DNSBL zone files and manually import them once a week or less often.

Lots of place still use the zone files.  Personally I prefer to do so 
too, rather than tie my mail system reliability on an outside source 
that may or may not tell me when they have problems that affect my 
service.  GoDaddy and their hosted mail service would be a great example 
since they can't be bothered to update their DNSBL zone files.  Their 
mail admins are using a copy of SORBS that is 3 years old.  3 damn years 
old.  How do I know this?  3 years ago a mistake in a Squid 
configuration turned one of my services into an open proxy for about a 
week.  Even today mail from that server to a domain with mail hosted at 
GoDaddy results in a bounce citing the ancient SORBS listing as the reason.

Thanks for the pointer.  Looks like they've already thought of what I 
suggested and implemented a solution.  I still voice for announcing 
returned assignment instead of announcing when an old assignment gets 
reassigned.

Thanks
  Justin




From aaron at wholesaleinternet.net  Tue Sep 15 11:22:39 2009
From: aaron at wholesaleinternet.net (Aaron Wendel)
Date: Tue, 15 Sep 2009 11:22:39 -0500
Subject: Repeated Blacklisting / IP reputation
In-Reply-To: <4AAFBE2D.9060407@justinshore.com>
References: <200909081950.n88Jo2Dl094175@aurora.sol.net>		<4AA82EBB.9080708@gmail.com>				<4AAE9271.2040006@justinshore.com>			
	<4AAFBE2D.9060407@justinshore.com>
Message-ID: <058d01ca3620$be3ea3b0$3abbeb10$@net>

The mailing sent daily contains both.




-----Original Message-----
From: Justin Shore [mailto:justin at justinshore.com] 
Sent: Tuesday, September 15, 2009 11:18 AM
To: Martin Hannigan
Cc: NANOG list
Subject: Re: Repeated Blacklisting / IP reputation

Martin Hannigan wrote:
> 
> Well, I haven't even had coffee yet and...
> 
> Get the removals:
> 
> curl -ls 
> http://lists.arin.net/pipermail/arin-issued/2009-September/000270.html | 
> grep Remove | grep -v "
"
> 
> Get the additions:
> 
> mahannig$ curl -ls 
> http://lists.arin.net/pipermail/arin-issued/2009-September/000270.html | 
> grep Add | grep -v "
"

That appears to be it.  I've also been told that there is a RSS feed of 
the same thing.  My understanding is that a posting is made to the 
mailing list or RSS feed when a new subnet is assigned.  I'd like to see 
them do something with the assignment is first returned to ARIN, not 
months later when the assignment is ready to be handed out again.  I 
think the extra time would help those people that download copies of the 
DNSBL zone files and manually import them once a week or less often.

Lots of place still use the zone files.  Personally I prefer to do so 
too, rather than tie my mail system reliability on an outside source 
that may or may not tell me when they have problems that affect my 
service.  GoDaddy and their hosted mail service would be a great example 
since they can't be bothered to update their DNSBL zone files.  Their 
mail admins are using a copy of SORBS that is 3 years old.  3 damn years 
old.  How do I know this?  3 years ago a mistake in a Squid 
configuration turned one of my services into an open proxy for about a 
week.  Even today mail from that server to a domain with mail hosted at 
GoDaddy results in a bounce citing the ancient SORBS listing as the reason.

Thanks for the pointer.  Looks like they've already thought of what I 
suggested and implemented a solution.  I still voice for announcing 
returned assignment instead of announcing when an old assignment gets 
reassigned.

Thanks
  Justin






From dmm at 1-4-5.net  Tue Sep 15 11:39:40 2009
From: dmm at 1-4-5.net (David Meyer)
Date: Tue, 15 Sep 2009 09:39:40 -0700
Subject: [NANOG-announce] Lightning talks open for NANOG 47
Message-ID: <20090915163940.GA6620@1-4-5.net>

	Just a reminder: Lightning talks are open for NANOG 47.
	Looking forward to your submissions. 

	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 fw at deneb.enyo.de  Tue Sep 15 12:13:36 2009
From: fw at deneb.enyo.de (Florian Weimer)
Date: Tue, 15 Sep 2009 17:13:36 +0000
Subject: 
In-Reply-To:  (Mikael
	Abrahamsson's message of "Mon, 14 Sep 2009 19:39:12 +0200 (CEST)")
References: <9F285BFE1D7757499D9FF095B4EE347D0444E7F3@tw-xchange01.TWC.local>
	
Message-ID: <87bplcgmgv.fsf@mid.deneb.enyo.de>

* Mikael Abrahamsson:

>> What does exactly the message mean and how do I stabilize this?  Any
>> help will be appreciated.
>
> This is most likely an MTU problem.

Does IOS enable PMTUD for BGP sessions by default these days?  The 476
(or something like that) MTU is unlikely an issue.  There could be a
forwarding bug which causes drops dependent on packet size, though.



From mruiz at telwestservices.com  Tue Sep 15 12:28:02 2009
From: mruiz at telwestservices.com (Michael Ruiz)
Date: Tue, 15 Sep 2009 12:28:02 -0500
Subject: 
In-Reply-To: <87bplcgmgv.fsf@mid.deneb.enyo.de>
References: <9F285BFE1D7757499D9FF095B4EE347D0444E7F3@tw-xchange01.TWC.local>
	<87bplcgmgv.fsf@mid.deneb.enyo.de>
Message-ID: <9F285BFE1D7757499D9FF095B4EE347D0444EEBD@tw-xchange01.TWC.local>

* Mikael Abrahamsson:

>> What does exactly the message mean and how do I stabilize this?  Any
>> help will be appreciated.
>
> This is most likely an MTU problem.

>>Does IOS enable PMTUD for BGP sessions by default these days?  The 476
>>(or something like that) MTU is unlikely an issue.  There could be a
>>forwarding bug which causes drops dependent on packet size, though.

I am not sure. I think it is, but I went ahead and put in the command
manually. 

Here is more of the configuration to do with TCP information.

ip tcp selective-ack
ip tcp window-size 65535
ip tcp synwait-time 10
ip tcp path-mtu-discovery




-----Original Message-----
From: Florian Weimer [mailto:fw at deneb.enyo.de] 
Sent: Tuesday, September 15, 2009 12:14 PM
To: Mikael Abrahamsson
Cc: Michael Ruiz; nanog at nanog.org
Subject: Re: 

* Mikael Abrahamsson:

>> What does exactly the message mean and how do I stabilize this?  Any
>> help will be appreciated.
>
> This is most likely an MTU problem.

Does IOS enable PMTUD for BGP sessions by default these days?  The 476
(or something like that) MTU is unlikely an issue.  There could be a
forwarding bug which causes drops dependent on packet size, though.



From ras at e-gerbil.net  Tue Sep 15 14:54:26 2009
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Tue, 15 Sep 2009 14:54:26 -0500
Subject: 
In-Reply-To: <9F285BFE1D7757499D9FF095B4EE347D0444EEBD@tw-xchange01.TWC.local>
References: <87bplcgmgv.fsf@mid.deneb.enyo.de>
	<9F285BFE1D7757499D9FF095B4EE347D0444EEBD@tw-xchange01.TWC.local>
Message-ID: <20090915195426.GL51443@gerbil.cluepon.net>

On Tue, Sep 15, 2009 at 12:28:02PM -0500, Michael Ruiz wrote:
> Here is more of the configuration to do with TCP information.
> 
> ip tcp selective-ack
> ip tcp window-size 65535
> ip tcp synwait-time 10
> ip tcp path-mtu-discovery

Every time I turn those on (plus timestamping), it breaks something. The
last time I tried it broke ftp based transfers of new IOS, had to
disable or use tftp to get a non-corrupted image (SRA). The time before
that, it occasionally caused bgp keepalives to be missed and thus
dropped the session (SXF). It may work now, or there may be more subtle 
Cisco bugs lurking, who knows. :)

You can confirm what MSS is actually being used in show ip bgp neighbor,
under the "max data segment" line. I believe in modern code there is a
way to turn on pmtud for all bgp neighbors (or individual ones) which
may or may not depend on the global ip tcp path-mtu-discovery setting. I
don't recall off the top of my head, but you should be able to confirm
what size messages you're actually trying to send. FWIW I've run
extensive tests on BGP with > 9000 byte MSS (though numbers that large
are completely irrelevent, since bgp's maximum message size is 4096
bytes) and never hit a problem. I once saw a bug where Cisco
miscalculated the MSS when doing tcp md5 (off by the number of bytes
that the tcp option would take, I forget which direction), but I'm sure
that's fixed now too. :)

-- 
Richard A Steenbergen        http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)



From mruiz at telwestservices.com  Tue Sep 15 15:10:52 2009
From: mruiz at telwestservices.com (Michael Ruiz)
Date: Tue, 15 Sep 2009 15:10:52 -0500
Subject: 
In-Reply-To: <20090915195426.GL51443@gerbil.cluepon.net>
References: <87bplcgmgv.fsf@mid.deneb.enyo.de>
	<9F285BFE1D7757499D9FF095B4EE347D0444EEBD@tw-xchange01.TWC.local>
	<20090915195426.GL51443@gerbil.cluepon.net>
Message-ID: <9F285BFE1D7757499D9FF095B4EE347D0444F03C@tw-xchange01.TWC.local>

>Every time I turn those on (plus timestamping), it breaks something.
The
>last time I tried it broke ftp based transfers of new IOS, had to
>disable or use tftp to get a non-corrupted image (SRA). The time before
>that, it occasionally caused bgp keepalives to be missed and thus
>dropped the session (SXF). It may work now, or there may be more subtle

>Cisco bugs lurking, who knows. :)

I tried that, no dice.  I thought it would actually work.  

>You can confirm what MSS is actually being used in show ip bgp
neighbor,
>under the "max data segment" line. I believe in modern code there is a
>way to turn on pmtud for all bgp neighbors (or individual ones) which
>may or may not depend on the global ip tcp path-mtu-discovery setting.
I
>don't recall off the top of my head, but you should be able to confirm
>what size messages you're actually trying to send. FWIW I've run
>extensive tests on BGP with > 9000 byte MSS (though numbers that large
>are completely irrelevent, since bgp's maximum message size is 4096
>bytes) and never hit a problem. I once saw a bug where Cisco
>miscalculated the MSS when doing tcp md5 (off by the number of bytes
>that the tcp option would take, I forget which direction), but I'm sure
>that's fixed now too. :)

Below is snap shot of the neighbor in question.

Datagrams (max data segment is 4410 bytes):
Rcvd: 6 (out of order: 0), with data: 4, total data bytes: 278
Sent: 6 (retransmit: 5), with data: 2, total data bytes: 4474

Could there be a problem with the total data bytes size exceeds the size
of the max data segment?

Below is the router (7206 NPE-400) I am trying to establish a session
with BGP neighbor.


Description: cr1.AUSTTXEE
 Member of peer-group TelWest-iBGP for session parameters
  BGP version 4, remote router ID 67.214.64.97
  BGP state = Established, up for 00:00:02
  Last read 00:00:02, hold time is 180, keepalive interval is 60 seconds
  Neighbor capabilities:
    Route refresh: advertised and received(old & new)
    Address family IPv4 Unicast: advertised and received
  Message statistics:


Datagrams (max data segment is 4410 bytes):
Rcvd: 4 (out of order: 0), with data: 1, total data bytes: 64
Sent: 5 (retransmit: 0, fastretransmit: 0), with data: 3, total data
bytes: 259
cr2.CRCHTXCB#

-----Original Message-----
From: Richard A Steenbergen [mailto:ras at e-gerbil.net] 
Sent: Tuesday, September 15, 2009 2:54 PM
To: Michael Ruiz
Cc: nanog at nanog.org
Subject: Re: 

On Tue, Sep 15, 2009 at 12:28:02PM -0500, Michael Ruiz wrote:
> Here is more of the configuration to do with TCP information.
> 
> ip tcp selective-ack
> ip tcp window-size 65535
> ip tcp synwait-time 10
> ip tcp path-mtu-discovery

Every time I turn those on (plus timestamping), it breaks something. The
last time I tried it broke ftp based transfers of new IOS, had to
disable or use tftp to get a non-corrupted image (SRA). The time before
that, it occasionally caused bgp keepalives to be missed and thus
dropped the session (SXF). It may work now, or there may be more subtle 
Cisco bugs lurking, who knows. :)

You can confirm what MSS is actually being used in show ip bgp neighbor,
under the "max data segment" line. I believe in modern code there is a
way to turn on pmtud for all bgp neighbors (or individual ones) which
may or may not depend on the global ip tcp path-mtu-discovery setting. I
don't recall off the top of my head, but you should be able to confirm
what size messages you're actually trying to send. FWIW I've run
extensive tests on BGP with > 9000 byte MSS (though numbers that large
are completely irrelevent, since bgp's maximum message size is 4096
bytes) and never hit a problem. I once saw a bug where Cisco
miscalculated the MSS when doing tcp md5 (off by the number of bytes
that the tcp option would take, I forget which direction), but I'm sure
that's fixed now too. :)

-- 
Richard A Steenbergen 
http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1
2CBC)



From Valdis.Kletnieks at vt.edu  Tue Sep 15 15:21:55 2009
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 15 Sep 2009 16:21:55 -0400
Subject: Hijacked Blocks
In-Reply-To: Your message of "Mon, 14 Sep 2009 16:52:26 CDT."
	<202705b0909141452x7d787898k42f3648683fc70f3@mail.gmail.com>
References: <148476.263921252421878121.JavaMail.root@zimbra>
	<4C56255D-0D8A-449A-9BC8-3013CBDE92CC@arin.net>
	<75cb24520909140741w6dfd0913vb33ef893ffa56682@mail.gmail.com>
	<4AAE6816.5060209@rxsec.com>
	<75cb24520909140939u2557ca3fp2e86de3974062df0@mail.gmail.com>
	<2E2FECEBAE57CC4BAACDE67638305F1048510F3C68@ROCH-EXCH1.corp.pvt>
	
	<75cb24520909141402g5b67dc55odbda691b2709440d@mail.gmail.com>
	
	<75cb24520909141427j5d68f1edv89c4ed2dad8dfc91@mail.gmail.com>
	<202705b0909141452x7d787898k42f3648683fc70f3@mail.gmail.com>
Message-ID: <30489.1253046115@turing-police.cc.vt.edu>

On Mon, 14 Sep 2009 16:52:26 CDT, Jorge Amodio said:

> In the transition from the old IANA to FrICANNstein

Well, that monitor needed cleaning anynow... ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: 

From Valdis.Kletnieks at vt.edu  Tue Sep 15 15:23:22 2009
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 15 Sep 2009 16:23:22 -0400
Subject: Repeated Blacklisting / IP reputation
In-Reply-To: Your message of "Tue, 15 Sep 2009 08:01:48 PDT."
	<4AAFAC5C.8040008@gmail.com>
References: 
	<4AAFAC5C.8040008@gmail.com>
Message-ID: <30570.1253046202@turing-police.cc.vt.edu>

On Tue, 15 Sep 2009 08:01:48 PDT, Shawn Somers said:

>   Anyone that intentionally uses address space in a manner that they 
> know will cause it to become contaminated should be denied on any 
> further address space requests.

You *do* realize that the people you're directing that paragraph at are
able to say with a totally straight face: "We're doing nothing wrong and
we have *no* idea why we end up in so many local block lists"?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: 

From morrowc.lists at gmail.com  Tue Sep 15 15:31:04 2009
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 15 Sep 2009 16:31:04 -0400
Subject: Repeated Blacklisting / IP reputation
In-Reply-To: <30570.1253046202@turing-police.cc.vt.edu>
References: 
	<4AAFAC5C.8040008@gmail.com>
	<30570.1253046202@turing-police.cc.vt.edu>
Message-ID: <75cb24520909151331p7e5710b7wffe904d9146b44fa@mail.gmail.com>

On Tue, Sep 15, 2009 at 4:23 PM,   wrote:
> On Tue, 15 Sep 2009 08:01:48 PDT, Shawn Somers said:
>
>> ? Anyone that intentionally uses address space in a manner that they
>> know will cause it to become contaminated should be denied on any
>> further address space requests.
>
> You *do* realize that the people you're directing that paragraph at are
> able to say with a totally straight face: "We're doing nothing wrong and
> we have *no* idea why we end up in so many local block lists"?

Also, you can very well disable new allocations to Spammer-Bob, did
you also know his friend Sue is asking now for space? Sue is very
nice, she even has cookies... oh damn after we allocated to her we
found out she's spamming :(

Spammers have a lot of variables to change in this equation, RIR's
dont always have the ability to see all of the variables, nor
correlate all of the changes they see :(

-Chris



From ras at e-gerbil.net  Tue Sep 15 15:31:19 2009
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Tue, 15 Sep 2009 15:31:19 -0500
Subject: 
In-Reply-To: <9F285BFE1D7757499D9FF095B4EE347D0444F03C@tw-xchange01.TWC.local>
References: <87bplcgmgv.fsf@mid.deneb.enyo.de>
	<9F285BFE1D7757499D9FF095B4EE347D0444EEBD@tw-xchange01.TWC.local>
	<20090915195426.GL51443@gerbil.cluepon.net>
	<9F285BFE1D7757499D9FF095B4EE347D0444F03C@tw-xchange01.TWC.local>
Message-ID: <20090915203119.GN51443@gerbil.cluepon.net>

On Tue, Sep 15, 2009 at 03:10:52PM -0500, Michael Ruiz wrote:
> Below is snap shot of the neighbor in question.
> 
> Datagrams (max data segment is 4410 bytes):
> Rcvd: 6 (out of order: 0), with data: 4, total data bytes: 278
> Sent: 6 (retransmit: 5), with data: 2, total data bytes: 4474
> 
> Could there be a problem with the total data bytes size exceeds the size
> of the max data segment?

The maximum BGP message size is 4096 and there is no padding, so you
would need a heck of a lot of overhead to get another 300+ bytes on
there. I'd say the answer is no, unless you're running this over a MPLS
over GRE over MPLS over IPSec over MPLS over... well... you get the
picture. :)

It's possible that your link isn't actually capable of passing 4096-ish 
byte packets for whatever resaon. A quick way to validate or eliminate 
that theory is to do some pings from the router with different size 
payloads, sourced from your side of the /30 and pinging the far side, 
and using the df-bit to prevent fragmentation. Failing that, make sure 
you aren't doing anything stupid with your control plane policiers, 
maybe try turning those off to see if there is an improvement.

-- 
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  Tue Sep 15 15:39:33 2009
From: Brian.Dickson at concertia.com (Brian Dickson)
Date: Tue, 15 Sep 2009 17:39:33 -0300
Subject: 
In-Reply-To: 
References: <9F285BFE1D7757499D9FF095B4EE347D0444E7F3@tw-xchange01.TWC.local>
	
Message-ID: <21D41A38B8859B4A97B1AE2313922B8A811AB6F0B9@concertiabl02.concertia.com>

And more specifically, possibly an interface MTU (or ip mtu, I forget which).

If there is a mismatch between ends of a link, in one direction, MTU-sized packets get sent, and the other end sees those as "giants".

I've seen situations where the MTU is calculated incorrectly, when using some technology that adds a few bytes (e.g. VLAN tags, MPLS tags, etc.).

On Cisco boxes, when talking to other Cisco boxes, even.

Take a look at the interfaces over which the peering session runs, at both ends.
I.e., is this the only BGP session *over that interface*, for the local box?

(It might not be the end you think it's at, BTW.)

Oh, and if you find something, please, let us know.
War stories make for great bar BOFs at NANOG meetings. :-)

Brian

-----Original Message-----
From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] 
Sent: September-14-09 2:39 PM
To: Michael Ruiz
Cc: nanog at nanog.org
Subject: Re: 

On Mon, 14 Sep 2009, Michael Ruiz wrote:

> I am having difficulty maintaining my BGP session from my 6509 with
> Sup-7203bxls to a 7206 VXR NPE-400.  The session bounces every 3
> minutes.  I do have other IBGP sessions that are established with no
> problems, however, this is the only IBGP peer that is bouncing
> regularly.
>
> What does exactly the message mean and how do I stabilize this?  Any
> help will be appreciated.

This is most likely an MTU problem. Your SYN/SYN+ACK goes thru, but then 
the first fullsize MSS packet is sent, and it's not getting to the 
destination. 3 minutes is the dead timer for keepalives, which are not 
getting thru either because of the stalled TCP session.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se




From bmanning at vacation.karoshi.com  Tue Sep 15 15:46:19 2009
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 15 Sep 2009 20:46:19 +0000
Subject: Repeated Blacklisting / IP reputation
In-Reply-To: <75cb24520909151331p7e5710b7wffe904d9146b44fa@mail.gmail.com>
References: 
	<4AAFAC5C.8040008@gmail.com>
	<30570.1253046202@turing-police.cc.vt.edu>
	<75cb24520909151331p7e5710b7wffe904d9146b44fa@mail.gmail.com>
Message-ID: <20090915204619.GA19640@vacation.karoshi.com.>

 
so... this thread has a couple of really interesting characteristics.
a couple are worth mentioning more directly (they have been alluded to elsewhere)...

	Who gets to define "bad" - other than a blacklist operator?
	Are the common, consistent defintions of "contamination"?

	If these are social/political - recognise that while the ARIN
	region is fairly consistent in its general use and interpretation
	of law, there are known varients - based on soveriegn region.

this whole debate/discussion seems based on the premise that there are well
known, consistent, legally defendable choices for defining offensive behaviours.
and pretty much all of history shows us this is not the case.

	(is or is not a mother nursing her child in public pornographic?)

So - I suspect that in the end, a registry (ARIN) or an ISP (COMCAST) is only
going to be able to tell you a few things about the prefix you have been handed.

	a) its virginal - never been used (that we know of)
	b) its been used once.
	c) it has a checkered past

and it will be up to the receipient to trust/accept the resource for what it
currently is or chose to reject it and find soliace elsewhere.

--bill


On Tue, Sep 15, 2009 at 04:31:04PM -0400, Christopher Morrow wrote:
> On Tue, Sep 15, 2009 at 4:23 PM,   wrote:
> > On Tue, 15 Sep 2009 08:01:48 PDT, Shawn Somers said:
> >
> >>   Anyone that intentionally uses address space in a manner that they
> >> know will cause it to become contaminated should be denied on any
> >> further address space requests.
> >
> > You *do* realize that the people you're directing that paragraph at are
> > able to say with a totally straight face: "We're doing nothing wrong and
> > we have *no* idea why we end up in so many local block lists"?
> 
> Also, you can very well disable new allocations to Spammer-Bob, did
> you also know his friend Sue is asking now for space? Sue is very
> nice, she even has cookies... oh damn after we allocated to her we
> found out she's spamming :(
> 
> Spammers have a lot of variables to change in this equation, RIR's
> dont always have the ability to see all of the variables, nor
> correlate all of the changes they see :(
> 
> -Chris
> 



From mruiz at telwestservices.com  Tue Sep 15 15:49:57 2009
From: mruiz at telwestservices.com (Michael Ruiz)
Date: Tue, 15 Sep 2009 15:49:57 -0500
Subject: 
In-Reply-To: <21D41A38B8859B4A97B1AE2313922B8A811AB6F0B9@concertiabl02.concertia.com>
References: <9F285BFE1D7757499D9FF095B4EE347D0444E7F3@tw-xchange01.TWC.local>
	
	<21D41A38B8859B4A97B1AE2313922B8A811AB6F0B9@concertiabl02.concertia.com>
Message-ID: <9F285BFE1D7757499D9FF095B4EE347D0444F098@tw-xchange01.TWC.local>

>Take a look at the interfaces over which the peering session runs, at
both ends.
>I.e., is this the only BGP session *over that interface*, for the local
box?

You are going to find this even more strange.  I have two routers that
are communicating over the same transport medium and are actually in the
same rack. One router is a Cisco 7606 which has an IBGP session
established with my Cisco 6509.  Both equipment have Sup-7203bxls 1 Gig
of memory. Ironically from the 6509's perspective, I cannot seem to
maintain a session with my 7206VXR which has two directly connected
DS-3s.  In order for my 6509 to establish an IBGP session with my 7606,
it has to go through the 7206 VXR.  Crazy right?

Yeah I can already this is going to be a *War Story* as you said it. :)

-----Original Message-----
From: Brian Dickson [mailto:Brian.Dickson at concertia.com] 
Sent: Tuesday, September 15, 2009 3:40 PM
To: Mikael Abrahamsson; Michael Ruiz
Cc: nanog at nanog.org
Subject: RE: 

And more specifically, possibly an interface MTU (or ip mtu, I forget
which).

If there is a mismatch between ends of a link, in one direction,
MTU-sized packets get sent, and the other end sees those as "giants".

I've seen situations where the MTU is calculated incorrectly, when using
some technology that adds a few bytes (e.g. VLAN tags, MPLS tags, etc.).

On Cisco boxes, when talking to other Cisco boxes, even.

Take a look at the interfaces over which the peering session runs, at
both ends.
I.e., is this the only BGP session *over that interface*, for the local
box?

(It might not be the end you think it's at, BTW.)

Oh, and if you find something, please, let us know.
War stories make for great bar BOFs at NANOG meetings. :-)

Brian

-----Original Message-----
From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] 
Sent: September-14-09 2:39 PM
To: Michael Ruiz
Cc: nanog at nanog.org
Subject: Re: 

On Mon, 14 Sep 2009, Michael Ruiz wrote:

> I am having difficulty maintaining my BGP session from my 6509 with
> Sup-7203bxls to a 7206 VXR NPE-400.  The session bounces every 3
> minutes.  I do have other IBGP sessions that are established with no
> problems, however, this is the only IBGP peer that is bouncing
> regularly.
>
> What does exactly the message mean and how do I stabilize this?  Any
> help will be appreciated.

This is most likely an MTU problem. Your SYN/SYN+ACK goes thru, but then

the first fullsize MSS packet is sent, and it's not getting to the 
destination. 3 minutes is the dead timer for keepalives, which are not 
getting thru either because of the stalled TCP session.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se




From ras at e-gerbil.net  Tue Sep 15 15:53:16 2009
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Tue, 15 Sep 2009 15:53:16 -0500
Subject: 
In-Reply-To: <21D41A38B8859B4A97B1AE2313922B8A811AB6F0B9@concertiabl02.concertia.com>
References: <9F285BFE1D7757499D9FF095B4EE347D0444E7F3@tw-xchange01.TWC.local>
	
	<21D41A38B8859B4A97B1AE2313922B8A811AB6F0B9@concertiabl02.concertia.com>
Message-ID: <20090915205316.GP51443@gerbil.cluepon.net>

On Tue, Sep 15, 2009 at 05:39:33PM -0300, Brian Dickson wrote:
> And more specifically, possibly an interface MTU (or ip mtu, I forget
> which).
> 
> If there is a mismatch between ends of a link, in one direction,
> MTU-sized packets get sent, and the other end sees those as "giants".

Well if the interface or ip mtu was smaller on one end, this would
result in a lower mss negotiation and you would just have smaller but
working packets. The bad situation is when there is a layer 2 device in
the middle which eats the big packets and doesn't generate an ICMP
needfrag. For example, if there was a 1500-byte only ethernet switch in
the middle of this link, it would drop anything > 1500 bytes and prevent
path mtu discovery from working, resulting in silent blackholing. I was
assuming that wasn't the case here based on the 4474 mtu (was assuming
sonet links or something), but looking at the original message he
doesn't say what media or what might be in the middle, so its possible
4474 is a manually configured mtu causing blackholing.

> I've seen situations where the MTU is calculated incorrectly, when
> using some technology that adds a few bytes (e.g. VLAN tags, MPLS
> tags, etc.).

Even when things are working as intended, different vendors mean 
different things when they talk about MTU. For example, Juniper and 
Cisco disagree as to whether the mtu should include layer 2 or .1q tag 
overhead, resuling in inconsistent MTU numbers which are not only 
different between the vendors, but which can change depending on what 
type of trunk you're running between the devices. Enabling > 1500 byte 
MTUs is a dangerous game if you don't know what you're doing, or if 
you're connected to other people who are sloppy and don't fully verify 
their MTU settings on every link.

> War stories make for great bar BOFs at NANOG meetings. :-)

Never ending supply of those things. :)

-- 
Richard A Steenbergen        http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)



From brandon at bitradius.com  Tue Sep 15 16:12:55 2009
From: brandon at bitradius.com (Brandon Lehmann)
Date: Tue, 15 Sep 2009 17:12:55 -0400
Subject: Repeated Blacklisting / IP reputation
In-Reply-To: <30570.1253046202@turing-police.cc.vt.edu>
References: 
	<4AAFAC5C.8040008@gmail.com>
	<30570.1253046202@turing-police.cc.vt.edu>
Message-ID: 

I believe there is another side to that argument as well.

If I operate a regional ISP and request address space for dynamic  
address pools I am aware of a few things:

1) I am fully aware that there is a chance a customer's system could  
become infected and generate millions of malicious messages/packets/ 
traffic.
2) I am also aware that it is possible that that one machine could  
have any number of IP addresses during the course of the week;  
therefore, it would be possible that they could 'contaminate' an  
entire /24
3) I know that if I'm made aware of the zombified machine that I'll  
disable access to the customer quickly; however, the damage has  
usually already been done.
4) Do I actually care if one of my dynamic address blocks are in a  
DNSBL? Not at all. They should be using my mail server anyways.

Should I have to go through and make sure that every single IP  
address/block is 'clean' before returning the allocation to ARIN? I  
can say with utmost confidence "I don't care" because I no longer  
need them. If my ability to receive new allocations required that I  
clean up a dynamic address block before receiving a new one I would  
take better care of my blocks; however, it may be cheaper just to  
keep the old block (null route it) and ask for another one.

The question becomes: Where do you draw the 'contamination' line? A  
network may be using a block well within what we would consider  
'reasonable' usage; however, the block may become 'unusable' for  
certain purposes. Should they too be denied further address space? If  
thats the case every broadband provider out there should be cut off  
because they're customers keep getting infected and are used to DDOS/ 
SPAM/Exploit our networks.

What I'm trying to say in a long-winded and round about way is simple  
--- The contamination doesn't always happen 'on purpose' or with any  
foresight and it may not be an entire block that is bad. Everyone is  
guilty at some point of having a few 'dirty' IPs on their network...  
and I'm sure all of us have left many dirty because god only knows  
where all it is blocked.




On Sep 15, 2009, at 4:23 PM, Valdis.Kletnieks at vt.edu wrote:

> On Tue, 15 Sep 2009 08:01:48 PDT, Shawn Somers said:
>
>>   Anyone that intentionally uses address space in a manner that they
>> know will cause it to become contaminated should be denied on any
>> further address space requests.
>
> You *do* realize that the people you're directing that paragraph at  
> are
> able to say with a totally straight face: "We're doing nothing  
> wrong and
> we have *no* idea why we end up in so many local block lists"?



From zaid at zaidali.com  Tue Sep 15 16:31:16 2009
From: zaid at zaidali.com (Zaid Ali)
Date: Tue, 15 Sep 2009 14:31:16 -0700
Subject: Repeated Blacklisting / IP reputation
In-Reply-To: <75cb24520909151331p7e5710b7wffe904d9146b44fa@mail.gmail.com>
References: 
	<4AAFAC5C.8040008@gmail.com>
	<30570.1253046202@turing-police.cc.vt.edu>
	<75cb24520909151331p7e5710b7wffe904d9146b44fa@mail.gmail.com>
Message-ID: <1A445928-4413-463D-B438-FF4C19BE8B40@zaidali.com>

I think costs of maintaining an abuse helpdesk is a big factor here. I  
don't see many ISP's putting money and resources into an abuse  
helpdesk and this is because it is low cost to obtain a Netblock so  
why should one employ and build expertise on managing it. If you go to  
SpamHaus you will see a major ISP and their netblocks listed and  
associated with known spammers. What is this ISP doing about this?  
Nothing!  My guess is that they look at their bottom $$ and look at  
Spamming customer A and say "crap we will be spending $$$ on this  
customer just to get them off SpamHaus so just leave it, we are  
afterall in the bandwidth business". If ARIN were to say to this major  
ISP that they wont allocate more addresses to them until they adhere  
to an AUP then maybe the game will change but the bigger question here  
is should ARIN get into this kind of policy.

Zaid


On Sep 15, 2009, at 1:31 PM, Christopher Morrow wrote:

> On Tue, Sep 15, 2009 at 4:23 PM,   wrote:
>> On Tue, 15 Sep 2009 08:01:48 PDT, Shawn Somers said:
>>
>>>   Anyone that intentionally uses address space in a manner that they
>>> know will cause it to become contaminated should be denied on any
>>> further address space requests.
>>
>> You *do* realize that the people you're directing that paragraph at  
>> are
>> able to say with a totally straight face: "We're doing nothing  
>> wrong and
>> we have *no* idea why we end up in so many local block lists"?
>
> Also, you can very well disable new allocations to Spammer-Bob, did
> you also know his friend Sue is asking now for space? Sue is very
> nice, she even has cookies... oh damn after we allocated to her we
> found out she's spamming :(
>
> Spammers have a lot of variables to change in this equation, RIR's
> dont always have the ability to see all of the variables, nor
> correlate all of the changes they see :(
>
> -Chris
>




From schampeo at hesketh.com  Tue Sep 15 16:40:30 2009
From: schampeo at hesketh.com (Steven Champeon)
Date: Tue, 15 Sep 2009 17:40:30 -0400
Subject: on naming conventions (was: Re: Repeated Blacklisting / IP reputation)
In-Reply-To: <148476.263921252421878121.JavaMail.root@zimbra>
References: <27247188.263871252421864157.JavaMail.root@zimbra>
	<148476.263921252421878121.JavaMail.root@zimbra>
Message-ID: <20090915214030.GA20988@hesketh.com>

on Tue, Sep 08, 2009 at 09:57:58AM -0500, Tom Pipes wrote:
> [...] We have done our best to ensure these blocks conform to RFC
> standards, including the proper use of reverse DNS pointers.

Sorry to jump in so late, been catching up from vacation. I'm checking
out the PTRs for the /18 you mention, and I see that you've used a few
different naming conventions, some of which are friendly to those who
block on dot-separated substrings, some of which are confusing, and some
of which are custom to specific clients. If I could speak on behalf of
the tens of thousands of mail admins out there for a minute, I'd ask
that instead of (e.g.)

  69.197.115.62: 69-197-115-62-dynamic.t6b.com

you instead use a dot to separate the 'dynamic' from the generated
IP-based hostname part, a la

  69.197.115.62: 69-197-115-62.dynamic.t6b.com

This allows admins of most FOSS MTAs to simply deny traffic from all
of those hosts on the grounds that they are dynamically assigned, for
example in sendmail's access.db:

Connect:dynamic.t6b.com ERROR:5.7.1:"550 Go away, dynamic user."

If you choose not to, it doesn't bother me; I've got a rather extensive
set of regular expressions that can handle those naming conventions, but
the rest of the mail admins may find it more friendly were you to do so.

Additionally, it may also be useful to indicate what sort of access is
being provided, so for dialups you might want to do

  69.197.115.62: 69-197-115-62.dialup.dynamic.t6b.com

(Note: not 'dynamic.dialup.t6b.com', most people care more about whether
a host is dynamic at least in the context of antispam operations).

I also note that the vast majority of the /18 simply lacks PTRs at all;
you also mix statics and dynamics (though on different /24s, eg
69.197.106, 69.197.107, 69.197.108 seem static where 69.197.110,
69.197.111, and 69.197.115 do not, with more statics seen in 69.197.117
and 69.197.118 ff.) and don't seem to SWIP the statics or indicate in
whois which are dynamic pools. All of these are likely to result in
unfunny errors by DNSBL operators if they decide that you're serious and
the whole /18 is dynamic based on a preponderance of hosts in some /24s
with dynamic-appearing names AND a lack of evidence otherwise in the
whois record.

Of course, if you follow MAAWG's port 25 blocking BCP, it's moot as
far as the dynamics go.

Ultimately, you'd want to make sure any static customer intending to
provide mail services have their own custom PTR(s) for those hosts,
in their domains (not yours). 

HTH,
Steve

-- 
hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/
antispam news and intelligence to help you stop spam: http://enemieslist.com/



From morrowc.lists at gmail.com  Tue Sep 15 20:22:02 2009
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 15 Sep 2009 21:22:02 -0400
Subject: Repeated Blacklisting / IP reputation
In-Reply-To: <1A445928-4413-463D-B438-FF4C19BE8B40@zaidali.com>
References: 
	<4AAFAC5C.8040008@gmail.com>
	<30570.1253046202@turing-police.cc.vt.edu>
	<75cb24520909151331p7e5710b7wffe904d9146b44fa@mail.gmail.com>
	<1A445928-4413-463D-B438-FF4C19BE8B40@zaidali.com>
Message-ID: <75cb24520909151822j5d833b3byadd05b585a5a3543@mail.gmail.com>

On Tue, Sep 15, 2009 at 5:31 PM, Zaid Ali  wrote:
> I think costs of maintaining an abuse helpdesk is a big factor here. I don't
> see many ISP's putting money and resources into an abuse helpdesk and this
> is because it is low cost to obtain a Netblock so why should one employ and

have you ever had to re-number a customer, several customers, a
hundred?? 'getting a new netblock is low cost' is hardly an accurate
statement, especially if you keep in mind that you have to justify the
usage of old netblocks in order to obtain the new one.

> build expertise on managing it. If you go to SpamHaus you will see a major
> ISP and their netblocks listed and associated with known spammers. What is
> this ISP doing about this? Nothing! ?My guess is that they look at their

'nothing' that you can see? or nothing? or something you can't see or
that's taking longer than you'd expect/like? There certainly are bad
actors out there, but I think the majority are doing things to keep
clean, perhaps not in the manner you would like (or the speed you
would like or with as much public information as you'd like).

>From the outside most ISP operations look quite opaque, proclaiming
'Nothing is being done' simply looks uneducated and shortsighted.

> bottom $$ and look at Spamming customer A and say "crap we will be spending
> $$$ on this customer just to get them off SpamHaus so just leave it, we are
> afterall in the bandwidth business". If ARIN were to say to this major ISP
> that they wont allocate more addresses to them until they adhere to an AUP
> then maybe the game will change but the bigger question here is should ARIN
> get into this kind of policy.

doubtful that: 1) arin would say this (not want to be net police), 2)
isp's couldn't show (for the vast majority of isps) that they are in
fact upholding their AUP.

-chris

> On Sep 15, 2009, at 1:31 PM, Christopher Morrow wrote:
>
>> On Tue, Sep 15, 2009 at 4:23 PM, ? wrote:
>>>
>>> On Tue, 15 Sep 2009 08:01:48 PDT, Shawn Somers said:
>>>
>>>> ?Anyone that intentionally uses address space in a manner that they
>>>> know will cause it to become contaminated should be denied on any
>>>> further address space requests.
>>>
>>> You *do* realize that the people you're directing that paragraph at are
>>> able to say with a totally straight face: "We're doing nothing wrong and
>>> we have *no* idea why we end up in so many local block lists"?
>>
>> Also, you can very well disable new allocations to Spammer-Bob, did
>> you also know his friend Sue is asking now for space? Sue is very
>> nice, she even has cookies... oh damn after we allocated to her we
>> found out she's spamming :(
>>
>> Spammers have a lot of variables to change in this equation, RIR's
>> dont always have the ability to see all of the variables, nor
>> correlate all of the changes they see :(
>>
>> -Chris
>>
>
>



From morrowc.lists at gmail.com  Tue Sep 15 20:34:14 2009
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 15 Sep 2009 21:34:14 -0400
Subject: Repeated Blacklisting / IP reputation
In-Reply-To: <20090915204619.GA19640@vacation.karoshi.com.>
References: 
	<4AAFAC5C.8040008@gmail.com>
	<30570.1253046202@turing-police.cc.vt.edu>
	<75cb24520909151331p7e5710b7wffe904d9146b44fa@mail.gmail.com>
	<20090915204619.GA19640@vacation.karoshi.com.>
Message-ID: <75cb24520909151834o5109c402w9310838d9ce28032@mail.gmail.com>

On Tue, Sep 15, 2009 at 4:46 PM,   wrote:
>
> so... this thread has a couple of really interesting characteristics.
> a couple are worth mentioning more directly (they have been alluded to elsewhere)...

as always, despite your choice in floral patterned shirts :) good
comments/questions.

>
> ? ? ? ?Who gets to define "bad" - other than a blacklist operator?
> ? ? ? ?Are the common, consistent defintions of "contamination"?
>

nope, each BL (as near as I can tell) has their own criteria (with
some overlaps to be certain) and they all have their own set of rules
that they either break at-will or change when it suits them. Their
incentives are not aligned with actually getting the problem resolved,
sadly... and they really don't have any power to resolve problems
anyway.

> ? ? ? ?If these are social/political - recognise that while the ARIN
> ? ? ? ?region is fairly consistent in its general use and interpretation
> ? ? ? ?of law, there are known varients - based on soveriegn region.

Yup, you don't like my business how about I move to the caymans where
it's no longer illegal? :( The Internet brings with it some
interesting judicial/jurisdictional baggage.

> this whole debate/discussion seems based on the premise that there are well
> known, consistent, legally defendable choices for defining offensive behaviours.
> and pretty much all of history shows us this is not the case.

There are really two discussions, I think somewhere along the path
they were conflated:

1) newly allocated from IANA netblocks show up to end customers and
reachability problems ensue. (route-filters and/or firewall filters)

2) newly re-allocated netblocks show up with RBL baggage (rbls and
smtp blocks at the application layer)

For #1 there was some work (rbush and prior to that Jon Lewis
69block.org?) showing that folks 'never' alter their 'bogon route
filters' or 'bogon access-list entries'.

For #2 ARIN may have a solution in place, if it were more publicly
known (rss feed of allocations, care of RS and marty hannigan
pointers) that RBL operators could use to clean out entries in their
lists providing a better service to their 'users' even, perish the
thought!

> ? ? ? ?(is or is not a mother nursing her child in public pornographic?)

or SI Swinsuit edition depending on the part of the world you are in,
yes, or even YouTube videos, weee!

> So - I suspect that in the end, a registry (ARIN) or an ISP (COMCAST) is only
> going to be able to tell you a few things about the prefix you have been handed.
>
> ? ? ? ?a) its virginal - never been used (that we know of)
> ? ? ? ?b) its been used once.
> ? ? ? ?c) it has a checkered past

I actually don't think it's a help for ARIN to say anything here,
since they can never know all the RBL's and history for a netblock,
and they can't help in the virginal case since they don't run
network-wide filters.

A FAQ that says some of the above with some pointers to testing
harnesses to use may be useful. Some tools for network operators to
use in updating things in a timely fashion may be useful.
Better/wider/louder notification 'services' for new block allocations
from IANA -> RIR's may be useful.

Not everyone who runs a router reads their local 'nog' list... Leo
Vegoda does a great job tell us about RIPE allocations, Someone does
the same for ARIN (drc maybe??) and I'm not certain I recall who's
last announced APNIC block yahtzee.  Where else is this data
available? In a form that your avg enterprise network op may notice?

> and it will be up to the receipient to trust/accept the resource for what it
> currently is or chose to reject it and find soliace elsewhere.
>

'solace elsewhere'... dude there is no 'elsewhere'.

-Chris
(and yes, I'm yanking your chain about the shirts...)

> --bill
>
>
> On Tue, Sep 15, 2009 at 04:31:04PM -0400, Christopher Morrow wrote:
>> On Tue, Sep 15, 2009 at 4:23 PM, ? wrote:
>> > On Tue, 15 Sep 2009 08:01:48 PDT, Shawn Somers said:
>> >
>> >> ? Anyone that intentionally uses address space in a manner that they
>> >> know will cause it to become contaminated should be denied on any
>> >> further address space requests.
>> >
>> > You *do* realize that the people you're directing that paragraph at are
>> > able to say with a totally straight face: "We're doing nothing wrong and
>> > we have *no* idea why we end up in so many local block lists"?
>>
>> Also, you can very well disable new allocations to Spammer-Bob, did
>> you also know his friend Sue is asking now for space? Sue is very
>> nice, she even has cookies... oh damn after we allocated to her we
>> found out she's spamming :(
>>
>> Spammers have a lot of variables to change in this equation, RIR's
>> dont always have the ability to see all of the variables, nor
>> correlate all of the changes they see :(
>>
>> -Chris
>>
>



From simon at darkmere.gen.nz  Tue Sep 15 21:14:01 2009
From: simon at darkmere.gen.nz (NANOG Mail List Committee)
Date: Wed, 16 Sep 2009 14:14:01 +1200
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 bmanning at vacation.karoshi.com  Tue Sep 15 21:29:16 2009
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 16 Sep 2009 02:29:16 +0000
Subject: Repeated Blacklisting / IP reputation
In-Reply-To: <75cb24520909151834o5109c402w9310838d9ce28032@mail.gmail.com>
References: 
	<4AAFAC5C.8040008@gmail.com>
	<30570.1253046202@turing-police.cc.vt.edu>
	<75cb24520909151331p7e5710b7wffe904d9146b44fa@mail.gmail.com>
	<20090915204619.GA19640@vacation.karoshi.com.>
	<75cb24520909151834o5109c402w9310838d9ce28032@mail.gmail.com>
Message-ID: <20090916022916.GB20782@vacation.karoshi.com.>

On Tue, Sep 15, 2009 at 09:34:14PM -0400, Christopher Morrow wrote:
> On Tue, Sep 15, 2009 at 4:46 PM,   wrote:
> >
> > so... this thread has a couple of really interesting characteristics.
> > a couple are worth mentioning more directly (they have been alluded to elsewhere)...
> 
> as always, despite your choice in floral patterned shirts :) good
> comments/questions.

	humph... at least I wear pants.

> >
> >        Who gets to define "bad" - other than a blacklist operator?
> >        Are the common, consistent defintions of "contamination"?
> 
> nope, each BL (as near as I can tell) has their own criteria (with

	trick question... each ISP gets to define good/bad on their
	own merits or can outsource it to third parties.


> 1) newly allocated from IANA netblocks show up to end customers and
> reachability problems ensue. (route-filters and/or firewall filters)
> 
> 2) newly re-allocated netblocks show up with RBL baggage (rbls and
> smtp blocks at the application layer)

	you forgot #3 ... a "clean" IANA block that was "borrowed"
	for a while .. and already shows up in some filter lists.


> > So - I suspect that in the end, a registry (ARIN) or an ISP (COMCAST) is only
> > going to be able to tell you a few things about the prefix you have been handed.
> >
> >        a) its virginal - never been used (that we know of)
> >        b) its been used once.
> >        c) it has a checkered past
> 
> I actually don't think it's a help for ARIN to say anything here,
> since they can never know all the RBL's and history for a netblock,
> and they can't help in the virginal case since they don't run
> network-wide filters.

	not RBL specific ...  

	a) this block came directly from IANA and has never been previously allocated
	   in/through the IANA/RIR process
	b) this block has had one registered steward in recorded history
	c) this block has been in/out of the RIR/registry system more than once.

> A FAQ that says some of the above with some pointers to testing
> harnesses to use may be useful. Some tools for network operators to
> use in updating things in a timely fashion may be useful.
> Better/wider/louder notification 'services' for new block allocations
> from IANA -> RIR's may be useful.

	indeed - I'd like to see the suite extended to the ISPs as well, esp
	if such tricks will be used in v6land...

> last announced APNIC block yahtzee.  Where else is this data
> available? In a form that your avg enterprise network op may notice?

	oh... I'd suggest some of the security lists might be a good
	channel.

> > and it will be up to the receipient to trust/accept the resource for what it
> > currently is or chose to reject it and find soliace elsewhere.
> 
> 'solace elsewhere'... dude there is no 'elsewhere'.

	and yet... Jimmy and Warren Buffet will tell you its always 1700 somewhere....
	and if that doesn't work,  whip out the NAT and reuse 10.0.0.0 -again-.... :)


> 
> -Chris
> (and yes, I'm yanking your chain about the shirts...)
> 
> > --bill
> >
> >
> > On Tue, Sep 15, 2009 at 04:31:04PM -0400, Christopher Morrow wrote:
> >> On Tue, Sep 15, 2009 at 4:23 PM,   wrote:
> >> > On Tue, 15 Sep 2009 08:01:48 PDT, Shawn Somers said:
> >> >
> >> >>   Anyone that intentionally uses address space in a manner that they
> >> >> know will cause it to become contaminated should be denied on any
> >> >> further address space requests.
> >> >
> >> > You *do* realize that the people you're directing that paragraph at are
> >> > able to say with a totally straight face: "We're doing nothing wrong and
> >> > we have *no* idea why we end up in so many local block lists"?
> >>
> >> Also, you can very well disable new allocations to Spammer-Bob, did
> >> you also know his friend Sue is asking now for space? Sue is very
> >> nice, she even has cookies... oh damn after we allocated to her we
> >> found out she's spamming :(
> >>
> >> Spammers have a lot of variables to change in this equation, RIR's
> >> dont always have the ability to see all of the variables, nor
> >> correlate all of the changes they see :(
> >>
> >> -Chris
> >>
> >



From morrowc.lists at gmail.com  Tue Sep 15 21:40:53 2009
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 15 Sep 2009 22:40:53 -0400
Subject: Repeated Blacklisting / IP reputation
In-Reply-To: <20090916022916.GB20782@vacation.karoshi.com.>
References: 
	<4AAFAC5C.8040008@gmail.com>
	<30570.1253046202@turing-police.cc.vt.edu>
	<75cb24520909151331p7e5710b7wffe904d9146b44fa@mail.gmail.com>
	<20090915204619.GA19640@vacation.karoshi.com.>
	<75cb24520909151834o5109c402w9310838d9ce28032@mail.gmail.com>
	<20090916022916.GB20782@vacation.karoshi.com.>
Message-ID: <75cb24520909151940v62771450j45064672c786560f@mail.gmail.com>

On Tue, Sep 15, 2009 at 10:29 PM,   wrote:
> On Tue, Sep 15, 2009 at 09:34:14PM -0400, Christopher Morrow wrote:
>> On Tue, Sep 15, 2009 at 4:46 PM, ? wrote:
>> >
>> > so... this thread has a couple of really interesting characteristics.
>> > a couple are worth mentioning more directly (they have been alluded to elsewhere)...
>>
>> as always, despite your choice in floral patterned shirts :) good
>> comments/questions.
>
> ? ? ? ?humph... at least I wear pants.

you have something against skirts? or dresses? always with the pants
with you!! 

>> >
>> > ? ? ? ?Who gets to define "bad" - other than a blacklist operator?
>> > ? ? ? ?Are the common, consistent defintions of "contamination"?
>>
>> nope, each BL (as near as I can tell) has their own criteria (with
>
> ? ? ? ?trick question... each ISP gets to define good/bad on their
> ? ? ? ?own merits or can outsource it to third parties.

sure... outsourcing in this case often happens without a real business
relationship.

>
>> 1) newly allocated from IANA netblocks show up to end customers and
>> reachability problems ensue. (route-filters and/or firewall filters)
>>
>> 2) newly re-allocated netblocks show up with RBL baggage (rbls and
>> smtp blocks at the application layer)
>
> ? ? ? ?you forgot #3 ... a "clean" IANA block that was "borrowed"
> ? ? ? ?for a while .. and already shows up in some filter lists.

ok... but we can't ever really know that Verizon uses 114/8 and 104/8
internally can we? (and has/may leak this to external parties on
occasion by mistake)

>
>> > So - I suspect that in the end, a registry (ARIN) or an ISP (COMCAST) is only
>> > going to be able to tell you a few things about the prefix you have been handed.
>> >
>> > ? ? ? ?a) its virginal - never been used (that we know of)
>> > ? ? ? ?b) its been used once.
>> > ? ? ? ?c) it has a checkered past
>>
>> I actually don't think it's a help for ARIN to say anything here,
>> since they can never know all the RBL's and history for a netblock,
>> and they can't help in the virginal case since they don't run
>> network-wide filters.
>
> ? ? ? ?not RBL specific ...
>
> ? ? ? ?a) this block came directly from IANA and has never been previously allocated
> ? ? ? ? ? in/through the IANA/RIR process
> ? ? ? ?b) this block has had one registered steward in recorded history
> ? ? ? ?c) this block has been in/out of the RIR/registry system more than once.

Ok, is this in the final email from hostmaster@ to 'enduser@'? or
somewhere else? what's the recourse when someone says: "But I don't
want a USED netblock, it my have the herp!"

I'm trying to see if ARIN can say something of use here without
raising its costs or causing extra/more confusion to the end-site(s).

>> A FAQ that says some of the above with some pointers to testing
>> harnesses to use may be useful. Some tools for network operators to
>> use in updating things in a timely fashion may be useful.
>> Better/wider/louder notification 'services' for new block allocations
>> from IANA -> RIR's may be useful.
>
> ? ? ? ?indeed - I'd like to see the suite extended to the ISPs as well, esp
> ? ? ? ?if such tricks will be used in v6land...
>
>> last announced APNIC block yahtzee. ?Where else is this data
>> available? In a form that your avg enterprise network op may notice?
>
> ? ? ? ?oh... I'd suggest some of the security lists might be a good
> ? ? ? ?channel.
>

sure, most of those folks also read nanog-l, this won't also reach
enterprise folk... (admittedly it's hard to reach 'everyone', but
spammers seem to be able to...)

>> > and it will be up to the receipient to trust/accept the resource for what it
>> > currently is or chose to reject it and find soliace elsewhere.
>>
>> 'solace elsewhere'... dude there is no 'elsewhere'.
>
> ? ? ? ?and yet... Jimmy and Warren Buffet will tell you its always 1700 somewhere....
> ? ? ? ?and if that doesn't work, ?whip out the NAT and reuse 10.0.0.0 -again-.... :)

ha... :(

-chris

>>
>> -Chris
>> (and yes, I'm yanking your chain about the shirts...)
>>
>> > --bill
>> >
>> >
>> > On Tue, Sep 15, 2009 at 04:31:04PM -0400, Christopher Morrow wrote:
>> >> On Tue, Sep 15, 2009 at 4:23 PM, ? wrote:
>> >> > On Tue, 15 Sep 2009 08:01:48 PDT, Shawn Somers said:
>> >> >
>> >> >> ? Anyone that intentionally uses address space in a manner that they
>> >> >> know will cause it to become contaminated should be denied on any
>> >> >> further address space requests.
>> >> >
>> >> > You *do* realize that the people you're directing that paragraph at are
>> >> > able to say with a totally straight face: "We're doing nothing wrong and
>> >> > we have *no* idea why we end up in so many local block lists"?
>> >>
>> >> Also, you can very well disable new allocations to Spammer-Bob, did
>> >> you also know his friend Sue is asking now for space? Sue is very
>> >> nice, she even has cookies... oh damn after we allocated to her we
>> >> found out she's spamming :(
>> >>
>> >> Spammers have a lot of variables to change in this equation, RIR's
>> >> dont always have the ability to see all of the variables, nor
>> >> correlate all of the changes they see :(
>> >>
>> >> -Chris
>> >>
>> >
>



From joelja at bogus.com  Tue Sep 15 23:08:54 2009
From: joelja at bogus.com (Joel Jaeggli)
Date: Tue, 15 Sep 2009 21:08:54 -0700
Subject: Repeated Blacklisting / IP reputation
In-Reply-To: <75cb24520909151331p7e5710b7wffe904d9146b44fa@mail.gmail.com>
References: 	<4AAFAC5C.8040008@gmail.com>	<30570.1253046202@turing-police.cc.vt.edu>
	<75cb24520909151331p7e5710b7wffe904d9146b44fa@mail.gmail.com>
Message-ID: <4AB064D6.7000604@bogus.com>

Christopher Morrow wrote:
>
> Spammers have a lot of variables to change in this equation, RIR's
> dont always have the ability to see all of the variables, nor
> correlate all of the changes they see :(

Being a crimnal enterprise there are some tools in your kit that a
legitimate business does not have. The problems  becomes,  how the
raising the legitimacy bar more effectively discriminates against
legitimate entities then crimnal one's.

If a discriminatory measure were for example to raise the bar for new
entrants that, by it's nature represents an Internet scale tragedy.

joel

> -Chris
> 



From morrowc.lists at gmail.com  Tue Sep 15 23:41:23 2009
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 16 Sep 2009 00:41:23 -0400
Subject: Repeated Blacklisting / IP reputation
In-Reply-To: <4AB064D6.7000604@bogus.com>
References: 
	<4AAFAC5C.8040008@gmail.com>
	<30570.1253046202@turing-police.cc.vt.edu>
	<75cb24520909151331p7e5710b7wffe904d9146b44fa@mail.gmail.com>
	<4AB064D6.7000604@bogus.com>
Message-ID: <75cb24520909152141t3c56d409y84f2b015e16092dc@mail.gmail.com>

On Wed, Sep 16, 2009 at 12:08 AM, Joel Jaeggli  wrote:
> Christopher Morrow wrote:
>>
>> Spammers have a lot of variables to change in this equation, RIR's
>> dont always have the ability to see all of the variables, nor
>> correlate all of the changes they see :(
>
> Being a crimnal enterprise there are some tools in your kit that a
> legitimate business does not have. The problems ?becomes, ?how the

that was my point, yes.

> raising the legitimacy bar more effectively discriminates against
> legitimate entities then crimnal one's.
>
> If a discriminatory measure were for example to raise the bar for new
> entrants that, by it's nature represents an Internet scale tragedy.

I think we are in agreement on this issue, and the above actually.

-Chris



From mruiz at telwestservices.com  Wed Sep 16 13:18:20 2009
From: mruiz at telwestservices.com (Michael Ruiz)
Date: Wed, 16 Sep 2009 13:18:20 -0500
Subject: 
In-Reply-To: <20090915205316.GP51443@gerbil.cluepon.net>
References: <9F285BFE1D7757499D9FF095B4EE347D0444E7F3@tw-xchange01.TWC.local>
	
	<21D41A38B8859B4A97B1AE2313922B8A811AB6F0B9@concertiabl02.concertia.com>
	<20090915205316.GP51443@gerbil.cluepon.net>
Message-ID: <9F285BFE1D7757499D9FF095B4EE347D0449C144@tw-xchange01.TWC.local>

>I was assuming that wasn't the case here based on the 4474 mtu (was
assuming
>sonet links or something), but looking at the original message he
>doesn't say what media or what might be in the middle, so its possible
>4474 is a manually configured mtu causing blackholing.

Here is the network architecture from the Cisco 6509 to the 7206 VXR.
The 6509 has a successful BGP session established with another router,
Cisco 7606 w/ Sup720-3bxls.  The 7606 and 7206 VXR are connected
together by a Cisco 3550 switch. In order for the 6509 to establish the
IBGP session to the 7606, it has to pass through two DS-3s, go through
the 7206 VXR, out the Fast E, through the Cisco 3550, and then to the
7606. I checked the MTUs on the 3550s and I am seeing the Fast E
interfaces are still showing 1500 bytes. Would increasing the MTU size
on the switches cause any harm? 

-----Original Message-----
From: Richard A Steenbergen [mailto:ras at e-gerbil.net] 
Sent: Tuesday, September 15, 2009 3:53 PM
To: Brian Dickson
Cc: Mikael Abrahamsson; Michael Ruiz; nanog at nanog.org
Subject: Re: 

On Tue, Sep 15, 2009 at 05:39:33PM -0300, Brian Dickson wrote:
> And more specifically, possibly an interface MTU (or ip mtu, I forget
> which).
> 
> If there is a mismatch between ends of a link, in one direction,
> MTU-sized packets get sent, and the other end sees those as "giants".

Well if the interface or ip mtu was smaller on one end, this would
result in a lower mss negotiation and you would just have smaller but
working packets. The bad situation is when there is a layer 2 device in
the middle which eats the big packets and doesn't generate an ICMP
needfrag. For example, if there was a 1500-byte only ethernet switch in
the middle of this link, it would drop anything > 1500 bytes and prevent
path mtu discovery from working, resulting in silent blackholing. I was
assuming that wasn't the case here based on the 4474 mtu (was assuming
sonet links or something), but looking at the original message he
doesn't say what media or what might be in the middle, so its possible
4474 is a manually configured mtu causing blackholing.

> I've seen situations where the MTU is calculated incorrectly, when
> using some technology that adds a few bytes (e.g. VLAN tags, MPLS
> tags, etc.).

Even when things are working as intended, different vendors mean 
different things when they talk about MTU. For example, Juniper and 
Cisco disagree as to whether the mtu should include layer 2 or .1q tag 
overhead, resuling in inconsistent MTU numbers which are not only 
different between the vendors, but which can change depending on what 
type of trunk you're running between the devices. Enabling > 1500 byte 
MTUs is a dangerous game if you don't know what you're doing, or if 
you're connected to other people who are sloppy and don't fully verify 
their MTU settings on every link.

> War stories make for great bar BOFs at NANOG meetings. :-)

Never ending supply of those things. :)

-- 
Richard A Steenbergen 
http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1
2CBC)



From sthaug at nethelp.no  Wed Sep 16 14:00:38 2009
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Wed, 16 Sep 2009 21:00:38 +0200 (CEST)
Subject: 
In-Reply-To: <9F285BFE1D7757499D9FF095B4EE347D0449C144@tw-xchange01.TWC.local>
References: <21D41A38B8859B4A97B1AE2313922B8A811AB6F0B9@concertiabl02.concertia.com>
	<20090915205316.GP51443@gerbil.cluepon.net>
	<9F285BFE1D7757499D9FF095B4EE347D0449C144@tw-xchange01.TWC.local>
Message-ID: <20090916.210038.85324334.sthaug@nethelp.no>

> I checked the MTUs on the 3550s and I am seeing the Fast E
> interfaces are still showing 1500 bytes. Would increasing the MTU size
> on the switches cause any harm? 

The 3550s are very limited with respect to MTU - the standard model
can only do up to 1546 byte, while I believe the -12G model can to
2000 byte. In any case - you won't get a 4470 byte packet through a
3550. Also, changing the MTU on the 3550 requires a reboot.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no



From ras at e-gerbil.net  Wed Sep 16 14:07:05 2009
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Wed, 16 Sep 2009 14:07:05 -0500
Subject: 
In-Reply-To: <9F285BFE1D7757499D9FF095B4EE347D0449C144@tw-xchange01.TWC.local>
References: <9F285BFE1D7757499D9FF095B4EE347D0444E7F3@tw-xchange01.TWC.local>
	
	<21D41A38B8859B4A97B1AE2313922B8A811AB6F0B9@concertiabl02.concertia.com>
	<20090915205316.GP51443@gerbil.cluepon.net>
	<9F285BFE1D7757499D9FF095B4EE347D0449C144@tw-xchange01.TWC.local>
Message-ID: <20090916190705.GU51443@gerbil.cluepon.net>

On Wed, Sep 16, 2009 at 01:18:20PM -0500, Michael Ruiz wrote:
> Here is the network architecture from the Cisco 6509 to the 7206 VXR.
> The 6509 has a successful BGP session established with another router,
> Cisco 7606 w/ Sup720-3bxls.  The 7606 and 7206 VXR are connected
> together by a Cisco 3550 switch. In order for the 6509 to establish the
> IBGP session to the 7606, it has to pass through two DS-3s, go through
> the 7206 VXR, out the Fast E, through the Cisco 3550, and then to the
> 7606. I checked the MTUs on the 3550s and I am seeing the Fast E
> interfaces are still showing 1500 bytes. Would increasing the MTU size
> on the switches cause any harm? 

As other people have said, this definitely sounds like an MTU problem. 
Basically you're trying to pass 4470 byte BGP packets over a link that
drops anything bigger than 1500. The session will establish because all
the setup packets are small, but the tcp session will stall as soon as
you try to send routes across it.

What should be happening here is the 6509 will generate a 4470 byte
packet because it sees the directly connected interface as a DS3 and
doesn't know the path is incapable of supporting > 1500 bytes end to
end. The layer 3 device on the mtu choke point, in this case the faste
interface on the 7206vxr, should be configured to a 1500 byte mtu. This
will cause the 7206vxr to generate an ICMP neegfrag when the 4470 byte
packet comes along, and cause path mtu discovery to lower the MSS on the
IBGP session. Either a) you have the mtu misconfigured on that 7206vxr
port, b) your router is misconfigured not to generate the icmp, c)
something in the middle is misconfigured to filter this necessary icmp
packet, or d) some other screwup probably related to one of the above.

Generally speaking increasing the MTU size on a switch can never hurt
anything, but having an insufficiently large MTU on the switch is what
will break you the most (as is happening here). The problem occurs when
you increase the MTU on the layer 3 routers to something beyond what the
layer 2 link in the middle is capable of supporting. Layer 3 devices
will either fragment (deprecated) or generate ICMP NeedFrags which will
cause path MTU discovery to shrink the MSS. Layer 2 devices are
incapable of doing this, so you MUST NOT set the layer 3 MTU above what
the layer 2 link is capable of handling.

Now that said, increasing the mtu on the 3550 won't work here because
3550 MTU support is terrible. The only option you have is to configure
the MTU of all interfaces to 1546 with the "system mtu 1546" command,
followed by a reload. This is not big enough to pass your 4470 byte
packets, and will also break any MTU dependent configuration you might
be running. For example, after you do this, any OSPF speakers on your
3550 will have to have their MTUs adjusted as well, or OSPF will not
come back up due to the interface mismatch. For more details see:

http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_example09186a008010edab.shtml#c4

Your best bet (in order of most preferable to least) is to a) fix
whatever is breaking path mtu discovery on the 7206vxr in the first
place, b) force the mss of the ibgp session to something under 1460, or
c) lower the mtu on the ds3 interface to 1500.

-- 
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  Wed Sep 16 15:03:42 2009
From: Brian.Dickson at concertia.com (Brian Dickson)
Date: Wed, 16 Sep 2009 17:03:42 -0300
Subject: 
In-Reply-To: <20090916190705.GU51443@gerbil.cluepon.net>
References: <9F285BFE1D7757499D9FF095B4EE347D0444E7F3@tw-xchange01.TWC.local>
	
	<21D41A38B8859B4A97B1AE2313922B8A811AB6F0B9@concertiabl02.concertia.com>
	<20090915205316.GP51443@gerbil.cluepon.net>
	<9F285BFE1D7757499D9FF095B4EE347D0449C144@tw-xchange01.TWC.local>
	<20090916190705.GU51443@gerbil.cluepon.net>
Message-ID: <21D41A38B8859B4A97B1AE2313922B8A811AB6F14B@concertiabl02.concertia.com>

RAS wrote:

[ lots of good stuff elided for brevity ]

> c) lower the mtu on the ds3 interface to 1500.

This will have another benefit, if it is done to all such interfaces on the two devices.
(Where by "all such interfaces", I mean "everything with set-able MTU > 1500".)

Configuring one common MTU size on the interfaces, means the buffer pool on the box will switch from several pools of varying sizes, to one pool.
The number of buffers per pool get pro-rated by speed * buffer size, so high-speed, high-MTU interfaces get a gigantic chunk of buffer space.

Once you reduce things to one pool, you significantly reduce the likelihood of buffer starvation.

Note that the discussion on benefits to buffers is old info, and may even be moot these days, but buffers are fundamental enough that I doubt it.

However, the original problem, iBGP not working, will definitely be resolved by this.

Note also, changing this often won't take effect until a reboot, and/or may result in buffer re-carving with an attendant "hit" of up to 30 seconds of no forwarding packets (!!). You've been warned...

In other words, plan this carefully, and make sure you have remote hands available or are on site. This qualifies as "deep voodoo". ;-)

Brian



From lee at asgard.org  Wed Sep 16 17:11:29 2009
From: lee at asgard.org (Lee Howard)
Date: Wed, 16 Sep 2009 18:11:29 -0400
Subject: Repeated Blacklisting / IP reputation
In-Reply-To: <75cb24520909151834o5109c402w9310838d9ce28032@mail.gmail.com>
References: 	<4AAFAC5C.8040008@gmail.com>	<30570.1253046202@turing-police.cc.vt.edu>	<75cb24520909151331p7e5710b7wffe904d9146b44fa@mail.gmail.com>	<20090915204619.GA19640@vacation.karoshi.com.>
	<75cb24520909151834o5109c402w9310838d9ce28032@mail.gmail.com>
Message-ID: <003701ca371a$aa2c7c80$fe857580$@org>

> > and it will be up to the receipient to trust/accept the resource for
what it
> > currently is or chose to reject it and find soliace elsewhere.
> >
> 
> 'solace elsewhere'... dude there is no 'elsewhere'.

"elsewhere" = "designated transfer"
https://www.arin.net/policy/nrpm.html#eight3

Do you get a premium for a "clean" /18?

Lee




From mruiz at telwestservices.com  Wed Sep 16 18:47:10 2009
From: mruiz at telwestservices.com (Michael Ruiz)
Date: Wed, 16 Sep 2009 18:47:10 -0500
Subject: 
In-Reply-To: <20090916190705.GU51443@gerbil.cluepon.net>
References: <9F285BFE1D7757499D9FF095B4EE347D0444E7F3@tw-xchange01.TWC.local><21D41A38B8859B4A97B1AE2313922B8A811AB6F0B9@concertiabl02.concertia.com><20090915205316.GP51443@gerbil.cluepon.net><9F285BFE1D7757499D9FF095B4EE347D0449C144@tw-xchange01.TWC.local>
	<20090916190705.GU51443@gerbil.cluepon.net>
Message-ID: <9F285BFE1D7757499D9FF095B4EE347D0449C3C1@tw-xchange01.TWC.local>

>Either a) you have the mtu misconfigured on that 7206vxr

That part is where I am at a loss.  How is it the 6509 can establish a
IBGP session with a 7606 when it has to go through the 7206 VXR?  The
DS-3s are connected to the 7206 VXR. To add more depth to the story.  I
have 8 IBGP sessions that are connected to the 7206 VXR that have been
up and running for over a year.  Some of the sessions traverse the DS-3s
and or a GigE long haul connections.  There are a total 10 Core routers
that are mixture of Cisco 7606, 6509s, 7206 VXR w/ NPE400s or G1s.  Only
this one IBGP session out of 9 routers is not being established.  Since
I have a switch between the 7606 and 7206, I plan to put a packet
capture server and see what I can see. 


-----Original Message-----
From: Richard A Steenbergen [mailto:ras at e-gerbil.net] 
Sent: Wednesday, September 16, 2009 2:07 PM
To: Michael Ruiz
Cc: Brian Dickson; nanog at nanog.org
Subject: Re: 

On Wed, Sep 16, 2009 at 01:18:20PM -0500, Michael Ruiz wrote:
> Here is the network architecture from the Cisco 6509 to the 7206 VXR.
> The 6509 has a successful BGP session established with another router,
> Cisco 7606 w/ Sup720-3bxls.  The 7606 and 7206 VXR are connected
> together by a Cisco 3550 switch. In order for the 6509 to establish
the
> IBGP session to the 7606, it has to pass through two DS-3s, go through
> the 7206 VXR, out the Fast E, through the Cisco 3550, and then to the
> 7606. I checked the MTUs on the 3550s and I am seeing the Fast E
> interfaces are still showing 1500 bytes. Would increasing the MTU size
> on the switches cause any harm? 

As other people have said, this definitely sounds like an MTU problem. 
Basically you're trying to pass 4470 byte BGP packets over a link that
drops anything bigger than 1500. The session will establish because all
the setup packets are small, but the tcp session will stall as soon as
you try to send routes across it.

What should be happening here is the 6509 will generate a 4470 byte
packet because it sees the directly connected interface as a DS3 and
doesn't know the path is incapable of supporting > 1500 bytes end to
end. The layer 3 device on the mtu choke point, in this case the faste
interface on the 7206vxr, should be configured to a 1500 byte mtu. This
will cause the 7206vxr to generate an ICMP neegfrag when the 4470 byte
packet comes along, and cause path mtu discovery to lower the MSS on the
IBGP session. Either a) you have the mtu misconfigured on that 7206vxr
port, b) your router is misconfigured not to generate the icmp, c)
something in the middle is misconfigured to filter this necessary icmp
packet, or d) some other screwup probably related to one of the above.

Generally speaking increasing the MTU size on a switch can never hurt
anything, but having an insufficiently large MTU on the switch is what
will break you the most (as is happening here). The problem occurs when
you increase the MTU on the layer 3 routers to something beyond what the
layer 2 link in the middle is capable of supporting. Layer 3 devices
will either fragment (deprecated) or generate ICMP NeedFrags which will
cause path MTU discovery to shrink the MSS. Layer 2 devices are
incapable of doing this, so you MUST NOT set the layer 3 MTU above what
the layer 2 link is capable of handling.

Now that said, increasing the mtu on the 3550 won't work here because
3550 MTU support is terrible. The only option you have is to configure
the MTU of all interfaces to 1546 with the "system mtu 1546" command,
followed by a reload. This is not big enough to pass your 4470 byte
packets, and will also break any MTU dependent configuration you might
be running. For example, after you do this, any OSPF speakers on your
3550 will have to have their MTUs adjusted as well, or OSPF will not
come back up due to the interface mismatch. For more details see:

http://www.cisco.com/en/US/products/hw/switches/ps700/products_configura
tion_example09186a008010edab.shtml#c4

Your best bet (in order of most preferable to least) is to a) fix
whatever is breaking path mtu discovery on the 7206vxr in the first
place, b) force the mss of the ibgp session to something under 1460, or
c) lower the mtu on the ds3 interface to 1500.

-- 
Richard A Steenbergen 
http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1
2CBC)




From ras at e-gerbil.net  Wed Sep 16 20:58:47 2009
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Wed, 16 Sep 2009 20:58:47 -0500
Subject: 
In-Reply-To: <9F285BFE1D7757499D9FF095B4EE347D0449C3C1@tw-xchange01.TWC.local>
References: <20090916190705.GU51443@gerbil.cluepon.net>
	<9F285BFE1D7757499D9FF095B4EE347D0449C3C1@tw-xchange01.TWC.local>
Message-ID: <20090917015847.GC51443@gerbil.cluepon.net>

On Wed, Sep 16, 2009 at 06:47:10PM -0500, Michael Ruiz wrote:
> >Either a) you have the mtu misconfigured on that 7206vxr
> 
> That part is where I am at a loss.  How is it the 6509 can establish a
> IBGP session with a 7606 when it has to go through the 7206 VXR?  The
> DS-3s are connected to the 7206 VXR. To add more depth to the story.  I
> have 8 IBGP sessions that are connected to the 7206 VXR that have been
> up and running for over a year.  Some of the sessions traverse the DS-3s
> and or a GigE long haul connections.  There are a total 10 Core routers
> that are mixture of Cisco 7606, 6509s, 7206 VXR w/ NPE400s or G1s.  Only
> this one IBGP session out of 9 routers is not being established.  Since
> I have a switch between the 7606 and 7206, I plan to put a packet
> capture server and see what I can see. 

And is that the one that traverses the 3550 with the 1500 byte MTU? 
Re-read what we said. You should be able to test the MTU theory by 
disabling path-mtu-discovery, which will cause MSS to fail back to the 
minimum 576.

-- 
Richard A Steenbergen        http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)



From rens at autempspourmoi.be  Wed Sep 16 23:49:37 2009
From: rens at autempspourmoi.be (Rens)
Date: Thu, 17 Sep 2009 06:49:37 +0200
Subject: BGP question
Message-ID: <75DCC067ECAD4A83A191968F2D46999E@EU.corp.clearwire.com>

Hi all,

 

I'm having difficulties to understand why I am not advertising a certain
customer range to my upstream.

I can see this range in my BGP table 3 times.

 

show ip bgp customer_range 

Number of BGP Routes matching display condition : 3

Status codes: s suppressed, d damped, h history, * valid, > best, i internal

Origin codes: i - IGP, e - EGP, ? - incomplete

    Network                    Next Hop                       Metric
LocPrf   Weight Path

*>i customer_range        Local IX                                     110
0          XXXX YYYY i

*   customer_range         upstream provider                       100
0          AAAA BBBB  XXXX YYYY i

*   customer_range         my customer                 0          120
0          YYYY YYYY i

       Last update to IP routing table: 0h23m34s, 1 path(s) installed:

       Route is not advertised to any peers

 

customer_range = each time the same /24

 

But it seems to choose the set the one as local IX as best.

When I disable local IX it sets the one with my upstream provider as best.

 

Shouldn't it set the customer_range I receive from my customer as best since
it's highest local pref and advertise it to my upstream provider peer?

 

Regards,

 

Rens

 

 



From ras at e-gerbil.net  Thu Sep 17 01:32:56 2009
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Thu, 17 Sep 2009 01:32:56 -0500
Subject: BGP question
In-Reply-To: <75DCC067ECAD4A83A191968F2D46999E@EU.corp.clearwire.com>
References: <75DCC067ECAD4A83A191968F2D46999E@EU.corp.clearwire.com>
Message-ID: <20090917063256.GE51443@gerbil.cluepon.net>

On Thu, Sep 17, 2009 at 06:49:37AM +0200, Rens wrote:
> *>i customer_range        Local IX                                     110
> 0          XXXX YYYY i
> *   customer_range         upstream provider                       100
> 0          AAAA BBBB  XXXX YYYY i
> *   customer_range         my customer                 0          120
> 0          YYYY YYYY i
> 
>        Last update to IP routing table: 0h23m34s, 1 path(s) installed:
>        Route is not advertised to any peers
> 
...
> But it seems to choose the set the one as local IX as best.
> 
> When I disable local IX it sets the one with my upstream provider as best.
> 
> Shouldn't it set the customer_range I receive from my customer as best since
> it's highest local pref and advertise it to my upstream provider peer?

Yes, which means there must be something else wrong with that route to
keep it from getting installed as best path. That CLI output smells like
Foundry, and I don't remember exactly how it would show up, but on Cisco
for example "show ip bgp" not only shows your rib but also the adj rib
in for neighbors which have soft-reconfig enabled. This would show up as
(received) but not say "used", though again I'm not sure if Foundry does
this or how it would show up.

If you aren't doing something silly like outright rejecting the route in
the route-map or prefix-list on the neighbor, make sure the next-hop is
valid and reachable. IIRC Foundry doesn't do bgp next-hop recursion by
default, you have to manually enable it. If I remember my Foundry BGP
correctly (despite many years and a lot of therapy trying to repress
those memories) you can see more details with "show ip bgp routes detail
x.x.x.x".

-- 
Richard A Steenbergen        http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)



From rens at autempspourmoi.be  Thu Sep 17 01:55:16 2009
From: rens at autempspourmoi.be (Rens)
Date: Thu, 17 Sep 2009 08:55:16 +0200
Subject: BGP question
In-Reply-To: <20090917063256.GE51443@gerbil.cluepon.net>
References: <75DCC067ECAD4A83A191968F2D46999E@EU.corp.clearwire.com>
	<20090917063256.GE51443@gerbil.cluepon.net>
Message-ID: <91735095617B4BBC8FF14789E3C10645@EU.corp.clearwire.com>

That routes detail command doesn't really give me that much extra info over
the other one.

Could it be that my import at RIPE for my customer AS is set to action
pref=100 instead of 120 is causing this?

Regards,

Rens
-----Original Message-----
From: Richard A Steenbergen [mailto:ras at e-gerbil.net] 
Sent: jeudi 17 septembre 2009 8:33
To: Rens
Cc: nanog at nanog.org
Subject: Re: BGP question

On Thu, Sep 17, 2009 at 06:49:37AM +0200, Rens wrote:
> *>i customer_range        Local IX                                     110
> 0          XXXX YYYY i
> *   customer_range         upstream provider                       100
> 0          AAAA BBBB  XXXX YYYY i
> *   customer_range         my customer                 0          120
> 0          YYYY YYYY i
> 
>        Last update to IP routing table: 0h23m34s, 1 path(s) installed:
>        Route is not advertised to any peers
> 
...
> But it seems to choose the set the one as local IX as best.
> 
> When I disable local IX it sets the one with my upstream provider as best.
> 
> Shouldn't it set the customer_range I receive from my customer as best
since
> it's highest local pref and advertise it to my upstream provider peer?

Yes, which means there must be something else wrong with that route to
keep it from getting installed as best path. That CLI output smells like
Foundry, and I don't remember exactly how it would show up, but on Cisco
for example "show ip bgp" not only shows your rib but also the adj rib
in for neighbors which have soft-reconfig enabled. This would show up as
(received) but not say "used", though again I'm not sure if Foundry does
this or how it would show up.

If you aren't doing something silly like outright rejecting the route in
the route-map or prefix-list on the neighbor, make sure the next-hop is
valid and reachable. IIRC Foundry doesn't do bgp next-hop recursion by
default, you have to manually enable it. If I remember my Foundry BGP
correctly (despite many years and a lot of therapy trying to repress
those memories) you can see more details with "show ip bgp routes detail
x.x.x.x".

-- 
Richard A Steenbergen        http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)




From devangnp at gmail.com  Thu Sep 17 02:30:30 2009
From: devangnp at gmail.com (Devangnp)
Date: Thu, 17 Sep 2009 01:30:30 -0600
Subject: PPPOE design
Message-ID: <0272BA25-0319-4D56-94E0-19EA83D6EDC1@gmail.com>

Hi,

Any design consideration on PPPoE agg & routing? Any good example of  
covering multiple customers or subnets ?

Thanks,
Devang Patel



From jzp-sc at rsuc.gweep.net  Thu Sep 17 07:07:20 2009
From: jzp-sc at rsuc.gweep.net (Joe Provo)
Date: Thu, 17 Sep 2009 08:07:20 -0400
Subject: [NANOG-announce] 2009 Elections Update
Message-ID: <20090917120719.GA3304@gweep.net>


Hi NANOGers,

Thanks to everyone who has thrown their hat into the ring for the 
NANOG Steering Committee!  If you were nominated and had not yet 
sent in your bio or confirmation, please take a moment today to 
do so by sending mail to .  For the list,
see
http://www.nanog.org/governance/elections/2009elections/2009sc_candidates.php

As Dave posted previously, the PC nominations are currently open.
If you think you or someone you know could help continue to improve
the conference, send your nominations to .
After the election, the new Steering Committee will appoint people
to fill the vacant slots.  The current slate of nominees are posted
here
http://www.nanog.org/governance/elections/2009elections/2009pc_candidates.php

For more information, please check out the 2009 elections page:
    http://www.nanog.org/governance/elections/2009elections/
 

IMPORTANT DATES
Mon 2009-09-28 	MLC nominations open
Mon 2009-09-28 	Charter draft amendments posted to NANOG website
Tue 2009-10-06 	Ballot confirmed and finalized at NANOG SC meeting
Sun 2009-10-18 	Voting for the 2009/2010 NANOG SC opens 
Mon 2009-10-19 	PC nominations close, candidate information posted
Wed 2009-10-21 	Voting for the 2009/2010 NANOG SC closes 
Thu 2009-10-22 	SC appoints new PC
Thu 2009-10-29 	MLC nominations close, candidate information posted
Tue 2009-11-03 	SC appoints new MLC


Cheers!

Joe Provo
for the NANOG Steering Committee

-- 
             RSUC / GweepNet / Spunk / FnB / Usenix / SAGE

_______________________________________________
NANOG-announce mailing list
NANOG-announce at nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce



From mruiz at telwestservices.com  Thu Sep 17 07:46:46 2009
From: mruiz at telwestservices.com (Michael Ruiz)
Date: Thu, 17 Sep 2009 07:46:46 -0500
Subject: 
Message-ID: <0af101ca3794$ec316f3a$610a0a0a@TWC.local>

And is that the one that traverses the 3550 with the 1500 byte MTU? 

Both connection traver through the 3550. I will disable the command on 7206 vxr. thanks

-----Original Message-----
From: "Richard A Steenbergen" 
To: "Michael Ruiz" 
Cc: "Brian Dickson" ; "nanog at nanog.org" 
Sent: 9/16/09 8:58 PM
Subject: Re: 

On Wed, Sep 16, 2009 at 06:47:10PM -0500, Michael Ruiz wrote:
> >Either a) you have the mtu misconfigured on that 7206vxr
> 
> That part is where I am at a loss.  How is it the 6509 can establish a
> IBGP session with a 7606 when it has to go through the 7206 VXR?  The
> DS-3s are connected to the 7206 VXR. To add more depth to the story.  I
> have 8 IBGP sessions that are connected to the 7206 VXR that have been
> up and running for over a year.  Some of the sessions traverse the DS-3s
> and or a GigE long haul connections.  There are a total 10 Core routers
> that are mixture of Cisco 7606, 6509s, 7206 VXR w/ NPE400s or G1s.  Only
> this one IBGP session out of 9 routers is not being established.  Since
> I have a switch between the 7606 and 7206, I plan to put a packet
> capture server and see what I can see. 

And is that the one that traverses the 3550 with the 1500 byte MTU? 
Re-read what we said. You should be able to test the MTU theory by 
disabling path-mtu-discovery, which will cause MSS to fail back to the 
minimum 576.

-- 
Richard A Steenbergen        http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)



From truman at suspicious.org  Thu Sep 17 08:49:30 2009
From: truman at suspicious.org (Truman Boyes)
Date: Thu, 17 Sep 2009 23:49:30 +1000
Subject: PPPOE design
In-Reply-To: <0272BA25-0319-4D56-94E0-19EA83D6EDC1@gmail.com>
References: <0272BA25-0319-4D56-94E0-19EA83D6EDC1@gmail.com>
Message-ID: 

Hi,

PPPoX connections terminated on BRAS/BNG devices will use AAA, and  
therefore you can assign whatever routes you want to the customer with  
RADIUS VSAs. Typically you will aggregate or null routes for your dhcp  
or ppp local pools, and then a policy to advertise these routes via  
BGP to the rest of your network.

If some customers get static /32's for inet4 pppoe you would then also  
want to export the local/access routes into BGP. I would suggest using  
a different network range for static customers so you can better  
control your route advertisements.

Kind regards,
Truman


On 17/09/2009, at 5:30 PM, Devangnp wrote:

> Hi,
>
> Any design consideration on PPPoE agg & routing? Any good example of  
> covering multiple customers or subnets ?
>
> Thanks,
> Devang Patel
>




From mruiz at telwestservices.com  Thu Sep 17 09:17:00 2009
From: mruiz at telwestservices.com (Michael Ruiz)
Date: Thu, 17 Sep 2009 09:17:00 -0500
Subject: 
In-Reply-To: <0af101ca3794$ec316f3a$610a0a0a@TWC.local>
References: <0af101ca3794$ec316f3a$610a0a0a@TWC.local>
Message-ID: <9F285BFE1D7757499D9FF095B4EE347D0449C466@tw-xchange01.TWC.local>

Oh you guys are going to love this...Before I could send out the maintenance notification for tonight to make changes,  The session has been up for 21 hours.  This is before I could put a packet capture server on the segment.   


  BGP state = Established, up for 21:29:25
  Last read 00:00:24, last write 00:00:02, hold time is 180, keepalive interval is 60 seconds
  Neighbor capabilities:


-----Original Message-----
From: Michael Ruiz 
Sent: Thursday, September 17, 2009 7:47 AM
To: Richard A Steenbergen; Michael Ruiz
Cc: Brian Dickson; nanog at nanog.org
Subject: RE: 

And is that the one that traverses the 3550 with the 1500 byte MTU? 

Both connection traver through the 3550. I will disable the command on 7206 vxr. thanks

-----Original Message-----
From: "Richard A Steenbergen" 
To: "Michael Ruiz" 
Cc: "Brian Dickson" ; "nanog at nanog.org" 
Sent: 9/16/09 8:58 PM
Subject: Re: 

On Wed, Sep 16, 2009 at 06:47:10PM -0500, Michael Ruiz wrote:
> >Either a) you have the mtu misconfigured on that 7206vxr
> 
> That part is where I am at a loss.  How is it the 6509 can establish a
> IBGP session with a 7606 when it has to go through the 7206 VXR?  The
> DS-3s are connected to the 7206 VXR. To add more depth to the story.  I
> have 8 IBGP sessions that are connected to the 7206 VXR that have been
> up and running for over a year.  Some of the sessions traverse the DS-3s
> and or a GigE long haul connections.  There are a total 10 Core routers
> that are mixture of Cisco 7606, 6509s, 7206 VXR w/ NPE400s or G1s.  Only
> this one IBGP session out of 9 routers is not being established.  Since
> I have a switch between the 7606 and 7206, I plan to put a packet
> capture server and see what I can see. 

And is that the one that traverses the 3550 with the 1500 byte MTU? 
Re-read what we said. You should be able to test the MTU theory by 
disabling path-mtu-discovery, which will cause MSS to fail back to the 
minimum 576.

-- 
Richard A Steenbergen        http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

From ras at e-gerbil.net  Thu Sep 17 13:11:11 2009
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Thu, 17 Sep 2009 13:11:11 -0500
Subject: 
In-Reply-To: <9F285BFE1D7757499D9FF095B4EE347D0449C466@tw-xchange01.TWC.local>
References: <0af101ca3794$ec316f3a$610a0a0a@TWC.local>
	<9F285BFE1D7757499D9FF095B4EE347D0449C466@tw-xchange01.TWC.local>
Message-ID: <20090917181111.GH51443@gerbil.cluepon.net>

On Thu, Sep 17, 2009 at 09:17:00AM -0500, Michael Ruiz wrote:
> Oh you guys are going to love this...Before I could send out the maintenance notification for tonight to make changes,  The session has been up for 21 hours.  This is before I could put a packet capture server on the segment.   
> 
> 
>   BGP state = Established, up for 21:29:25
>   Last read 00:00:24, last write 00:00:02, hold time is 180, keepalive interval is 60 seconds
>   Neighbor capabilities:

You don't need to use an external sniffer, you can use "debug ip packet"
to see traffic being punted to the control plane, or in the case of the
6500 you can use ELAM or ERSPAN (though this is probably a little bit on
the advanced side). If this was an MTU mismatch a sniffer wouldn't
reveal anything other than missing packets anyways, which you could just
as easily deduce from a debug or looking at the retransmit counters on
the bgp neighbor.

http://cisco.cluepon.net/index.php/Using_capture_buffer_with_ELAM
http://cisco.cluepon.net/index.php/6500_SPAN_the_RP

My money is still on MTU mismatch. Assume the simplest and most likely 
explanation until proved otherwise.

-- 
Richard A Steenbergen        http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)



From mruiz at telwestservices.com  Thu Sep 17 13:41:55 2009
From: mruiz at telwestservices.com (Michael Ruiz)
Date: Thu, 17 Sep 2009 13:41:55 -0500
Subject: 
In-Reply-To: <20090917181111.GH51443@gerbil.cluepon.net>
References: <0af101ca3794$ec316f3a$610a0a0a@TWC.local>
	<9F285BFE1D7757499D9FF095B4EE347D0449C466@tw-xchange01.TWC.local>
	<20090917181111.GH51443@gerbil.cluepon.net>
Message-ID: <9F285BFE1D7757499D9FF095B4EE347D0449C6AC@tw-xchange01.TWC.local>

>http://cisco.cluepon.net/index.php/Using_capture_buffer_with_ELAM
>http://cisco.cluepon.net/index.php/6500_SPAN_the_RP

Well even the IBGP session came up on its own now and has been up for 1
day and 1 hour, I can honestly say this is bizarre situation.  I will
use the above links if something like this or weird happens.  Thank you
all. 

-----Original Message-----
From: Richard A Steenbergen [mailto:ras at e-gerbil.net] 
Sent: Thursday, September 17, 2009 1:11 PM
To: Michael Ruiz
Cc: Brian Dickson; nanog at nanog.org
Subject: Re: 

On Thu, Sep 17, 2009 at 09:17:00AM -0500, Michael Ruiz wrote:
> Oh you guys are going to love this...Before I could send out the
maintenance notification for tonight to make changes,  The session has
been up for 21 hours.  This is before I could put a packet capture
server on the segment.   
> 
> 
>   BGP state = Established, up for 21:29:25
>   Last read 00:00:24, last write 00:00:02, hold time is 180, keepalive
interval is 60 seconds
>   Neighbor capabilities:

You don't need to use an external sniffer, you can use "debug ip packet"
to see traffic being punted to the control plane, or in the case of the
6500 you can use ELAM or ERSPAN (though this is probably a little bit on
the advanced side). If this was an MTU mismatch a sniffer wouldn't
reveal anything other than missing packets anyways, which you could just
as easily deduce from a debug or looking at the retransmit counters on
the bgp neighbor.

http://cisco.cluepon.net/index.php/Using_capture_buffer_with_ELAM
http://cisco.cluepon.net/index.php/6500_SPAN_the_RP

My money is still on MTU mismatch. Assume the simplest and most likely 
explanation until proved otherwise.

-- 
Richard A Steenbergen 
http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1
2CBC)



From davekm3t at gmail.com  Thu Sep 17 14:03:55 2009
From: davekm3t at gmail.com (Dave Pascoe)
Date: Thu, 17 Sep 2009 15:03:55 -0400
Subject: Contact w/ clue re: AT&T SMS email gateway?
Message-ID: <4AB2881B.5090103@gmail.com>

Recently something seems to have changed with the @txt.att.net email to
SMS gateway.  Messages sent through the gateway suffer from the following:

1) Long delay in reaching the phone (intermittent)
   (yes I know there is no latency guarantee)

and, even more crippling,

2) Message comes through as just "SMS Message" instead of the SMTP
message content.  And the sender is always 410-000-01x, where x
increments by 1 with each new incoming email-to-SMS gateway-handled message.

Phone is an iPhone 3GS.  This has worked fine for quite a while.  No
changes on the iPhone.

I have gone through normal AT&T Wireless Customer Service but there
isn't much clue there - had to explain what an email to SMS gateway is.

Anyone elese seeing this?  Anyone from AT&T Wireless here?

Please contact me off-list.

TIA,
Dave Pascoe



From sethm at rollernet.us  Thu Sep 17 14:59:19 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 17 Sep 2009 12:59:19 -0700
Subject: Contact w/ clue re: AT&T SMS email gateway?
In-Reply-To: <4AB2881B.5090103@gmail.com>
References: <4AB2881B.5090103@gmail.com>
Message-ID: <4AB29517.5080503@rollernet.us>

Dave Pascoe wrote:
> Recently something seems to have changed with the @txt.att.net email to
> SMS gateway.  Messages sent through the gateway suffer from the following:
> 
> 1) Long delay in reaching the phone (intermittent)
>    (yes I know there is no latency guarantee)
> 
> and, even more crippling,
> 
> 2) Message comes through as just "SMS Message" instead of the SMTP
> message content.  And the sender is always 410-000-01x, where x
> increments by 1 with each new incoming email-to-SMS gateway-handled message.
> 
> Phone is an iPhone 3GS.  This has worked fine for quite a while.  No
> changes on the iPhone.
> 
> I have gone through normal AT&T Wireless Customer Service but there
> isn't much clue there - had to explain what an email to SMS gateway is.
> 
> Anyone elese seeing this?  Anyone from AT&T Wireless here?
> 

I've had better luck with SNPP (Simple Network Paging Protocol) these
days and completely abandoned anything using SMTP gateways. Better
delivery performance in my experience than the SMTP gateways, but the
sender always shows up as "1600". I use Sprint.

~Seth



From Crist.Clark at globalstar.com  Thu Sep 17 15:31:51 2009
From: Crist.Clark at globalstar.com (Crist Clark)
Date: Thu, 17 Sep 2009 13:31:51 -0700
Subject: Contact w/ clue re: AT&T SMS email gateway?
In-Reply-To: <4AB2881B.5090103@gmail.com>
References: <4AB2881B.5090103@gmail.com>
Message-ID: <4AB23A44.33E4.0097.0@globalstar.com>

>>> On 9/17/2009 at 12:03 PM, Dave Pascoe  wrote:
> Recently something seems to have changed with the @txt.att.net email to
> SMS gateway.  Messages sent through the gateway suffer from the following:
> 
> 1) Long delay in reaching the phone (intermittent)
>    (yes I know there is no latency guarantee)
> 
> and, even more crippling,
> 
> 2) Message comes through as just "SMS Message" instead of the SMTP
> message content.  And the sender is always 410-000-01x, where x
> increments by 1 with each new incoming email-to-SMS gateway-handled message.
> 
> Phone is an iPhone 3GS.  This has worked fine for quite a while.  No
> changes on the iPhone.
> 
> I have gone through normal AT&T Wireless Customer Service but there
> isn't much clue there - had to explain what an email to SMS gateway is.
> 
> Anyone elese seeing this?  Anyone from AT&T Wireless here?

If you do find anyone, can you ask them about the really annoying
reject-after-DATA problem?

That is, if 555-555-1234, for some reason is not authorized to receive
SMS, you get a 250 response after RCPT TO, but a 5xx after the DATA
is sent. So if the message had multiple recipients, some of which are
allowed to receive SMS, the message then fails for all of them.

Verizon also has this problem, BTW.




From mike at m5computersecurity.com  Thu Sep 17 16:45:36 2009
From: mike at m5computersecurity.com (Michael J McCafferty)
Date: Thu, 17 Sep 2009 14:45:36 -0700
Subject: cross connect reliability
Message-ID: <1253223936.6803.391.camel@mike-desktop>

All,
	Today I had yet another cross-connect fail at our colo provider. From
memory, this is the 6th cross-connect to fail while in service, in 4yrs
and recently there was a bad SFP on their end as well. This seemes like
a high failure rate to me. When I asked about the high failure rate,
they said that they run a lot of cables and there is a lot of jiggling
and wiggling... lots of chances to get bent out of whack from activity
near my patches and cables.
	Until a few years ago my time was spent mostly in single tenant data
centers, and it may be true that we made fewer cabling changes and made
less of a ruckus when cabling... but this still seems like a pretty high
failure rate at the colo.
	I am curious; what do you expect the average reliability of your FastE
or GigE copper cross-connects at a colo?

Thanks,
Mike

-- 
************************************************************
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 sethm at rollernet.us  Thu Sep 17 16:52:47 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 17 Sep 2009 14:52:47 -0700
Subject: cross connect reliability
In-Reply-To: <1253223936.6803.391.camel@mike-desktop>
References: <1253223936.6803.391.camel@mike-desktop>
Message-ID: <4AB2AFAF.50900@rollernet.us>

Michael J McCafferty wrote:
> All,
> 	Today I had yet another cross-connect fail at our colo provider. From
> memory, this is the 6th cross-connect to fail while in service, in 4yrs
> and recently there was a bad SFP on their end as well. This seemes like
> a high failure rate to me. When I asked about the high failure rate,
> they said that they run a lot of cables and there is a lot of jiggling
> and wiggling... lots of chances to get bent out of whack from activity
> near my patches and cables.
> 	Until a few years ago my time was spent mostly in single tenant data
> centers, and it may be true that we made fewer cabling changes and made
> less of a ruckus when cabling... but this still seems like a pretty high
> failure rate at the colo.
> 	I am curious; what do you expect the average reliability of your FastE
> or GigE copper cross-connects at a colo?
> 

Never to fail? Seriously; if you're talking about a passive connection
(optical or electrical) like a patch panel, I'd expect it to keep going
forever unless someone damages it.

~Seth



From nenolod at systeminplace.net  Thu Sep 17 16:57:34 2009
From: nenolod at systeminplace.net (William Pitcock)
Date: Thu, 17 Sep 2009 21:57:34 +0000
Subject: cross connect reliability
Message-ID: <2112743169-1253224450-cardhu_decombobulator_blackberry.rim.net-1158245689-@bda146.bisx.prod.on.blackberry>

We have never had a xconnect fail, ever.  And we have several.  This is over a 6 year period.

William
------Original Message------
From: Michael J McCafferty
To: nanog
Subject: cross connect reliability
Sent: Sep 17, 2009 4:45 PM

All,
	Today I had yet another cross-connect fail at our colo provider. From
memory, this is the 6th cross-connect to fail while in service, in 4yrs
and recently there was a bad SFP on their end as well. This seemes like
a high failure rate to me. When I asked about the high failure rate,
they said that they run a lot of cables and there is a lot of jiggling
and wiggling... lots of chances to get bent out of whack from activity
near my patches and cables.
	Until a few years ago my time was spent mostly in single tenant data
centers, and it may be true that we made fewer cabling changes and made
less of a ruckus when cabling... but this still seems like a pretty high
failure rate at the colo.
	I am curious; what do you expect the average reliability of your FastE
or GigE copper cross-connects at a colo?

Thanks,
Mike

-- 
************************************************************
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
************************************************************




-- 
William Pitcock
SystemInPlace - Simple Hosting Solutions
1-866-519-6149

From dhubbard at dino.hostasaurus.com  Thu Sep 17 16:54:35 2009
From: dhubbard at dino.hostasaurus.com (David Hubbard)
Date: Thu, 17 Sep 2009 17:54:35 -0400
Subject: cross connect reliability
Message-ID: 

From: Michael J McCafferty [mailto:mike at m5computersecurity.com] 
> 
> All,
> 	Today I had yet another cross-connect fail at our colo 
> provider. From memory, this is the 6th cross-connect to
> fail while in service, in 4yrs and recently there was a
> bad SFP on their end as well. This seemes like a high
> failure rate to me. When I asked about the high failure
> rate, they said that they run a lot of cables and there
> is a lot of jiggling and wiggling... lots of chances to
> get bent out of whack from activity near my patches and
> cables.

> 	I am curious; what do you expect the average 
> reliability of your FastE
> or GigE copper cross-connects at a colo?

You're seeing these failures on copper?!  I've
worked in some places with absolute cabling
nightmares on the copper side of things in wiring
closets but those were all enterprise situations
and we still rarely had failures of ports and even
less on the wiring itself.  I'd never expect there
to be frequent copper issues in a colo where you
would not have anywhere near the volume of moving
cables around that goes on in an enterprise.

On the fiber side, your experience still seems high
although obviously much easier to damage fiber
cables.  Perhaps they have a big mess of a fiber
plant and have to fish tape new runs through it
and like to snag adjacent cables, etc.  It can only
get worse if that's the problem and they don't
clean it up.

David



From mksmith at adhost.com  Thu Sep 17 16:54:49 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Thu, 17 Sep 2009 14:54:49 -0700
Subject: cross connect reliability
In-Reply-To: <1253223936.6803.391.camel@mike-desktop>
References: <1253223936.6803.391.camel@mike-desktop>
Message-ID: <17838240D9A5544AAA5FF95F8D52031606AFCC31@ad-exh01.adhost.lan>

Hello Michael:

> -----Original Message-----
> From: Michael J McCafferty [mailto:mike at m5computersecurity.com]
> Sent: Thursday, September 17, 2009 2:46 PM
> To: nanog
> Subject: cross connect reliability
> 
> All,
> 	Today I had yet another cross-connect fail at our colo provider.
> From
> memory, this is the 6th cross-connect to fail while in service, in
4yrs
> and recently there was a bad SFP on their end as well. This seemes
like
> a high failure rate to me. When I asked about the high failure rate,
> they said that they run a lot of cables and there is a lot of jiggling
> and wiggling... lots of chances to get bent out of whack from activity
> near my patches and cables.
> 	Until a few years ago my time was spent mostly in single tenant
> data
> centers, and it may be true that we made fewer cabling changes and
made
> less of a ruckus when cabling... but this still seems like a pretty
> high
> failure rate at the colo.
> 	I am curious; what do you expect the average reliability of your
> FastE
> or GigE copper cross-connects at a colo?
> 
> Thanks,
> Mike
> 
I agree with their Reason for Outage, but it sounds like a design issue.
We prewire all of our switches to patch panels so they don't get touched
once they're installed.  The patch panels are much more friendly to
insertions and removals than a 48 port 1-U switch.  We also have
multiple connections on the fiber side to avoid those failures.  With
all of that, we still have failures, but their effect and frequency are
minimized.

Mike

--
Michael K. Smith - CISSP, GISP
Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)





From abalashov at evaristesys.com  Thu Sep 17 16:57:09 2009
From: abalashov at evaristesys.com (Alex Balashov)
Date: Thu, 17 Sep 2009 17:57:09 -0400
Subject: cross connect reliability
In-Reply-To: <4AB2AFAF.50900@rollernet.us>
References: <1253223936.6803.391.camel@mike-desktop>
	<4AB2AFAF.50900@rollernet.us>
Message-ID: <4AB2B0B5.4040106@evaristesys.com>

Seth Mattinen wrote:
> Michael J McCafferty wrote:
>> All,
>> 	Today I had yet another cross-connect fail at our colo provider. From
>> memory, this is the 6th cross-connect to fail while in service, in 4yrs
>> and recently there was a bad SFP on their end as well. This seemes like
>> a high failure rate to me. When I asked about the high failure rate,
>> they said that they run a lot of cables and there is a lot of jiggling
>> and wiggling... lots of chances to get bent out of whack from activity
>> near my patches and cables.
>> 	Until a few years ago my time was spent mostly in single tenant data
>> centers, and it may be true that we made fewer cabling changes and made
>> less of a ruckus when cabling... but this still seems like a pretty high
>> failure rate at the colo.
>> 	I am curious; what do you expect the average reliability of your FastE
>> or GigE copper cross-connects at a colo?
>>
> 
> Never to fail? Seriously; if you're talking about a passive connection
> (optical or electrical) like a patch panel, I'd expect it to keep going
> forever unless someone damages it.

That's truly wishful thinking, as are the assumptions that insulate it 
from damaging factors.  Nothing lasts forever.

-- 
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671



From tme at americafree.tv  Thu Sep 17 16:59:34 2009
From: tme at americafree.tv (Marshall Eubanks)
Date: Thu, 17 Sep 2009 17:59:34 -0400
Subject: cross connect reliability
In-Reply-To: <4AB2AFAF.50900@rollernet.us>
References: <1253223936.6803.391.camel@mike-desktop>
	<4AB2AFAF.50900@rollernet.us>
Message-ID: <7C79FE41-AA98-40C5-BBC6-EB0FD919A91B@americafree.tv>


On Sep 17, 2009, at 5:52 PM, Seth Mattinen wrote:

> Michael J McCafferty wrote:
>> All,
>> 	Today I had yet another cross-connect fail at our colo provider.  
>> From
>> memory, this is the 6th cross-connect to fail while in service, in  
>> 4yrs
>> and recently there was a bad SFP on their end as well. This seemes  
>> like
>> a high failure rate to me. When I asked about the high failure rate,
>> they said that they run a lot of cables and there is a lot of  
>> jiggling
>> and wiggling... lots of chances to get bent out of whack from  
>> activity
>> near my patches and cables.
>> 	Until a few years ago my time was spent mostly in single tenant data
>> centers, and it may be true that we made fewer cabling changes and  
>> made
>> less of a ruckus when cabling... but this still seems like a pretty  
>> high
>> failure rate at the colo.
>> 	I am curious; what do you expect the average reliability of your  
>> FastE
>> or GigE copper cross-connects at a colo?
>>
>
> Never to fail? Seriously; if you're talking about a passive connection
> (optical or electrical) like a patch panel, I'd expect it to keep  
> going
> forever unless someone damages it.
>

Or until someone pulls out the wrong cable (which has happened to me).

Regards
Marshall


> ~Seth
>
>




From lists at mtin.net  Thu Sep 17 17:17:46 2009
From: lists at mtin.net (Justin Wilson - MTIN)
Date: Thu, 17 Sep 2009 18:17:46 -0400
Subject: cross connect reliability
In-Reply-To: <1253223936.6803.391.camel@mike-desktop>
Message-ID: 


From: Michael J McCafferty 
Organization: M5Hosting
Date: Thu, 17 Sep 2009 14:45:36 -0700
To: nanog 
Subject: cross connect reliability

All,
 Today I had yet another cross-connect fail at our colo provider. From
memory, this is the 6th cross-connect to fail while in service, in 4yrs
and recently there was a bad SFP on their end as well. This seemes like
a high failure rate to me. When I asked about the high failure rate,
they said that they run a lot of cables and there is a lot of jiggling
and wiggling... lots of chances to get bent out of whack from activity
near my patches and cables.
 Until a few years ago my time was spent mostly in single tenant data
centers, and it may be true that we made fewer cabling changes and made
less of a ruckus when cabling... but this still seems like a pretty high
failure rate at the colo.
 I am curious; what do you expect the average reliability of your FastE
or GigE copper cross-connects at a colo?

Thanks,
Mike



    Does the colo let anyone run cables or do they have approved
contractors?    It sounds like a design issue to me in the way the cables
are treated.  In 4 years at a busy colo we have had one copper cross connect
not act right.  It would pass data but was flaky.  We replaced it because it
was an easy run just to rule it out.

    I am assuming your are in shared space.  If so I would investigate your
weak points (which I am sure you already are doing).
    
    Justin



From sethm at rollernet.us  Thu Sep 17 17:21:13 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 17 Sep 2009 15:21:13 -0700
Subject: cross connect reliability
In-Reply-To: <4AB2B0B5.4040106@evaristesys.com>
References: <1253223936.6803.391.camel@mike-desktop>
	<4AB2AFAF.50900@rollernet.us> <4AB2B0B5.4040106@evaristesys.com>
Message-ID: <4AB2B659.6040801@rollernet.us>

Alex Balashov wrote:
> Seth Mattinen wrote:
>> Michael J McCafferty wrote:
>>> All,
>>>     Today I had yet another cross-connect fail at our colo provider.
>>> From
>>> memory, this is the 6th cross-connect to fail while in service, in 4yrs
>>> and recently there was a bad SFP on their end as well. This seemes like
>>> a high failure rate to me. When I asked about the high failure rate,
>>> they said that they run a lot of cables and there is a lot of jiggling
>>> and wiggling... lots of chances to get bent out of whack from activity
>>> near my patches and cables.
>>>     Until a few years ago my time was spent mostly in single tenant data
>>> centers, and it may be true that we made fewer cabling changes and made
>>> less of a ruckus when cabling... but this still seems like a pretty high
>>> failure rate at the colo.
>>>     I am curious; what do you expect the average reliability of your
>>> FastE
>>> or GigE copper cross-connects at a colo?
>>>
>>
>> Never to fail? Seriously; if you're talking about a passive connection
>> (optical or electrical) like a patch panel, I'd expect it to keep going
>> forever unless someone damages it.
> 
> That's truly wishful thinking, as are the assumptions that insulate it
> from damaging factors.  Nothing lasts forever.
> 

What the OP is describing is abnormally high in my view.

Based purely on my own personal experience, the structured wiring in my
parent's house I put in in the mid 90's has never suffered a failure, is
still in use today, and it's in a residential environment with dogs and
cats. I'd expect a properly managed environment to fare at least as good
as that.

~Seth




From charles at thewybles.com  Thu Sep 17 17:35:37 2009
From: charles at thewybles.com (Charles Wyble)
Date: Thu, 17 Sep 2009 15:35:37 -0700
Subject: cross connect reliability
In-Reply-To: <7C79FE41-AA98-40C5-BBC6-EB0FD919A91B@americafree.tv>
References: <1253223936.6803.391.camel@mike-desktop>	<4AB2AFAF.50900@rollernet.us>
	<7C79FE41-AA98-40C5-BBC6-EB0FD919A91B@americafree.tv>
Message-ID: <4AB2B9B9.60406@thewybles.com>



Marshall Eubanks wrote:
> 
> On Sep 17, 2009, at 5:52 PM, Seth Mattinen wrote:
> 
>> Michael J McCafferty wrote:
>>> All,
>>>     Today I had yet another cross-connect fail at our colo provider. 
>>> From
>>> memory, this is the 6th cross-connect to fail while in service, in 4yrs
>>> and recently there was a bad SFP on their end as well. This seemes like
>>> a high failure rate to me. When I asked about the high failure rate,
>>> they said that they run a lot of cables and there is a lot of jiggling
>>> and wiggling... lots of chances to get bent out of whack from activity
>>> near my patches and cables.
>>>     Until a few years ago my time was spent mostly in single tenant data
>>> centers, and it may be true that we made fewer cabling changes and made
>>> less of a ruckus when cabling... but this still seems like a pretty high
>>> failure rate at the colo.
>>>     I am curious; what do you expect the average reliability of your 
>>> FastE
>>> or GigE copper cross-connects at a colo?
>>>
>>
>> Never to fail? Seriously; if you're talking about a passive connection
>> (optical or electrical) like a patch panel, I'd expect it to keep going
>> forever unless someone damages it.
>>
> 
> Or until someone pulls out the wrong cable (which has happened to me).
> 

That's not a failure though. It's a disconnection. It happens but is 
readily attributable to a cause.

Random failures of a single ports connectivity.... bizzare and annoying. 
Whole switches? Seen it.
Whole panels? Seen it.
Whole blades? Seen it.

Single port on a switch or patch panel? Never.



From AOsgood at Streamline-Solutions.net  Thu Sep 17 17:35:51 2009
From: AOsgood at Streamline-Solutions.net (Aaron D. Osgood)
Date: Thu, 17 Sep 2009 18:35:51 -0400
Subject: Contact w/ clue re: AT&T SMS email gateway?
In-Reply-To: <4AB2881B.5090103@gmail.com>
References: <4AB2881B.5090103@gmail.com>
Message-ID: <013b01ca37e7$36617490$a3245db0$@net>

>From another list:

" I am not sure if this has anything to do with your client's issue, but ask
if he/she has updated their iPhone software to version 3.1  Apparently, the
following telephony issue was addressed in 3.1:

o	Telephony
CVE-ID: CVE-2009-2815

Available for: iPhone OS 1.0 through 3.0.1

Impact: Receiving a maliciously crafted SMS message may lead to an
unexpected service interruption

Description: A null pointer dereference issue exists in the handling of SMS
arrival notifications. Receiving a maliciously crafted SMS message may lead
to an unexpected service interruption. This update addresses the issue
through improved handling of incoming SMS messages. Credit to Charlie Miller
of Independent Security Evaluators, and Collin Mulliner of Technical
University Berlin for reporting this issue.
Here is the link to Apple's security notice:
http://support.apple.com/kb/HT3860"



Aaron D. Osgood

Streamline Solutions L.L.C

P.O. Box 6115
Falmouth, ME 04105 

TEL: 207-781-5561
FAX: 615-704-8067
MOBILE: 207-831-5829
AOsgood at Streamline-Solutions.net
http://www.streamline-solutions.net

Introducing Efficiency to Business since 1986.


-----Original Message-----
From: Dave Pascoe [mailto:davekm3t at gmail.com] 
Sent: Thursday, September 17, 2009 3:04 PM
To: nanog at nanog.org
Subject: Contact w/ clue re: AT&T SMS email gateway?

Recently something seems to have changed with the @txt.att.net email to
SMS gateway.  Messages sent through the gateway suffer from the following:

1) Long delay in reaching the phone (intermittent)
   (yes I know there is no latency guarantee)

and, even more crippling,

2) Message comes through as just "SMS Message" instead of the SMTP
message content.  And the sender is always 410-000-01x, where x
increments by 1 with each new incoming email-to-SMS gateway-handled message.

Phone is an iPhone 3GS.  This has worked fine for quite a while.  No
changes on the iPhone.

I have gone through normal AT&T Wireless Customer Service but there
isn't much clue there - had to explain what an email to SMS gateway is.

Anyone elese seeing this?  Anyone from AT&T Wireless here?

Please contact me off-list.

TIA,
Dave Pascoe






From deepak at ai.net  Thu Sep 17 17:37:16 2009
From: deepak at ai.net (Deepak Jain)
Date: Thu, 17 Sep 2009 18:37:16 -0400
Subject: cross connect reliability
In-Reply-To: <4AB2B659.6040801@rollernet.us>
References: <1253223936.6803.391.camel@mike-desktop>
	<4AB2AFAF.50900@rollernet.us> <4AB2B0B5.4040106@evaristesys.com>
	<4AB2B659.6040801@rollernet.us>
Message-ID: 


[lots of stuff deleted]. 

We've seen cross-connects fail at sites like "E" and others. Generally speaking, it is a human-error issue and not a component failure one. Either people are being sloppy and aren't reading labels, or the labels aren't there. 

In a cabinet situation, every cabinet does not necessarily home back to its own patch panel, so some trashing may occur -- it can be avoided with good design [cables in the back stay there, etc].

When you are talking about optics failing and they are providing "smart" cross-connects, almost anything is possible. 

The true tell tale is whether you have to call when the cross-connect goes down, or if it just "bounces". Either way, have them take you to their cross-connect room and show you their mess. Once you see it, you'll know what to expect going forward.

Deepak

From rgolodner at infratection.com  Thu Sep 17 17:46:27 2009
From: rgolodner at infratection.com (Richard Golodner)
Date: Thu, 17 Sep 2009 17:46:27 -0500
Subject: cross connect reliability
In-Reply-To: <7C79FE41-AA98-40C5-BBC6-EB0FD919A91B@americafree.tv>
References: <1253223936.6803.391.camel@mike-desktop>
	<4AB2AFAF.50900@rollernet.us>
	<7C79FE41-AA98-40C5-BBC6-EB0FD919A91B@americafree.tv>
Message-ID: <1253227587.11514.70.camel@Andromeda>

On Thu, 2009-09-17 at 17:59 -0400, Marshall Eubanks wrote:
> Or until someone pulls out the wrong cable (which has happened to me).
> 
	Not that I would know from experience, but it is rumored that certain
telco techs in the NYC area can be persuaded to "borrow" other people's
pairs for less than a hundred dollars. 
	
	Richard Golodner




From mikelieman at gmail.com  Thu Sep 17 18:04:17 2009
From: mikelieman at gmail.com (Mike Lieman)
Date: Thu, 17 Sep 2009 19:04:17 -0400
Subject: cross connect reliability
In-Reply-To: <7C79FE41-AA98-40C5-BBC6-EB0FD919A91B@americafree.tv>
References: <1253223936.6803.391.camel@mike-desktop>
	<4AB2AFAF.50900@rollernet.us>
	<7C79FE41-AA98-40C5-BBC6-EB0FD919A91B@americafree.tv>
Message-ID: <43661d390909171604s60344304m98d447c4e5622629@mail.gmail.com>

We have a winner!

On Thu, Sep 17, 2009 at 5:59 PM, Marshall Eubanks wrote:

>
> Or until someone pulls out the wrong cable (which has happened to me).
>
> Regards
> Marshall
>
>
>  ~Seth
>>
>>
>>
>
>


From devangnp at gmail.com  Thu Sep 17 18:13:13 2009
From: devangnp at gmail.com (devang patel)
Date: Thu, 17 Sep 2009 17:13:13 -0600
Subject: MPLS Multi-vrf and IP Multicast
Message-ID: 

Hello All,

Any scenario where we are using MPLS between PE-CE when CE is multi-vrf
router, any deployment in real word? Carrier supporting carrier CSC is one
where you have MPLS between PE-CE link.
If PE-CE running MPLS between them then what will be impact on MULTICAST
between two site?
If PE-CE connectivity is pure IP then i think multicast will work properly
right?

thanks,
Devang Patel


From pete at altadena.net  Thu Sep 17 18:14:06 2009
From: pete at altadena.net (Pete Carah)
Date: Thu, 17 Sep 2009 19:14:06 -0400
Subject: cross connect reliability
In-Reply-To: 
References: <1253223936.6803.391.camel@mike-desktop>	<4AB2AFAF.50900@rollernet.us>
	<4AB2B0B5.4040106@evaristesys.com>	<4AB2B659.6040801@rollernet.us>
	
Message-ID: <4AB2C2BE.8070303@altadena.net>

On 09/17/2009 06:37 PM, Deepak Jain wrote:
> 
> [lots of stuff deleted]. 
> 

A famous one that can happen with some techs is that they make jumpers
from solid wire with generic rj45 plugs (yes, I've seen this recently
from several folks who should know better).  These will last somewhere
around a year (long enough to forget when they were installed) then
randomly fail from just fan vibration or slight breezes.  There are rj45
plugs made for solid wire (have 3 little prongs instead of 2, and they
are offset to straddle the wire) but I feel that even these can go bad.
 I know if the techs are properly educated that this "will never happen"
(tm)...  (till someone needs a custom-length jumper on a sunday...)
(for which, one colo building has an ace hardware with most of the right
stuff, but unfortunately most don't).

As we all (should) know, all solid-wire cable should terminate in a
panel and proper short jumpers (pref. with molded strain-relief) are
used for the rest.

-- Pete



From jlewis at lewis.org  Thu Sep 17 18:23:04 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Thu, 17 Sep 2009 19:23:04 -0400 (EDT)
Subject: cross connect reliability
In-Reply-To: <43661d390909171604s60344304m98d447c4e5622629@mail.gmail.com>
References: <1253223936.6803.391.camel@mike-desktop>
	<4AB2AFAF.50900@rollernet.us>
	<7C79FE41-AA98-40C5-BBC6-EB0FD919A91B@americafree.tv>
	<43661d390909171604s60344304m98d447c4e5622629@mail.gmail.com>
Message-ID: 

Not really.  That's all too easy to diagnose and fix.  Poorly terminated 
and or mistreated cabling is far more likely.  I wrote a long post about 
all the crap termination and poor treatment I've seen...but canceled the 
message.

On Thu, 17 Sep 2009, Mike Lieman wrote:

> We have a winner!
>
> On Thu, Sep 17, 2009 at 5:59 PM, Marshall Eubanks wrote:
>
>>
>> Or until someone pulls out the wrong cable (which has happened to me).
>>
>> Regards
>> Marshall
>>
>>
>>  ~Seth
>>>
>>>
>>>
>>
>>
>

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________



From mikelieman at gmail.com  Thu Sep 17 18:25:24 2009
From: mikelieman at gmail.com (Mike Lieman)
Date: Thu, 17 Sep 2009 19:25:24 -0400
Subject: cross connect reliability
In-Reply-To: 
References: <1253223936.6803.391.camel@mike-desktop>
	<4AB2AFAF.50900@rollernet.us>
	<7C79FE41-AA98-40C5-BBC6-EB0FD919A91B@americafree.tv>
	<43661d390909171604s60344304m98d447c4e5622629@mail.gmail.com>
	
Message-ID: <43661d390909171625n33a1e633lab55a59f1611998d@mail.gmail.com>

Because no-one is stealing pairs anymore?

On Thu, Sep 17, 2009 at 7:23 PM, Jon Lewis  wrote:

> Not really.  That's all too easy to diagnose and fix.  Poorly terminated
> and or mistreated cabling is far more likely.  I wrote a long post about all
> the crap termination and poor treatment I've seen...but canceled the
> message.
>
> On Thu, 17 Sep 2009, Mike Lieman wrote:
>
>  We have a winner!
>>
>> On Thu, Sep 17, 2009 at 5:59 PM, Marshall Eubanks > >wrote:
>>
>>
>>> Or until someone pulls out the wrong cable (which has happened to me).
>>>
>>> Regards
>>> Marshall
>>>
>>>
>>>  ~Seth
>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
> ----------------------------------------------------------------------
>  Jon Lewis                   |  I route
>  Senior Network Engineer     |  therefore you are
>  Atlantic Net                |
> _________ http://www.lewis.org/~jlewis/pgpfor PGP public key_________
>


From ras at e-gerbil.net  Thu Sep 17 18:29:01 2009
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Thu, 17 Sep 2009 18:29:01 -0500
Subject: cross connect reliability
In-Reply-To: <1253223936.6803.391.camel@mike-desktop>
References: <1253223936.6803.391.camel@mike-desktop>
Message-ID: <20090917232901.GS51443@gerbil.cluepon.net>

On Thu, Sep 17, 2009 at 02:45:36PM -0700, Michael J McCafferty wrote:
> All,
> 	Today I had yet another cross-connect fail at our colo provider. From
> memory, this is the 6th cross-connect to fail while in service, in 4yrs
> and recently there was a bad SFP on their end as well. This seemes like
> a high failure rate to me. When I asked about the high failure rate,
> they said that they run a lot of cables and there is a lot of jiggling
> and wiggling... lots of chances to get bent out of whack from activity
> near my patches and cables.

I once had a circuit go down because the fiber connector wasn't crimped
on correctly, and the fiber pulled out of the connector while a tech was
working in the cable tray nearby. After we opened a ticket about the
issue, said tech "fixed" it by shoving the fiber back into the connector
by hand, and walking away. Needless to say it went down again the next
day. Names withheld to protect the guilty and keep them from raising my
prices for heckling them in public, but the moral of the story is never
underestimate the laziness or stupidity of the cable monkeys some of
these places hire and let touch your routers. :)

-- 
Richard A Steenbergen        http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)



From jlewis at lewis.org  Thu Sep 17 18:30:11 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Thu, 17 Sep 2009 19:30:11 -0400 (EDT)
Subject: cross connect reliability
In-Reply-To: <43661d390909171625n33a1e633lab55a59f1611998d@mail.gmail.com>
References: <1253223936.6803.391.camel@mike-desktop>
	<4AB2AFAF.50900@rollernet.us>
	<7C79FE41-AA98-40C5-BBC6-EB0FD919A91B@americafree.tv> 
	<43661d390909171604s60344304m98d447c4e5622629@mail.gmail.com> 
	
	<43661d390909171625n33a1e633lab55a59f1611998d@mail.gmail.com>
Message-ID: 

It's just not as interesting or hard to troubleshoot as a poorly made 
patch cable that's had one conductor go open, only goes open when the wire 
is tugged a certain direction, nicked wires shorting, a switch port with 
its RX side burned out, an RJ45 plug who's mistreated tab no longer works, 
and though it looks inserted in the port, it's really just kind of hanging 
there not making full/good contact, etc.

I would hope in any data center, "stealing pairs" doesn't happen as much 
as any of the above or taking pairs the tech genuinely thought were dead.

On Thu, 17 Sep 2009, Mike Lieman wrote:

> Because no-one is stealing pairs anymore?
>
> On Thu, Sep 17, 2009 at 7:23 PM, Jon Lewis  wrote:
>
>> Not really.  That's all too easy to diagnose and fix.  Poorly terminated
>> and or mistreated cabling is far more likely.  I wrote a long post about all
>> the crap termination and poor treatment I've seen...but canceled the
>> message.
>>
>> On Thu, 17 Sep 2009, Mike Lieman wrote:
>>
>>  We have a winner!
>>>
>>> On Thu, Sep 17, 2009 at 5:59 PM, Marshall Eubanks >>> wrote:
>>>
>>>
>>>> Or until someone pulls out the wrong cable (which has happened to me).
>>>>
>>>> Regards
>>>> Marshall
>>>>
>>>>
>>>>  ~Seth
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>> ----------------------------------------------------------------------
>>  Jon Lewis                   |  I route
>>  Senior Network Engineer     |  therefore you are
>>  Atlantic Net                |
>> _________ http://www.lewis.org/~jlewis/pgpfor PGP public key_________
>>
>

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________



From jlewis at lewis.org  Thu Sep 17 18:34:01 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Thu, 17 Sep 2009 19:34:01 -0400 (EDT)
Subject: cross connect reliability
In-Reply-To: <20090917232901.GS51443@gerbil.cluepon.net>
References: <1253223936.6803.391.camel@mike-desktop>
	<20090917232901.GS51443@gerbil.cluepon.net>
Message-ID: 

On Thu, 17 Sep 2009, Richard A Steenbergen wrote:

> I once had a circuit go down because the fiber connector wasn't crimped
> on correctly, and the fiber pulled out of the connector while a tech was
> working in the cable tray nearby. After we opened a ticket about the
> issue, said tech "fixed" it by shoving the fiber back into the connector
> by hand, and walking away. Needless to say it went down again the next
> day. Names withheld to protect the guilty and keep them from raising my
> prices for heckling them in public, but the moral of the story is never
> underestimate the laziness or stupidity of the cable monkeys some of
> these places hire and let touch your routers. :)

In their defense, that was clearly the fastest way to fix it. :)

Just not a very long term solution.

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________



From sronan at fattoc.com  Thu Sep 17 18:39:37 2009
From: sronan at fattoc.com (Shane Ronan)
Date: Fri, 18 Sep 2009 00:39:37 +0100
Subject: cross connect reliability
In-Reply-To: <1253223936.6803.391.camel@mike-desktop>
References: <1253223936.6803.391.camel@mike-desktop>
Message-ID: <665B8C07-41C3-47A4-A779-E7FE15DB1119@fattoc.com>

Having work in high traffic colo spaces around the world for the last  
ten years or so, in my experience this type of issue is very rare. If  
you are having this type of "quality" issue, I would sit down with  
your sales rep and ask to be stepped through their processes, there is  
obviously something that has gone VERY VERY WRONG.

Shane

On Sep 17, 2009, at 10:45 PM, Michael J McCafferty wrote:

> All,
> 	Today I had yet another cross-connect fail at our colo provider. From
> memory, this is the 6th cross-connect to fail while in service, in  
> 4yrs
> and recently there was a bad SFP on their end as well. This seemes  
> like
> a high failure rate to me. When I asked about the high failure rate,
> they said that they run a lot of cables and there is a lot of jiggling
> and wiggling... lots of chances to get bent out of whack from activity
> near my patches and cables.
> 	Until a few years ago my time was spent mostly in single tenant data
> centers, and it may be true that we made fewer cabling changes and  
> made
> less of a ruckus when cabling... but this still seems like a pretty  
> high
> failure rate at the colo.
> 	I am curious; what do you expect the average reliability of your  
> FastE
> or GigE copper cross-connects at a colo?
>
> Thanks,
> Mike
>
> -- 
> ************************************************************
> 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 ras at e-gerbil.net  Thu Sep 17 18:45:47 2009
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Thu, 17 Sep 2009 18:45:47 -0500
Subject: cross connect reliability
In-Reply-To: <4AB2B9B9.60406@thewybles.com>
References: <1253223936.6803.391.camel@mike-desktop>
	<4AB2AFAF.50900@rollernet.us>
	<7C79FE41-AA98-40C5-BBC6-EB0FD919A91B@americafree.tv>
	<4AB2B9B9.60406@thewybles.com>
Message-ID: <20090917234547.GT51443@gerbil.cluepon.net>

On Thu, Sep 17, 2009 at 03:35:37PM -0700, Charles Wyble wrote:
> 
> Random failures of a single ports connectivity.... bizzare and annoying. 
> Whole switches? Seen it.
> Whole panels? Seen it.
> Whole blades? Seen it.
> 
> Single port on a switch or patch panel? Never.

You've never seen a single port go bad on a switch? I can't even count
the number of times I've seen that happen. Not that I'm not suggesting 
the OP wasn't the victim of a human error like unplugging the wrong port 
and they just lied to him, that happens even more.

My favorite bizarre random failure story is a toss-up between one of 
these two:

Story 1. Had a customer report that they weren't able to transfer this
one particular file over their connection. The transfer would start and
then at a certain point the tcp session would just lock up. After a lot
of head scratching, it turned out that for 8 ports on a 24 port FastE
switch blade, this certain combination of bytes caused the packet to be
dropped on this otherwise perfectly normal and functioning card, thus
stalling the tcp session while leaving everything around it unaffected.
If you moved them to a different port outside this group of 8, or used
https, or uuencoded it, it would go through fine.

Story 2. Had a customer report that they were getting extremely slow 
transfers to another network, despite not being able to find any packet 
loss. Shifting the traffic to a different port to reach the same network 
resolved the problem. After removing the traffic and attempting to ping 
the far side, I got the following:


64 bytes from x.x.x.x: icmp_seq=1 ttl=61 time=0.194 ms
64 bytes from x.x.x.x: icmp_seq=2 ttl=61 time=0.196 ms
64 bytes from x.x.x.x: icmp_seq=3 ttl=61 time=0.183 ms
64 bytes from x.x.x.x: icmp_seq=0 ttl=61 time=4.159 ms

64 bytes from x.x.x.x: icmp_seq=5 ttl=61 time=0.194 ms
64 bytes from x.x.x.x: icmp_seq=6 ttl=61 time=0.196 ms
64 bytes from x.x.x.x: icmp_seq=7 ttl=61 time=0.183 ms
64 bytes from x.x.x.x: icmp_seq=4 ttl=61 time=4.159 ms

After a little bit more testing, it turned out that every 4th packet
that was being sent to the peers' router was being queued until another
"4th packet" would come along and knock it out. If you increased the
interval time of the ping, you would see the amount of time the packet
spent in the queue increase. At one point I had it up to over 350
seconds (not milliseconds) that the packet stayed in the other routers'
queue before that 4th packet came along and knocked it free. I suspect
it could have gone higher, but random scanning traffic on the internet
was coming in. When there was a lot of traffic on the interface you
would never see the packet loss, just reordering of every 4th packet and 
thus slow tcp transfers. :)

-- 
Richard A Steenbergen        http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)



From marka at isc.org  Thu Sep 17 18:56:24 2009
From: marka at isc.org (Mark Andrews)
Date: Fri, 18 Sep 2009 09:56:24 +1000
Subject: cross connect reliability 
In-Reply-To: Your message of "Thu, 17 Sep 2009 18:45:47 EST."
	<20090917234547.GT51443@gerbil.cluepon.net> 
References: <1253223936.6803.391.camel@mike-desktop>
	<4AB2AFAF.50900@rollernet.us>
	<7C79FE41-AA98-40C5-BBC6-EB0FD919A91B@americafree.tv>
	<4AB2B9B9.60406@thewybles.com>
	<20090917234547.GT51443@gerbil.cluepon.net> 
Message-ID: <200909172356.n8HNuOAR027135@drugs.dv.isc.org>


In message <20090917234547.GT51443 at gerbil.cluepon.net>, Richard A Steenbergen w
rites:
> On Thu, Sep 17, 2009 at 03:35:37PM -0700, Charles Wyble wrote:
> > 
> > Random failures of a single ports connectivity.... bizzare and annoying. 
> > Whole switches? Seen it.
> > Whole panels? Seen it.
> > Whole blades? Seen it.
> > 
> > Single port on a switch or patch panel? Never.
> 
> You've never seen a single port go bad on a switch? I can't even count
> the number of times I've seen that happen. Not that I'm not suggesting 
> the OP wasn't the victim of a human error like unplugging the wrong port 
> and they just lied to him, that happens even more.
> 
> My favorite bizarre random failure story is a toss-up between one of 
> these two:
> 
> Story 1. Had a customer report that they weren't able to transfer this
> one particular file over their connection. The transfer would start and
> then at a certain point the tcp session would just lock up. After a lot
> of head scratching, it turned out that for 8 ports on a 24 port FastE
> switch blade, this certain combination of bytes caused the packet to be
> dropped on this otherwise perfectly normal and functioning card, thus
> stalling the tcp session while leaving everything around it unaffected.
> If you moved them to a different port outside this group of 8, or used
> https, or uuencoded it, it would go through fine.

Seen that more than once.  It's worse when it's in some router on the
other side of the planet and your just a lowly customer.
 
> Story 2. Had a customer report that they were getting extremely slow 
> transfers to another network, despite not being able to find any packet 
> loss. Shifting the traffic to a different port to reach the same network 
> resolved the problem. After removing the traffic and attempting to ping 
> the far side, I got the following:
> 
> 
> 64 bytes from x.x.x.x: icmp_seq=1 ttl=61 time=0.194 ms
> 64 bytes from x.x.x.x: icmp_seq=2 ttl=61 time=0.196 ms
> 64 bytes from x.x.x.x: icmp_seq=3 ttl=61 time=0.183 ms
> 64 bytes from x.x.x.x: icmp_seq=0 ttl=61 time=4.159 ms
> 
> 64 bytes from x.x.x.x: icmp_seq=5 ttl=61 time=0.194 ms
> 64 bytes from x.x.x.x: icmp_seq=6 ttl=61 time=0.196 ms
> 64 bytes from x.x.x.x: icmp_seq=7 ttl=61 time=0.183 ms
> 64 bytes from x.x.x.x: icmp_seq=4 ttl=61 time=4.159 ms
> 
> After a little bit more testing, it turned out that every 4th packet
> that was being sent to the peers' router was being queued until another
> "4th packet" would come along and knock it out. If you increased the
> interval time of the ping, you would see the amount of time the packet
> spent in the queue increase. At one point I had it up to over 350
> seconds (not milliseconds) that the packet stayed in the other routers'
> queue before that 4th packet came along and knocked it free. I suspect
> it could have gone higher, but random scanning traffic on the internet
> was coming in. When there was a lot of traffic on the interface you
> would never see the packet loss, just reordering of every 4th packet and 
> thus slow tcp transfers. :)
> 
> -- 
> Richard A Steenbergen        http://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



From bpalmer at fxcm.com  Thu Sep 17 19:58:36 2009
From: bpalmer at fxcm.com (Brandon Palmer)
Date: Thu, 17 Sep 2009 20:58:36 -0400
Subject: cross connect reliability
In-Reply-To: <1253223936.6803.391.camel@mike-desktop>
References: <1253223936.6803.391.camel@mike-desktop>
Message-ID: <4AB2A2FC.374D.0046.0@fxcm.com>

We've never had a fiber CC fail.  
 
We HAVE had DS3 and T1s fail.  Those were due to other customer circuits being installed near ours and bumping them.

>>> Michael J McCafferty  9/17/2009 5:45 PM >>>
All,
Today I had yet another cross-connect fail at our colo provider. From
memory, this is the 6th cross-connect to fail while in service, in 4yrs
and recently there was a bad SFP on their end as well. This seemes like
a high failure rate to me. When I asked about the high failure rate,
they said that they run a lot of cables and there is a lot of jiggling
and wiggling... lots of chances to get bent out of whack from activity
near my patches and cables.
Until a few years ago my time was spent mostly in single tenant data
centers, and it may be true that we made fewer cabling changes and made
less of a ruckus when cabling... but this still seems like a pretty high
failure rate at the colo.
I am curious; what do you expect the average reliability of your FastE
or GigE copper cross-connects at a colo?

Thanks,
Mike

-- 
************************************************************
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 carlos at race.com  Thu Sep 17 22:02:34 2009
From: carlos at race.com (Carlos Alcantar)
Date: Thu, 17 Sep 2009 20:02:34 -0700
Subject: cross connect reliability
Message-ID: <859604546CD1FF488BDB6EA94C896AFB9C59B5@racexchange.race.local>

We seem to have the highest failure rate on cross connects from ds3's
and t1's.

-carlos

-----Original Message-----
From: Brandon Palmer [mailto:bpalmer at fxcm.com] 
Sent: Thursday, September 17, 2009 5:59 PM
To: Michael J McCafferty; nanog
Subject: Re: cross connect reliability

We've never had a fiber CC fail.  
 
We HAVE had DS3 and T1s fail.  Those were due to other customer circuits
being installed near ours and bumping them.

>>> Michael J McCafferty  9/17/2009 5:45 PM
>>>
All,
Today I had yet another cross-connect fail at our colo provider. From
memory, this is the 6th cross-connect to fail while in service, in 4yrs
and recently there was a bad SFP on their end as well. This seemes like
a high failure rate to me. When I asked about the high failure rate,
they said that they run a lot of cables and there is a lot of jiggling
and wiggling... lots of chances to get bent out of whack from activity
near my patches and cables.
Until a few years ago my time was spent mostly in single tenant data
centers, and it may be true that we made fewer cabling changes and made
less of a ruckus when cabling... but this still seems like a pretty high
failure rate at the colo.
I am curious; what do you expect the average reliability of your FastE
or GigE copper cross-connects at a colo?

Thanks,
Mike

-- 
************************************************************
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 truman at suspicious.org  Thu Sep 17 23:37:30 2009
From: truman at suspicious.org (Truman Boyes)
Date: Fri, 18 Sep 2009 14:37:30 +1000
Subject: MPLS Multi-vrf and IP Multicast
In-Reply-To: 
References: 
Message-ID: <2E17244E-C9C6-4AF2-9022-88D1F2358C84@suspicious.org>

Hi Devang,

You can take a look at BGP Multicast Inter-AS VPNs. There is a  
difference between CSC/CoC and Inter-AS VPNs. You can have multicast  
trees per VPN, but it depends on what you are trying to do. Do you  
currently have CSC or are you deciding which way to go?

Truman



On 18/09/2009, at 9:13 AM, devang patel wrote:

> Hello All,
>
> Any scenario where we are using MPLS between PE-CE when CE is multi- 
> vrf
> router, any deployment in real word? Carrier supporting carrier CSC  
> is one
> where you have MPLS between PE-CE link.
> If PE-CE running MPLS between them then what will be impact on  
> MULTICAST
> between two site?
> If PE-CE connectivity is pure IP then i think multicast will work  
> properly
> right?
>
> thanks,
> Devang Patel
>




From davids at webmaster.com  Fri Sep 18 00:02:48 2009
From: davids at webmaster.com (David Schwartz)
Date: Thu, 17 Sep 2009 22:02:48 -0700
Subject: Repeated Blacklisting / IP reputation
In-Reply-To: <4AAFAC5C.8040008@gmail.com>
Message-ID: 


Shawn Somers wrote:

> Anyone that intentionally uses address space in a manner that they
> know will cause it to become contaminated should be denied on any
> further address space requests.

I couldn't disagree more with this kind of heckler's veto proposal. RBL
operators should not be permited to set registry policy, even indirectly.

The point of an RBL is that it operates consensually. I choose to use an RBL
to filter something because I agree with the RBL's policy decisions. There
is nothing inherently wrong with being added to an RBL, it simply indicates
that the RBL's operators felt you met their policy for inclusion.

If someone wants to make an RBL that lists people with "bad ideas", they are
welcome to. Those who agree with them can have a "bad idea"-free internet.
But it does not follow that there's any reason to punish those on the RBL,
even if they do so intentionally, and even if that RBL listen would burden
other owners of the block.

Of course, they should not be permitted to launder their blocks either. Just
as registries should not impose costs on people just for getting listed in
an RBL, they should not impose costs on RBL-operators by helping people
evade earned listings and forcing re-listings.

DS





From martin at theicelandguy.com  Fri Sep 18 12:22:19 2009
From: martin at theicelandguy.com (Martin Hannigan)
Date: Fri, 18 Sep 2009 13:22:19 -0400
Subject: cross connect reliability
In-Reply-To: <1253223936.6803.391.camel@mike-desktop>
References: <1253223936.6803.391.camel@mike-desktop>
Message-ID: 

On Thu, Sep 17, 2009 at 5:45 PM, Michael J McCafferty <
mike at m5computersecurity.com> wrote:

[ clip ]


>        I am curious; what do you expect the average reliability of your
> FastE
> or GigE copper cross-connects at a colo?
>
>

At the physical layer, near zero. If "jiggling and wiggling" is causing
cable failures, they have bigger problems. The last time I had problems with
"jiggle and wiggle" was with techs walking by ds3 xcon farms and "testing"
if the cables were "taught" enough with respect to the termination hardware.
If you pull on them enough, they will come apart and they will fail.

I'd love to see a picture of their xcon frames.

-M<


-- 
Martin Hannigan                               martin at theicelandguy.com
p: +16178216079
Power, Network, and Costs Consulting for Iceland Datacenters and Occupants


From warren at kumari.net  Fri Sep 18 12:55:25 2009
From: warren at kumari.net (Warren Kumari)
Date: Fri, 18 Sep 2009 13:55:25 -0400
Subject: cross connect reliability
In-Reply-To: <20090917234547.GT51443@gerbil.cluepon.net>
References: <1253223936.6803.391.camel@mike-desktop>
	<4AB2AFAF.50900@rollernet.us>
	<7C79FE41-AA98-40C5-BBC6-EB0FD919A91B@americafree.tv>
	<4AB2B9B9.60406@thewybles.com>
	<20090917234547.GT51443@gerbil.cluepon.net>
Message-ID: 


On Sep 17, 2009, at 7:45 PM, Richard A Steenbergen wrote:

[ SNIP ]

> Story 2. Had a customer report that they were getting extremely slow
> transfers to another network, despite not being able to find any  
> packet
> loss. Shifting the traffic to a different port to reach the same  
> network
> resolved the problem. After removing the traffic and attempting to  
> ping
> the far side, I got the following:
>
> 
> 64 bytes from x.x.x.x: icmp_seq=1 ttl=61 time=0.194 ms
> 64 bytes from x.x.x.x: icmp_seq=2 ttl=61 time=0.196 ms
> 64 bytes from x.x.x.x: icmp_seq=3 ttl=61 time=0.183 ms
> 64 bytes from x.x.x.x: icmp_seq=0 ttl=61 time=4.159 ms
> 
> 64 bytes from x.x.x.x: icmp_seq=5 ttl=61 time=0.194 ms
> 64 bytes from x.x.x.x: icmp_seq=6 ttl=61 time=0.196 ms
> 64 bytes from x.x.x.x: icmp_seq=7 ttl=61 time=0.183 ms
> 64 bytes from x.x.x.x: icmp_seq=4 ttl=61 time=4.159 ms
>
> After a little bit more testing, it turned out that every 4th packet
> that was being sent to the peers' router was being queued until  
> another
> "4th packet" would come along and knock it out. If you increased the
> interval time of the ping, you would see the amount of time the packet
> spent in the queue increase. At one point I had it up to over 350
> seconds (not milliseconds) that the packet stayed in the other  
> routers'
> queue before that 4th packet came along and knocked it free. I suspect
> it could have gone higher, but random scanning traffic on the internet
> was coming in. When there was a lot of traffic on the interface you
> would never see the packet loss, just reordering of every 4th packet  
> and
> thus slow tcp transfers. :)

Story 1:
-----------
I had a router where I was suddenly unable to reach certain hosts on  
the (/24) ethernet interface -- pinging form the router worked fine,  
transit traffic wouldn't. I decided to try and figure out if there was  
any sort of rhyme or reason to which hosts had gone unreachable. I  
could successfully reach
xxx.yyy.zzz.1
xxx.yyy.zzz.2
xxx.yyy.zzz.3
xxx.yyy.zzz.5
xxx.yyy.zzz.7
xxx.yyy.zzz.11
xxx.yyy.zzz.13
xxx.yyy.zzz.17
...
xxx.yyy.zzz.197
xxx.yyy.zzz.199

There were only 200 hosts on the LAN, but I'd bet dollars to donuts  
that I know what the next reachable one would have been if there had  
been more.  Unfortunately the box rebooted itself (when I tried to  
view the FIB) before I could collect more info.

Story 2:
----------
Had a small router connecting a remote office over a multilink PPP[1]  
interface (4xE1). Site starts getting massive packet-loss, so I figure  
one of the circuits has gone bad, but didn't get removed from the  
bundle. I'm having a hard time reaching the remote side, so I pull the  
interfaces from protocols and try ping the remote router -- no  
replies.... Luckily I didn't hit Ctrl-C on the ping, because suddenly  
I start getting replies with no drops:

64 bytes from x.x.x.x: icmp_seq=1 ttl=120 time=30132.148 ms
64 bytes from x.x.x.x: icmp_seq=2 ttl=120 time=30128.178 ms
64 bytes from x.x.x.x: icmp_seq=3 ttl=120 time=30133.231 ms
64 bytes from x.x.x.x: icmp_seq=4 ttl=120 time=30112.571 ms
64 bytes from x.x.x.x: icmp_seq=5 ttl=120 time=30132.632 ms


What?! I figure it's gotta be MLPPP stupidity and / or depref of ICMP,  
so I connect OOB and  A: remove MLPPP and use just a single interface  
and B: start pinging a host behind the router instead...

64 bytes from x.x.x.x: icmp_seq=1 ttl=120 time=30142.323 ms
64 bytes from x.x.x.x: icmp_seq=2 ttl=120 time=30144.571 ms
64 bytes from x.x.x.x: icmp_seq=3 ttl=120 time=30141.632 ms
64 bytes from x.x.x.x: icmp_seq=4 ttl=120 time=30142.420 ms
64 bytes from x.x.x.x: icmp_seq=5 ttl=120 time=30159.706 ms

I fire up tcpdump and try ssh to a host on the remote side -- I see  
the SYN leave my machine and then, 30 *seconds* later I get back a SYN- 
ACK. I change the queuing on the interface from FIFO to something else  
and the problem goes away. I change the queuing back to FIFO and it's  
30 second RTT again. Somehow it seems to be buffering as much traffic  
as it can (and anything more than one copy of ping running (or ping  
with anything larger than the default packet size) makes if start  
dropping badly). I ran "show buffers" to try get more of an idea what  
was happening, but it didn't like that and reloaded. Came back up fine  
though...

Story 3:
----------

Running a network that had a large number of L3 switches from a vendor  
(lets call them "X") in a single OSPF area. This area also contained a  
large number of poor quality international circuits that would flap  
often, so there was *lots* of churn. Apparently this vendor X's OSPF  
implementation didn't much like this and so would become unhappy. The  
way it would express its displeasure was by corrupting a pointer to /  
in the LSDB so it was off-by-one and you'd get:
Nov 24 22:23:53.633 EST: %OSPF-4-BADLSAMASK: Bad LSA mask: Type 5,  
LSID 0.9.32.5
Mask 10.160.8.0 from 10.178.255.252
NOTE: This route will not be installed in the routing table.
Nov 26 11:01:32.997 EST: %OSPF-4-BADLSAMASK: Bad LSA mask: Type 5,  
LSID 0.4.2.3
Mask 10.2.153.0 from 10.178.255.252
NOTE: This route will not be installed in the routing table.
Nov 27 23:14:00.660 EST: %OSPF-4-BADLSAMASK: Bad LSA mask: Type 5,  
LSID 0.4.2.3
Mask 10.2.153.0 from 10.178.255.252
NOTE: This route will not be installed in the routing table.
(This network was addressed out of 10/8 -  10.178.255.252 is one of  
vendors X boxes and 10.160.8.0 is a valid subnet, but, surprisingly  
enough, not a valid mask..... ).
To make mattes even more fun, the OSPF adjacency would go down and  
then come back up -- and the grumpy box would flood all of it's  
(corrupt) LSAs...

W

[1]: Hey, not my idea...

>
> -- 
> Richard A Steenbergen        http://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1  
> 2CBC)
>

--
"Real children don't go hoppity-skip unless they are on drugs."

     -- Susan, the ultimate sensible governess (Terry Pratchett,  
Hogfather)







From cscora at apnic.net  Fri Sep 18 13:14:00 2009
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 19 Sep 2009 04:14:00 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <200909181814.n8IIE0TT020209@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 19 Sep, 2009

Report Website:     http://thyme.apnic.net
Detailed Analysis:  http://thyme.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              296617
    Prefixes after maximum aggregation:                          139697
    Deaggregation factor:                                          2.12
    Unique aggregates announced to Internet:                     147808
Total ASes present in the Internet Routing Table:                 32213
    Prefixes per ASN:                                              9.21
Origin-only ASes present in the Internet Routing Table:           27997
Origin ASes announcing only one prefix:                           13673
Transit ASes present in the Internet Routing Table:                4216
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:                                      39
    Max AS path prepend of ASN (22394)                               36
Prefixes from unregistered ASNs in the Routing Table:               432
    Unregistered ASNs in the Routing Table:                         121
Number of 32-bit ASNs allocated by the RIRs:                        275
Prefixes from 32-bit ASNs in the Routing Table:                     126
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:            229
Number of addresses announced to Internet:                   2107111040
    Equivalent to 125 /8s, 151 /16s and 246 /24s
    Percentage of available address space announced:               56.8
    Percentage of allocated address space announced:               65.1
    Percentage of available address space allocated:               87.3
    Percentage of address space in use by end-sites:               78.9
Total number of prefixes smaller than registry allocations:      142159

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                    71434
    Total APNIC prefixes after maximum aggregation:               25020
    APNIC Deaggregation factor:                                    2.86
Prefixes being announced from the APNIC address blocks:           67830
    Unique aggregates announced from the APNIC address blocks:    30301
APNIC Region origin ASes present in the Internet Routing Table:    3792
    APNIC Prefixes per ASN:                                       17.89
APNIC Region origin ASes announcing only one prefix:               1036
APNIC Region transit ASes present in the Internet Routing Table:    583
Average APNIC Region AS path length visible:                        3.5
    Max APNIC Region AS path length visible:                         15
Number of APNIC addresses announced to Internet:              460221984
    Equivalent to 27 /8s, 110 /16s and 110 /24s
    Percentage of available APNIC address space announced:         78.4

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:                    125111
    Total ARIN prefixes after maximum aggregation:                66615
    ARIN Deaggregation factor:                                     1.88
Prefixes being announced from the ARIN address blocks:            99638
    Unique aggregates announced from the ARIN address blocks:     38372
ARIN Region origin ASes present in the Internet Routing Table:    13244
    ARIN Prefixes per ASN:                                         7.52
ARIN Region origin ASes announcing only one prefix:                5129
ARIN Region transit ASes present in the Internet Routing Table:    1300
Average ARIN Region AS path length visible:                         3.3
    Max ARIN Region AS path length visible:                          39
Number of ARIN addresses announced to Internet:               705394816
    Equivalent to 42 /8s, 11 /16s and 120 /24s
    Percentage of available ARIN address space announced:          61.8

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:                     68436
    Total RIPE prefixes after maximum aggregation:                40022
    RIPE Deaggregation factor:                                     1.71
Prefixes being announced from the RIPE address blocks:            62149
    Unique aggregates announced from the RIPE address blocks:     41489
RIPE Region origin ASes present in the Internet Routing Table:    13484
    RIPE Prefixes per ASN:                                         4.61
RIPE Region origin ASes announcing only one prefix:                7037
RIPE Region transit ASes present in the Internet Routing Table:    2031
Average RIPE Region AS path length visible:                         3.9
    Max RIPE Region AS path length visible:                          21
Number of RIPE addresses announced to Internet:               399639232
    Equivalent to 23 /8s, 210 /16s and 2 /24s
    Percentage of available RIPE address space announced:          79.4

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 196608-197631
RIPE Address Blocks     25/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:                   25376
    Total LACNIC prefixes after maximum aggregation:               6231
    LACNIC Deaggregation factor:                                   4.07
Prefixes being announced from the LACNIC address blocks:          23706
    Unique aggregates announced from the LACNIC address blocks:   13257
LACNIC Region origin ASes present in the Internet Routing Table:   1177
    LACNIC Prefixes per ASN:                                      20.14
LACNIC Region origin ASes announcing only one prefix:               381
LACNIC Region transit ASes present in the Internet Routing Table:   189
Average LACNIC Region AS path length visible:                       4.1
    Max LACNIC Region AS path length visible:                        21
Number of LACNIC addresses announced to Internet:              66558464
    Equivalent to 3 /8s, 247 /16s and 154 /24s
    Percentage of available LACNIC address space announced:        66.1

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:                   5892
    Total AfriNIC prefixes after maximum aggregation:              1545
    AfriNIC Deaggregation factor:                                  3.81
Prefixes being announced from the AfriNIC address blocks:          4268
    Unique aggregates announced from the AfriNIC address blocks:   1495
AfriNIC Region origin ASes present in the Internet Routing Table:   319
    AfriNIC Prefixes per ASN:                                     13.38
AfriNIC Region origin ASes announcing only one prefix:               90
AfriNIC Region transit ASes present in the Internet Routing Table:   68
Average AfriNIC Region AS path length visible:                      3.8
    Max AfriNIC Region AS path length visible:                       14
Number of AfriNIC addresses announced to Internet:             12382208
    Equivalent to 0 /8s, 188 /16s and 240 /24s
    Percentage of available AfriNIC address space announced:       36.9

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     1761       6995         453   Korea Telecom (KIX)
17488     1547        138         105   Hathway IP Over Cable Interne
 4755     1263        292         143   TATA Communications formerly 
 9583     1098         87         533   Sify Limited
 4134     1008      18168         391   CHINANET-BACKBONE
18101      976        203          33   Reliance Infocom Ltd Internet
 7545      857        198         100   TPG Internet Pty Ltd
 9829      812        625          18   BSNL National Internet Backbo
24560      766        284         166   Bharti Airtel Ltd., Telemedia
 4808      764       1518         182   CNCGROUP IP network: China169

Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC

ARIN Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     4170       3627         313   bellsouth.net, inc. 
 4323     1927       1049         386   Time Warner Telecom
 1785     1742        714         138   PaeTec Communications, Inc.
20115     1641       1478         673   Charter Communications 
 7018     1488       5875        1053   AT&T WorldNet Services
 6478     1427        284         259   AT&T Worldnet Services 
 2386     1313        656         951   AT&T Data Communications Serv
 3356     1227      10980         439   Level 3 Communications, LLC 
11492     1123        208          12   Cable One 
22773     1102       2604          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      491         93         200   Evolva Telecom
 3292      447       1900         394   TDC Tele Danmark
12479      424        578           6   Uni2 Autonomous System
  702      423       1821         341   UUNET - Commercial IP service
35805      392         40           5   United Telecom of Georgia
 9198      376        138          12   Kazakhtelecom Data Network Ad
 8866      358        110          23   Bulgarian Telecommunication C
 3320      354       7067         303   Deutsche Telekom AG
 3301      349       1412         309   TeliaNet Sweden
 3215      347       3121         111   France Telecom Transpac

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     1476       2899         246   UniNet S.A. de C.V. 
10620     1010        226          99   TVCABLE BOGOTA 
28573      710        622          62   NET Servicos de Comunicao S.A
 7303      640        339          90   Telecom Argentina Stet-France
22047      542        302          14   VTR PUNTO NET S.A. 
11830      475        310          61   Instituto Costarricense de El
11172      439         99          70   Servicios Alestra S.A de C.V 
 7738      424        858          29   Telecomunicacoes da Bahia S.A
 6471      423         96          31   ENTEL CHILE S.A. 
14117      418         29          11   Telefonica del Sur S.A. 

Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8452      978        188           7   TEDATA
24863      935         96          61   LINKdotNET AS number
 3741      272        856         234   The Internet Solution 
 2018      197        187         116   Tertiary Education Network 
 6713      175        166          16   Itissalat Al-MAGHRIB
29571      139         14           6   Ci Telecom Autonomous system 
24835      123         46           9   RAYA Telecom - Egypt
33776      123          7          11   Starcomms Nigeria Limited
 5536      122          8          13   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     4170       3627         313   bellsouth.net, inc. 
 4323     1927       1049         386   Time Warner Telecom
 4766     1761       6995         453   Korea Telecom (KIX)
 1785     1742        714         138   PaeTec Communications, Inc.
20115     1641       1478         673   Charter Communications 
17488     1547        138         105   Hathway IP Over Cable Interne
 7018     1488       5875        1053   AT&T WorldNet Services
 8151     1476       2899         246   UniNet S.A. de C.V. 
 6478     1427        284         259   AT&T Worldnet Services 
 2386     1313        656         951   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
 1785      1742        1604      PaeTec Communications, Inc.
 4323      1927        1541      Time Warner Telecom
17488      1547        1442      Hathway IP Over Cable Interne
 4766      1761        1308      Korea Telecom (KIX)
 8151      1476        1230      UniNet S.A. de C.V. 
 6478      1427        1168      AT&T Worldnet Services 
 4755      1263        1120      TATA Communications formerly 
11492      1123        1111      Cable One 
18566      1062        1052      Covad Communications 
22773      1102        1036      Cox Communications, Inc.

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
41.223.92.0/22       36936     >>UNKNOWN<<
41.223.189.0/24      26452     Local Communications Networks
43.245.0.0/16         7502     Internetwork Kyoto
62.61.220.0/24       24974     Tachyon Europe BV - Wireless 
62.61.221.0/24       24974     Tachyon Europe BV - Wireless 
63.140.213.0/24      22555     Universal Talkware Corporatio
63.143.251.0/24      22555     Universal Talkware Corporatio
64.31.32.0/19        11955     ServiceCo LLC - Road Runner 
64.72.112.0/20       19166     Allied Riser Communications, 
64.247.160.0/20      10937     Island Internet Services 

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:24      /11:63      /12:175     
/13:355     /14:626     /15:1197    /16:10663   /17:4826    /18:8374    
/19:17422   /20:20842   /21:20788   /22:27097   /23:26608   /24:154744  
/25:932     /26:1056    /27:567     /28:166     /29:40      /30:15      
/31:0       /32:8       

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
 6389     2701          4170      bellsouth.net, inc. 
 4766     1434          1761      Korea Telecom (KIX)
17488     1292          1547      Hathway IP Over Cable Interne
 1785     1209          1742      PaeTec Communications, Inc.
11492     1051          1123      Cable One 
18566     1043          1062      Covad Communications 
 4323      968          1927      Time Warner Telecom
 9583      950          1098      Sify Limited
10620      916          1010      TVCABLE BOGOTA 
 8452      902           978      TEDATA

Complete listing at http://thyme.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   4:13        8:226      12:2150     13:7        15:21       16:3      
  17:5        20:36       24:1136     32:52       34:2        38:601    
  40:97       41:1717     43:1        44:2        47:13       52:6      
  55:2        56:2        57:25       58:608      59:635      60:461    
  61:1071     62:1030     63:2013     64:3632     65:2402     66:3402   
  67:1790     68:979      69:2749     70:569      71:157      72:1657   
  73:2        74:1745     75:179      76:323      77:872      78:586    
  79:380      80:900      81:798      82:518      83:437      84:529    
  85:1029     86:380      87:680      88:386      89:1473     90:55     
  91:2553     92:404      93:1230     94:1180     95:1098     96:165    
  97:266      98:287      99:30      109:3       110:201     111:438    
 112:131     113:150     114:256     115:350     116:1134    117:562    
 118:329     119:785     120:122     121:772     122:1278    123:768    
 124:1054    125:1367    128:222     129:217     130:129     131:423    
 132:75      133:10      134:174     135:42      136:241     137:164    
 138:173     139:84      140:433     141:121     142:382     143:343    
 144:377     145:49      146:391     147:163     148:531     149:213    
 150:208     151:187     152:215     153:155     154:2       155:279    
 156:165     157:304     158:113     159:352     160:291     161:164    
 162:271     163:165     164:276     165:522     166:475     167:371    
 168:685     169:166     170:473     171:40      172:2       173:413    
 174:331     175:1       178:1       180:25      182:1       186:142    
 187:147     188:1018    189:571     190:3016    192:5768    193:4269   
 194:3286    195:2757    196:1141    198:3554    199:3349    200:5188   
 201:1309    202:7844    203:8269    204:3896    205:2194    206:2391   
 207:2725    208:3955    209:3394    210:2563    211:1127    212:1603   
 213:1636    214:178     215:33      216:4282    217:1313    218:410    
 219:450     220:1132    221:442     222:325    

End of report



From cmadams at hiwaay.net  Fri Sep 18 13:15:37 2009
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 18 Sep 2009 13:15:37 -0500
Subject: cross connect reliability
In-Reply-To: 
References: <1253223936.6803.391.camel@mike-desktop>
	<4AB2AFAF.50900@rollernet.us>
	<7C79FE41-AA98-40C5-BBC6-EB0FD919A91B@americafree.tv>
	<4AB2B9B9.60406@thewybles.com>
	<20090917234547.GT51443@gerbil.cluepon.net>
	
Message-ID: <20090918181537.GC580085@hiwaay.net>

Once upon a time, Warren Kumari  said:
> xxx.yyy.zzz.1
> xxx.yyy.zzz.2
> xxx.yyy.zzz.3
> xxx.yyy.zzz.5
> xxx.yyy.zzz.7
> xxx.yyy.zzz.11
> xxx.yyy.zzz.13
> xxx.yyy.zzz.17
> ...
> xxx.yyy.zzz.197
> xxx.yyy.zzz.199

Oh, come on; everybody knows 1 doesn't belong in that list! :-)

-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From Valdis.Kletnieks at vt.edu  Fri Sep 18 13:57:11 2009
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 18 Sep 2009 14:57:11 -0400
Subject: cross connect reliability
In-Reply-To: Your message of "Fri, 18 Sep 2009 13:15:37 CDT."
	<20090918181537.GC580085@hiwaay.net>
References: <1253223936.6803.391.camel@mike-desktop>
	<4AB2AFAF.50900@rollernet.us>
	<7C79FE41-AA98-40C5-BBC6-EB0FD919A91B@americafree.tv>
	<4AB2B9B9.60406@thewybles.com>
	<20090917234547.GT51443@gerbil.cluepon.net>
	
	<20090918181537.GC580085@hiwaay.net>
Message-ID: <44312.1253300231@turing-police.cc.vt.edu>

On Fri, 18 Sep 2009 13:15:37 CDT, Chris Adams said:

> Oh, come on; everybody knows 1 doesn't belong in that list! :-)

Microcode bug, obviously. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: 

From cidr-report at potaroo.net  Fri Sep 18 17:00:03 2009
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 18 Sep 2009 22:00:03 GMT
Subject: BGP Update Report
Message-ID: <200909182200.n8IM03Op008864@wattle.apnic.net>

BGP Update Report
Interval: 10-Sep-09 -to- 16-Sep-09 (6 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS9198            71236  7.8%     334.4 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration
 2 - AS8452             9617  1.1%      12.8 -- TEDATA TEDATA
 3 - AS35805            9258  1.0%      25.1 -- UTG-AS United Telecom AS
 4 - AS17488            7088  0.8%       6.0 -- HATHWAY-NET-AP Hathway IP Over Cable Internet
 5 - AS21565            7013  0.8%      30.1 -- HTCC - HTC Communications, LLC
 6 - AS17974            6625  0.7%       9.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
 7 - AS24863            6123  0.7%       8.9 -- LINKdotNET-AS
 8 - AS7643             5901  0.6%       6.4 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT)
 9 - AS13489            5887  0.6%      19.6 -- EPM Telecomunicaciones S.A. E.S.P.
10 - AS4795             5519  0.6%      21.1 -- INDOSATM2-ID INDOSATM2  ASN
11 - AS20858            5249  0.6%      22.7 -- EGYNET-AS
12 - AS10620            4871  0.5%       4.8 -- TV Cable S.A.
13 - AS5050             4800  0.5%      87.3 -- PSC-EXT - Pittsburgh Supercomputing Center
14 - AS12479            4588  0.5%      74.0 -- UNI2-AS Uni2 Autonomous System
15 - AS14846            4475  0.5%     101.7 -- CGNOGE - NBC Internet
16 - AS8151             4398  0.5%       6.2 -- Uninet S.A. de C.V.
17 - AS20115            4094  0.5%       6.5 -- CHARTER-NET-HKY-NC - Charter Communications
18 - AS3921             4088  0.5%     116.8 -- AGNOGE - General Electric Company
19 - AS17465            4034  0.4%      22.7 -- ASIANET Cable ISP in India
20 - AS17557            4027  0.4%      14.3 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS5691             2048  0.2%    2048.0 -- MITRE-AS-5 - The MITRE Corporation
 2 - AS49517            3379  0.4%    1689.5 -- TEIKHOS-AS Teikhos
 3 - AS17136            1683  0.2%    1683.0 -- SPANGROUP-UTI - Span Manufacturing Ltd.
 4 - AS47640            1516  0.2%    1516.0 -- TRICOMPAS Tricomp Sp. z. o. o.
 5 - AS15145             980  0.1%     980.0 -- GLOBALSCAPE - GlobalSCAPE, Inc.
 6 - AS22739            1476  0.2%     738.0 -- BYU-H - Brigham Young University Hawaii
 7 - AS48462             701  0.1%     701.0 -- NEOCOM Neocom LLC
 8 - AS38519             662  0.1%     662.0 -- M8T-AS-ID Mobile-8 Telecom, Tbk
 9 - AS19398            1249  0.1%     624.5 -- INDENET - Indenet.net
10 - AS48497             542  0.1%     542.0 -- GTT General Transit Telecom
11 - AS41904             533  0.1%     533.0 -- SGAICE-AS JSC Severgazautomatica ICE
12 - AS26414             391  0.0%     391.0 -- LVCINT - LVC International, LLC
13 - AS3944              375  0.0%     375.0 -- PARTAN-LAB - Partan & Partan
14 - AS31630             352  0.0%     352.0 -- GENELEC-INET-AS Information Engineering Company GENELEC
15 - AS9198            71236  7.8%     334.4 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration
16 - AS4628              938  0.1%     312.7 -- ASN-PACIFIC-INTERNET-IX Pacific Internet Ltd
17 - AS17819            3217  0.3%     292.5 -- ASN-EQUINIX-AP Equinix Asia Pacific
18 - AS11613             280  0.0%     280.0 -- U-SAVE - U-Save Auto Rental of America, Inc.
19 - AS48944             277  0.0%     277.0 -- ASKHALIJFARSONLINE Khalij Ettela Resan Jonoub LTD
20 - AS11323             523  0.1%     261.5 -- GETTYIMAGES - Getty Images


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 95.59.8.0/23       7840  0.8%   AS9198  -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration
 2 - 95.59.2.0/23       7840  0.8%   AS9198  -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration
 3 - 95.59.3.0/24       7839  0.8%   AS9198  -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration
 4 - 95.59.4.0/22       7839  0.8%   AS9198  -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration
 5 - 89.218.220.0/23    7835  0.8%   AS9198  -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration
 6 - 89.218.218.0/23    7834  0.8%   AS9198  -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration
 7 - 92.46.244.0/23     7823  0.8%   AS9198  -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration
 8 - 88.204.221.0/24    7628  0.8%   AS9198  -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration
 9 - 95.59.1.0/24       7612  0.8%   AS9198  -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration
10 - 72.23.246.0/24     4618  0.5%   AS5050  -- PSC-EXT - Pittsburgh Supercomputing Center
11 - 84.1.45.0/24       3913  0.4%   AS41313 -- NOVATEL-AS Novatel Bulgaria
12 - 85.60.208.0/21     2129  0.2%   AS12479 -- UNI2-AS Uni2 Autonomous System
13 - 192.12.120.0/24    2048  0.2%   AS5691  -- MITRE-AS-5 - The MITRE Corporation
14 - 213.108.64.0/21    2026  0.2%   AS49517 -- TEIKHOS-AS Teikhos
15 - 85.60.208.0/22     1942  0.2%   AS12479 -- UNI2-AS Uni2 Autonomous System
16 - 206.210.121.0/24   1683  0.2%   AS17136 -- SPANGROUP-UTI - Span Manufacturing Ltd.
17 - 202.177.222.0/24   1600  0.2%   AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific
18 - 202.177.223.0/24   1600  0.2%   AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific
19 - 94.124.16.0/21     1516  0.2%   AS47640 -- TRICOMPAS Tricomp Sp. z. o. o.
20 - 202.51.206.0/24    1427  0.1%   AS10220 -- INFOASIA-ID-AP InfoAsia  Online

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 Sep 18 17:00:00 2009
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 18 Sep 2009 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <200909182200.n8IM00NC008856@wattle.apnic.net>

This report has been generated at Fri Sep 18 21:10:00 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
        11-09-09    302098      186291
        12-09-09    302212      186183
        13-09-09    302519      186425
        14-09-09    302719      186698
        15-09-09    303023      181742
        16-09-09    303122      181866
        17-09-09    303315      181866
        18-09-09         0      181866


AS Summary
             0  Number of ASes in routing system
             0  Number of ASes announcing only one prefix
          4313  Largest number of prefixes announced by an AS
                AS4323 : TWTC - tw telecom holdings, inc.
             0  Largest address span announced by an AS (/32s)
                ??    : TWTC - tw telecom holdings, inc.


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').

 --- 18Sep09 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     303314   181866   121448    40.0%   All ASes

AS6389      4170      326     3844    92.2%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS4323      4313     1641     2672    62.0%   TWTC - tw telecom holdings,
                                               inc.
AS4766      1862      568     1294    69.5%   KIXS-AS-KR Korea Telecom
AS17488     1548      290     1258    81.3%   HATHWAY-NET-AP Hathway IP Over
                                               Cable Internet
AS18566     1062       10     1052    99.1%   COVAD - Covad Communications
                                               Co.
AS22773     1099       71     1028    93.5%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS8151      1480      533      947    64.0%   Uninet S.A. de C.V.
AS1785      1740      800      940    54.0%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS18101      976       66      910    93.2%   RIL-IDC Reliance Infocom Ltd
                                               Internet Data Centre,
AS4755      1262      439      823    65.2%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS19262     1043      233      810    77.7%   VZGNI-TRANSIT - Verizon
                                               Internet Services Inc.
AS6478      1407      634      773    54.9%   ATT-INTERNET3 - AT&T WorldNet
                                               Services
AS8452       992      240      752    75.8%   TEDATA TEDATA
AS3356      1229      481      748    60.9%   LEVEL3 Level 3 Communications
AS4804       680       68      612    90.0%   MPX-AS Microplex PTY LTD
AS11492     1120      513      607    54.2%   CABLEONE - CABLE ONE, INC.
AS4808       764      189      575    75.3%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS7303       638       93      545    85.4%   Telecom Argentina S.A.
AS4134      1008      474      534    53.0%   CHINANET-BACKBONE
                                               No.31,Jin-rong Street
AS22047      542       14      528    97.4%   VTR BANDA ANCHA S.A.
AS9498       639      133      506    79.2%   BBIL-AP BHARTI Airtel Ltd.
AS10620     1013      513      500    49.4%   TV Cable S.A.
AS5668       790      339      451    57.1%   AS-5668 - CenturyTel Internet
                                               Holdings, Inc.
AS17908      496       56      440    88.7%   TCISL Tata Communications
AS17676      564      125      439    77.8%   GIGAINFRA Softbank BB Corp.
AS7018      1497     1061      436    29.1%   ATT-INTERNET4 - AT&T WorldNet
                                               Services
AS4780       568      135      433    76.2%   SEEDNET Digital United Inc.
AS855        615      202      413    67.2%   CANET-ASN-4 - Bell Aliant
                                               Regional Communications, Inc.
AS7011      1013      604      409    40.4%   FRONTIER-AND-CITIZENS -
                                               Frontier Communications of
                                               America, Inc.
AS7545       856      448      408    47.7%   TPG-INTERNET-AP TPG Internet
                                               Pty Ltd

Total      36986    11299    25687    69.5%   Top 30 total


Possible Bogus Routes

        24.245.128.0/17      AS11492 CABLEONE - CABLE ONE, INC.
        41.223.92.0/22       AS36936 CELTEL-GABON Celtel Gabon Internet Service
        41.223.189.0/24      AS26452 BRING-AS - BringCom, Inc.
        43.245.0.0/16        AS7502  IP-KYOTO Internetwork Kyoto
        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
        64.72.112.0/20       AS19166 
        64.247.160.0/20      AS10937 IIS - Island Internet Services
        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
        68.168.0.0/20        AS22438 CLEAR-RATE-COMMUNICATIONS - Clear Rate Communications, Inc.
        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 
        74.120.160.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.161.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.162.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.163.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.164.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.165.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.166.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.167.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.168.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.169.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.170.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.171.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.172.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.173.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.174.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.175.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        80.88.10.0/24        AS33774 DJAWEB
        80.88.12.0/24        AS33779 wataniya-telecom-as
        96.8.64.0/18         AS19166 
        96.8.127.0/24        AS19166 
        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
        122.128.120.0/22     AS38456 PACTEL-AS-AP Pacific Teleports. 
        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.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.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 / iLink Telecom
        195.225.58.0/24      AS6714  ATOMNET ATOM SA
        196.6.108.0/24       AS5713  SAIX-NET
        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.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.0.0/21       AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center
        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.134.0/24     AS3541  ITSDN-U4 - 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.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.84.10.0/23       AS9308  CHINA-ABITCOOL Abitcool(China) Inc.
        202.86.252.0/22      AS4748  RESOLINK-AS-AP Resources Link Network Limited
        202.86.252.0/24      AS9304  HUTCHISON-AS-AP Hutchison Global Communications
        202.86.253.0/24      AS9304  HUTCHISON-AS-AP Hutchison Global Communications
        202.86.254.0/24      AS9304  HUTCHISON-AS-AP Hutchison Global Communications
        202.86.255.0/24      AS9304  HUTCHISON-AS-AP Hutchison Global Communications
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.94.70.0/24       AS2764  AAPT AAPT Limited
        202.124.195.0/24     AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited
        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.160.0/24     AS4841  
        202.140.162.0/24     AS4841  
        202.140.168.0/24     AS4841  
        202.140.170.0/24     AS4841  
        202.140.171.0/24     AS4841  
        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.150.227.0/24     AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa
        202.174.70.0/24      AS21175 M-LINK Wind International Services SA  (previously known as M-LINK)
        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.34.37.0/24       AS38818 
        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.89.139.0/24      AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd.
        203.112.111.0/24     AS7474  OPTUSCOM-AS01-AU SingTel Optus Pty Ltd
        203.112.113.0/24     AS7474  OPTUSCOM-AS01-AU SingTel Optus Pty Ltd
        203.112.114.0/24     AS4802  ASN-IINET iiNet Limited
        203.112.116.0/24     AS7474  OPTUSCOM-AS01-AU SingTel Optus Pty Ltd
        203.112.117.0/24     AS7474  OPTUSCOM-AS01-AU SingTel Optus Pty Ltd
        203.112.118.0/24     AS7474  OPTUSCOM-AS01-AU SingTel Optus Pty Ltd
        203.112.119.0/24     AS7474  OPTUSCOM-AS01-AU SingTel Optus Pty Ltd
        203.112.120.0/24     AS7474  OPTUSCOM-AS01-AU SingTel Optus Pty Ltd
        203.112.121.0/24     AS7474  OPTUSCOM-AS01-AU SingTel Optus Pty Ltd
        203.112.127.0/24     AS7474  OPTUSCOM-AS01-AU SingTel Optus Pty Ltd
        203.128.128.0/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.19.14.0/23       AS577   BACOM - Bell Canada
        204.89.214.0/24      AS4323  TWTC - tw telecom holdings, inc.
        204.138.167.0/24     AS18990 AIRBAND-DALLAS - Airband Communications, 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.166.112.0/20     AS10937 IIS - Island Internet Services
        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.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.217.224.0/19     AS6130  AIS-WEST - American Internet Services, LLC.
        209.222.5.0/24       AS26699 PSI-CT - Printing For Systems Inc
        210.5.128.0/20       AS4837  CHINA169-BACKBONE CNCGROUP China169 Backbone
        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
        217.78.71.0/24       AS12491 IPPLANET-AS Gilat Satcom
        217.78.72.0/24       AS12491 IPPLANET-AS Gilat Satcom
        217.78.73.0/24       AS12491 IPPLANET-AS Gilat Satcom


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 andy at nosignal.org  Sat Sep 19 12:08:49 2009
From: andy at nosignal.org (Andy Davidson)
Date: Sat, 19 Sep 2009 18:08:49 +0100
Subject: colo space in vancouver, bc?
In-Reply-To: <4AA856D0.70504@nic-naa.net>
References: <4AA856D0.70504@nic-naa.net>
Message-ID: <074CD2AC-D3DC-4300-B5C2-B93026745960@nosignal.org>


On 10 Sep 2009, at 02:30, Eric Brunner-Williams wrote:
> I've a project that needs approximately a rack, in the Vancouver, BC  
> area. Suggestions?

I met someone from Peer1 at a past nanog, maybe LA (44) who told me  
about their facility in Vancouver.  Tell me if I should find their  
card for you.

Let us know how you get on so that your learning is added to the  
archives ! :-)


Best wishes
Andy





-- 
Regards, Andy Davidson       +44 (0)20 7993 1700       www.netsumo.com
NetSumo  Specialist networks consultancy for ISPs, Whitelabel 24/7 NOC
/* Opinions are mine & do not constitute policy of those I work for */










From andy at nosignal.org  Sat Sep 19 12:10:54 2009
From: andy at nosignal.org (Andy Davidson)
Date: Sat, 19 Sep 2009 18:10:54 +0100
Subject: BGP Confederation over Route Reflector
In-Reply-To: 
References: 
Message-ID: 


On 10 Sep 2009, at 03:52, devang patel wrote:

> What are the advantages of BGP Confederation over Route Reflector? I  
> mean when one should decide to deploy BGP Confederation over Route  
> Reflector deployment?


When doing so is simpler to support in your ibgp mesh than not doing  
so.  And probably not before this time !


Best wishes,
Andy




-- 
Regards, Andy Davidson       +44 (0)20 7993 1700       www.netsumo.com
NetSumo  Specialist networks consultancy for ISPs, Whitelabel 24/7 NOC
/* Opinions are mine & do not constitute policy of those I work for */










From bh05gc at myblackberry.com  Sat Sep 19 16:48:35 2009
From: bh05gc at myblackberry.com (BH)
Date: Sat, 19 Sep 2009 17:48:35 -0400
Subject: FOSS WAN Acceleration Software
In-Reply-To: 
References: 
Message-ID: 

Summary:
With some private replies I got a few leads. Most of which are not generic
wan accellerators but still appreciated. The two I considered:

TrafficSqueezer: still in alpha stage but performs both compression and flow
control

WANProxy: only does compression, but is slightly more "polished"


Thanks to all that replied.



On Thu, Sep 10, 2009 at 19:40, BH  wrote:

> Hello,
> I was wondering if anyone had experience or could recommend free open
> source WAN Accelerators/Optimizers. There seems to be only one FOSS project
> called TrafficSqueezer but development has stopped and the project is still
> in an Alpha stage.
>
> I am not interested in the offerings of Cisco (WAAS) or Riverbed
> (StealHead) or any other appliance based solution.
>
> Thank-you in advance for any and all replies.
>
> --
> BH
>
>


-- 
BH


From nanog at shreddedmail.com  Sun Sep 20 15:17:41 2009
From: nanog at shreddedmail.com (Rick Ernst)
Date: Sun, 20 Sep 2009 13:17:41 -0700
Subject: Multi-POP design check/help question
Message-ID: 

Cross-posted from cisco-nsp.  We are a (mostly) Cisco shop, but I'm looking
more for BCP and overall design, not provisioning specifics.


-----

My Cisco bookshelf isn't helping me much with this...

We currently have a single POP with border/core/aggregation topology.
Upstreams each come in on their own border router and the core is used as a
route-reflector for border and aggregation. The internal network uses OSPF
as an IGP and each device is dual-connected for redundancy on independent
layer-2 networks.  OSPF load-shares with loopback IPs and IBGP uses the
loopback addresses for peering.

We are looking at turning up two additional POPs in the metro area, each
connected by redundant GigE loops to the original POP.  Each POP may have
zero or more direct upstream connections.  I'd like local traffic at each
POP to prefer both in and outbound traffic via the local upstream, but still
be able to failover to upstreams at other POPs if needed.

My initial thoughts are to BGP peer between POPs with a higher local-pref
for the local outbound traffic and to prepend between the POPs so inbound
traffic is more likely to take the shortest path inbound.


Is this too simplistic? Prone to trouble? What gotchas should I be looking
at, or other designs should I be considering?


From Stefan.Fouant at neustar.biz  Sun Sep 20 16:37:06 2009
From: Stefan.Fouant at neustar.biz (Fouant, Stefan)
Date: Sun, 20 Sep 2009 17:37:06 -0400
Subject: Multi-POP design check/help question
Message-ID: <01B071CE08A7514CB72950074134151AE288F4@STNTEXCH12.cis.neustar.com>

I don't know if you want to arbitrarily use local-pref and AS-Path prepend in a one-size-fits-all approach, as under certain scenarios it might be more beneficial to route traffic between POPs to take advantage of routes via shortest AS Path or other constraints.  Why not just extend your IGP across all POPs and set inter-POP links to a higher metric?  In this scenario, if a given route is received via muliple POPs and all things being equal (AS Path, etc.), you'll prefer to route traffic out the shortest-cost path to a POP exit point.

Sorry for the top post, I'm on my BB.

Stefan Fouant 
Neustar, Inc. / Principal Engineer
46000 Center Oak Plaza Sterling, VA 20166
Office: +1.571.434.5656 ? Mobile: +1.202.210.2075 ? GPG ID: 0xB5E3803D ? stefan.fouant at neustar.biz

----- Original Message -----
From: Rick Ernst 
To: nanog at nanog.org 
Sent: Sun Sep 20 16:17:41 2009
Subject: Multi-POP design check/help question

Cross-posted from cisco-nsp.  We are a (mostly) Cisco shop, but I'm looking
more for BCP and overall design, not provisioning specifics.


-----

My Cisco bookshelf isn't helping me much with this...

We currently have a single POP with border/core/aggregation topology.
Upstreams each come in on their own border router and the core is used as a
route-reflector for border and aggregation. The internal network uses OSPF
as an IGP and each device is dual-connected for redundancy on independent
layer-2 networks.  OSPF load-shares with loopback IPs and IBGP uses the
loopback addresses for peering.

We are looking at turning up two additional POPs in the metro area, each
connected by redundant GigE loops to the original POP.  Each POP may have
zero or more direct upstream connections.  I'd like local traffic at each
POP to prefer both in and outbound traffic via the local upstream, but still
be able to failover to upstreams at other POPs if needed.

My initial thoughts are to BGP peer between POPs with a higher local-pref
for the local outbound traffic and to prepend between the POPs so inbound
traffic is more likely to take the shortest path inbound.


Is this too simplistic? Prone to trouble? What gotchas should I be looking
at, or other designs should I be considering?

From lcaron at unix-scripts.info  Sun Sep 20 16:39:59 2009
From: lcaron at unix-scripts.info (Laurent CARON)
Date: Sun, 20 Sep 2009 23:39:59 +0200
Subject: FOSS WAN Acceleration Software
In-Reply-To: 
References: 
Message-ID: <4AB6A12F.8050700@unix-scripts.info>

On 11/09/2009 01:40, BH wrote:
> Hello,
> I was wondering if anyone had experience or could recommend free open source
> WAN Accelerators/Optimizers. There seems to be only one FOSS project called
> TrafficSqueezer but development has stopped and the project is still in an
> Alpha stage.
>
> I am not interested in the offerings of Cisco (WAAS) or Riverbed (StealHead)
> or any other appliance based solution.
>
> Thank-you in advance for any and all replies.
>

Hi,

Should you use an IPSec implementation like Free/Open Swan between your 
sites, you can try to enable compression on your tunnels.

Laurent



From ryan at deadfrog.net  Sun Sep 20 19:20:55 2009
From: ryan at deadfrog.net (Ryan Wilkins)
Date: Sun, 20 Sep 2009 19:20:55 -0500
Subject: FOSS WAN Acceleration Software
In-Reply-To: 
References: 
	
Message-ID: <938A0332-496C-4B96-BF58-FFBD5B7B1DA1@deadfrog.net>

While not FOSS, supposedly Cisco routers with reasonably current IOS  
releases have RBSCP support which hints at acting in this capacity.   
I've wanted to test it since the majority of our networks are over  
satellite, but most of the modems we use have WAN acceleration built  
in and thus the need to try RBSCP has been low.

If you try it and it works I'd be interested to hear your results.

Regards,
Ryan Wilkins

On Sep 19, 2009, at 4:48 PM, BH  wrote:

> Summary:
> With some private replies I got a few leads. Most of which are not  
> generic
> wan accellerators but still appreciated. The two I considered:
>
> TrafficSqueezer: still in alpha stage but performs both compression  
> and flow
> control
>
> WANProxy: only does compression, but is slightly more "polished"
>
>
> Thanks to all that replied.
>
>
>
> On Thu, Sep 10, 2009 at 19:40, BH  wrote:
>
>> Hello,
>> I was wondering if anyone had experience or could recommend free open
>> source WAN Accelerators/Optimizers. There seems to be only one FOSS  
>> project
>> called TrafficSqueezer but development has stopped and the project  
>> is still
>> in an Alpha stage.
>>
>> I am not interested in the offerings of Cisco (WAAS) or Riverbed
>> (StealHead) or any other appliance based solution.
>>
>> Thank-you in advance for any and all replies.
>>
>> --
>> BH
>>
>>
>
>
> -- 
> BH



From truman at suspicious.org  Sun Sep 20 23:34:33 2009
From: truman at suspicious.org (Truman Boyes)
Date: Mon, 21 Sep 2009 14:34:33 +1000
Subject: Multi-POP design check/help question
In-Reply-To: <01B071CE08A7514CB72950074134151AE288F4@STNTEXCH12.cis.neustar.com>
References: <01B071CE08A7514CB72950074134151AE288F4@STNTEXCH12.cis.neustar.com>
Message-ID: 


On 21/09/2009, at 7:37 AM, Fouant, Stefan wrote:

> I don't know if you want to arbitrarily use local-pref and AS-Path  
> prepend in a one-size-fits-all approach, as under certain scenarios  
> it might be more beneficial to route traffic between POPs to take  
> advantage of routes via shortest AS Path or other constraints.  Why  
> not just extend your IGP across all POPs and set inter-POP links to  
> a higher metric?  In this scenario, if a given route is received via  
> muliple POPs and all things being equal (AS Path, etc.), you'll  
> prefer to route traffic out the shortest-cost path to a POP exit  
> point.
>
> Sorry for the top post, I'm on my BB.
>
> Stefan Fouant
> Neustar, Inc. / Principal Engineer
> 46000 Center Oak Plaza Sterling, VA 20166
> Office: +1.571.434.5656 ? Mobile: +1.202.210.2075 ? GPG ID:  
> 0xB5E3803D ? stefan.fouant at neustar.biz
>

I agree with Stefan. You are better off extending your IGP across PoPs  
as it will give you more flexibility in the long run. If you ever want  
to go down the path of traffic engineering / MPLS / etc, you will find  
it much easier as this will allow for CSPF and multi-topology routing  
architectures.

Truman



> ----- Original Message -----
> From: Rick Ernst 
> To: nanog at nanog.org 
> Sent: Sun Sep 20 16:17:41 2009
> Subject: Multi-POP design check/help question
>
> Cross-posted from cisco-nsp.  We are a (mostly) Cisco shop, but I'm  
> looking
> more for BCP and overall design, not provisioning specifics.
>
>
> -----
>
> My Cisco bookshelf isn't helping me much with this...
>
> We currently have a single POP with border/core/aggregation topology.
> Upstreams each come in on their own border router and the core is  
> used as a
> route-reflector for border and aggregation. The internal network  
> uses OSPF
> as an IGP and each device is dual-connected for redundancy on  
> independent
> layer-2 networks.  OSPF load-shares with loopback IPs and IBGP uses  
> the
> loopback addresses for peering.
>
> We are looking at turning up two additional POPs in the metro area,  
> each
> connected by redundant GigE loops to the original POP.  Each POP may  
> have
> zero or more direct upstream connections.  I'd like local traffic at  
> each
> POP to prefer both in and outbound traffic via the local upstream,  
> but still
> be able to failover to upstreams at other POPs if needed.
>
> My initial thoughts are to BGP peer between POPs with a higher local- 
> pref
> for the local outbound traffic and to prepend between the POPs so  
> inbound
> traffic is more likely to take the shortest path inbound.
>
>
> Is this too simplistic? Prone to trouble? What gotchas should I be  
> looking
> at, or other designs should I be considering?




From lsc at prgmr.com  Mon Sep 21 01:29:56 2009
From: lsc at prgmr.com (Luke S Crawford)
Date: 21 Sep 2009 02:29:56 -0400
Subject: cross connect reliability
In-Reply-To: <20090917234547.GT51443@gerbil.cluepon.net>
References: <1253223936.6803.391.camel@mike-desktop>
	<4AB2AFAF.50900@rollernet.us>
	<7C79FE41-AA98-40C5-BBC6-EB0FD919A91B@americafree.tv>
	<4AB2B9B9.60406@thewybles.com>
	<20090917234547.GT51443@gerbil.cluepon.net>
Message-ID: 

Richard A Steenbergen  writes:
> 
> You've never seen a single port go bad on a switch? I can't even count
> the number of times I've seen that happen. Not that I'm not suggesting 
> the OP wasn't the victim of a human error like unplugging the wrong port 
> and they just lied to him, that happens even more.

I know it happens;  it's happened to me, and I have probably touched fewer
switches than you.  Still, from what I can understand, it can be
prevented/minimized by the use of a grounded port.


from: 
http://support.3com.com/documents/switches/baseline/3Com-Switch-Family_Safety-Reg-Info.pdf


"CAUTION: If you want to install the Switch using a Category 5E or
Category 6 cable, 3Com recommends that you briefly connect the cable
to a grounded port before you connect to the network equipment. If you
do not, the cable?s electrostatic discharge (ESD) may damage the Switch's
port.

You can create a grounded port by connecting all wires at one end of a
UTP cable to an earth ground point, and the other end to a female RJ-45
connector located, for example, on a Switch rack or patch panel. The
RJ-45 connector is now a grounded port."



From sethm at rollernet.us  Mon Sep 21 01:48:56 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Sun, 20 Sep 2009 23:48:56 -0700
Subject: cross connect reliability
In-Reply-To: 
References: <1253223936.6803.391.camel@mike-desktop>	<4AB2AFAF.50900@rollernet.us>	<7C79FE41-AA98-40C5-BBC6-EB0FD919A91B@americafree.tv>	<4AB2B9B9.60406@thewybles.com>	<20090917234547.GT51443@gerbil.cluepon.net>
	
Message-ID: <4AB721D8.4040306@rollernet.us>

Luke S Crawford wrote:
> Richard A Steenbergen  writes:
>> You've never seen a single port go bad on a switch? I can't even count
>> the number of times I've seen that happen. Not that I'm not suggesting 
>> the OP wasn't the victim of a human error like unplugging the wrong port 
>> and they just lied to him, that happens even more.
> 
> I know it happens;  it's happened to me, and I have probably touched fewer
> switches than you.  Still, from what I can understand, it can be
> prevented/minimized by the use of a grounded port.
> 
> 
> from: 
> http://support.3com.com/documents/switches/baseline/3Com-Switch-Family_Safety-Reg-Info.pdf
> 
> 
> "CAUTION: If you want to install the Switch using a Category 5E or
> Category 6 cable, 3Com recommends that you briefly connect the cable
> to a grounded port before you connect to the network equipment. If you
> do not, the cable?s electrostatic discharge (ESD) may damage the Switch's
> port.
> 
> You can create a grounded port by connecting all wires at one end of a
> UTP cable to an earth ground point, and the other end to a female RJ-45
> connector located, for example, on a Switch rack or patch panel. The
> RJ-45 connector is now a grounded port."
> 


HP chassis switches ship with a grounding jack accessory you attach to
the DB9 port (I assume it ties all RJ-45 pins to shied/ground)
explicitly for this purpose. The instructions say to always plug a cable
into the grounding device before connecting to a switch port.

~Seth



From andy at nosignal.org  Mon Sep 21 07:26:50 2009
From: andy at nosignal.org (Andy Davidson)
Date: Mon, 21 Sep 2009 13:26:50 +0100
Subject: Multi-homed implementation and BGP convergence time
In-Reply-To: 
References: 
Message-ID: 


On 11 Sep 2009, at 21:54, Andrew.Claybaugh at securian.com wrote:

> Hello - my company currently has two connections with a single tier  
> 1 ISP. We are using the AS from our ISP at this time.  In the next  
> month we will be implementing a third connection with a second tier  
> 1 ISP, so we will now be using our own AS number on all three routers.

Does this mean that right now, you BGP peer with your ISP on a private  
ASN which they have given you ?

I also assume that you have your own PI, and that you are not  
deaggregating some of your providers' addressing ....

> My question is when we implement the new connection and update our  
> existing connections to use are own AS number, how much downtime  
> will there be?  So far the second ISP has only said that it could be  
> hours for BGP to fully converge.  We are looking for more detail  
> about how long the outage will be and how widespread.

It will be hours if you don't plan the work in advance, but if you  
partner with someone who rolls this stuff out all of the time to plan  
and execute the work, then there will be a short amount of downtime.

If your kit supports local-as, then I would roll this out in a few  
phases.

  - Migrate to your new ASN for ibgp, use local-as to announce via the  
old asn on your ebgp session with ISP1.  This is the bit where the  
service disruption will be.  By keeping the scope of this window  
small, you increase the chances of this disruptive maintenance working  
fine.
  - Turn up isp2.  Test, thoroughly.
  - Migrate isp1 from the private asn to your new public asn.  All  
traffic should pass through isp2, so disruption should be limited.  
Test, thoroughly.

> Will it be relatively short to our customers that are on one of the  
> ISPs we are directly connected to?  Is downtime less for customers  
> on other tier 1 ISPs versus tier 2, etc. ISPs?

Downtime is less the more competent your ISP. :-)  "Tierness" is not a  
measure of this.

Sorry for the late reply, if this still needs to be rolled out, then  
we can help.



Best wishes
Andy



-- 
Regards, Andy Davidson       +44 (0)20 7993 1700       www.netsumo.com
NetSumo  Specialist networks consultancy for ISPs, Whitelabel 24/7 NOC
/* Opinions are mine & do not constitute policy of those I work for */










From rmoseley at softlayer.com  Mon Sep 21 11:00:16 2009
From: rmoseley at softlayer.com (Ric Moseley)
Date: Mon, 21 Sep 2009 11:00:16 -0500
Subject: subnet aggregation script
Message-ID: <98E72206041B1B408D3F92E91E80BF1802750530@slmail101.softlayer.local>

Does anyone know of a tool/script that can aggregate subnets feed to it
via command line?  Meaning if I give it multiple /30s (or any size
subnet) it will scrunch them together. 

 

Example: 

 

#aggregate_subnets.script 192.168.0.0/30 192.168.0.4/30 10.0.0.16/29
10.0.0.24/29

#192.168.0.0/29 10.0.0.16/28

 

Thanks. 

 

Ric Moseley

VP of Engineering

rmoseley at softlayer.com

214-442-0555 direct

972-989-7813 cell

214-442-0600 office

866-398-7638 toll-free

214-442-0601 fax

 

 

6400 International Parkway, Suite 2000
Plano, TX 75093
http://www.softlayer.com

 



The contents of this email message and any attachments are confidential and are intended solely for the addressee. The information may also be legally privileged. This transmission is sent in trust for the sole purpose of delivery to the intended recipient. If you have received this transmission in error; any use, reproduction or dissemination of this transmission is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply email and delete this message and all associated attachments. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 922 bytes
Desc: image001.gif
URL: 

From john-nanog at johnpeach.com  Mon Sep 21 11:09:40 2009
From: john-nanog at johnpeach.com (John Peach)
Date: Mon, 21 Sep 2009 12:09:40 -0400
Subject: subnet aggregation script
In-Reply-To: <98E72206041B1B408D3F92E91E80BF1802750530@slmail101.softlayer.local>
References: <98E72206041B1B408D3F92E91E80BF1802750530@slmail101.softlayer.local>
Message-ID: <20090921120940.17a6f994@jpeach-desktop.1425mad.mountsinai.org>

netmask:


netmask 192.168.0.0/30 192.168.0.4/30 10.0.0.16/29
      10.0.0.16/29
    192.168.0.0/29

Certainly available in the ubuntu repositories.




On Mon, 21 Sep 2009 11:00:16 -0500
"Ric Moseley"  wrote:

> Does anyone know of a tool/script that can aggregate subnets feed to
> it via command line?  Meaning if I give it multiple /30s (or any size
> subnet) it will scrunch them together. 
> 
>  
> 
> Example: 
> 
>  
> 
> #aggregate_subnets.script 192.168.0.0/30 192.168.0.4/30 10.0.0.16/29
> 10.0.0.24/29
> 
> #192.168.0.0/29 10.0.0.16/28
> 
>  
> 
> Thanks. 
> 
>  
> 
> Ric Moseley
> 
> VP of Engineering
> 
> rmoseley at softlayer.com
> 
> 214-442-0555 direct
> 
> 972-989-7813 cell
> 
> 214-442-0600 office
> 
> 866-398-7638 toll-free
> 
> 214-442-0601 fax
> 
>  
> 
>  
> 
> 6400 International Parkway, Suite 2000
> Plano, TX 75093
> http://www.softlayer.com
> 
>  
> 
> 
> 
> The contents of this email message and any attachments are
> confidential and are intended solely for the addressee. The
> information may also be legally privileged. This transmission is sent
> in trust for the sole purpose of delivery to the intended recipient.
> If you have received this transmission in error; any use,
> reproduction or dissemination of this transmission is strictly
> prohibited. If you are not the intended recipient, please immediately
> notify the sender by reply email and delete this message and all
> associated attachments. 


-- 
John



From nanog at ml.karotte.org  Mon Sep 21 11:18:02 2009
From: nanog at ml.karotte.org (Sebastian Wiesinger)
Date: Mon, 21 Sep 2009 18:18:02 +0200
Subject: Google Pagerank and "Class-C Addresses"
Message-ID: <20090921161802.GB27976@danton.fire-world.de>

Hello Nanog,

I'm looking into a weird request which more and more customers have.
They want "different Class C addresses", by which they mean IPs in
different /24 subnets.

The apparent reason for this is that Google will rank links from
different /24 higher then links from the same /24. So it's a SEO
thingy.

I googled a bit and found pages after pages of FUD and such great
things as the "Class C Checker":  "This free Class C Checker tool
allows you to check if some sites are hosted on the same Class C IP
Range."

My question is: Is there any proof that Google does differentiate
between /24s, or even better is there any proof that this isn't the
case? I will not give a customer space from different address blocks
just because he read it in a SEO magazine.

Perhaps someone from Google itself can answer this question?

Also how do you handle such requests? I expect I'm not the only one
who gets them.

Regards,

Sebastian

-- 
New GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
Old GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
            -- Terry Pratchett, The Fifth Elephant



From networkjedi at geekwhore.net  Mon Sep 21 11:22:49 2009
From: networkjedi at geekwhore.net (Nick Colton)
Date: Mon, 21 Sep 2009 10:22:49 -0600
Subject: Cisco 7600 vs ASR 9000
Message-ID: <497ac88a0909210922g416cae96t141c0e154d129347@mail.gmail.com>

I work for a small CLEC, we have been doing FTTP for 5 years now but are
getting ready to update our core network and introduce IPTV services.  Cisco
has been recommending the Cisco 7600 as our core router.  My concern is that
cisco told us that in the event of an RSP failover the 7600 could take up to
30 seconds to begin routing packets again, this seems wrong to me since my
old Extreme Networks BD 6808 can do failovers and rebuild route tables in
under 5 seconds but??  More recently I have been reading up on the ASR 9000
however and it appears that it would be better sized for our company than
the 7600.  A few questions I have for the group.
1.  Has anyone used the ASR 9000 in place of a Cisco 7600?

2.  Is the ASR 9000 Carrier ready?  Meaning 5x9's of availability, few
component failures, solid software...etc

3.  Has anyone had issues where it took the 7600 30 seconds to start routing
again after an RSP failover?

Thanks,

Nick


From jabley at hopcount.ca  Mon Sep 21 11:29:19 2009
From: jabley at hopcount.ca (Joe Abley)
Date: Mon, 21 Sep 2009 12:29:19 -0400
Subject: subnet aggregation script
In-Reply-To: <98E72206041B1B408D3F92E91E80BF1802750530@slmail101.softlayer.local>
References: <98E72206041B1B408D3F92E91E80BF1802750530@slmail101.softlayer.local>
Message-ID: 


On 2009-09-21, at 12:00, Ric Moseley wrote:

> Does anyone know of a tool/script that can aggregate subnets feed to  
> it
> via command line?  Meaning if I give it multiple /30s (or any size
> subnet) it will scrunch them together.

I wrote this years ago and we used it in 6461 for various things.

ftp://ftp.isc.org/isc/aggregate/aggregate-1.6.tar.gz

> Example:
>
> #aggregate_subnets.script 192.168.0.0/30 192.168.0.4/30 10.0.0.16/29
> 10.0.0.24/29
>
> #192.168.0.0/29 10.0.0.16/28

[octopus:~]% cat >input-file
192.168.0.0/30
192.168.0.4/30
10.0.0.16/29
10.0.0.24/29
[octopus:~]%
[octopus:~]% aggregate output-file
aggregate: maximum prefix length permitted will be 32
[octopus:~]% cat output-file
10.0.0.16/28
192.168.0.0/29
[octopus:~]%

It's quite bad at dealing with really long lists, but it's ok for  
small applications. There's a manual page, and options, and stuff. You  
can make it show its working, if you're worried about whether it is  
sane.

[octopus:~]% aggregate -v 
References: <497ac88a0909210922g416cae96t141c0e154d129347@mail.gmail.com>
Message-ID: <4AB7ABFE.107@ieee.org>


What about 7600-S models ?
I think Cisco is claiming that Cisco 7600-S (7606S, etc...) chassis is
ready for less than 50 ms switching time with right software.
For routing, you can setup graceful restart or something like that.


For Cisco ASR9000, I couldn't say much, because it is new product.
When I checked Cisco product lines around January 2009, it wasn't there.
So I consider it as still beta test product at customer's expense. :-)


Alex


Nick Colton wrote:
> I work for a small CLEC, we have been doing FTTP for 5 years now but are
> getting ready to update our core network and introduce IPTV services.  Cisco
> has been recommending the Cisco 7600 as our core router.  My concern is that
> cisco told us that in the event of an RSP failover the 7600 could take up to
> 30 seconds to begin routing packets again, this seems wrong to me since my
> old Extreme Networks BD 6808 can do failovers and rebuild route tables in
> under 5 seconds but??  More recently I have been reading up on the ASR 9000
> however and it appears that it would be better sized for our company than
> the 7600.  A few questions I have for the group.
> 1.  Has anyone used the ASR 9000 in place of a Cisco 7600?
>
> 2.  Is the ASR 9000 Carrier ready?  Meaning 5x9's of availability, few
> component failures, solid software...etc
>
> 3.  Has anyone had issues where it took the 7600 30 seconds to start routing
> again after an RSP failover?
>
> Thanks,
>
> Nick
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>   




From aaronh at bind.com  Mon Sep 21 11:58:44 2009
From: aaronh at bind.com (Aaron Hughes)
Date: Mon, 21 Sep 2009 09:58:44 -0700
Subject: West Coast U.S. interesting outage 21 Sept. ~1105h UTC
Message-ID: <20090921165844.GK1185@trace.bind.com>

All,

This morning around 0405h PDT there were several odd network outages around LA where packets simply stopped forwarding in several networks. I saw no circuit drops, however, several massive traffic drops. Thus far I have heard (unconfirmed) Telia had some kind of capacity drop / equipment failure and it has been fixed. Does anyone have any details on this and/or can confirm/deny this was a Telia outage?

Cheers,
Aaron


-- 

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 fabio.mendes at bsd.com.br  Mon Sep 21 12:08:34 2009
From: fabio.mendes at bsd.com.br (Fabio Mendes)
Date: Mon, 21 Sep 2009 14:08:34 -0300
Subject: 802.17b Case studies and current usage on Metro Ethernets
Message-ID: 

I'd appreciate if someone could answer some of my questions:


1. What vendors currently offer support to the IEEE 802.17b standard ?

2. After extensive searching, have found no case studies. Do you guys could
recomend any ?

3. If someone had been envolved with 802.17's deployments, what are your
thoughts about it ? I mean, the whole process as well as the benefits (and
problems) that arose.



Thanks !


From mike.gazzerro at nobistech.net  Mon Sep 21 12:18:30 2009
From: mike.gazzerro at nobistech.net (Mike Gazzerro)
Date: Mon, 21 Sep 2009 12:18:30 -0500
Subject: Google Pagerank and "Class-C Addresses"
In-Reply-To: <20090921161802.GB27976@danton.fire-world.de>
References: <20090921161802.GB27976@danton.fire-world.de>
Message-ID: <18DCD1A1EB78DF41B564964698425DE23FBB41EB04@srv372.exchange.nobistech.net>

Matt Cutts, who works for Google, has iterated over and over that this is absolutely, positively, not the case and does not help page rank: http://www.mattcutts.com/blog/myth-busting-virtual-hosts-vs-dedicated-ip-addresses/

So there's an answer from someone at Google.

How do I answer such requests?  I tell them they if they want to waste their money, that's what this service is for:
http://www.seohosting.com/

Regards,
Mike Gazzerro
www.ubiquityservers.com
866-438-8247 x 500

-----Original Message-----
From: Sebastian Wiesinger [mailto:nanog at ml.karotte.org] 
Sent: Monday, September 21, 2009 11:18 AM
To: NANOG
Subject: Google Pagerank and "Class-C Addresses"

Hello Nanog,

I'm looking into a weird request which more and more customers have.
They want "different Class C addresses", by which they mean IPs in
different /24 subnets.

The apparent reason for this is that Google will rank links from
different /24 higher then links from the same /24. So it's a SEO
thingy.

I googled a bit and found pages after pages of FUD and such great
things as the "Class C Checker":  "This free Class C Checker tool
allows you to check if some sites are hosted on the same Class C IP
Range."

My question is: Is there any proof that Google does differentiate
between /24s, or even better is there any proof that this isn't the
case? I will not give a customer space from different address blocks
just because he read it in a SEO magazine.

Perhaps someone from Google itself can answer this question?

Also how do you handle such requests? I expect I'm not the only one
who gets them.

Regards,

Sebastian

-- 
New GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
Old GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
            -- Terry Pratchett, The Fifth Elephant




From joelja at bogus.com  Mon Sep 21 12:20:52 2009
From: joelja at bogus.com (Joel Jaeggli)
Date: Mon, 21 Sep 2009 10:20:52 -0700
Subject: Google Pagerank and "Class-C Addresses"
In-Reply-To: <20090921161802.GB27976@danton.fire-world.de>
References: <20090921161802.GB27976@danton.fire-world.de>
Message-ID: <4AB7B5F4.1030300@bogus.com>

Got to stop using classful addressing terminology... It's only been 16
or so years and you're not referring to:

192.0.0.0/5

Snake-oil salesmen abound in this space. More to the point, any
technique used to sculpt pank-rank scores on a systematic basis is
likely to result in a countervailing adjustment by search engine operators.

http://en.wikipedia.org/wiki/Search_engine_optimization

http://en.wikipedia.org/wiki/PageRank

Sebastian Wiesinger wrote:
> Hello Nanog,
> 
> I'm looking into a weird request which more and more customers have.
> They want "different Class C addresses", by which they mean IPs in
> different /24 subnets.
> 
> The apparent reason for this is that Google will rank links from
> different /24 higher then links from the same /24. So it's a SEO
> thingy.
> 
> I googled a bit and found pages after pages of FUD and such great
> things as the "Class C Checker":  "This free Class C Checker tool
> allows you to check if some sites are hosted on the same Class C IP
> Range."
> 
> My question is: Is there any proof that Google does differentiate
> between /24s, or even better is there any proof that this isn't the
> case? I will not give a customer space from different address blocks
> just because he read it in a SEO magazine.
> 
> Perhaps someone from Google itself can answer this question?
> 
> Also how do you handle such requests? I expect I'm not the only one
> who gets them.
> 
> Regards,
> 
> Sebastian
> 



From noah.adablah at africaonline.com.gh  Mon Sep 21 12:26:03 2009
From: noah.adablah at africaonline.com.gh (Noah Adablah)
Date: Mon, 21 Sep 2009 17:26:03 -0000
Subject: NEW ON THE BLOCK
Message-ID: <02cd01ca3ae0$9848beb0$c8da3c10$@adablah@africaonline.com.gh>

 
Hello,
I am new on the block.
 
Kind regards,

Noah Adablah 
RF Systems Manager
Africa Online Holdings Ltd
Tel : +233-21-211823
Cell: + 233 246541404
Email:   noahada at africaonline.com.gh 
AIM: noahadablah
cid:image001.jpg at 01C8D62B.E2CE7C60

A Member of the Telkom South Africa Group

Africa Online Disclaimer and Confidentiality Note 
This e-mail, its attachments and any rights attaching hereto are, unless the
context clearly indicates otherwise, the property of Africa Online Holdings
(Mauritius) Limited and / or its subsidiaries ("the Group"). It is
confidential and intended for the addressee only. Should you not be the
addressee and have received this e-mail by mistake, kindly notify the
sender, delete this e-mail immediately and do not disclose or use the same
in any manner whatsoever. Views and opinions expressed in this e-mail are
those of the sender unless clearly stated as those of the Group. The Group
accepts no liability whatsoever for any loss or damages, however incurred,
resulting from the use of this e-mail or its attachments. The Group does not
warrant the integrity of this e-mail, nor that it is free of errors,
viruses, interception or interference. For more information about Africa
Online, please visit our website at  
http://www.africaonline.com
 
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 4627 bytes
Desc: not available
URL: 

From bmanning at vacation.karoshi.com  Mon Sep 21 12:28:11 2009
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Mon, 21 Sep 2009 17:28:11 +0000
Subject: NEW ON THE BLOCK
In-Reply-To: <02cd01ca3ae0$9848beb0$c8da3c10$@adablah@africaonline.com.gh>
References: <02cd01ca3ae0$9848beb0$c8da3c10$@adablah@africaonline.com.gh>
Message-ID: <20090921172811.GA3738@vacation.karoshi.com.>

 welcome to North America.. :)

--bill


On Mon, Sep 21, 2009 at 05:26:03PM -0000, Noah Adablah wrote:
>  
> Hello,
> I am new on the block.
>  
> Kind regards,
> 
> Noah Adablah 
> RF Systems Manager
> Africa Online Holdings Ltd
> Tel : +233-21-211823
> Cell: + 233 246541404
> Email:   noahada at africaonline.com.gh 
> AIM: noahadablah
> cid:image001.jpg at 01C8D62B.E2CE7C60
> 
> A Member of the Telkom South Africa Group
> 
> Africa Online Disclaimer and Confidentiality Note 

	does not apply to me or my posts.


--bill



From nenolod at systeminplace.net  Mon Sep 21 13:01:56 2009
From: nenolod at systeminplace.net (William Pitcock)
Date: Mon, 21 Sep 2009 13:01:56 -0500
Subject: Google Pagerank and "Class-C Addresses"
In-Reply-To: <20090921161802.GB27976@danton.fire-world.de>
References: <20090921161802.GB27976@danton.fire-world.de>
Message-ID: <1253556116.25881.8.camel@petrie>

On Mon, 2009-09-21 at 18:18 +0200, Sebastian Wiesinger wrote:
> Hello Nanog,
> 
> I'm looking into a weird request which more and more customers have.
> They want "different Class C addresses", by which they mean IPs in
> different /24 subnets.
> 
> The apparent reason for this is that Google will rank links from
> different /24 higher then links from the same /24. So it's a SEO
> thingy.
> 

They are wrong.  Unfortunately, this is a rumour that is being cashed in
greatly by companies like GotWebHost.com, which offer "SEO hosting".
They may honestly believe that this is true, it is not.  Infact, IPs
have nothing to do at all, with PageRank, and don't let any of these SEO
crackheads tell you otherwise.

A google employee blogged about this topic at: 
http://www.mattcutts.com/blog/myth-busting-virtual-hosts-vs-dedicated-ip-addresses/

> I googled a bit and found pages after pages of FUD and such great
> things as the "Class C Checker":  "This free Class C Checker tool
> allows you to check if some sites are hosted on the same Class C IP
> Range."
> 
> My question is: Is there any proof that Google does differentiate
> between /24s, or even better is there any proof that this isn't the
> case? I will not give a customer space from different address blocks
> just because he read it in a SEO magazine.

As said above: No, it is not true.  Further, SEO is mostly a load of
bullshit that only delivers temporary results, as the search engines
will change their algorithms, etcetera.

> 
> Perhaps someone from Google itself can answer this question?
> 
> Also how do you handle such requests? I expect I'm not the only one
> who gets them.

It depends on how much money they pay me.

If they pay me a lot of money, then I will likely give them what they
want.  If not, well, that's too bad for them.

It doesn't matter to me, regardless, provided that they aren't violating
my AUP by you know, spamming or something along those lines.  In those
cases, well, they probably wouldn't be asking for more IPs, because they
would be offline.

William
-- 
William Pitcock                 SystemInPlace - Simple Hosting Solutions
1-866-519-6149                             http://www.systeminplace.net/
Follow us on Twitter:               http://www.twitter.com/systeminplace




From ray at oneunified.net  Mon Sep 21 13:12:03 2009
From: ray at oneunified.net (Ray Burkholder)
Date: Mon, 21 Sep 2009 15:12:03 -0300
Subject: Google Pagerank and "Class-C Addresses"
In-Reply-To: <1253556116.25881.8.camel@petrie>
References: <20090921161802.GB27976@danton.fire-world.de>
	<1253556116.25881.8.camel@petrie>
Message-ID: <025201ca3ae7$059f68f0$10de3ad0$@net>

> >
> > The apparent reason for this is that Google will rank links from
> > different /24 higher then links from the same /24. So it's a SEO
> > thingy.
> >

Just in case anyone cares, from personal experience, I can see that Google's
priority is indeed 'rank by content'.  Everything else is fluff.  I've
chosen a key phrase or two, and incorporated them multiple times into a blog
entry.  Looking at Google a couple of days later for those key words, and I
can get a top three ranking quite easily.

Ray


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




From scott at doc.net.au  Mon Sep 21 14:28:39 2009
From: scott at doc.net.au (Scott Howard)
Date: Mon, 21 Sep 2009 12:28:39 -0700
Subject: Google Pagerank and "Class-C Addresses"
In-Reply-To: <025201ca3ae7$059f68f0$10de3ad0$@net>
References: <20090921161802.GB27976@danton.fire-world.de>
	<1253556116.25881.8.camel@petrie>
	<025201ca3ae7$059f68f0$10de3ad0$@net>
Message-ID: 

On Mon, Sep 21, 2009 at 11:12 AM, Ray Burkholder  wrote:

> Just in case anyone cares, from personal experience, I can see that
> Google's
> priority is indeed 'rank by content'.  Everything else is fluff.


This is not true.  It's been well documented that PageRank uses a number of
metrics, probably the most important of them (in terms of ranking) being the
number of links to a page or site (and I believe, the PageRank of the
pages/websites those links come from).

One of my websites has consistently been in the top 10 or at worst top 20
results when searching for the word "megapixel" despite the word only
appearing on the resulting page about 4 times - if it was simply content
based there's no way that site would be ranked so highly.

  Scott.


From dhubbard at dino.hostasaurus.com  Mon Sep 21 14:35:45 2009
From: dhubbard at dino.hostasaurus.com (David Hubbard)
Date: Mon, 21 Sep 2009 15:35:45 -0400
Subject: Google Pagerank and "Class-C Addresses"
Message-ID: 

From: Scott Howard [mailto:scott at doc.net.au] 
> 
> 
> This is not true.  It's been well documented that PageRank 
> uses a number of
> metrics, probably the most important of them (in terms of 
> ranking) being the
> number of links to a page or site (and I believe, the PageRank of the
> pages/websites those links come from).
> 
> One of my websites has consistently been in the top 10 or at 
> worst top 20
> results when searching for the word "megapixel" despite the word only
> appearing on the resulting page about 4 times - if it was 
> simply content
> based there's no way that site would be ranked so highly.

Matt Cutts from Google has publicly stated this to not
be true; if it is true and he was lying, then everyone
hosted at a large provider would be penalized for doing
so from an SEO perspective since the likelihood of being
on a 'close' network to similar content would be high
when you've got hosts running hundreds of thousands
of name-based sites off one /24.  Actually he stated this
to not be true in response to a thread I started on this
list about this subject several years ago when I was
complaining about Google causing IPv4 exhaustion due to
people asking hosts, with some willing, to give them a
bunch of IP's on different /24's for SEO purposes when there
is no technical justification for it.  We've had customers
leave and go elsewhere after refusing to give them IP's
they didn't need because they were convinced by some
SEO 'expert' that they need a bunch of doorway sites on
a variety of /24's.  If someone is willing to leave their
host over that, there are certainly going to be hosts 
willing to dish up IP's for SEO reasons, and the waste of
addresses continues.

David



From leo.vegoda at icann.org  Mon Sep 21 10:47:46 2009
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Mon, 21 Sep 2009 08:47:46 -0700
Subject: 2/8 and 46/8 allocated to the RIPE NCC
Message-ID: 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

The IANA IPv4 registry has been updated to reflect the allocation
of two /8 IPv4 blocks to the RIPE NCC in September 2009: 2/8 and
46/8. You can find the IANA IPv4 registry at:

http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt

Please update your filters as appropriate.

The IANA free pool contains 26 unallocated unicast IPv4 /8s.

Regards,

Leo Vegoda
Number Resources Manager, IANA

-----BEGIN PGP SIGNATURE-----
Version: 9.10.0.500

wj8DBQFKt6AdvBLymJnAzRwRAiscAKDaqyQYv8YLcXsg/tubUBe1THTNIACfQ0iP
23SVpODdlrWi0qEuEHVbi5c=
=DVak
-----END PGP SIGNATURE-----




From drais at icantclick.org  Mon Sep 21 15:09:29 2009
From: drais at icantclick.org (david raistrick)
Date: Mon, 21 Sep 2009 16:09:29 -0400 (EDT)
Subject: Google Pagerank and "Class-C Addresses"
In-Reply-To: 
References: 
Message-ID: 

On Mon, 21 Sep 2009, David Hubbard wrote:

> We've had customers leave and go elsewhere after refusing to give them 
> IP's they didn't need because they were convinced by some SEO 'expert' 
> that they need a bunch of doorway sites on a variety of /24's.  If 
> someone is willing to leave their host over that, there are certainly 
> going to be hosts willing to dish up IP's for SEO reasons, and the waste 
> of addresses continues.


I'll take that one further:

I got -fired- my first day after explaining why using proxy servers spread 
across the world to "present" websites from different IP addresses a) did 
nothing to help their search result rankings and b) was a complete waste 
of resources.....


Some people just don't want to know.


--
david raistrick        http://www.netmeister.org/news/learn2quote.html
drais at icantclick.org             http://www.expita.com/nomime.html




From drais at icantclick.org  Mon Sep 21 15:12:39 2009
From: drais at icantclick.org (david raistrick)
Date: Mon, 21 Sep 2009 16:12:39 -0400 (EDT)
Subject: Google Pagerank and "Class-C Addresses"
In-Reply-To: 
References: 
	
Message-ID: 

On Mon, 21 Sep 2009, david raistrick wrote:

> I got -fired- my first day after explaining why using proxy servers spread

I should note that I was asked what I'd do with that type of setup, and 
assumed it was either a hypothetical situation or something that they were 
looking to address....I had no idea that they actually -did- that and 
thought it was great until after I'd answered.

I could have been a bit more PC with my answer if I'd wanted to...but then 
again....why? :)


--
david raistrick        http://www.netmeister.org/news/learn2quote.html
drais at icantclick.org             http://www.expita.com/nomime.html




From jeffrey.lyon at blacklotus.net  Mon Sep 21 15:26:49 2009
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Mon, 21 Sep 2009 16:26:49 -0400
Subject: Google Pagerank and "Class-C Addresses"
In-Reply-To: 
References: 
	
Message-ID: <16720fe00909211326r39d85e47w91f899426cd987dc@mail.gmail.com>

We used to have a lot of people buying IP's in bulk for SEO. They
would all cancel within one or two months citing that they couldn't
afford it or the project failed, etc. Guess they realized that the
whole thing is a myth.

Jeff

On Mon, Sep 21, 2009 at 4:09 PM, david raistrick  wrote:
> On Mon, 21 Sep 2009, David Hubbard wrote:
>
>> We've had customers leave and go elsewhere after refusing to give them
>> IP's they didn't need because they were convinced by some SEO 'expert' that
>> they need a bunch of doorway sites on a variety of /24's. ?If someone is
>> willing to leave their host over that, there are certainly going to be hosts
>> willing to dish up IP's for SEO reasons, and the waste of addresses
>> continues.
>
>
> I'll take that one further:
>
> I got -fired- my first day after explaining why using proxy servers spread
> across the world to "present" websites from different IP addresses a) did
> nothing to help their search result rankings and b) was a complete waste of
> resources.....
>
>
> Some people just don't want to know.
>
>
> --
> david raistrick ? ? ? ?http://www.netmeister.org/news/learn2quote.html
> drais at icantclick.org ? ? ? ? ? ? http://www.expita.com/nomime.html
>
>
>



-- 
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 if at xip.at  Mon Sep 21 16:01:34 2009
From: if at xip.at (Ingo Flaschberger)
Date: Mon, 21 Sep 2009 23:01:34 +0200 (CEST)
Subject: Google Pagerank and "Class-C Addresses"
In-Reply-To: <16720fe00909211326r39d85e47w91f899426cd987dc@mail.gmail.com>
References: 
	
	<16720fe00909211326r39d85e47w91f899426cd987dc@mail.gmail.com>
Message-ID: 

Hey,

I should tell my customers that the cross sum of the domains ip
also count to the pagerank, and the ip 255.255.255.255 is the best of all.

bye,
 	ingo flaschberger



From leslie at craigslist.org  Mon Sep 21 18:20:06 2009
From: leslie at craigslist.org (Leslie)
Date: Mon, 21 Sep 2009 16:20:06 -0700
Subject: Google Pagerank and "Class-C Addresses"
In-Reply-To: <20090921161802.GB27976@danton.fire-world.de>
References: <20090921161802.GB27976@danton.fire-world.de>
Message-ID: <4AB80A26.2060102@craigslist.org>



Sebastian Wiesinger wrote:
> Hello Nanog,
> 
> I'm looking into a weird request which more and more customers have.
> They want "different Class C addresses", by which they mean IPs in
> different /24 subnets.
> 
> The apparent reason for this is that Google will rank links from
> different /24 higher then links from the same /24. So it's a SEO
> thingy.
> 

I've found that a lot of spammers enjoy having diverse ip's from which 
to mail/proxy requests.  This may just be a case of ignorance/rumors on 
your customers part, but I might suspect some of them of being spammers...

Leslie





From jeffw at he.net  Mon Sep 21 18:42:08 2009
From: jeffw at he.net (Jeff Walter)
Date: Mon, 21 Sep 2009 16:42:08 -0700
Subject: subnet aggregation script
In-Reply-To: <98E72206041B1B408D3F92E91E80BF1802750530@slmail101.softlayer.local>
References: <98E72206041B1B408D3F92E91E80BF1802750530@slmail101.softlayer.local>
Message-ID: <4AB80F50.4040408@he.net>

Ric Moseley wrote:
> Does anyone know of a tool/script that can aggregate subnets feed to it
> via command line?  Meaning if I give it multiple /30s (or any size
> subnet) it will scrunch them together. 

Here is a Perl script to do just that.  My normal one reads from STDIN.

#!/usr/bin/perl

use Net::CIDR::Lite;

my $cidr = Net::CIDR::Lite->new ();

foreach (@ARGV) {
	if (/^[0-9a-f\.:]+(\/\d+)?$/) {
        	        $cidr->add_any ($_);
         }
}

print (join ("\n", $cidr->list ()));



From adrian at creative.net.au  Mon Sep 21 20:09:24 2009
From: adrian at creative.net.au (Adrian Chadd)
Date: Tue, 22 Sep 2009 09:09:24 +0800
Subject: Google Pagerank and "Class-C Addresses"
In-Reply-To: <16720fe00909211326r39d85e47w91f899426cd987dc@mail.gmail.com>
References: 
	
	<16720fe00909211326r39d85e47w91f899426cd987dc@mail.gmail.com>
Message-ID: <20090922010924.GH9496@skywalker.creative.net.au>

On Mon, Sep 21, 2009, Jeffrey Lyon wrote:
> We used to have a lot of people buying IP's in bulk for SEO. They
> would all cancel within one or two months citing that they couldn't
> afford it or the project failed, etc. Guess they realized that the
> whole thing is a myth.

.. or, which is more likely given my brief exposure to this crap, the
search engines cottoned on and changed the metrics again.




adrian




From ops.lists at gmail.com  Mon Sep 21 20:21:45 2009
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Tue, 22 Sep 2009 06:51:45 +0530
Subject: Google Pagerank and "Class-C Addresses"
In-Reply-To: <16720fe00909211326r39d85e47w91f899426cd987dc@mail.gmail.com>
References: 
	
	<16720fe00909211326r39d85e47w91f899426cd987dc@mail.gmail.com>
Message-ID: 

On Tue, Sep 22, 2009 at 1:56 AM, Jeffrey Lyon
 wrote:
> We used to have a lot of people buying IP's in bulk for SEO. They
> would all cancel within one or two months citing that they couldn't
> afford it or the project failed, etc. Guess they realized that the
> whole thing is a myth.

Or they burned through all those IPs, google penalized domains on
those IPs for obvious SEO gaming and they've now gone off to poison
some other IP space

--srs



From erickbe at yahoo.com  Tue Sep 22 01:54:48 2009
From: erickbe at yahoo.com (Erick Bergquist)
Date: Mon, 21 Sep 2009 23:54:48 -0700 (PDT)
Subject: Contact w/ clue re: AT&T SMS email gateway?
In-Reply-To: <4AB23A44.33E4.0097.0@globalstar.com>
References: <4AB2881B.5090103@gmail.com> <4AB23A44.33E4.0097.0@globalstar.com>
Message-ID: <362201.22716.qm@web112617.mail.gq1.yahoo.com>

I am having this problem the past week or so as well, along  with some friends. 
Have a iPhone 3GS also. However, seemed to be fine Monday. 




----- Original Message ----
From: Crist Clark 
To: nanog at nanog.org; Dave Pascoe 
Sent: Thursday, September 17, 2009 3:31:51 PM
Subject: Contact w/ clue re: AT&T SMS email gateway?

>>> On 9/17/2009 at 12:03 PM, Dave Pascoe  wrote:
> Recently something seems to have changed with the @txt.att.net email to
> SMS gateway.  Messages sent through the gateway suffer from the following:
> 
> 1) Long delay in reaching the phone (intermittent)
>    (yes I know there is no latency guarantee)
> 
> and, even more crippling,
> 
> 2) Message comes through as just "SMS Message" instead of the SMTP
> message content.  And the sender is always 410-000-01x, where x
> increments by 1 with each new incoming email-to-SMS gateway-handled message.
> 
> Phone is an iPhone 3GS.  This has worked fine for quite a while.  No
> changes on the iPhone.
> 
> I have gone through normal AT&T Wireless Customer Service but there
> isn't much clue there - had to explain what an email to SMS gateway is.
> 
> Anyone elese seeing this?  Anyone from AT&T Wireless here?

If you do find anyone, can you ask them about the really annoying
reject-after-DATA problem?

That is, if 555-555-1234, for some reason is not authorized to receive
SMS, you get a 250 response after RCPT TO, but a 5xx after the DATA
is sent. So if the message had multiple recipients, some of which are
allowed to receive SMS, the message then fails for all of them.

Verizon also has this problem, BTW.


      



From karnaugh at karnaugh.za.net  Tue Sep 22 03:24:02 2009
From: karnaugh at karnaugh.za.net (Colin Alston)
Date: Tue, 22 Sep 2009 10:24:02 +0200
Subject: SA pigeon 'faster than broadband'
In-Reply-To: <20090911115402.A670B0C9@resin13.mta.everyone.net>
References: <20090911115402.A670B0C9@resin13.mta.everyone.net>
Message-ID: <78bfcf050909220124lf1c0e1dt1a392b60f18f45c9@mail.gmail.com>

On Fri, Sep 11, 2009 at 8:54 PM, Scott Weeks  wrote:

>
> It would be nice to know what those recommendations were...
>
>
Excuse the delayed reply from a SA person :)

I'm guessing the recommendations were not to use an asymmetrical service for
trying to upload large amounts of data.

Ironically the company in question has access to MetroFibre (
http://www.durban.gov.za/durban/services/images-and-documentation/metroconnect.pdf),
but as with most Durban businesses and callcenter mentality in general -
they want carrier class upstream for home user money... There is a point to
be made that in SA "home user money" can get you a GE port at LoNAP. Still
many people don't understand the whole "you get what you pay for" thing, and
they expect blazingly fast internet on whatever they buy even if they have
100 users sharing it and all streaming Youtube concurrently.

They could of course also use a symmetrical wimax or wifi solution (we have
a couple of those now, I use one at my home office). And there are lots of
people doing bonded ADSL systems for people who want to scale downstream
capacity on the cheap.

Not really a monopoly anymore, but there is still a big lack of clue all
around (especially with Neotel who currently provision Seacom). It took for
example 2 weeks to convince my WiMAX ISP that ATPC was causing my uplink
encoding to downgrade to BPSK because the noise floor was too unstable, or
the tower was misconfiguration, or something - eventually I had to break
into the CPE and fix it myself...

So sadly Telkom ADSL still represents the best cost and reliability point
for many peoples use.

This particular story though was just a cheap publicity stunt that was
thwarted by the entire industry as specious.


From jp at seminte.lt  Tue Sep 22 04:59:26 2009
From: jp at seminte.lt (jp at seminte.lt)
Date: Tue, 22 Sep 2009 12:59:26 +0300
Subject: TDM data analyzer
Message-ID: <20090922125926.lwqbjpnb44w4wk00@webmail.moksleiviai.lt>

Hello fellow NANOGers. Slightly offtopic, but I would greatly appreciate
your suggestions. For my telecommunications engineering degree I am
designing a TDM data analyzer, and I need suggestion, what you would like in
an appliance like that.

Right now my idea is that it should be a transparent device that plugs in
between two E1/T1/J1 devices and then connect to FastEthernet for data
uplink. All data traveling between two devices is sent to central server
that can accept data from one or more capture devices.

End user (i.e. NANOGer debugging a problem) has a program to connect to data
acquisition server and can see decoded Q921/Q931 signaling data and to
play-out what's happening in any one of voice channels. BERT tester and
signal level indication with remote fault monitoring and logging would be
included also. End user will have ability to record voice data with
supplemental information too.

So my question to the community is what other features you would like to see
in a device? And most of all - if you had a device like that would you find
it useful?

All replies off list greatly appreciated.  I would like to ask people to
forward this email to colleagues that work with voice systems or to a voice
operators group if you are a member of one.

Thanks a lot,
Justin

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.




From jared at puck.nether.net  Tue Sep 22 06:09:39 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 22 Sep 2009 04:09:39 -0700
Subject: Cisco 7600 vs ASR 9000
In-Reply-To: <497ac88a0909210922g416cae96t141c0e154d129347@mail.gmail.com>
References: <497ac88a0909210922g416cae96t141c0e154d129347@mail.gmail.com>
Message-ID: 

This question would likely be better answered on cisco-nsp.

But the asr9k provides a better roadmap than the 7600/6500 platform.  
These are now quite old platforms in the overall lifecycle. The 9k  
also runs xr which is either an asset or liability depending on your  
network.

Me? I always want a box that provides good diagnostics and protected  
memory over one that does not. Bugs happen, software is imperfect. I  
want a device that provides the best possible debuging information  
when it comes to support time.

These items are not there in regular ios, and IMHO ios-xe does not  
really qualify (but is better, just like the ion/modular 6500 code).

Jared Mauch

On Sep 21, 2009, at 9:22 AM, Nick Colton   
wrote:

> I work for a small CLEC, we have been doing FTTP for 5 years now but  
> are
> getting ready to update our core network and introduce IPTV  
> services.  Cisco
> has been recommending the Cisco 7600 as our core router.  My concern  
> is that
> cisco told us that in the event of an RSP failover the 7600 could  
> take up to
> 30 seconds to begin routing packets again, this seems wrong to me  
> since my
> old Extreme Networks BD 6808 can do failovers and rebuild route  
> tables in
> under 5 seconds but??  More recently I have been reading up on the  
> ASR 9000
> however and it appears that it would be better sized for our company  
> than
> the 7600.  A few questions I have for the group.
> 1.  Has anyone used the ASR 9000 in place of a Cisco 7600?
>
> 2.  Is the ASR 9000 Carrier ready?  Meaning 5x9's of availability, few
> component failures, solid software...etc
>
> 3.  Has anyone had issues where it took the 7600 30 seconds to start  
> routing
> again after an RSP failover?
>
> Thanks,
>
> Nick



From abalashov at evaristesys.com  Tue Sep 22 07:01:08 2009
From: abalashov at evaristesys.com (Alex Balashov)
Date: Tue, 22 Sep 2009 08:01:08 -0400
Subject: TDM data analyzer
In-Reply-To: <20090922125926.lwqbjpnb44w4wk00@webmail.moksleiviai.lt>
References: <20090922125926.lwqbjpnb44w4wk00@webmail.moksleiviai.lt>
Message-ID: <4AB8BC84.1020004@evaristesys.com>

jp at seminte.lt wrote:

> Hello fellow NANOGers. Slightly offtopic, but I would greatly appreciate
> your suggestions. For my telecommunications engineering degree I am
> designing a TDM data analyzer, and I need suggestion, what you would 
> like in
> an appliance like that.
> 
> Right now my idea is that it should be a transparent device that plugs in
> between two E1/T1/J1 devices and then connect to FastEthernet for data
> uplink. All data traveling between two devices is sent to central server
> that can accept data from one or more capture devices.
> 
> End user (i.e. NANOGer debugging a problem) has a program to connect to 
> data
> acquisition server and can see decoded Q921/Q931 signaling data and to
> play-out what's happening in any one of voice channels. BERT tester and
> signal level indication with remote fault monitoring and logging would be
> included also. End user will have ability to record voice data with
> supplemental information too.
> 
> So my question to the community is what other features you would like to 
> see
> in a device? And most of all - if you had a device like that would you find
> it useful?
> 
> All replies off list greatly appreciated.  I would like to ask people to
> forward this email to colleagues that work with voice systems or to a voice
> operators group if you are a member of one.

Well, what do you presume to be entailed in "TDM?"  ISDN is not 
necessarily implied.  You could analyse E&M wink on D4 superframe.  ;) 
Much simpler.

-- 
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671



From zeusdadog at gmail.com  Tue Sep 22 09:34:05 2009
From: zeusdadog at gmail.com (Jay Nakamura)
Date: Tue, 22 Sep 2009 10:34:05 -0400
Subject: Google Pagerank and "Class-C Addresses"
In-Reply-To: <20090921161802.GB27976@danton.fire-world.de>
References: <20090921161802.GB27976@danton.fire-world.de>
Message-ID: <9418aca70909220734x30813070v7165770be72ab54d@mail.gmail.com>

On a similar issue, I have a debate going on in my company about SEO
and links coming from IP blocks allocated from different upstream
providers will improve page ranks.  (So, if I have block A from
provider 1 and block B from provider 2, web sites linking each other
on block A & B, the rank will go up)  Not just different /24, /24s
reassigned from different upstream.

I can't find anything to prove or dis-prove this theory.  Anyone have
a link or info on this issue/myth?

I shared this discussion thread and was told it's only discussing
different /24, not /24 allocated to different providers.

As far as I am concerned, if Google used ARIN swip record or routing
entry, it's going to identify us as the end provider so I can't see
how who gave us the IP would matter.


On Mon, Sep 21, 2009 at 12:18 PM, Sebastian Wiesinger
 wrote:
> Hello Nanog,
>
> I'm looking into a weird request which more and more customers have.
> They want "different Class C addresses", by which they mean IPs in
> different /24 subnets.
>
> The apparent reason for this is that Google will rank links from
> different /24 higher then links from the same /24. So it's a SEO
> thingy.
>
> I googled a bit and found pages after pages of FUD and such great
> things as the "Class C Checker": ?"This free Class C Checker tool
> allows you to check if some sites are hosted on the same Class C IP
> Range."
>
> My question is: Is there any proof that Google does differentiate
> between /24s, or even better is there any proof that this isn't the
> case? I will not give a customer space from different address blocks
> just because he read it in a SEO magazine.
>
> Perhaps someone from Google itself can answer this question?
>
> Also how do you handle such requests? I expect I'm not the only one
> who gets them.
>
> Regards,
>
> Sebastian
>
> --
> New GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A ?9D82 58A2 D94A 93A0 B9CE)
> Old GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20)
> 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
> ? ? ? ? ? ?-- Terry Pratchett, The Fifth Elephant
>
>



From fweimer at bfk.de  Tue Sep 22 09:49:04 2009
From: fweimer at bfk.de (Florian Weimer)
Date: Tue, 22 Sep 2009 14:49:04 +0000
Subject: Google Pagerank and "Class-C Addresses"
In-Reply-To: <20090921161802.GB27976@danton.fire-world.de> (Sebastian
	Wiesinger's message of "Mon\, 21 Sep 2009 18\:18\:02 +0200")
References: <20090921161802.GB27976@danton.fire-world.de>
Message-ID: <82y6o78273.fsf@mid.bfk.de>

* Sebastian Wiesinger:

> I'm looking into a weird request which more and more customers have.
> They want "different Class C addresses", by which they mean IPs in
> different /24 subnets.

It's not that weired at all.  Others demand the same because it
allegedly increases reliability.

> My question is: Is there any proof that Google does differentiate
> between /24s, or even better is there any proof that this isn't the
> case?

Good luck.  Google doesn't disclose their algorithms.  There doesn't
appear to be any Google statement on this matter, either.

-- 
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 jgreco at ns.sol.net  Tue Sep 22 09:58:53 2009
From: jgreco at ns.sol.net (Joe Greco)
Date: Tue, 22 Sep 2009 09:58:53 -0500 (CDT)
Subject: Google Pagerank and "Class-C Addresses"
In-Reply-To: <9418aca70909220734x30813070v7165770be72ab54d@mail.gmail.com>
	from "Jay Nakamura" at Sep 22, 2009 10:34:05 AM
Message-ID: <200909221458.n8MEwr5J031839@aurora.sol.net>

> On a similar issue, I have a debate going on in my company about SEO
> and links coming from IP blocks allocated from different upstream
> providers will improve page ranks.  (So, if I have block A from
> provider 1 and block B from provider 2, web sites linking each other
> on block A & B, the rank will go up)  Not just different /24, /24s
> reassigned from different upstream.
> 
> I can't find anything to prove or dis-prove this theory.  Anyone have
> a link or info on this issue/myth?
> 
> I shared this discussion thread and was told it's only discussing
> different /24, not /24 allocated to different providers.
> 
> As far as I am concerned, if Google used ARIN swip record or routing
> entry, it's going to identify us as the end provider so I can't see
> how who gave us the IP would matter.

If Google's even vaguely smart, they'll know to use a variety of ways
to automatically determine the closeness of IP addresses, including if
they're announced by the same ASN, have the same RDNS suffix, have any
commonalities in SWIP data, etc.

If I were Google and I were engaged in mere link-counting, I would take 
into consideration the statistical figures and note how often a URL is 
referenced from the Internet in general.  Then, I would look at how
often a URL is referenced from "nearby" URL's, exempting URL's that
are obviously components of the organization's web site, and then I 
would have some idea of whether or not someone was trying to game the
system.  This is relatively trivial to do, given the sort of data
Google has on the web.

I am not sure I would want to be on a list of sites-that-have-tried-to-
game-Google.  Who knows what sort of vengeful damage Google might inflict
on your PageRank.  :-)  (Just kidding Google!)  But seriously, just *how*
stupid do people think Google is?  They have massive resources and nutso
bright people who have looked at these problems.  To think that any 
trivially simplistic strategy that's been suggested for *years* now would
have an impact on PageRank strikes me as naive.

... 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 rossi at fidalia.com  Tue Sep 22 10:06:52 2009
From: rossi at fidalia.com (Shaun Rossi)
Date: Tue, 22 Sep 2009 11:06:52 -0400
Subject: SMS
Message-ID: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>

Hello,

                I have no idea what this is referred to as, so I will try to explain:  I have a client interested in setting up a mobile phone text message service where a mobile user would send a text to a short (say 5 digit) 'telephone' number.  I've seen commercials on TV where you could send a numeric/text code to a SMS gateway number, and it charges your mobile account for the returned text message or downloadable ringer/etc.

                Without knowing much about how to access this service, it seems relatively straightforward.

                I did a few web searches however I'm not sure what magic keyword I'm missing for the search.  Could anyone point me in the right direction?  The service would be established in Canada and potentially the United States.  I have called two of the largest mobile operators, but no one can get me to the right department.

As far as experience with texting goes, I have worked on some systems that do M2M (machine-to-machine) SMS communication, always using full mobile telephone numbers (GSM modems).

Many thanks,

-Shaun


Shaun Rossi
Fidalia Networks Inc
tel. (905) 271-0037 x 111
1-866-FIDALIA (343-2542) x 111
fax. (905) 271-1036

1 Port Street East - Second Floor
Mississauga, Ontario
L5G 4N1  Canada



From michael.holstein at csuohio.edu  Tue Sep 22 10:13:37 2009
From: michael.holstein at csuohio.edu (Michael Holstein)
Date: Tue, 22 Sep 2009 11:13:37 -0400
Subject: Google Pagerank and "Class-C Addresses"
In-Reply-To: <82y6o78273.fsf@mid.bfk.de>
References: <20090921161802.GB27976@danton.fire-world.de>
	<82y6o78273.fsf@mid.bfk.de>
Message-ID: <4AB8E9A1.90202@csuohio.edu>


> Good luck.  Google doesn't disclose their algorithms.  There doesn't
> appear to be any Google statement on this matter, either.
>   

No, but for "honest" folks, they do provide guidelines :

http://www.google.com/support/webmasters/bin/answer.py?answer=35769

One can't really fault Google for taking the attitude "do it right, then 
spend your money on advertising (with us). If you do it half-ass and 
spend your money on SEO instead, we might smite you".

Cheers,

Michael Holstein
Cleveland State University




From bill at edisys.co.uk  Tue Sep 22 10:17:58 2009
From: bill at edisys.co.uk (William Hamilton)
Date: Tue, 22 Sep 2009 16:17:58 +0100 (BST)
Subject: SMS
In-Reply-To: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>
References: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>
Message-ID: <5be65eb450cbe468daabd70e4f13e64d.squirrel@shiva.edisys.co.uk>


> Hello,
>
>                 I have no idea what this is referred to as, so I will try
> to explain:  I have a client interested in setting up a
> mobile phone text message service where a mobile user
> would send a text to a short (say 5 digit) 'telephone'
> number.  I've seen commercials on TV where you could send
> a numeric/text code to a SMS gateway number, and it
> charges your mobile account for the returned text message
> or downloadable ringer/etc.

*snip*

These are SMS short codes.

Essentially you purchase service from an SMS aggregator (that's your
missing key word) and you can bulk send your SMS through some sort of API
or HTML gateway. They will generally have agreements with the mobile
networks to have anything that is sent to a particular short code
forwarded onto the aggregator so that they can make them available to you.

A Google search for "SMS aggregator US" should point you in the right
direction, although I've only had direct experience (and a few years ago
now) with Opera Telecom in the UK.

B




From rossi at fidalia.com  Tue Sep 22 10:18:25 2009
From: rossi at fidalia.com (Shaun Rossi)
Date: Tue, 22 Sep 2009 11:18:25 -0400
Subject: SMS
Message-ID: <7EF30F70B022EF45A36F59FEB1D91217037E97010D@SERVER.smallbiz.local>

"Short-codes" it is!

Thanks everyone,

-Shaun


Shaun Rossi
Fidalia Networks Inc
tel. (905) 271-0037 x 111
1-866-FIDALIA (343-2542) x 111
fax. (905) 271-1036

1 Port Street East - Second Floor
Mississauga, Ontario
L5G 4N1  Canada



From mailinglists at expresswebsystems.com  Tue Sep 22 10:19:21 2009
From: mailinglists at expresswebsystems.com (Express Web Systems)
Date: Tue, 22 Sep 2009 10:19:21 -0500
Subject: SMS
In-Reply-To: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>
References: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>
Message-ID: <067601ca3b98$0fd53820$2f7fa860$@com>

Shaun,

This is called "Short code sms messaging". www.clickatell.com offers this
service and is considered to be one of the bigger players in the SMS market.

Warm regards,

Tom Walsh
Express Web Systems, Inc.

> -----Original Message-----
> From: Shaun Rossi [mailto:rossi at fidalia.com]
> Sent: Tuesday, September 22, 2009 10:07 AM
> To: nanog at nanog.org
> Subject: SMS
> 
> Hello,
> 
>                 I have no idea what this is referred to as, so I will
> try to explain:  I have a client interested in setting up a mobile
> phone text message service where a mobile user would send a text to a
> short (say 5 digit) 'telephone' number.  I've seen commercials on TV
> where you could send a numeric/text code to a SMS gateway number, and
> it charges your mobile account for the returned text message or
> downloadable ringer/etc.
> 
>                 Without knowing much about how to access this service,
> it seems relatively straightforward.
> 
>                 I did a few web searches however I'm not sure what
> magic keyword I'm missing for the search.  Could anyone point me in the
> right direction?  The service would be established in Canada and
> potentially the United States.  I have called two of the largest mobile
> operators, but no one can get me to the right department.
> 
> As far as experience with texting goes, I have worked on some systems
> that do M2M (machine-to-machine) SMS communication, always using full
> mobile telephone numbers (GSM modems).
> 
> Many thanks,
> 
> -Shaun
> 
> 
> Shaun Rossi
> Fidalia Networks Inc
> tel. (905) 271-0037 x 111
> 1-866-FIDALIA (343-2542) x 111
> fax. (905) 271-1036
> 
> 1 Port Street East - Second Floor
> Mississauga, Ontario
> L5G 4N1  Canada




From sronan at fattoc.com  Tue Sep 22 10:35:50 2009
From: sronan at fattoc.com (Shane Ronan)
Date: Tue, 22 Sep 2009 11:35:50 -0400
Subject: SMS
In-Reply-To: <067601ca3b98$0fd53820$2f7fa860$@com>
References: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>
	<067601ca3b98$0fd53820$2f7fa860$@com>
Message-ID: 

On that same note, can someone point me in the direction of an SMS  
gateway service? I would like to be able to send SMS messages from my  
monitoring systems, but I am unsure about how to go about it.

Appreciate the assistance.

Shane Ronan

On Sep 22, 2009, at 11:19 AM, Express Web Systems wrote:

> Shaun,
>
> This is called "Short code sms messaging". www.clickatell.com offers  
> this
> service and is considered to be one of the bigger players in the SMS  
> market.
>
> Warm regards,
>
> Tom Walsh
> Express Web Systems, Inc.
>
>> -----Original Message-----
>> From: Shaun Rossi [mailto:rossi at fidalia.com]
>> Sent: Tuesday, September 22, 2009 10:07 AM
>> To: nanog at nanog.org
>> Subject: SMS
>>
>> Hello,
>>
>>                I have no idea what this is referred to as, so I will
>> try to explain:  I have a client interested in setting up a mobile
>> phone text message service where a mobile user would send a text to a
>> short (say 5 digit) 'telephone' number.  I've seen commercials on TV
>> where you could send a numeric/text code to a SMS gateway number, and
>> it charges your mobile account for the returned text message or
>> downloadable ringer/etc.
>>
>>                Without knowing much about how to access this service,
>> it seems relatively straightforward.
>>
>>                I did a few web searches however I'm not sure what
>> magic keyword I'm missing for the search.  Could anyone point me in  
>> the
>> right direction?  The service would be established in Canada and
>> potentially the United States.  I have called two of the largest  
>> mobile
>> operators, but no one can get me to the right department.
>>
>> As far as experience with texting goes, I have worked on some systems
>> that do M2M (machine-to-machine) SMS communication, always using full
>> mobile telephone numbers (GSM modems).
>>
>> Many thanks,
>>
>> -Shaun
>>
>>
>> Shaun Rossi
>> Fidalia Networks Inc
>> tel. (905) 271-0037 x 111
>> 1-866-FIDALIA (343-2542) x 111
>> fax. (905) 271-1036
>>
>> 1 Port Street East - Second Floor
>> Mississauga, Ontario
>> L5G 4N1  Canada
>
>




From link at pobox.com  Tue Sep 22 10:41:52 2009
From: link at pobox.com (Terje Bless)
Date: Tue, 22 Sep 2009 17:41:52 +0200
Subject: Cisco 7600 vs ASR 9000
In-Reply-To: <497ac88a0909210922g416cae96t141c0e154d129347@mail.gmail.com>
References: <497ac88a0909210922g416cae96t141c0e154d129347@mail.gmail.com>
Message-ID: <47ac005a0909220841l727eb5a5k46c5d2cf4e19908@mail.gmail.com>

On Mon, Sep 21, 2009 at 6:22 PM, Nick Colton  wrote:
>Cisco has been recommending the Cisco 7600 as our core router. ?My concern
>is that cisco told us that in the event of an RSP failover the 7600 could take up to
>30 seconds to begin routing packets again, this seems wrong to me since my
>old Extreme Networks BD 6808 can do failovers and rebuild route tables in
>under 5 seconds but??

For NSF/SSO mode the 7600 is claimed to do Sup failover in 0-3 seconds
(which jives pretty well with my experience), but with some caveats. I
think it needs to rebuild its RIB tables, which may take on the order
of 30+ seconds, after a failover and can only keep forwarding traffic
based on the state of the tables at the point of the failover. NSF/SSO
mode has a couple limitations (only BGP, OSPF, and IS-IS supported),
doesn't support IPv6 multicast, etc.

30+ seconds failover time sounds more like RPR/RPR+.

You can find a fairly good overview of this on CCO:

* NSF/SSO: http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SXF/configuration/guide/nsfsso.html
* RPR/RPR+: http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SXF/configuration/guide/redund.html

I run these as essentially switches with very simple LAN routing so I
can't really tell you whether there are any huge honking caveats when
you use them as actual routers (i.e. WAN/SP type applications). I know
there have been some complaints about buggy IOS versions,
unpredictable feature/module support, and the notorious 6500 vs. 7600
platform split (thank you ever so much for that one Cisco, really).
I've been pretty happy with the platform over the years, but while
it's still got plenty of oomph for my applications it is getting to be
a quite old platform. If I were to start looking at building something
new (i.e. no existing platform investment to take into account) I'd
probably be looking at Nexus for datacenter and ASR for anything
router-ish. I think 6500/7600 will still scale further up
(significantly so, iirc) and is more flexible than the ASRs (I view
the ASRs competing/replacing the 7200/7300 rather than 6500/7600), but
if you're looking at anything resembling a clean slate you'll probably
want to evaluate those alternatives.

Anyways, if you're going with Cisco then asking on the cisco-nsp list,
as was suggested elsewhere, is probably not a bad idea.

HTH, -link



From abalashov at evaristesys.com  Tue Sep 22 10:52:54 2009
From: abalashov at evaristesys.com (Alex Balashov)
Date: Tue, 22 Sep 2009 11:52:54 -0400
Subject: SMS
In-Reply-To: 
References: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>	<067601ca3b98$0fd53820$2f7fa860$@com>
	
Message-ID: <4AB8F2D6.90107@evaristesys.com>

Shane Ronan wrote:

> On that same note, can someone point me in the direction of an SMS 
> gateway service? I would like to be able to send SMS messages from my 
> monitoring systems, but I am unsure about how to go about it.
> 
> Appreciate the assistance.

Why not use an e-mail to SMS gateway from whichever carrier?

-- 
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671



From lists at nexus6.co.za  Tue Sep 22 10:54:37 2009
From: lists at nexus6.co.za (Andy Ashley)
Date: Tue, 22 Sep 2009 17:54:37 +0200
Subject: SAS70 Type II compliant colo providers - Chicago, IL
Message-ID: <4AB8F33D.9060101@nexus6.co.za>

Hi,

I would really appreciate any recommendations for SAS70 Type II 
compliant colocation providers in Chicago, IL

The requirement is fairly small (1/2 - 1 rack). Mail me off list please.

Thanks.

Regards,
Andy.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




From scott at sberkman.net  Tue Sep 22 10:59:50 2009
From: scott at sberkman.net (Scott Berkman)
Date: Tue, 22 Sep 2009 11:59:50 -0400
Subject: SMS
In-Reply-To: <4AB8F2D6.90107@evaristesys.com>
References: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>	<067601ca3b98$0fd53820$2f7fa860$@com>	
	<4AB8F2D6.90107@evaristesys.com>
Message-ID: <004401ca3b9d$b80ca0a0$2825e1e0$@net>

Many people consider these (carrier email to SMS gateways) too unreliable as
there are no SLAs from the carriers, and sometimes experience long delays in
message delivery, or just flat out dropped messages.  If this is what you
are depending on for outage notification that's a big risk.

Some people use a serial interface to a specific model cell phones to
directly send the message over the carrier's cellular network.  This is good
in the event of isolation of a location from any IP connectivity to a
carrier gateway.

I believe there was another solution that involved direct carrier
connections, but these are most likely cost prohibitive in most situations.

There is a good thread on this somewhere a little while back in the NANOG
archives with more details of the solutions.

	-Scott

-----Original Message-----
From: Alex Balashov [mailto:abalashov at evaristesys.com] 
Sent: Tuesday, September 22, 2009 11:53 AM
To: Shane Ronan
Cc: nanog at nanog.org
Subject: Re: SMS

Shane Ronan wrote:

> On that same note, can someone point me in the direction of an SMS 
> gateway service? I would like to be able to send SMS messages from my 
> monitoring systems, but I am unsure about how to go about it.
> 
> Appreciate the assistance.

Why not use an e-mail to SMS gateway from whichever carrier?

-- 
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671





From scott at sberkman.net  Tue Sep 22 11:03:43 2009
From: scott at sberkman.net (Scott Berkman)
Date: Tue, 22 Sep 2009 12:03:43 -0400
Subject: SMS
In-Reply-To: <067601ca3b98$0fd53820$2f7fa860$@com>
References: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>
	<067601ca3b98$0fd53820$2f7fa860$@com>
Message-ID: <004701ca3b9e$430a9900$c91fcb00$@net>

Another for this list is http://msgme.com/.

Setting up your own short codes is an expensive and long process, so you are
usually best starting off with a shared code from one of these companies and
you can migrate down the line if the revenue/volume is there to make it
worthwhile.

	-Scott

-----Original Message-----
From: Express Web Systems [mailto:mailinglists at expresswebsystems.com] 
Sent: Tuesday, September 22, 2009 11:19 AM
To: 'Shaun Rossi'; nanog at nanog.org
Subject: RE: SMS

Shaun,

This is called "Short code sms messaging". www.clickatell.com offers this
service and is considered to be one of the bigger players in the SMS market.

Warm regards,

Tom Walsh
Express Web Systems, Inc.

> -----Original Message-----
> From: Shaun Rossi [mailto:rossi at fidalia.com]
> Sent: Tuesday, September 22, 2009 10:07 AM
> To: nanog at nanog.org
> Subject: SMS
> 
> Hello,
> 
>                 I have no idea what this is referred to as, so I will
> try to explain:  I have a client interested in setting up a mobile
> phone text message service where a mobile user would send a text to a
> short (say 5 digit) 'telephone' number.  I've seen commercials on TV
> where you could send a numeric/text code to a SMS gateway number, and
> it charges your mobile account for the returned text message or
> downloadable ringer/etc.
> 
>                 Without knowing much about how to access this service,
> it seems relatively straightforward.
> 
>                 I did a few web searches however I'm not sure what
> magic keyword I'm missing for the search.  Could anyone point me in the
> right direction?  The service would be established in Canada and
> potentially the United States.  I have called two of the largest mobile
> operators, but no one can get me to the right department.
> 
> As far as experience with texting goes, I have worked on some systems
> that do M2M (machine-to-machine) SMS communication, always using full
> mobile telephone numbers (GSM modems).
> 
> Many thanks,
> 
> -Shaun
> 
> 
> Shaun Rossi
> Fidalia Networks Inc
> tel. (905) 271-0037 x 111
> 1-866-FIDALIA (343-2542) x 111
> fax. (905) 271-1036
> 
> 1 Port Street East - Second Floor
> Mississauga, Ontario
> L5G 4N1  Canada






From warren at kumari.net  Tue Sep 22 11:16:44 2009
From: warren at kumari.net (Warren Kumari)
Date: Tue, 22 Sep 2009 12:16:44 -0400
Subject: Google Pagerank and "Class-C Addresses"
In-Reply-To: <1253556116.25881.8.camel@petrie>
References: <20090921161802.GB27976@danton.fire-world.de>
	<1253556116.25881.8.camel@petrie>
Message-ID: <03A43FC4-9C9E-44A8-9975-9A1A529A6645@kumari.net>


On Sep 21, 2009, at 2:01 PM, William Pitcock wrote:

> On Mon, 2009-09-21 at 18:18 +0200, Sebastian Wiesinger wrote:
>> Hello Nanog,
>>
>> I'm looking into a weird request which more and more customers have.
>> They want "different Class C addresses", by which they mean IPs in
>> different /24 subnets.
>>
>> The apparent reason for this is that Google will rank links from
>> different /24 higher then links from the same /24. So it's a SEO
>> thingy.
>>
>
> They are wrong.  Unfortunately, this is a rumour that is being  
> cashed in
> greatly by companies like GotWebHost.com, which offer "SEO hosting".
> They may honestly believe that this is true, it is not.  Infact, IPs
> have nothing to do at all, with PageRank, and don't let any of these  
> SEO
> crackheads tell you otherwise.
>
> A google employee blogged about this topic at:
> http://www.mattcutts.com/blog/myth-busting-virtual-hosts-vs-dedicated-ip-addresses/

Yes, and I'll second this -- PageRank does not in any way get improved  
by hosting on multiple IPs (or different ranges or Class A's or Class- 
C's[0] or swamp space or space from different RIRs or "premium  
addresses" (?!) or anything like that...).


>
>> I googled a bit and found pages after pages of FUD and such great
>> things as the "Class C Checker":  "This free Class C Checker tool
>> allows you to check if some sites are hosted on the same Class C IP
>> Range."
>>
>> My question is: Is there any proof that Google does differentiate
>> between /24s, or even better is there any proof that this isn't the
>> case?

There's Matt's word and Craig Silverstein's word and (not that it  
count for as much) my word -- PageRank does NOT differentiate between / 
24's.

Google has stated this multiple times and we have nothing to gain by  
lying or making things up -- the SEO folks on the other hand have a  
large incentive to claim that IPs *do* make a difference as they sell  
this as a service...

W

[0]: Yes, yes, I know, settle down....


>> I will not give a customer space from different address blocks
>> just because he read it in a SEO magazine.
>
> As said above: No, it is not true.  Further, SEO is mostly a load of
> bullshit that only delivers temporary results, as the search engines
> will change their algorithms, etcetera.
>
>>
>> Perhaps someone from Google itself can answer this question?
>>
>> Also how do you handle such requests? I expect I'm not the only one
>> who gets them.
>
> It depends on how much money they pay me.
>
> If they pay me a lot of money, then I will likely give them what they
> want.  If not, well, that's too bad for them.
>
> It doesn't matter to me, regardless, provided that they aren't  
> violating
> my AUP by you know, spamming or something along those lines.  In those
> cases, well, they probably wouldn't be asking for more IPs, because  
> they
> would be offline.
>
> William
> -- 
> William Pitcock                 SystemInPlace - Simple Hosting  
> Solutions
> 1-866-519-6149                             http://www.systeminplace.net/
> Follow us on Twitter:               http://www.twitter.com/systeminplace
>
>

-- 
No man is an island, But if you take a bunch of dead guys and tie them  
together, they make a pretty good raft.
                 --Anon.





From vasil at ludost.net  Tue Sep 22 11:23:47 2009
From: vasil at ludost.net (Vasil Kolev)
Date: Tue, 22 Sep 2009 19:23:47 +0300
Subject: Router for a file hosting service
Message-ID: <1253636627.3992.52.camel@shrike.home.ludost.net>

Hi all,

I've been banging my head for a while and finally decided to ask for a
recommendation for a router for a somewhat weird situation.

What we currently have is a number of 10G ethernet ports to one carrier,
just switches and nothing more, the carrier is the gw for all the
servers we have (everything is one big VLAN).

What I need is something that can handle something like 24 10gbit ports
- 10-12 to switches with the serving equipment (each one of them pushing
around 8-9Gbit) and on the other side connected to a few ISPs, some of
them with full tables, some of them just peering, and to push the
80-100Gbps around.
(all traffic is TCP, live data says 8.4Gbps is around 1mpps)

Now this seems pretty straightforward, but there's a twist. Because of
the nature of the app we need to be able to do some policy routing - the
devices on the back should be able to set something in the packet (like
the ToS field), and the outbound route preference to be picked based on
that. We'll also need to push to the routes some idea on what to prefer
for specific destinations (because we have some pretty good metrics on
the backend on the packet loss to each destination).
There's also the small issue of scrubbing the packets of the marker I've
set on the backend, not to leak it, because it seems some people tend to
do weird stuff with prioritization because of it (we had one case with
BT, i think).
Doing these two issues at wire speed doesn't seem to be covered in the
documentation, or at least in what I found. 

We've looked into cisco 7609 for this, but I've already read enough on
this list that made me a bit wary of it (and after all the reading I'm
still not sure how well would it handle the policy routing issue and the
rest of the nasty things we're planning for it.

Any ideas or pointers?
-- 
Regards,
Vasil Kolev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: ???? ? ??????? ????????? ???? ?? ???????
URL: 

From herrin-nanog at dirtside.com  Tue Sep 22 11:29:13 2009
From: herrin-nanog at dirtside.com (William Herrin)
Date: Tue, 22 Sep 2009 12:29:13 -0400
Subject: SMS
In-Reply-To: <004401ca3b9d$b80ca0a0$2825e1e0$@net>
References: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>
	<067601ca3b98$0fd53820$2f7fa860$@com>
	
	<4AB8F2D6.90107@evaristesys.com> <004401ca3b9d$b80ca0a0$2825e1e0$@net>
Message-ID: <3c3e3fca0909220929w7b4ea46bvcd21f10efc897122@mail.gmail.com>

On Tue, Sep 22, 2009 at 11:59 AM, Scott Berkman  wrote:
> Some people use a serial interface to a specific model cell phones to
> directly send the message over the carrier's cellular network. ?This is good
> in the event of isolation of a location from any IP connectivity to a
> carrier gateway.

The Multitech Multimodem GPRS model MTCBA-G-EN-F4 has an ethernet
port. Add a SIM card from your favorite wireless carrier and you can
send and receive SMS messages via "AT" commands over a TCP socket.
Problem is, it seizes up or otherwise founders every few weeks and has
to be power cycled.

Has anyone heard of other products with a good reliability record?


> I believe there was another solution that involved direct carrier
> connections, but these are most likely cost prohibitive in most situations.

Any pointers on this would be greatly appreciated. I have a need for
geographically redundant access to the same phone numbers in order to
send and receive SMS messages. Even if I have to buy a pair of T1s
that are 99.9% idle, it'd be worth it.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: 
Falls Church, VA 22042-3004



From Stefan.Fouant at neustar.biz  Tue Sep 22 11:38:56 2009
From: Stefan.Fouant at neustar.biz (Fouant, Stefan)
Date: Tue, 22 Sep 2009 12:38:56 -0400
Subject: Router for a file hosting service
In-Reply-To: <1253636627.3992.52.camel@shrike.home.ludost.net>
References: <1253636627.3992.52.camel@shrike.home.ludost.net>
Message-ID: <01B071CE08A7514CB72950074134151A017331C6@STNTEXCH12.cis.neustar.com>

> -----Original Message-----
> From: Vasil Kolev [mailto:vasil at ludost.net]
> 
> What I need is something that can handle something like 24 10gbit ports
> - 10-12 to switches with the serving equipment (each one of them
> pushing around 8-9Gbit) and on the other side connected to a few ISPs,
> some of them with full tables, some of them just peering, and to push
> the 80-100Gbps around.
> (all traffic is TCP, live data says 8.4Gbps is around 1mpps)
> 
> Now this seems pretty straightforward, but there's a twist. Because of
> the nature of the app we need to be able to do some policy routing -
> the devices on the back should be able to set something in the packet
> (like the ToS field), and the outbound route preference to be picked
> based on that. We'll also need to push to the routes some idea on what
> to prefer for specific destinations (because we have some pretty good
> metrics on the backend on the packet loss to each destination).
> There's also the small issue of scrubbing the packets of the marker
> I've set on the backend, not to leak it, because it seems some people
> tend to do weird stuff with prioritization because of it (we had one
> case with BT, i think).
> Doing these two issues at wire speed doesn't seem to be covered in the
> documentation, or at least in what I found.
> 
> We've looked into cisco 7609 for this, but I've already read enough on
> this list that made me a bit wary of it (and after all the reading I'm
> still not sure how well would it handle the policy routing issue and
> the rest of the nasty things we're planning for it.
> 
> Any ideas or pointers?

Sounds like a Juniper MX480 would be a good fit for what you are trying to do.  It should support the port densities you are looking for, plus you can group several interfaces into common bridge groups.  Furthermore, you should be able to support full-route tables, perform Filter-Based Forwarding for policy routing, classification, queuing, re-marking, etc. all at line-rate, or pretty darn close.

Stefan Fouant 
Neustar, Inc. / Principal Engineer
46000 Center Oak Plaza Sterling, VA 20166
Office: +1.571.434.5656 ? Mobile: +1.202.210.2075 ? GPG ID: 0xB5E3803D ? stefan.fouant at neustar.biz

From source_route at yahoo.com  Tue Sep 22 11:59:52 2009
From: source_route at yahoo.com (Philip Lavine)
Date: Tue, 22 Sep 2009 09:59:52 -0700 (PDT)
Subject: UDP and IP fragmentation
Message-ID: <303905.85469.qm@web30807.mail.mud.yahoo.com>

To all,

I am running a Windows based high performance computing application that uses "reliable" multicast (29West) on a gigabit LAN. All systems are logically on the same VLAN and even on the same physical switch The application is set to use an 8k buffer and therefore results in IP fragmentation when datagrams are transmitted. The application is sensitive to any latency or data loss (of course) and uses a proprietary mechanism to create TCP-like retransmissions in case there is any actual data loss. Unfortunately, becasue of the fragmentation during the retransmission window all ip fragments must be resent even though only one may have been lost.

If the buffer size is tweeked to the ~1460 this may fix the fragmentation but will the side effects be less throughput and possibly more latency. Is there a sweet spot for UDP on an ethernet segment? 

Philip



      



From scott at sberkman.net  Tue Sep 22 12:00:37 2009
From: scott at sberkman.net (Scott Berkman)
Date: Tue, 22 Sep 2009 13:00:37 -0400
Subject: SMS
In-Reply-To: <3c3e3fca0909220929w7b4ea46bvcd21f10efc897122@mail.gmail.com>
References: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>	
	<067601ca3b98$0fd53820$2f7fa860$@com>	
		
	<4AB8F2D6.90107@evaristesys.com>
	<004401ca3b9d$b80ca0a0$2825e1e0$@net>
	<3c3e3fca0909220929w7b4ea46bvcd21f10efc897122@mail.gmail.com>
Message-ID: <008f01ca3ba6$3bc1ffa0$b345fee0$@net>

FYI here is one view of one of the threads I was recalling:

http://www.gossamer-threads.com/lists/nanog/users/104612?search_string=sms;#
104612

Make sure to look at post #5 that summarized a previous thread too.

I think the "direct connection" I was thinking of was the modem to TAP
gateway options.

	-Scott

-----Original Message-----
From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William
Herrin
Sent: Tuesday, September 22, 2009 12:29 PM
To: Scott Berkman
Cc: nanog at nanog.org
Subject: Re: SMS

On Tue, Sep 22, 2009 at 11:59 AM, Scott Berkman  wrote:
> Some people use a serial interface to a specific model cell phones to
> directly send the message over the carrier's cellular network. ?This is
good
> in the event of isolation of a location from any IP connectivity to a
> carrier gateway.

The Multitech Multimodem GPRS model MTCBA-G-EN-F4 has an ethernet
port. Add a SIM card from your favorite wireless carrier and you can
send and receive SMS messages via "AT" commands over a TCP socket.
Problem is, it seizes up or otherwise founders every few weeks and has
to be power cycled.

Has anyone heard of other products with a good reliability record?


> I believe there was another solution that involved direct carrier
> connections, but these are most likely cost prohibitive in most
situations.

Any pointers on this would be greatly appreciated. I have a need for
geographically redundant access to the same phone numbers in order to
send and receive SMS messages. Even if I have to buy a pair of T1s
that are 99.9% idle, it'd be worth it.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: 
Falls Church, VA 22042-3004





From Richard.E.Brown at dartware.com  Tue Sep 22 12:02:36 2009
From: Richard.E.Brown at dartware.com (Richard E. Brown)
Date: 22 Sep 2009 13:02:36 -0400
Subject: SMS
Message-ID: <4601580@blitz.dartware.com>

--- Shane Ronan wrote:
On that same note, can someone point me in the direction of an SMS
gateway service? I would like to be able to send SMS messages from my
monitoring systems, but I am unsure about how to go about it.
--- end of quote ---

There are several ways to do this:

- Open source software like Gammu (http://cihar.com/gammu/) can send SMS messages  
through a USB or RS232 attached mobile phone or cellular modem.

- We've had good luck with the MultiTech MultiModem GPRS, model MTCBA-G-U-F2 (USB)  
and Multitech GPRS MTCBA-G-F4 and Wavecomm RS-232 GSM (RS-232) modems.

- Many monitoring/management packages have built-in or add-on SMS sending utilities.

- You may not want to rely on the cellular carrier's e-mail-to-SMS gateway, either  
because of connectivity problems or the cell carrier's delay/reliability problems.

- There's also a kludge that's good for a "disaster notification" that simply  
rings a phone when something really bad happens. :-) Basically, the system uses  
its numeric pager/TAP software to dial through an analog modem and a POTS line  
and ring your phone/cell. The CallerID tells you who's calling, even there's no  
message. There's a KB article at the InterMapper site describing this is at...

    http://forums.dartware.com/viewtopic.php?t=913

Rich Brown                    richard.e.brown at dartware.com
Dartware, LLC                 http://www.dartware.com
66-7 Benning Street           Telephone: 603-643-9600
West Lebanon, NH 03784-3407   Fax: 603-643-2289



From adrian at creative.net.au  Tue Sep 22 12:17:44 2009
From: adrian at creative.net.au (Adrian Chadd)
Date: Wed, 23 Sep 2009 01:17:44 +0800
Subject: UDP and IP fragmentation
In-Reply-To: <303905.85469.qm@web30807.mail.mud.yahoo.com>
References: <303905.85469.qm@web30807.mail.mud.yahoo.com>
Message-ID: <20090922171744.GC24485@skywalker.creative.net.au>

On Tue, Sep 22, 2009, Philip Lavine wrote:
> To all,
> 
> I am running a Windows based high performance computing application that uses "reliable" multicast (29West) on a gigabit LAN. All systems are logically on the same VLAN and even on the same physical switch The application is set to use an 8k buffer and therefore results in IP fragmentation when datagrams are transmitted. The application is sensitive to any latency or data loss (of course) and uses a proprietary mechanism to create TCP-like retransmissions in case there is any actual data loss. Unfortunately, becasue of the fragmentation during the retransmission window all ip fragments must be resent even though only one may have been lost.
> 
> If the buffer size is tweeked to the ~1460 this may fix the fragmentation but will the side effects be less throughput and possibly more latency. Is there a sweet spot for UDP on an ethernet segment? 

First, figure out whether all of the above matters. :)

Invest in a switch and NIC infrastructure that lets you stuff said 8k frames into
an >8k jumbo frame. Then make sure you've read and understood QoS basics, including
the generic stuff (packet scheduling, queuing/dequeuing concepts); investigate
what various vendors claim their switches do and then actually look around for
feedback about what others have -seen-.

Finally, use all of that clue to make sure that the consultant you then hire to
do the work is actually doing their job.

No, I'm not (mostly) being facetious. It is mostly easy to get it "right" when
it works, but it is -not- right to get it "right enough" when it doesn't work.




Adrian




From cmadams at hiwaay.net  Tue Sep 22 12:35:35 2009
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 22 Sep 2009 12:35:35 -0500
Subject: SMS
In-Reply-To: <4AB8F2D6.90107@evaristesys.com>
References: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>
	<067601ca3b98$0fd53820$2f7fa860$@com>
	
	<4AB8F2D6.90107@evaristesys.com>
Message-ID: <20090922173535.GG982750@hiwaay.net>

Once upon a time, Alex Balashov  said:
> Shane Ronan wrote:
> >On that same note, can someone point me in the direction of an SMS 
> >gateway service? I would like to be able to send SMS messages from my 
> >monitoring systems, but I am unsure about how to go about it.
> 
> Why not use an e-mail to SMS gateway from whichever carrier?

They tend to be unreliable (long delays and dropped messages).  Also,
how can your monitoring system email the gateway when the network is
down?
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From cmadams at hiwaay.net  Tue Sep 22 12:41:25 2009
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 22 Sep 2009 12:41:25 -0500
Subject: SMS
In-Reply-To: <3c3e3fca0909220929w7b4ea46bvcd21f10efc897122@mail.gmail.com>
References: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>
	<067601ca3b98$0fd53820$2f7fa860$@com>
	
	<4AB8F2D6.90107@evaristesys.com>
	<004401ca3b9d$b80ca0a0$2825e1e0$@net>
	<3c3e3fca0909220929w7b4ea46bvcd21f10efc897122@mail.gmail.com>
Message-ID: <20090922174125.GH982750@hiwaay.net>

Once upon a time, William Herrin  said:
> The Multitech Multimodem GPRS model MTCBA-G-EN-F4 has an ethernet
> port. Add a SIM card from your favorite wireless carrier and you can
> send and receive SMS messages via "AT" commands over a TCP socket.
> Problem is, it seizes up or otherwise founders every few weeks and has
> to be power cycled.
> 
> Has anyone heard of other products with a good reliability record?

We have the MTCBA-G-U-F4-ED (the USB version) and have not had any
trouble.  I had to modify the Linux kernel driver for the chipset used
to load the firmware correctly (and optionally externally instead of
just compiled in), but those changes are in the upstream kernel now.

We haven't had any problem with it locking up or anything; the server
with it attached has been up for a year (as of 41 minutes ago :-) ) with
no problems (haven't had to pull the modem or anything like that).

We have an AT&T SIM card in it, and we did have problems with AT&T's SMS
several months ago; for several hours, they were rejecting messages from
our modem.  Now I have an additional monitor that sends a message to
itself periodically, and (of course) we haven't had that problem since.
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From sronan at fattoc.com  Tue Sep 22 15:27:57 2009
From: sronan at fattoc.com (Shane Ronan)
Date: Tue, 22 Sep 2009 16:27:57 -0400
Subject: SMS
In-Reply-To: <4AB8F2D6.90107@evaristesys.com>
References: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>	<067601ca3b98$0fd53820$2f7fa860$@com>
	
	<4AB8F2D6.90107@evaristesys.com>
Message-ID: 

How do I send out an email if the network is down?

On Sep 22, 2009, at 11:52 AM, Alex Balashov wrote:

> Shane Ronan wrote:
>
>> On that same note, can someone point me in the direction of an SMS  
>> gateway service? I would like to be able to send SMS messages from  
>> my monitoring systems, but I am unsure about how to go about it.
>> Appreciate the assistance.
>
> Why not use an e-mail to SMS gateway from whichever carrier?
>
> -- 
> Alex Balashov - Principal
> Evariste Systems
> Web     : http://www.evaristesys.com/
> Tel     : (+1) (678) 954-0670
> Direct  : (+1) (678) 954-0671




From brandon.galbraith at gmail.com  Tue Sep 22 15:31:48 2009
From: brandon.galbraith at gmail.com (Brandon Galbraith)
Date: Tue, 22 Sep 2009 15:31:48 -0500
Subject: SMS
In-Reply-To: 
References: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>
	<067601ca3b98$0fd53820$2f7fa860$@com>
	
	<4AB8F2D6.90107@evaristesys.com>
	
Message-ID: <366100670909221331p51b3d99akf65b57539291fcde@mail.gmail.com>

On Tue, Sep 22, 2009 at 3:27 PM, Shane Ronan  wrote:

> How do I send out an email if the network is down?
>
>
Why not use an e-mail to SMS gateway from whichever carrier?
>>
>
>
Your external monitoring box sends the email? You do have something doing
external monitoring, right?


-- 
Brandon Galbraith
Mobile: 630.400.6992
FNAL: 630.840.2141


From bmanning at vacation.karoshi.com  Tue Sep 22 15:37:09 2009
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 22 Sep 2009 20:37:09 +0000
Subject: SMS
In-Reply-To: <366100670909221331p51b3d99akf65b57539291fcde@mail.gmail.com>
References: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>
	<067601ca3b98$0fd53820$2f7fa860$@com>
	
	<4AB8F2D6.90107@evaristesys.com>
	
	<366100670909221331p51b3d99akf65b57539291fcde@mail.gmail.com>
Message-ID: <20090922203709.GA19776@vacation.karoshi.com.>

On Tue, Sep 22, 2009 at 03:31:48PM -0500, Brandon Galbraith wrote:
> On Tue, Sep 22, 2009 at 3:27 PM, Shane Ronan  wrote:
> 
> > How do I send out an email if the network is down?
> >
> >
> Why not use an e-mail to SMS gateway from whichever carrier?
> >>
> >
> >
> Your external monitoring box sends the email? You do have something doing
> external monitoring, right?
> 
> 
> -- 
> Brandon Galbraith
> Mobile: 630.400.6992
> FNAL: 630.840.2141


	well, my ISP is my telco, is my cable/TV co...  that whole
	triple-play - bundled service thing.

	so not only can't i send email, i can't call either.  fortunately
	i have these homing birds ... faster than RSA DSL and likely most
	"broadband" in the US too.

--bill



From AOsgood at Streamline-Solutions.net  Tue Sep 22 15:58:21 2009
From: AOsgood at Streamline-Solutions.net (Aaron D. Osgood)
Date: Tue, 22 Sep 2009 16:58:21 -0400
Subject: SMS
In-Reply-To: <3c3e3fca0909220929w7b4ea46bvcd21f10efc897122@mail.gmail.com>
References: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>	<067601ca3b98$0fd53820$2f7fa860$@com>		<4AB8F2D6.90107@evaristesys.com>
	<004401ca3b9d$b80ca0a0$2825e1e0$@net>
	<3c3e3fca0909220929w7b4ea46bvcd21f10efc897122@mail.gmail.com>
Message-ID: <021401ca3bc7$6c293110$447b9330$@net>

We have a package which uses the MultiTech line of modems coupled with
software that will watch files on your network and generate SMS messges (or
SNPP, WCTP, TAP, FAX, etc). The underlying engine is a highly customized
version of PageGate software from NotePage, Inc. Part of our customization
was to defeat the issue you mentioned of "modem suspension". It was
initially designed for high volume short messages of a critical nature and
is in use in numerous Public Safety (Fire/Police/EMS) communications
centers. Often, the Public Safety agency will contract with us to provide
and install the system, then the IT department realizes the benefits of
using it to monitor their systems. Please contact me off list if you would
like more information

Aaron D. Osgood

Streamline Solutions L.L.C

P.O. Box 6115
Falmouth, ME 04105 

TEL: 207-781-5561
FAX: 615-704-8067
MOBILE: 207-831-5829
AOsgood at Streamline-Solutions.net
http://www.streamline-solutions.net

Introducing Efficiency to Business since 1986.


-----Original Message-----
From: William Herrin [mailto:herrin-nanog at dirtside.com] 
Sent: Tuesday, September 22, 2009 12:29 PM
To: Scott Berkman
Cc: nanog at nanog.org
Subject: Re: SMS

On Tue, Sep 22, 2009 at 11:59 AM, Scott Berkman  wrote:
> Some people use a serial interface to a specific model cell phones to
> directly send the message over the carrier's cellular network. ?This is
good
> in the event of isolation of a location from any IP connectivity to a
> carrier gateway.

The Multitech Multimodem GPRS model MTCBA-G-EN-F4 has an ethernet
port. Add a SIM card from your favorite wireless carrier and you can
send and receive SMS messages via "AT" commands over a TCP socket.
Problem is, it seizes up or otherwise founders every few weeks and has
to be power cycled.

Has anyone heard of other products with a good reliability record?


> I believe there was another solution that involved direct carrier
> connections, but these are most likely cost prohibitive in most
situations.

Any pointers on this would be greatly appreciated. I have a need for
geographically redundant access to the same phone numbers in order to
send and receive SMS messages. Even if I have to buy a pair of T1s
that are 99.9% idle, it'd be worth it.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: 
Falls Church, VA 22042-3004






From frederic at placenet.org  Tue Sep 22 15:59:14 2009
From: frederic at placenet.org (=?ISO-8859-1?Q?Fr=E9d=E9ric?=)
Date: Tue, 22 Sep 2009 22:59:14 +0200
Subject: SMS
In-Reply-To: 
References: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>
	<067601ca3b98$0fd53820$2f7fa860$@com>
	
	<4AB8F2D6.90107@evaristesys.com>
	
Message-ID: <1253653154.17528.1.camel@home.placenet.fr>

Le mardi 22 septembre 2009 ? 16:27 -0400, Shane Ronan a ?crit :
> How do I send out an email if the network is down?
> 

via a gsm modem (phone + usb cable) connect to you monitoring server.




> On Sep 22, 2009, at 11:52 AM, Alex Balashov wrote:
> 
> > Shane Ronan wrote:
> >
> >> On that same note, can someone point me in the direction of an SMS  
> >> gateway service? I would like to be able to send SMS messages from  
> >> my monitoring systems, but I am unsure about how to go about it.
> >> Appreciate the assistance.
> >
> > Why not use an e-mail to SMS gateway from whichever carrier?
> >
> > -- 
> > Alex Balashov - Principal
> > Evariste Systems
> > Web     : http://www.evaristesys.com/
> > Tel     : (+1) (678) 954-0670
> > Direct  : (+1) (678) 954-0671
> 
> 
> 




From AOsgood at Streamline-Solutions.net  Tue Sep 22 16:00:35 2009
From: AOsgood at Streamline-Solutions.net (Aaron D. Osgood)
Date: Tue, 22 Sep 2009 17:00:35 -0400
Subject: RETRACTION : SMS
Message-ID: <021801ca3bc7$bd5f4ab0$381de010$@net>

My apologies for the wasted bandwidth - my last message was not intended for
the list

(NOTE TO SELF: Double check the TO line when I hit REPLY!)

 

 

Aaron D. Osgood

 

Streamline Solutions L.L.C

 

P.O. Box 6115

Falmouth, ME 04105 

 

TEL: 207-781-5561

FAX: 615-704-8067

MOBILE: 207-831-5829

  AOsgood at Streamline-Solutions.net

http://www.streamline-solutions.net

 

Introducing Efficiency to Business since 1986.

 



From AOsgood at Streamline-Solutions.net  Tue Sep 22 16:02:24 2009
From: AOsgood at Streamline-Solutions.net (Aaron D. Osgood)
Date: Tue, 22 Sep 2009 17:02:24 -0400
Subject: Contact w/ clue re: AT&T SMS email gateway?
In-Reply-To: <362201.22716.qm@web112617.mail.gq1.yahoo.com>
References: <4AB2881B.5090103@gmail.com> <4AB23A44.33E4.0097.0@globalstar.com>
	<362201.22716.qm@web112617.mail.gq1.yahoo.com>
Message-ID: <021d01ca3bc7$fd159060$f740b120$@net>

Point of note: NONE of the cellular carriers treat SMS messages as "data".
SMS messaging is carried on the "Control" channel that works similar to the
"D" channel on a PRI

Aaron D. Osgood

Streamline Solutions L.L.C

P.O. Box 6115
Falmouth, ME 04105 

TEL: 207-781-5561
FAX: 615-704-8067
MOBILE: 207-831-5829
AOsgood at Streamline-Solutions.net
http://www.streamline-solutions.net

Introducing Efficiency to Business since 1986.


-----Original Message-----
From: Erick Bergquist [mailto:erickbe at yahoo.com] 
Sent: Tuesday, September 22, 2009 2:55 AM
To: nanog at nanog.org
Subject: Re: Contact w/ clue re: AT&T SMS email gateway?

I am having this problem the past week or so as well, along  with some
friends. 
Have a iPhone 3GS also. However, seemed to be fine Monday. 




----- Original Message ----
From: Crist Clark 
To: nanog at nanog.org; Dave Pascoe 
Sent: Thursday, September 17, 2009 3:31:51 PM
Subject: Contact w/ clue re: AT&T SMS email gateway?

>>> On 9/17/2009 at 12:03 PM, Dave Pascoe  wrote:
> Recently something seems to have changed with the @txt.att.net email to
> SMS gateway.  Messages sent through the gateway suffer from the following:
> 
> 1) Long delay in reaching the phone (intermittent)
>    (yes I know there is no latency guarantee)
> 
> and, even more crippling,
> 
> 2) Message comes through as just "SMS Message" instead of the SMTP
> message content.  And the sender is always 410-000-01x, where x
> increments by 1 with each new incoming email-to-SMS gateway-handled
message.
> 
> Phone is an iPhone 3GS.  This has worked fine for quite a while.  No
> changes on the iPhone.
> 
> I have gone through normal AT&T Wireless Customer Service but there
> isn't much clue there - had to explain what an email to SMS gateway is.
> 
> Anyone elese seeing this?  Anyone from AT&T Wireless here?

If you do find anyone, can you ask them about the really annoying
reject-after-DATA problem?

That is, if 555-555-1234, for some reason is not authorized to receive
SMS, you get a 250 response after RCPT TO, but a 5xx after the DATA
is sent. So if the message had multiple recipients, some of which are
allowed to receive SMS, the message then fails for all of them.

Verizon also has this problem, BTW.


      






From wmaton at ryouko.imsb.nrc.ca  Tue Sep 22 16:09:39 2009
From: wmaton at ryouko.imsb.nrc.ca (William F. Maton Sotomayor)
Date: Tue, 22 Sep 2009 17:09:39 -0400 (EDT)
Subject: SMS
In-Reply-To: 
References: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>
	<067601ca3b98$0fd53820$2f7fa860$@com>
	
	<4AB8F2D6.90107@evaristesys.com>
	
Message-ID: 

On Tue, 22 Sep 2009, Shane Ronan wrote:

> How do I send out an email if the network is down?

I have had success using a GSM phone hooked up to the server via USB. 
(Bonus is that the server constantly 'charges' the phone).  An ugly set of 
scripts deals with taking emails and changing them into SMS messages which 
are then transmitted through that phone to another.

>
> On Sep 22, 2009, at 11:52 AM, Alex Balashov wrote:
>
>> Shane Ronan wrote:
>> 
>>> On that same note, can someone point me in the direction of an SMS gateway 
>>> service? I would like to be able to send SMS messages from my monitoring 
>>> systems, but I am unsure about how to go about it.
>>> Appreciate the assistance.
>> 
>> Why not use an e-mail to SMS gateway from whichever carrier?
>> 
>> -- 
>> Alex Balashov - Principal
>> Evariste Systems
>> Web     : http://www.evaristesys.com/
>> Tel     : (+1) (678) 954-0670
>> Direct  : (+1) (678) 954-0671
>


wfms



From sethm at rollernet.us  Tue Sep 22 16:15:40 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Tue, 22 Sep 2009 14:15:40 -0700
Subject: SMS
In-Reply-To: 
References: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>	<067601ca3b98$0fd53820$2f7fa860$@com>		<4AB8F2D6.90107@evaristesys.com>	
	
Message-ID: <4AB93E7C.1070302@rollernet.us>

William F. Maton Sotomayor wrote:
> On Tue, 22 Sep 2009, Shane Ronan wrote:
> 
>> How do I send out an email if the network is down?
> 
> I have had success using a GSM phone hooked up to the server via USB.
> (Bonus is that the server constantly 'charges' the phone).  An ugly set
> of scripts deals with taking emails and changing them into SMS messages
> which are then transmitted through that phone to another.
> 

I use an old 1xRTT Sprint phone and send SMS via SNPP. As a bonus, as
long as I know the IP the PPP connection has, I can SSH back as long as
whatever took out all my hardlines doesn't kill all the cell towers in
range.

~Seth



From davekm3t at gmail.com  Tue Sep 22 18:26:33 2009
From: davekm3t at gmail.com (Dave Pascoe)
Date: Tue, 22 Sep 2009 19:26:33 -0400
Subject: Contact w/ clue re: AT&T SMS email gateway?
In-Reply-To: <4AB2881B.5090103@gmail.com>
References: <4AB2881B.5090103@gmail.com>
Message-ID: <74df4ca00909221626h4765e14ck5c59b341833c003@mail.gmail.com>

Many people responded to me directly, so I thought I would summarize
my findings.

1) AT&T Customer Service never returned my call, despite saying they
would.  I guess they couldn't get to the right folks.  The occasional
curse of being in a really large company.

2) A very kind inside AT&T person from this list replied to me
privately and informed me that they had just cut over to a new gateway
for the consumer mail-to-SMS service and that they were experiencing
some issues with it.  Perhaps the issue was a massive influx of
messages when they brought the system back, but that is just me
speculating.  Doesn't explain the message body corruption issue,
though.

3) Someone let me know that AT&T Wireless has a business offering
called Enterprise Paging:
http://www.wireless.att.com/businesscenter/solutions/email-messaging/enterprise-paging.jsp

This costs about $5.00 extra per month and offers a separate
email-to-SMS gateway and other SMS injection methods:
WCTP, SNPP, TAP .  This service uses 10-digit-number at page.att.net as
the gateway email address format.

Another benefit is longer messages - up to 456 characters.  This can be helpful.

I opted for upgrading to Enterprise Paging.  Solved the issue for me,
seems reliable, and offers options that give me value.  Also has 24/7
support and (apparently) some sort of SLA.

Other reports indicate the @txt.att.net consumer gateway has settled
down after the issues from last week.

Hope this helps some folks.

-Dave



From nanog at daork.net  Tue Sep 22 18:28:31 2009
From: nanog at daork.net (Nathan Ward)
Date: Wed, 23 Sep 2009 11:28:31 +1200
Subject: SMS
In-Reply-To: <3c3e3fca0909220929w7b4ea46bvcd21f10efc897122@mail.gmail.com>
References: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>
	<067601ca3b98$0fd53820$2f7fa860$@com>
	
	<4AB8F2D6.90107@evaristesys.com>
	<004401ca3b9d$b80ca0a0$2825e1e0$@net>
	<3c3e3fca0909220929w7b4ea46bvcd21f10efc897122@mail.gmail.com>
Message-ID: <6D3D1CB6-7834-4B67-859A-273F35A7901F@daork.net>

On 23/09/2009, at 4:29 AM, William Herrin wrote:

> On Tue, Sep 22, 2009 at 11:59 AM, Scott Berkman   
> wrote:
>> Some people use a serial interface to a specific model cell phones to
>> directly send the message over the carrier's cellular network.   
>> This is good
>> in the event of isolation of a location from any IP connectivity to a
>> carrier gateway.
>
> The Multitech Multimodem GPRS model MTCBA-G-EN-F4 has an ethernet
> port. Add a SIM card from your favorite wireless carrier and you can
> send and receive SMS messages via "AT" commands over a TCP socket.
> Problem is, it seizes up or otherwise founders every few weeks and has
> to be power cycled.
>
> Has anyone heard of other products with a good reliability record?

That is shocking.

I have had a fantastic track record with a Maestro 100 GSM modem with  
a serial interface.

One of my customers has one powered on for about a year now, and it's  
never missed a beat.

They apparently support TCP/IP and the datasheet mentions something  
about email, but I have no idea what that really means, and don't  
really care so much.
I send it standard GSM AT commands, and it just works.

I've done the whole old nokia handset thing in the past several times  
and it's *ok*. Now though, I say don't bother, this thing is maybe a  
couple hundred dollars, and saves you oodles of time fooling around  
making it work reliably.

--
Nathan Ward




From jcurran at istaff.org  Tue Sep 22 18:52:04 2009
From: jcurran at istaff.org (John Curran)
Date: Tue, 22 Sep 2009 19:52:04 -0400
Subject: SAS70 Type II compliant colo providers - Chicago, IL
In-Reply-To: <4AB8F33D.9060101@nexus6.co.za>
References: <4AB8F33D.9060101@nexus6.co.za>
Message-ID: <54FF0D32-F131-45A0-89F0-D67C00922A10@istaff.org>

On Sep 22, 2009, at 11:54 AM, Andy Ashley wrote:
>
> Hi,
>
> I would really appreciate any recommendations for SAS70 Type II  
> compliant colocation providers in Chicago, IL

Andy -

    As an FYI, SAS 70 Type II compliance means whatever that  
provider's "SAS 70 Type II" audit document states for controls, i.e.  
there is no specific requirements associated with SAS 70 Type II, only  
that you publish a documented set of management and security controls  
and then are audited for compliance against that list.  That may not  
be realized by the folks who've sent you to go get SAS 70 Type II  
compliant hosting, but is something that you probably want to keep in  
mind since little items like generators and door locks aren't  
necessarily included.

/John




From jeffrey.lyon at blacklotus.net  Tue Sep 22 19:17:43 2009
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Tue, 22 Sep 2009 20:17:43 -0400
Subject: SAS70 Type II compliant colo providers - Chicago, IL
In-Reply-To: <54FF0D32-F131-45A0-89F0-D67C00922A10@istaff.org>
References: <4AB8F33D.9060101@nexus6.co.za>
	<54FF0D32-F131-45A0-89F0-D67C00922A10@istaff.org>
Message-ID: <16720fe00909221717k60ad8909yda25a461e0d2c6f8@mail.gmail.com>

People buy SAS 70 compliant anything just because it's the latest
buzzword, kind of like PCI compliance.

Jeff

On Tue, Sep 22, 2009 at 7:52 PM, John Curran  wrote:
> On Sep 22, 2009, at 11:54 AM, Andy Ashley wrote:
>>
>> Hi,
>>
>> I would really appreciate any recommendations for SAS70 Type II compliant
>> colocation providers in Chicago, IL
>
> Andy -
>
> ? As an FYI, SAS 70 Type II compliance means whatever that provider's "SAS
> 70 Type II" audit document states for controls, i.e. there is no specific
> requirements associated with SAS 70 Type II, only that you publish a
> documented set of management and security controls and then are audited for
> compliance against that list. ?That may not be realized by the folks who've
> sent you to go get SAS 70 Type II compliant hosting, but is something that
> you probably want to keep in mind since little items like generators and
> door locks aren't necessarily included.
>
> /John
>
>
>



-- 
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 jayfar at jayfar.com  Tue Sep 22 19:50:28 2009
From: jayfar at jayfar.com (Jay Farrell)
Date: Tue, 22 Sep 2009 20:50:28 -0400
Subject: SAS70 Type II compliant colo providers - Chicago, IL
In-Reply-To: <16720fe00909221717k60ad8909yda25a461e0d2c6f8@mail.gmail.com>
References: <4AB8F33D.9060101@nexus6.co.za>
	<54FF0D32-F131-45A0-89F0-D67C00922A10@istaff.org> 
	<16720fe00909221717k60ad8909yda25a461e0d2c6f8@mail.gmail.com>
Message-ID: <890005330909221750h2a0b6accvc630e54ea9bac4df@mail.gmail.com>

Yes, but with PCI compliance the powers that be (credit card
companies) can actually fine you big bucks for being non-compliant.

http://www.google.com/search?hl=en&source=hp&q=pci+compliance+fines&aq=f&oq=&aqi=g1g-m1

http://www.pcicomplianceguide.org/pcifaqs.php#11

Cheers,
Jayfar

On Tue, Sep 22, 2009 at 8:17 PM, Jeffrey Lyon
 wrote:
> People buy SAS 70 compliant anything just because it's the latest
> buzzword, kind of like PCI compliance.
>
> Jeff
>
> On Tue, Sep 22, 2009 at 7:52 PM, John Curran  wrote:
>> On Sep 22, 2009, at 11:54 AM, Andy Ashley wrote:
>>>
>>> Hi,
>>>
>>> I would really appreciate any recommendations for SAS70 Type II compliant
>>> colocation providers in Chicago, IL
>>
>> Andy -
>>
>> ? As an FYI, SAS 70 Type II compliance means whatever that provider's "SAS
>> 70 Type II" audit document states for controls, i.e. there is no specific
>> requirements associated with SAS 70 Type II, only that you publish a
>> documented set of management and security controls and then are audited for
>> compliance against that list. ?That may not be realized by the folks who've
>> sent you to go get SAS 70 Type II compliant hosting, but is something that
>> you probably want to keep in mind since little items like generators and
>> door locks aren't necessarily included.
>>
>> /John
>>
>>
>>
>
>
>
> --
> 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 Sep 22 19:53:55 2009
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Tue, 22 Sep 2009 20:53:55 -0400
Subject: SAS70 Type II compliant colo providers - Chicago, IL
In-Reply-To: <890005330909221750h2a0b6accvc630e54ea9bac4df@mail.gmail.com>
References: <4AB8F33D.9060101@nexus6.co.za>
	<54FF0D32-F131-45A0-89F0-D67C00922A10@istaff.org>
	<16720fe00909221717k60ad8909yda25a461e0d2c6f8@mail.gmail.com>
	<890005330909221750h2a0b6accvc630e54ea9bac4df@mail.gmail.com>
Message-ID: <16720fe00909221753o2fd18489sc39f12c5ee4f5356@mail.gmail.com>

Most of our customers just make up their own definition of PCI and
then demand that we help them adhere to it.

Jeff

On Tue, Sep 22, 2009 at 8:50 PM, Jay Farrell  wrote:
> Yes, but with PCI compliance the powers that be (credit card
> companies) can actually fine you big bucks for being non-compliant.
>
> http://www.google.com/search?hl=en&source=hp&q=pci+compliance+fines&aq=f&oq=&aqi=g1g-m1
>
> http://www.pcicomplianceguide.org/pcifaqs.php#11
>
> Cheers,
> Jayfar
>
> On Tue, Sep 22, 2009 at 8:17 PM, Jeffrey Lyon
>  wrote:
>> People buy SAS 70 compliant anything just because it's the latest
>> buzzword, kind of like PCI compliance.
>>
>> Jeff
>>
>> On Tue, Sep 22, 2009 at 7:52 PM, John Curran  wrote:
>>> On Sep 22, 2009, at 11:54 AM, Andy Ashley wrote:
>>>>
>>>> Hi,
>>>>
>>>> I would really appreciate any recommendations for SAS70 Type II compliant
>>>> colocation providers in Chicago, IL
>>>
>>> Andy -
>>>
>>> ? As an FYI, SAS 70 Type II compliance means whatever that provider's "SAS
>>> 70 Type II" audit document states for controls, i.e. there is no specific
>>> requirements associated with SAS 70 Type II, only that you publish a
>>> documented set of management and security controls and then are audited for
>>> compliance against that list. ?That may not be realized by the folks who've
>>> sent you to go get SAS 70 Type II compliant hosting, but is something that
>>> you probably want to keep in mind since little items like generators and
>>> door locks aren't necessarily included.
>>>
>>> /John
>>>
>>>
>>>
>>
>>
>>
>> --
>> 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 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 johnl at iecc.com  Tue Sep 22 22:23:18 2009
From: johnl at iecc.com (John Levine)
Date: 23 Sep 2009 03:23:18 -0000
Subject: SMS
In-Reply-To: 
Message-ID: <20090923032318.57490.qmail@simone.iecc.com>

In article  you write:
>On that same note, can someone point me in the direction of an SMS  
>gateway service? I would like to be able to send SMS messages from my  
>monitoring systems, but I am unsure about how to go about it.

If your monitoring system has reliable IP connectivity, I can recommend
Clickatell.  If not, try one of the cellular modem kludges people have
described.

For my own amusement, I wrote a little hack that takes the voicemail
messages that my VoIP service mails me, extracts a few salient facts
of calling number and message length, and sends me an SMS notification
to my mobile phone so I know to call and pick up my messages.  Works
great.

R's,
John





From w3yni1 at gmail.com  Tue Sep 22 22:26:45 2009
From: w3yni1 at gmail.com (Charles Mills)
Date: Tue, 22 Sep 2009 23:26:45 -0400
Subject: SAS70 Type II compliant colo providers - Chicago, IL
In-Reply-To: <16720fe00909221753o2fd18489sc39f12c5ee4f5356@mail.gmail.com>
References: <4AB8F33D.9060101@nexus6.co.za>
	<54FF0D32-F131-45A0-89F0-D67C00922A10@istaff.org>
	<16720fe00909221717k60ad8909yda25a461e0d2c6f8@mail.gmail.com>
	<890005330909221750h2a0b6accvc630e54ea9bac4df@mail.gmail.com>
	<16720fe00909221753o2fd18489sc39f12c5ee4f5356@mail.gmail.com>
Message-ID: <607f1e0a0909222026y13489ce3u7a87a0f2903458c2@mail.gmail.com>

Hmm...the ones I've been involved with have to go through an
independent third party audit to ensure that they are compliant.  The
independent auditor has to agree that they're practices are secure and
satisfies the credit card company's security objectives.
If it were that loose you'd see a lot more security breaches on the
magnitude of the TJX breach.

Chuck

On Tue, Sep 22, 2009 at 8:53 PM, Jeffrey Lyon
 wrote:
> Most of our customers just make up their own definition of PCI and
> then demand that we help them adhere to it.
>
> Jeff
>
> On Tue, Sep 22, 2009 at 8:50 PM, Jay Farrell  wrote:
>> Yes, but with PCI compliance the powers that be (credit card
>> companies) can actually fine you big bucks for being non-compliant.
>>
>> http://www.google.com/search?hl=en&source=hp&q=pci+compliance+fines&aq=f&oq=&aqi=g1g-m1
>>
>> http://www.pcicomplianceguide.org/pcifaqs.php#11
>>
>> Cheers,
>> Jayfar
>>
>> On Tue, Sep 22, 2009 at 8:17 PM, Jeffrey Lyon
>>  wrote:
>>> People buy SAS 70 compliant anything just because it's the latest
>>> buzzword, kind of like PCI compliance.
>>>
>>> Jeff
>>>
>>> On Tue, Sep 22, 2009 at 7:52 PM, John Curran  wrote:
>>>> On Sep 22, 2009, at 11:54 AM, Andy Ashley wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I would really appreciate any recommendations for SAS70 Type II compliant
>>>>> colocation providers in Chicago, IL
>>>>
>>>> Andy -
>>>>
>>>> ? As an FYI, SAS 70 Type II compliance means whatever that provider's "SAS
>>>> 70 Type II" audit document states for controls, i.e. there is no specific
>>>> requirements associated with SAS 70 Type II, only that you publish a
>>>> documented set of management and security controls and then are audited for
>>>> compliance against that list. ?That may not be realized by the folks who've
>>>> sent you to go get SAS 70 Type II compliant hosting, but is something that
>>>> you probably want to keep in mind since little items like generators and
>>>> door locks aren't necessarily included.
>>>>
>>>> /John
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> 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 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 bannai at pacbell.net  Tue Sep 22 23:31:49 2009
From: bannai at pacbell.net (Vinay Bannai)
Date: Tue, 22 Sep 2009 21:31:49 -0700
Subject: 802.17b Case studies and current usage on Metro Ethernets
In-Reply-To: 
References: 
Message-ID: <4AB9A4B5.80903@pacbell.net>

Fabio,

I believe there are several companies that build equipment based on the 
802.17B standard. I will be more than glad to list them if you want.
I was quite involved in IEEE 802.17 during the standardization up till 
2005. What are you looking for in the case studies?

I can go at length on the merits of RPR.
- You can have upto 255 nodes in a ring (2000KM rings) and very robust
- It runs a native L2 based topology and had 50ms recovery for fiber 
chops and restoration
- It supports both source steering and wrapping
- Most importantly it support CoS and fairness for nodes on the ring for 
certain types of traffic

Some of the cons:
- Limited number of vendors and chip makers supporting this technology
- Has remained a niche technology and faces competition from EAPS and ERPS
- A little complex to understand

Let me know if you have any more questions.

Vinay Bannai

Fabio Mendes wrote:
> I'd appreciate if someone could answer some of my questions:
>
>
> 1. What vendors currently offer support to the IEEE 802.17b standard ?
>
> 2. After extensive searching, have found no case studies. Do you guys could
> recomend any ?
>
> 3. If someone had been envolved with 802.17's deployments, what are your
> thoughts about it ? I mean, the whole process as well as the benefits (and
> problems) that arose.
>
>
>
> Thanks !
>
>   




From morrowc.lists at gmail.com  Tue Sep 22 23:50:34 2009
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 23 Sep 2009 00:50:34 -0400
Subject: SAS70 Type II compliant colo providers - Chicago, IL
In-Reply-To: <607f1e0a0909222026y13489ce3u7a87a0f2903458c2@mail.gmail.com>
References: <4AB8F33D.9060101@nexus6.co.za>
	<54FF0D32-F131-45A0-89F0-D67C00922A10@istaff.org>
	<16720fe00909221717k60ad8909yda25a461e0d2c6f8@mail.gmail.com>
	<890005330909221750h2a0b6accvc630e54ea9bac4df@mail.gmail.com>
	<16720fe00909221753o2fd18489sc39f12c5ee4f5356@mail.gmail.com>
	<607f1e0a0909222026y13489ce3u7a87a0f2903458c2@mail.gmail.com>
Message-ID: <75cb24520909222150g651a4e65j6a4b27a5b2e8a1b2@mail.gmail.com>

On Tue, Sep 22, 2009 at 11:26 PM, Charles Mills  wrote:
> Hmm...the ones I've been involved with have to go through an
> independent third party audit to ensure that they are compliant. ?The

the pci-is-good/sux (and sas-70 is-good/sux) discussion seems out of
nanog scope, to me... but really PCI compliance isn't the panacea,
heck I bet TJX was PCI compliant for some portions of the things owned
six ways to sunday in their breach. The same goes for the last 12
'major' breaches and information leaks.

No compliance doc/cert is going to save the day, only good ongoing
practices and vigilant administration is going to make it better.

That said did anyone actualy suggest a sas-70 colo in ORD?? VZB's
CHI10 facility used to be in this set, the OP might consider checking
with them... (though I recall CHI10 being 'full' or 'out of power',
but I'm sure that's changed/improved)

-Chris
(there was some effort a while back to sas-70 ceritfy most of the
ex-UU datacenters)

> independent auditor has to agree that they're practices are secure and
> satisfies the credit card company's security objectives.
> If it were that loose you'd see a lot more security breaches on the
> magnitude of the TJX breach.
>
> Chuck
>
> On Tue, Sep 22, 2009 at 8:53 PM, Jeffrey Lyon
>  wrote:
>> Most of our customers just make up their own definition of PCI and
>> then demand that we help them adhere to it.
>>
>> Jeff
>>
>> On Tue, Sep 22, 2009 at 8:50 PM, Jay Farrell  wrote:
>>> Yes, but with PCI compliance the powers that be (credit card
>>> companies) can actually fine you big bucks for being non-compliant.
>>>
>>> http://www.google.com/search?hl=en&source=hp&q=pci+compliance+fines&aq=f&oq=&aqi=g1g-m1
>>>
>>> http://www.pcicomplianceguide.org/pcifaqs.php#11
>>>
>>> Cheers,
>>> Jayfar
>>>
>>> On Tue, Sep 22, 2009 at 8:17 PM, Jeffrey Lyon
>>>  wrote:
>>>> People buy SAS 70 compliant anything just because it's the latest
>>>> buzzword, kind of like PCI compliance.
>>>>
>>>> Jeff
>>>>
>>>> On Tue, Sep 22, 2009 at 7:52 PM, John Curran  wrote:
>>>>> On Sep 22, 2009, at 11:54 AM, Andy Ashley wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I would really appreciate any recommendations for SAS70 Type II compliant
>>>>>> colocation providers in Chicago, IL
>>>>>
>>>>> Andy -
>>>>>
>>>>> ? As an FYI, SAS 70 Type II compliance means whatever that provider's "SAS
>>>>> 70 Type II" audit document states for controls, i.e. there is no specific
>>>>> requirements associated with SAS 70 Type II, only that you publish a
>>>>> documented set of management and security controls and then are audited for
>>>>> compliance against that list. ?That may not be realized by the folks who've
>>>>> sent you to go get SAS 70 Type II compliant hosting, but is something that
>>>>> you probably want to keep in mind since little items like generators and
>>>>> door locks aren't necessarily included.
>>>>>
>>>>> /John
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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 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 lists at nexus6.co.za  Wed Sep 23 07:06:40 2009
From: lists at nexus6.co.za (Andy Ashley)
Date: Wed, 23 Sep 2009 14:06:40 +0200
Subject: SAS70 Type II compliant colo providers - Chicago, IL
In-Reply-To: <4AB8F33D.9060101@nexus6.co.za>
References: <4AB8F33D.9060101@nexus6.co.za>
Message-ID: <4ABA0F50.4020303@nexus6.co.za>

Andy Ashley wrote:
> Hi,
>
> I would really appreciate any recommendations for SAS70 Type II 
> compliant colocation providers in Chicago, IL
>
> The requirement is fairly small (1/2 - 1 rack). Mail me off list please.
>
> Thanks.
>
Thanks to everyone who replied with advice and 
recommendations/referrals, there were too many to respond to individually.
I have made a couple of choices and will make further enquiries with 
those companies.

Regards,
Andy.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




From jtodd at loligo.com  Wed Sep 23 09:42:08 2009
From: jtodd at loligo.com (John Todd)
Date: Wed, 23 Sep 2009 07:42:08 -0700
Subject: SMS
In-Reply-To: <3c3e3fca0909220929w7b4ea46bvcd21f10efc897122@mail.gmail.com>
References: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>
	<067601ca3b98$0fd53820$2f7fa860$@com>
	
	<4AB8F2D6.90107@evaristesys.com>
	<004401ca3b9d$b80ca0a0$2825e1e0$@net>
	<3c3e3fca0909220929w7b4ea46bvcd21f10efc897122@mail.gmail.com>
Message-ID: <4088C5A4-C93F-4F63-B1E9-716A7F7985EA@loligo.com>


On Sep 22, 2009, at 9:29 AM, William Herrin wrote:

> On Tue, Sep 22, 2009 at 11:59 AM, Scott Berkman   
> wrote:
> [snip]
>> I believe there was another solution that involved direct carrier
>> connections, but these are most likely cost prohibitive in most  
>> situations.
>
> Any pointers on this would be greatly appreciated. I have a need for
> geographically redundant access to the same phone numbers in order to
> send and receive SMS messages. Even if I have to buy a pair of T1s
> that are 99.9% idle, it'd be worth it.
>
> Regards,
> Bill Herrin
>
> -- 
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: 
> Falls Church, VA 22042-3004


   This question frequently arises on the VoIP/Asterisk lists, since  
it is a question that VoIP service providers often wish to answer -  
"How do I SMS-enable my VoIP customer numbers?"

   In other areas of the world, SMS is much more easily tied into  
existing voice networks - in the UK (among others) for instance, SMS  
is possible over PRI connections, which enables "land lines" to send  
and receive SMS messages.  Clickatell, the company referenced  
previously, is based in South Africa.  Buying their service for  
delivery of SMS into North America means that your messages will be  
sent with a "generic" short-code, which is not guaranteed and has in  
the past even been blocked by carriers.  Users cannot reply to those  
messages, because many other companies are using the same short code  
return address.  If you look at their website, you'll see that if you  
live in one of a few non-NA nations, you can buy an actual phone  
number (not a short code) which can be used for high-volume  
bidirectional communication via SMS.

   Here in North America, we're basically out of luck unless you hack  
together a hardware-based SMS device, and even that may be not  
reliable since carriers explicitly state that their accounts cannot be  
shared, and a large number of SMS messages to/from a particular  
account may cause it to be disconnected without warning.  It appears  
to me that carriers have taken the stance that SMS should be for  
infrequent messages between actual fingers (no automation allowed!) or  
via short codes, and short codes involve a significant amount of cost,  
configuration, and even arbitrary approvals from the carriers on the  
use of a short code.  If you look at the form required for a short  
code request, you'll discover that it's not for generic use - it's  
geared entirely for ad campaigns.

   A few years ago I tried searching for SMS-enabled SIP telephone  
numbers (DIDs) and found that there was a new service available, but  
the monthly price floor was pretty steep.  I still have not met anyone  
actually offering the service, but I'm sure there must be resellers of  
it by now.  It was Level 3, offering SIP trunks with DIDs on them.   
Another company, Syniverse, was then SMS-enabling those numbers in an  
exclusive agreement.  Payment had to go to each company, separately.   
The costs per number to enable SMS were fairly low, and the costs for  
message transmission were fairly low, but the Level 3 minimum purchase  
price was quite high (imagine that you could buy a nice sports car  
every month with the "minimum payment".)  I have no idea if this  
service is still available, or how successful it's been.

   If anyone now has direct experience with a reseller or small  
distributor of this service, let me know - I'm still looking for a SIP- 
capable DID that can handle SMTP/SMPP/XML-HTML transmission of SMS  
messages with some decent volume (200-1000 messages per day.)

Here's a message in a thread from a while back on this topic which has  
some pointers:

http://lists.digium.com/pipermail/asterisk-users/2008-October/220726.html

JT

---
John Todd                       email:jtodd at digium.com
Digium, Inc. | Asterisk Open Source Community Director
445 Jan Davis Drive NW -  Huntsville AL 35806  -   USA
direct: +1-256-428-6083         http://www.digium.com/



From rens at autempspourmoi.be  Wed Sep 23 09:43:57 2009
From: rens at autempspourmoi.be (Rens)
Date: Wed, 23 Sep 2009 16:43:57 +0200
Subject: Wireless STM-1 link
In-Reply-To: <4a80ecce0909100906h591d5e46k15f249cc7cc3b688@mail.gmail.com>
References: <9138BEE0A93342EBB729FA81440C6B06@EU.corp.clearwire.com>
	
	
	<4a80ecce0909100906h591d5e46k15f249cc7cc3b688@mail.gmail.com>
Message-ID: <81DBED0EAF7B4AABBDA706EF57FB51D1@EU.corp.clearwire.com>

When I do a lot of pings with small packet size I get drops.

I'm think this is because of the flow control that I activated and the link
can't handle it this fast and drops them.

This at least is what the vendor says => dropping the low priority ping
packets is normal behavior.

 

I have the ability to enable 802.1p on the link, is there a way to
prioritize the OSPF hello packets with this?

 

  _____  

From: Kenny Sallee [mailto:kenny.sallee at gmail.com] 
Sent: jeudi 10 septembre 2009 18:06
To: Rens
Cc: Adam Goodman; nanog at nanog.org
Subject: Re: Wireless STM-1 link

 

On Thu, Sep 10, 2009 at 2:55 AM, Rens  wrote:

All the interfaces are forced to 1Gbps and full duplex.

Maybe I should give some extra info.
All the traffic seems to pass ok via that link but I have seen that often
OSPF adjacencies go down/up , I suspect that the HELLO packets are being
dropped that pass via that link.

That's why I started to look a little deeper and do some ping tests.


-----Original Message-----
From: Adam Goodman [mailto:adam at wispring.com]
Sent: jeudi 10 septembre 2009 11:45
To: Rens
Cc: 
Subject: Re: Wireless STM-1 link

Sounds like this might be an Ethernet negotiaton problem

--------
Sent from my phone

 

Seems everyone has focused on GE as the problem.  You can quickly rule that
out by looking at interface error counters and doing PING tests from the
wireless router/device to something on the local network on both sides.  If
OSPF is flapping because of missed HELLO packets then I'm thinking you have
a problem with either saturation on the link or actual wireless issues.
When PING does work what do the times look like? I'd look at static routing
for a bit (if practical) or changing your OSPF HELLO intervals to see if
that does anything.  Here's a good link on troubleshooting OSPF adjacency
changes:
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094050
.shtml 

 



From tme at americafree.tv  Wed Sep 23 11:14:42 2009
From: tme at americafree.tv (Marshall Eubanks)
Date: Wed, 23 Sep 2009 12:14:42 -0400
Subject: BT US to UK
Message-ID: <3BBF8BBA-257F-41C6-8D43-9ADEFE116106@americafree.tv>

Is anyone else seeing issues with British Telecom from UK to the US ?

I have heard rumors that undersea fiber links might be involved.

Regards
Marshall



From psirt at cisco.com  Wed Sep 23 11:15:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 23 Sep 2009 12:15:00 -0400
Subject: Cisco Security Advisory: Cisco IOS Software Object-group Access
	Control List Bypass Vulnerability
Message-ID: <200909231215.acl@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS Software Object-group Access
Control List Bypass Vulnerability

Advisory ID: cisco-sa-20090923-acl

Revision 1.0

For Public Release 2009 September 23

+---------------------------------------------------------------------

Summary
=======

A vulnerability exists in Cisco IOS? software where an
unauthenticated attacker could bypass access control policies when
the Object Groups for Access Control Lists (ACLs) feature is used.
Cisco has released free software updates that address this
vulnerability. There are no workarounds for this vulnerability other
than disabling the Object Groups for ACLs feature.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-acl.shtml

Note: The September 23, 2009, Cisco IOS Security Advisory bundled
publication includes eleven Security Advisories. Ten of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the releases that correct the
vulnerability or vulnerabilities detailed in the advisory. The
following table lists releases that correct all Cisco IOS Software
vulnerabilities that have been published on September 23, 2009, or
earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090923-bundle.shtml

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Advisory Bundled Publication" at the following
link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep09.html

Affected Products
=================

Vulnerable Products
+------------------

Any Cisco device configured with ACLs using the object group feature
and running an affected Cisco IOS software version is affected by
this vulnerability.

Note: The Object Groups for ACLs feature was introduced in Cisco IOS
software version 12.4(20)T.

To verify whether object groups are configured in a Cisco IOS device,
use the "show object-group" command in user EXEC or privileged EXEC
mode. The following example displays a sample output from the "show
object-group" command when object groups are configured:

    Router# show object-group
    Network object group my_host_group
     host 172.18.104.123
    
    Service object group my_allowed_services
     tcp eq www
     tcp eq 443

Alternatively, administrators can also use the "show running config |
include ^ (permit|deny) .*object-group" command to verify whether
object groups are configured, as shown in the following example:

    Router#show running-config | include ^ (permit|deny) .*object-group
     permit object-group my_allowed_services host 10.10.1.1 host 10.20.1.1
     permit tcp any object-group my_host_group eq 22

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the
"show version" command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name displays in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the "show version" command or may provide
different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.3(26) with an installed image name of
C2500-IS-L:

    Router#show version
    Cisco Internetwork Operating System Software
    IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by cisco Systems, Inc.
    Compiled Mon 17-Mar-08 14:39 by dchih
    
    
    !--- output truncated
    

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.4(20)T with an installed image name of
C1841-ADVENTERPRISEK9-M:

    Router#show version
    Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by Cisco Systems, Inc.
    Compiled Thu 10-Jul-08 20:25 by prod_rel_team
    
    
    !--- output truncated
    

Products Confirmed Not Vulnerable
+--------------------------------

Cisco devices that are not configured with object groups are not
vulnerable.

Cisco IOS XE Software and Cisco IOS XR Software are not affected by
this vulnerability.

No other Cisco products are currently known to be affected by this
vulnerability.

Details
=======

In Cisco IOS Software an object group can contain a single object
(such as a single IP address, network, or subnet) or multiple objects
(such as a combination of multiple IP addresses, networks, or
subnets). In an ACL that is based on an object group, administrators
can create a single access control entry (ACE) that uses an object
group name instead of creating many ACEs, which each would require a
different IP address. A similar object group, such as a protocol port
group, can be extended to limit access to a set of applications for a
user group to a server group.

A vulnerability exists in Cisco IOS Software that could allow an
unauthenticated attacker to bypass access control policies when the
Object Groups for ACLs feature is used.

Note: The Object Groups for ACLs feature was introduced in Cisco IOS
software version 12.4(20)T.

This vulnerability is documented in the following Cisco Bug IDs:

  * CSCsx07114
  * CSCsu70214
  * CSCsw47076
  * CSCsv48603
  * CSCsy54122
  * CSCsu50252

This vulnerability has been assigned Common Vulnerabilities and
Exposures (CVE) identifier CVE-2009-2862.

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

CSCsx07114, CSCsu70214, CSCsw47076, CSCsv48603, CSCsy54122, CSCsu50252 -
Object-group Access Control List Bypass

CVSS Base Score - 4.3

Access Vector           - Network
Access Complexity       - Medium
Authentication          - None
Confidentiality Impact  - Parital
Integrity Impact        - None
Availability Impact     - none

CVSS Temporal Score - 3.6

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

Impact
======

Successful exploitation of the vulnerability may allow an attacker to
access resources that should be protected by the Cisco IOS device.

Software Versions and Fixes
===========================

When considering software upgrades, also consult:

http://www.cisco.com/go/psirt

and any subsequent advisories to determine exposure and a complete
upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|   Major    |          Availability of Repaired Releases           |
|  Release   |                                                      |
|------------+------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.0-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.0 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.1-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.1 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.2-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.1 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.3-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.3 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.4-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|------------+---------------------------------------+--------------|
| 12.4       | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.4GC     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
| 12.4JA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JMA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JMB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(11)MD9  |
|            |                                       |              |
| 12.4MD     | 12.4(22)MD1                           | 12.4(15)MD3  |
|            |                                       |              |
|            |                                       | 12.4(22)MD1  |
|------------+---------------------------------------+--------------|
| 12.4MDA    | 12.4(22)MDA1                          | 12.4(22)MDA1 |
|------------+---------------------------------------+--------------|
| 12.4MR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4SW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(20)T4   |
|            | 12.4(22)T2                            |              |
|            |                                       | 12.4(22)T3   |
| 12.4T      | 12.4(20)T4                            |              |
|            |                                       | 12.4(24)T2;  |
|            | 12.4(24)T1                            | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4XA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XE     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XM     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XN     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XP     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XT     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XV     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
|            |                                       | 12.4(22)T3   |
| 12.4XZ     | Vulnerable; first fixed in 12.4T      |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(22)T3   |
|            |                                       |              |
| 12.4YA     | Vulnerable; first fixed in 12.4T      | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4YB     | 12.4(22)YB4                           | 12.4(22)YB4  |
|------------+---------------------------------------+--------------|
| 12.4YD     | 12.4(22)YD1                           | 12.4(22)YD1  |
|------------+---------------------------------------+--------------|
| 12.4YE     | 12.4(22)YE1                           | 12.4(22)YE1  |
|------------+---------------------------------------+--------------|
| 12.4YG     | Not Vulnerable                        |              |
+-------------------------------------------------------------------+

Note: No Cisco IOS-XE or Cisco IOS Software Modularity releases are
affected by this vulnerability.

Workarounds
===========

There are no workarounds for this vulnerability other than disabling
the Object Groups for ACLs feature.

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. 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
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was found during internal testing.

Status of this Notice: FINAL
============================

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-20090923-acl.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 |                   | Initial |
| 1.0      | 2009-September-23 | 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
-----BEGIN PGP SIGNATURE-----

iD8DBQFKukF586n/Gc8U/uARAuXEAJ99dU6Wi1fZMY1yNgedSCx4/+0p8wCeOSKF
HmMwzq017QkqDzBFo/JH6DQ=
=XJAG
-----END PGP SIGNATURE-----



From psirt at cisco.com  Wed Sep 23 11:15:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 23 Sep 2009 12:15:00 -0400
Subject: Cisco Security Advisory: Cisco Unified Communications Manager Session
	Initiation Protocol Denial of Service Vulnerability
Message-ID: <200909231215.cm@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco Unified Communications Manager Session
Initiation Protocol Denial of Service Vulnerability

Advisory ID: cisco-sa-20090923-cm

Revision 1.0

For Public Release 2009 September 23

+---------------------------------------------------------------------

Summary
=======

Cisco Unified Communications Manager, which was formerly Cisco
Unified CallManager, contains a denial of service (DoS) vulnerability
in the Session Initiation Protocol (SIP) service. An exploit of this
vulnerability may cause an interruption in voice services.

Cisco has released free software updates that address this
vulnerability. There are no workarounds for this vulnerability.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-cm.shtml

Note: Cisco IOS? Software is also affected by the vulnerability
described in this advisory. A companion advisory for Cisco IOS
software is available at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-sip.shtml

Note: The September 23, 2009, Cisco IOS Security Advisory bundled
publication includes eleven Security Advisories. Ten of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the releases that correct the
vulnerability or vulnerabilities detailed in the advisory. The
following table lists releases that correct all Cisco IOS Software
vulnerabilities that have been published on September 23, 2009, or
earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090923-bundle.shtml

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Advisory Bundled Publication" at the following
link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep09.html

Affected Products
=================

The vulnerability described in this document applies to the Cisco
Unified Communications Manager.

Vulnerable Products
+------------------

The following Cisco Unified Communications Manager versions are
affected:

  * Cisco Unified Communications Manager 5.x versions prior to 5.1(3g)
  * Cisco Unified Communications Manager 6.x versions prior to 6.1(4)
  * Cisco Unified Communications Manager 7.0.x versions prior to 7.0(2a)su1
  * Cisco Unified Communications Manager 7.1.x versions prior to 7.1(2)

Cisco Unified CallManager versions 4.x are not affected by this
vulnerability. Administrators of systems that are running Cisco
Unified Communications Manager versions 5.x, 6.x and 7.x can
determine the software version by viewing the main page of the Cisco
Unified Communications Manager Administration interface. The software
version can also be determined by running the "show version active"
command via the command-line interface.

A SIP trunk must be configured for the Cisco Unified CallManager
server to begin listening for SIP messages on TCP and UDP port 5060
and TCP/5061. However, in Cisco Unified Communications Manager
versions 5.x and later, the use of SIP as a call signaling protocol
is enabled by default and cannot be disabled.

Cisco IOS Software is also affected by this vulnerability, but it is
associated with different Cisco bug IDs. A companion security
advisory for Cisco IOS Software is available at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-sip.shtml

Products Confirmed Not Vulnerable
+--------------------------------

Cisco Unified CallManager versions 4.x are not affected by this
vulnerability. With the exception of Cisco IOS software, no other
Cisco products are currently known to be affected by this
vulnerability.

Details
=======

Cisco Unified Communications Manager is the call processing component
of the Cisco IP Telephony solution that extends enterprise telephony
features and functions to packet telephony network devices, such as
IP phones, media processing devices, voice-over-IP gateways, and
multimedia applications.

SIP is a popular signaling protocol that manages voice and video
calls across IP networks such as the Internet. SIP is responsible for
handling all aspects of call setup and termination. Voice and video
are the most popular types of sessions that SIP handles, but the
protocol is flexible enough to accommodate other applications that
require call setup and termination. SIP call signaling can use UDP
(port 5060), TCP (port 5060), or Transport Layer Security (TLS; TCP
port 5061) as the underlying transport protocol.

A DoS vulnerability exists in the SIP implementation of the Cisco
Unified Communications Manager. This vulnerability could be triggered
when Cisco Unified Communications Manager processes crafted SIP
messages. An exploit could lead to a reload of the main Cisco Unified
Communications Manager process.

This vulnerability is documented in Cisco bug ID CSCsz95423 and has been
assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2009-2864.

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

CSCsz95423 - Crafted SIP packet may cause CM process to crash

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

Impact
======

Successful exploitation of the vulnerability that is described in
this advisory could result in a reload of the Cisco Unified
Communications Manager process, which may result in the interruption
of voice services.

Software Versions and Fixes
===========================

When considering software upgrades, also consult:

http://www.cisco.com/go/psirt

and any subsequent advisories to determine exposure and a complete
upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

The following table contains the first fixed software release for
this vulnerability. A device running a version of the given release
in a specific row (less than the First Fixed Release) is known to be
vulnerable.

+---------------------------------------+
| Release   | First Fixed Version       |
|-----------+---------------------------|
| 4.x       | Not Vulnerable            |
|-----------+---------------------------|
| 5.x       | 5.1(3g)                   |
|-----------+---------------------------|
| 6.x       | 6.1(4)                    |
|-----------+---------------------------|
| 7.0.x     | 7.0(2a)su1                |
|-----------+---------------------------|
| 7.1.x     | 7.1(2)                    |
+---------------------------------------+

Workarounds
===========

There are no workarounds for this vulnerability.

It is possible to mitigate this vulnerability by implementing
filtering on screening devices and permitting TCP/UDP access to ports
5060 and TCP/5061 only from networks that require SIP access to Cisco
Unified Communications Manager servers.

If Cisco Unified Communications Manager does not need to provide SIP
services, administrators can configure the Cisco Unified
Communications Manager to listen for SIP messages on non standard
ports. Use the following instructions to change the ports from their
default values:

Step 1 Log into the Cisco Unified CallManager Administration web
interface.

Step 2 Navigate to System > Cisco Unified CM and locate the
appropriate Cisco Unified Communications Manager.

Step 3 Change the fields SIP Phone Port and SIP Phone Secure Port
fields to a non standard port and click Save.

SIP Phone Port, which is 5060 by default, refers to the TCP and UDP
ports where the Cisco Unified Communications Manager listens for
normal SIP messages, and SIP Phone Secure Port, by default 5061,
refers to the TCP port where the Cisco Unified Communications Manager
listens for SIP over TLS messages. For additional information about
this procedure, refer to the "Updating a Cisco Unified Communications
Manager" section of the "Cisco Unified Communications Manager
Administration Guide" at:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucmbe/admin/7_0_1/ccmcfg/b02ccm.html#wp1057513

Note: For a SIP port change to take effect, the Cisco CallManager
Service must be restarted. For information on how to restart the
service, refer to the "Restarting the Cisco CallManager Service"
section of the document at:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucmbe/admin/7_0_1/ccmcfg/b03dpi.html#wp1075124

Additional mitigations that can be deployed on Cisco devices in the
network are available in the companion document "Cisco Applied
Mitigation Bulletin: Identifying and Mitigating Exploitation of the
Denial of Service Vulnerabilities in Cisco Unified Communications
Manager and Cisco IOS Software", which is available at the following
location:

http://www.cisco.com/warp/public/707/cisco-amb-20090923-voice.shtml

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. 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
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was discovered during internal testing.

Status of this Notice: FINAL
============================

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-20090923-cm.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 |                   | Initial |
| 1.0      | 2009-September-23 | 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
-----BEGIN PGP SIGNATURE-----

iD8DBQFKukGE86n/Gc8U/uARAp0sAJ9WOsbXB1KzPl36kQRFCcVHLqC9twCgiOQx
lBVMS0I0ypD4TW2DBvWPkLM=
=1qvW
-----END PGP SIGNATURE-----



From psirt at cisco.com  Wed Sep 23 11:15:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 23 Sep 2009 12:15:00 -0400
Subject: Cisco Security Advisory: Cisco Unified Communications Manager Express
	Vulnerability
Message-ID: <200909231215.cme@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco Unified Communications Manager Express
Vulnerability

Advisory ID: cisco-sa-20090923-cme

Revision 1.0

For Public Release 2009 September 23

+---------------------------------------------------------------------

Summary
=======

Cisco IOS? devices that are configured for Cisco Unified
Communications Manager Express (CME) and the Extension Mobility
feature are vulnerable to a buffer overflow vulnerability. Successful
exploitation of this vulnerability may result in the execution of
arbitrary code or a Denial of Service (DoS) condition on an affected
device.

Cisco has released free software updates that address this
vulnerability.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-cme.shtml

Note: The September 23, 2009, Cisco IOS Security Advisory bundled
publication includes eleven Security Advisories. Ten of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the releases that correct the
vulnerability or vulnerabilities detailed in the advisory. The
following table lists releases that correct all Cisco IOS Software
vulnerabilities that have been published on September 23, 2009, or
earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090923-bundle.shtml

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Advisory Bundled Publication" at the following
link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep09.html

Affected Products
=================

Cisco IOS devices, including Cisco Unified Communications 500 Series,
that are configured for Cisco Unified CME and the Extension Mobility
feature are affected.

Vulnerable Products
+------------------

A Cisco IOS device that is configured for Cisco Unified CME and
Extension Mobility contains the following output when the show
running-config command is issued:

    ephone [Ethernet phone tag]
      ...
      logout-profile [logout-profile tag]

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the 
"show version" command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name is displayed in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the "show version" command or may provide
different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.3(26) with an installed image name of
C2500-IS-L:

        Router#show version
        Cisco Internetwork Operating System Software
        IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2)
        Technical Support: http://www.cisco.com/techsupport
        Copyright (c) 1986-2008 by cisco Systems, Inc.
        Compiled Mon 17-Mar-08 14:39 by dchih
    
        

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.4(20)T with an installed image name of
C1841-ADVENTERPRISEK9-M:

        Router#show version
        Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
        Technical Support: http://www.cisco.com/techsupport
        Copyright (c) 1986-2008 by Cisco Systems, Inc.
        Compiled Thu 10-Jul-08 20:25 by prod_rel_team
    
        

Additional information about Cisco IOS Software release naming
conventions is available in "White Paper: Cisco IOS Reference Guide"
at the following link: http://www.cisco.com/warp/public/620/1.html .

Products Confirmed Not Vulnerable
+--------------------------------

Cisco IOS devices that are configured for Survivable Remote Site
Telephony (SRST) Mode are not affected.

Cisco IOS XR is not affected.

Cisco IOS XE is not affected.

Cisco Unified Communications Manager is not affected.

Cisco Unified CME is not affected unless configured to use the
Extension Mobility feature.

No other Cisco products are currently known to be affected by these
vulnerabilities.

Details
=======

Cisco Unified CME is the call processing component of an enhanced IP
telephony solution that is integrated into Cisco IOS.

The Extension Mobility feature in Cisco Unified CME provides the
benefit of phone mobility for end users. A user login service allows
phone users to temporarily access a physical phone other than their
own phone and utilize their personal settings, such as directory
number, speed-dial lists, and services, that is assigned to their own
desk phone. The phone user can make and receive calls on that phone
using the same personal directory number as is on their own desk
phone. More information on Extension Mobility feature is available at
the following URL:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmemobl.html

A vulnerability in the login section of the Extension Mobility
feature may allow an unauthenticated attacker to execute arbitrary
code or cause a Denial of Service (DoS) condition. Such packets can
only come from registered phone IP addresses in the form of HTTP
requests. If the auto-registration feature is enabled, an attacker
can register its IP address and subsequently send a crafted payload
to exploit this vulnerability. The auto-registration feature is
enabled by default. More information on auto-registration can be
found at the following link:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/command/reference/cme_a1ht.html#wp1031242.

This vulnerability is addressed by the Cisco Bug ID CSCsq58779 and has
been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2009-2865.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerabilities 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

CSCsq58779 - Vulnerability in Extension Mobility Feature

CVSS Base Score - 7.6

Access Vector           - Network
Access Complexity       - High
Authentication          - None
Confidentiality Impact  - Complete
Integrity Impact        - Complete
Availability Impact     - Complete

CVSS Temporal Score - 6.3

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

Impact
======

Successful exploitation of this vulnerability may result in the
execution of arbitrary code or a Denial of Service (DoS) condition on
an affected device.

Software Versions and Fixes
===========================

When considering software upgrades, also consult:

http://www.cisco.com/go/psirt

and any subsequent advisories to determine exposure and a complete
upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|    Major Release     |        Availability of Repaired Releases   |
|----------------------+--------------------------------------------|
| Affected 12.0-Based  |  First Fixed  |    Recommended Release     |
|       Releases       |    Release    |                            |
|-------------------------------------------------------------------|
| There are no affected 12.0 based releases.                        |
|-------------------------------------------------------------------|
| Affected 12.1-Based  |  First Fixed  |    Recommended Release     |
|       Releases       |    Release    |                            |
|-------------------------------------------------------------------|
| There are no affected 12.1 based releases.                        |
|-------------------------------------------------------------------|
| Affected 12.2-Based  |  First Fixed  |    Recommended Release     |
|       Releases       |    Release    |                            |
|-------------------------------------------------------------------|
| There are no affected 12.2 based releases.                        |
|-------------------------------------------------------------------|
| Affected 12.3-Based  |  First Fixed  |    Recommended Release     |
|       Releases       |    Release    |                            |
|-------------------------------------------------------------------|
| There are no affected 12.3 based releases.                        |
|-------------------------------------------------------------------|
| Affected 12.4-Based  |  First Fixed  |    Recommended Release     |
|       Releases       |    Release    |                            |
|----------------------+---------------+----------------------------|
| 12.4                 | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4GC               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4JA               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4JDA              | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4JDC              | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4JDD              | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4JK               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4JL               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4JMA              | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4JMB              | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4JX               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4MD               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4MDA              | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4MR               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4SW               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4T                | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XA               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XB               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XC               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XD               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XE               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XF               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XG               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XJ               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XK               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XL               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XM               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XN               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XP               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XQ               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XR               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XT               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4XV               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
|                      |               | 12.4(20)T4                 |
|                      |               |                            |
| 12.4XW               | 12.4(11)XW8   | 12.4(22)T3                 |
|                      |               |                            |
|                      |               | 12.4(24)T2; Available on   |
|                      |               | 23-OCT-2009                |
|----------------------+---------------+----------------------------|
|                      |               | 12.4(20)T4                 |
|                      |               |                            |
| 12.4XY               | 12.4(15)XY4   | 12.4(22)T3                 |
|                      |               |                            |
|                      |               | 12.4(24)T2; Available on   |
|                      |               | 23-OCT-2009                |
|----------------------+---------------+----------------------------|
|                      |               | 12.4(20)T4                 |
|                      |               |                            |
| 12.4XZ               | 12.4(15)XZ1   | 12.4(22)T3                 |
|                      |               |                            |
|                      |               | 12.4(24)T2; Available on   |
|                      |               | 23-OCT-2009                |
|----------------------+---------------+----------------------------|
|                      |               | 12.4(20)T4                 |
|                      |               |                            |
| 12.4YA               | 12.4(20)YA1   | 12.4(22)T3                 |
|                      |               |                            |
|                      |               | 12.4(24)T2; Available on   |
|                      |               | 23-OCT-2009                |
|----------------------+---------------+----------------------------|
| 12.4YB               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4YD               | Not           |                            |
|                      | Vulnerable    |                            |
|----------------------+---------------+----------------------------|
| 12.4YE               | Not           |                            |
|                      | Vulnerable    |                            |
+-------------------------------------------------------------------+

Workarounds
===========

There are no workarounds to mitigate this vulnerability, other than
disabling Extension Mobility. However, auto-registration can be
disabled to make exploitation more difficult. Auto-registration can
be disabled by the following command:

    telephony-service 
      no auto-reg-ephone 

Before disabling auto-registration, all phone MAC addresses need to
be explicitly defined on the Cisco Unified CME. Otherwise phones will
not be able to register. More information on auto-registration can be
found at the following link:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/command/reference/cme_a1ht.html#wp1031242

Additional mitigations that can be deployed on Cisco devices in the
network are available in the Cisco Applied Mitigation Bulletin
companion document for this advisory, which is available at the
following link:

http://www.cisco.com/warp/public/707/cisco-amb-20090923-cme.shtml

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. 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
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was found internally.

Status of this Notice: FINAL
============================

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-20090923-cme.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 |                   | Initial |
| 1.0      | 2009-September-23 | 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
-----BEGIN PGP SIGNATURE-----

iD8DBQFKukGH86n/Gc8U/uARAgunAJ90YNHlxpf2v1OEz8qFEo7oqmNAqACfbq6X
iHSiDV5CevynZQRrKe+sRiU=
=Fp40
-----END PGP SIGNATURE-----



From psirt at cisco.com  Wed Sep 23 11:15:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 23 Sep 2009 12:15:00 -0400
Subject: Cisco Security Advisory: Cisco IOS Software H.323 Denial of Service
	Vulnerability
Message-ID: <200909231215.h323@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS Software H.323 Denial of Service
Vulnerability

Advisory ID: cisco-sa-20090923-h323

Revision 1.0

For Public Release 2009 September 23

+---------------------------------------------------------------------

Summary
=======

The H.323 implementation in Cisco IOS? Software contains a
vulnerability that can be exploited remotely to cause a device that
is running Cisco IOS Software to reload.

Cisco has released free software updates that address this
vulnerability. There are no workarounds to mitigate the vulnerability
apart from disabling H.323 if the device that is running Cisco IOS
Software does not need to run H.323 for VoIP services.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-h323.shtml

Note: The September 23, 2009, Cisco IOS Security Advisory bundled
publication includes eleven Security Advisories. Ten of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the releases that correct the
vulnerability or vulnerabilities detailed in the advisory. The
following table lists releases that correct all Cisco IOS Software
vulnerabilities that have been published on September 23, 2009, or
earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090923-bundle.shtml

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Advisory Bundled Publication" at the following
link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep09.html

Affected Products
=================

Vulnerable Products
+------------------

Cisco devices that are running affected Cisco IOS Software versions
that are configured to process H.323 messages are affected by this
vulnerability. H.323 is not enabled by default.

To determine the Cisco IOS Software device is running H.323 services
use the "show process cpu | include 323" command, as shown in the
following example:

    Router#show process cpu | include 323
     249       16000           3       5333  0.00%  0.00%  0.00%   0 CCH323_CT
     250           0           1          0  0.00%  0.00%  0.00%   0 CCH323_DNS
    Router# 

Note: Only H.323 listening port TCP 1720 is affected.

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the 
"show version" command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name displays in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the "show version" command or may provide
different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.3(26) with an installed image name of
C2500-IS-L:

    Router#show version
    Cisco Internetwork Operating System Software
    IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by cisco Systems, Inc.
    Compiled Mon 17-Mar-08 14:39 by dchih
    
    
    !--- output truncated
    

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.4(20)T with an installed image name of
C1841-ADVENTERPRISEK9-M:

    Router#show version
    Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by Cisco Systems, Inc.
    Compiled Thu 10-Jul-08 20:25 by prod_rel_team
    
    
    !--- output truncated
    

Additional information about Cisco IOS Software release naming
conventions is available in "White Paper: Cisco IOS Reference Guide"
at the following link:

http://www.cisco.com/warp/public/620/1.html

Products Confirmed Not Vulnerable
+--------------------------------

Cisco IOS XE and Cisco IOS XR Software are not affected by this
vulnerability. No other Cisco products are currently known to be
affected by this vulnerability.

Details
=======

H.323 is the ITU standard for real-time multimedia communications and
conferencing over packet-based (IP) networks. A subset of the H.323
standard is H.225.0, a standard used for call signalling protocols
and media stream packetization over IP networks.

The H.323 implementation in Cisco IOS Software contains a
vulnerability. An attacker can exploit this vulnerability remotely by
sending an H.323 crafted packet to the affected device that is
running Cisco IOS Software. A TCP three-way handshake is needed to
exploit this vulnerability.

This vulnerability is documented in Cisco bug ID CSCsz38104 and has
been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2009-2866.

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

CSCsz38104 - Crafted H323 packets may cause device to reload

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

Impact
======

Successful exploitation of the vulnerability described in this
document may cause the affected device to reload. The issue could be
exploited repeatedly to cause an extended DoS condition.

Software Versions and Fixes
===========================

When considering software upgrades, also consult:

http://www.cisco.com/go/psirt

and any subsequent advisories to determine exposure and a complete
upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|   Major    |          Availability of Repaired Releases           |
|  Release   |                                                      |
|------------+------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.0-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.0 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.1-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.1 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.2-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|------------+---------------------------------------+--------------|
| 12.2       | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; first fixed in 12.4       | 12.4(25b)    |
| 12.2B      |                                       |              |
|            | Releases up to and including 12.2(4)  | 12.4(23b)    |
|            | B8 are not vulnerable.                |              |
|------------+---------------------------------------+--------------|
| 12.2BC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2BW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; first fixed in 12.4       | 12.4(25b)    |
| 12.2BX     |                                       |              |
|            | Releases up to and including 12.2(15) | 12.4(23b)    |
|            | BX are not vulnerable.                |              |
|------------+---------------------------------------+--------------|
| 12.2BY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2BZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2CX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2CY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2CZ     | Vulnerable; migrate to 12.2SB         | 12.2(33)SB7  |
|------------+---------------------------------------+--------------|
| 12.2DA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2DD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2DX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2EW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2EWA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2EX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2EY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2EZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2FX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2FY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2FZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IRA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IRB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IRC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXE    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXF    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXG    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXH    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2JA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2JK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2MB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Releases up to and including 12.2(15) |              |
|            | MC1 are not vulnerable.               | 12.4(25b)    |
| 12.2MC     |                                       |              |
|            | Releases 12.2(15)MC2b and later are   | 12.4(23b)    |
|            | not vulnerable; first fixed in 12.4   |              |
|------------+---------------------------------------+--------------|
| 12.2S      | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SBC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SCA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SCB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SE     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SEA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SEB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SEC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SED    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SEE    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SEF    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SEG    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SGA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SM     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SO     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SRA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SRB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SRC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SRD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2STE    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SV     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SVA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SVC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SVD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SVE    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXE    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXF    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXH    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXI    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; first fixed in 12.4       | 12.4(25b)    |
| 12.2T      |                                       |              |
|            | Releases up to and including 12.2(8)  | 12.4(23b)    |
|            | T10 are not vulnerable.               |              |
|------------+---------------------------------------+--------------|
| 12.2TPC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XE     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XH     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XI     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XM     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XNA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XNB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XNC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XND    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XO     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XS     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XT     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XV     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YE     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2YH     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2YJ     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
| 12.2YK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2YL     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.2YM     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2YN     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
| 12.2YO     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YP     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YS     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2YT     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2YU     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            | Releases prior to 12.2(11)YV1 are     |              |
| 12.2YV     | vulnerable, release 12.2(11)YV1 and   |              |
|            | later are not vulnerable              |              |
|------------+---------------------------------------+--------------|
| 12.2YW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2ZC     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2ZD     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.2ZE     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.2ZF     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
| 12.2ZG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.2ZH     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2ZJ     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2ZL     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2ZP     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
| 12.2ZU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZYA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|  Affected  |                                       | Recommended  |
| 12.3-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3       | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3B      | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
| 12.3BC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3BW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3EU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JEA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JEB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JEC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Releases up to and including 12.3(2)  |              |
|            | JK3 are not vulnerable.               | 12.4(25b)    |
| 12.3JK     |                                       |              |
|            | Releases 12.3(8)JK1 and later are not | 12.4(23b)    |
|            | vulnerable; first fixed in 12.4       |              |
|------------+---------------------------------------+--------------|
| 12.3JL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3T      | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
| 12.3TPC    | Releases up to and including 12.3(4)  |              |
|            | TPC11a are not vulnerable.            |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3VA     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            | Releases prior to 12.3(2)XA7 are      | 12.4(25b)    |
| 12.3XA     | vulnerable, release 12.3(2)XA7 and    |              |
|            | later are not vulnerable; first fixed | 12.4(23b)    |
|            | in 12.4                               |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.3XB     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XC     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XD     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XE     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.3XF     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XG     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            | Note: Releases prior to 12.3(7)XI11   | 12.2(33)SB7  |
| 12.3XI     | are vulnerable, release 12.3(7)XI11   |              |
|            | and later are not vulnerable;         | 12.2(31)SB16 |
|------------+---------------------------------------+--------------|
| 12.3XJ     | Vulnerable; migrate to any release in | 12.4(15)T10  |
|            | 12.4XN                                |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XK     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XL     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XQ     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XR     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
| 12.3XS     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            | Vulnerable; first fixed in 12.4T      | 12.4(20)T4   |
|            |                                       |              |
| 12.3XU     | Releases up to and including 12.3(8)  | 12.4(22)T3   |
|            | XU1 are not vulnerable.               |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            | Vulnerable; migrate to any release in | 12.4(15)XR7  |
| 12.3XW     | 12.4XR                                |              |
|            |                                       | 12.4(22)XR   |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XX     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XY     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XZ     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
| 12.3YA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; migrate to any release in | 12.4(15)XR7  |
| 12.3YF     | 12.4XR                                |              |
|            |                                       | 12.4(22)XR   |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YG     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.3YH     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YI     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            | Releases prior to 12.3(11)YK3 are     | 12.4(20)T4   |
|            | vulnerable, release 12.3(11)YK3 and   |              |
| 12.3YK     | later are not vulnerable; first fixed | 12.4(22)T3   |
|            | in 12.4T                              |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YM     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YQ     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            | Vulnerable; first fixed in 12.4T      | 12.4(20)T4   |
|            |                                       |              |
| 12.3YS     | Releases up to and including 12.3(11) | 12.4(22)T3   |
|            | YS1 are not vulnerable.               |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YT     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YU     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)XR7  |
| 12.3YX     | Vulnerable; migrate to 12.4XR         |              |
|            |                                       | 12.4(22)XR   |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.3YZ     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3ZA     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|  Affected  |                                       | Recommended  |
| 12.4-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|------------+---------------------------------------+--------------|
|            | 12.4(25b)                             | 12.4(25b)    |
| 12.4       |                                       |              |
|            | 12.4(23b)                             | 12.4(23b)    |
|------------+---------------------------------------+--------------|
| 12.4GC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JMA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JMB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4MD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4MDA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Releases prior to 12.4(19)MR3 are     |              |
| 12.4MR     | vulnerable, release 12.4(19)MR3 and   |              |
|            | later are not vulnerable              |              |
|------------+---------------------------------------+--------------|
| 12.4SW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            | 12.4(15)T10                           |              |
|            |                                       | 12.4(20)T4   |
|            | 12.4(20)T4                            |              |
| 12.4T      |                                       | 12.4(22)T3   |
|            | 12.4(22)T2                            |              |
|            |                                       | 12.4(24)T2;  |
|            | 12.4(24)T1                            | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XA     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XB     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XC     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XD     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XE     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4XF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XJ     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4XK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.4XL     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            | Vulnerable; first fixed in 12.4T      | 12.4(20)T4   |
|            |                                       |              |
| 12.4XM     | Releases up to and including 12.4(15) | 12.4(22)T3   |
|            | XM are not vulnerable.                |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4XN     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.4XP     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
| 12.4XQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XT     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.4XV     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XW     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XY     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XZ     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4YA     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4YB     | 12.4(22)YB4                           | 12.4(22)YB4  |
|------------+---------------------------------------+--------------|
| 12.4YD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4YE     | Not Vulnerable                        |              |
+-------------------------------------------------------------------+

Note: No Cisco IOS-XE Software or Cisco IOS Software Modularity
releases are affected by this vulnerability.

Workarounds
===========

There are no workarounds to mitigate the vulnerability apart from
disabling H.323 if the Cisco IOS device does not need to run H.323
for VoIP services. Affected devices that must run H.323 are
vulnerable, and there are not any specific configurations that can be
used to protect them. Applying access lists on interfaces that should
not accept H.323 traffic and putting firewalls in strategic locations
may greatly reduce exposure until an upgrade can be performed.

Cisco provides Solution Reference Network Design (SRND) guides to
help design and deploy networking solutions, which can be found at 
http://www.cisco.com/go/srnd Voice Security best practices are
covered in the Cisco Unified Communications SRND Based on Cisco
Unified Communications Manager 6.x at:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/6x/security.html

Below is an example of an access list to block H.323 management
traffic from anywhere but a permitted network. In this example, the
permitted network is 172.16.0.0/16.

    
    !--- Permit access from any IP address in the 172.16.0.0/16 
    !--- network to anywhere on port 1720.
    
    
    access-list 101 permit tcp 172.16.0.0 0.0.255.255 any eq 1720
    
    
    !--- Permit access from anywhere to a host in the 
    !--- 172.16.0.0/26 network on port 1720.
    
     
    access-list 101 permit tcp any 172.16.0.0 0.0.255.255 eq 1720
    
    
    !--- Deny all traffic from port 1720.
    
    
    access-list 101 deny tcp any eq 1720 any
    
    
    !--- Deny all traffic to port 1720.
    
    
    access-list 101 deny tcp any any eq 1720
    
    
    !--- Permit all other traffic.
    
    
    access-list 101 permit ip any any

Alternatively, you can use the "call service stop forced" command under
the "voice service voip" mode, as shown in the following example:

    voice service voip
     h323
      call service stop forced

Additional mitigations that can be deployed on Cisco devices within
the network are available in the companion document "Cisco Applied
Mitigation Bulletin: Identifying and Mitigating Exploitation of the
Denial of Service Vulnerabilities in Cisco Unified Communications
Manager and Cisco IOS Software", which is available at the following
location:

http://www.cisco.com/warp/public/707/cisco-amb-20090923-voice.shtml

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. 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
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was found during internal testing.

Status of this Notice: FINAL
============================

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-20090923-h323.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 |                   | Initial |
| 1.0      | 2009-September-23 | 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
-----BEGIN PGP SIGNATURE-----

iD8DBQFKukGL86n/Gc8U/uARAg57AJ9RtkzXFDXBhVYa/uszbYnplu2nhgCeJmtM
vims3xWW7vcpqLkfphuJWzs=
=eh5W
-----END PGP SIGNATURE-----



From psirt at cisco.com  Wed Sep 23 11:15:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 23 Sep 2009 12:15:00 -0400
Subject: Cisco Security Advisory: Cisco IOS Software Zone-Based Policy
	Firewall Vulnerability
Message-ID: <200909231215.ios-fw@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS Software Zone-Based Policy
Firewall Vulnerability

Advisory ID: cisco-sa-20090923-ios-fw

Revision 1.0

For Public Release 2009 September 23

+---------------------------------------------------------------------

Summary
=======

Cisco IOS? devices that are configured with Cisco IOS Zone-Based
Policy Firewall Session Initiation Protocol (SIP) inspection are
vulnerable to denial of service (DoS) attacks when processing a
specific SIP transit packet. Exploitation of the vulnerability could
result in a reload of the affected device.

Cisco has released free software updates that address this
vulnerability.

Workarounds that mitigate this vulnerability are available.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-ios-fw.shtml

Note: The September 23, 2009, Cisco IOS Security Advisory bundled
publication includes eleven Security Advisories. Ten of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the releases that correct the
vulnerability or vulnerabilities detailed in the advisory. The
following table lists releases that correct all Cisco IOS Software
vulnerabilities that have been published on September 23, 2009, or
earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090923-bundle.shtml

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Advisory Bundled Publication" at the following
link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep09.html

Affected Products
=================

This vulnerability affects a limited number of Cisco IOS Software
releases. Consult the "Software Versions and Fixes" section of this
advisory for the details of affected releases.

Only devices that are configured with Cisco IOS Zone-Based Policy
Firewall SIP inspection (UDP port 5060, TCP ports 5060, and 5061) are
vulnerable. Cisco IOS devices that are configured with legacy Cisco
IOS Firewall Support for SIP (context-based access control (CBAC))
are not vulnerable.

Vulnerable Products
+------------------

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the 
"show version" command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name displays in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the "show version" command or may provide
different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.3(26) with an installed image name of
C2500-IS-L:

    Router#show version
    Cisco Internetwork Operating System Software
    IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2)
    Technical Support: http://www.cisco.com/techsupport
    Copyright ?) 1986-2008 by cisco Systems, Inc.
    Compiled Mon 17-Mar-08 14:39 by dchih
    
    

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.4(20)T with an installed image name of
C1841-ADVENTERPRISEK9-M:

    Router#show version
    Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
    Technical Support: http://www.cisco.com/techsupport
    Copyright ?) 1986-2008 by Cisco Systems, Inc.
    Compiled Thu 10-Jul-08 20:25 by prod_rel_team
    
    

Additional information about Cisco IOS Software release naming
conventions is available in "White Paper: Cisco IOS Reference Guide"
at the following link:

http://www.cisco.com/warp/public/620/1.html

The device is vulnerable if the configuration has either a layer 3 or
layer 7 SIP application-specific policy configured, and these
policies are applied to any firewall zone. To determine whether the
device is running a vulnerable configuration, log in to the device
and issue the command line interface (CLI) command "show policy-map
type inspect zone-pair | include atch: access|protocol sip". If the
output contains "Match: protocol sip", the device is vulnerable. If
the output contains "Match: access-group number", then the device is
only vulnerable "if", the referenced access list permits the SIP
protocol (UDP port 5060, or TCP ports 5060 and 5061). The following
example shows a vulnerable device configured with Cisco IOS
Zone-Based Policy Firewall SIP inspection:

    Router#show policy-map type inspect zone-pair | include atch: access|protocol sip
          Match: protocol sip
    Router#

The following example shows a vulnerable device configured with SIP
inspection by way of an applied access list:

    Router#show policy-map type inspect zone-pair | include atch: access|protocol sip
          Match: access-group 102
    Router#
    Router#show access-list 102
    Extended IP access list 102
        10 permit udp any any eq 5060
        20 permit tcp any any eq 5060
        30 permit tcp any any eq 5061
    Router#

A device that is not configured for SIP inspection or does not
support this configuration will return either a blank line or an
error message. The following is an example of a device that supports
Cisco IOS Firewall but does not have SIP inspection enabled:

    Router#show policy-map type inspect zone-pair | include atch: access|protocol sip
    Router#

Products Confirmed Not Vulnerable
+--------------------------------

No other Cisco products are currently known to be affected by this
vulnerability. Products confirmed not vulnerable include:

  * Cisco PIX 500 Series Firewall
  * Cisco ASA 5500 Series Adaptive Security Appliance
  * Firewall Services Module (FWSM) for Catalyst 6500 Series Switches
    and 7600 Series Routers
  * Virtual Firewall (VFW) application on the multiservice blade
    (MSB) on the Cisco XR 12000 Series Router
  * Cisco ACE Application Control Engine Module
  * Cisco IOS devices NOT configured with Cisco IOS Zone-Based Policy
    Firewall SIP inspection.
  * Cisco IOS devices configured with legacy Cisco IOS Firewall
    Support for SIP (CBAC)
  * Cisco IOS XE Software
  * Cisco IOS XR Software

Details
=======

Firewalls are networking devices that control access to the network
assets of an organization. Firewalls are often positioned at the
entrance points into networks. Cisco IOS software provides a set of
security features that enable you to configure a simple or elaborate
firewall policy, according to your particular requirements.

SIP inspection in the Cisco IOS Firewall provides basic SIP inspect
functionality (SIP packet inspection and pinhole opening) as well as
protocol conformance and application security.

Cisco IOS Software that is configured with Cisco IOS Zone-Based
Policy Firewall SIP inspection are vulnerable to a DoS attack when
processing a specific SIP transit packet. Exploitation of this
vulnerability will result in a reload of the affected device.

Cisco IOS Zone-Based Policy Firewall SIP inspection was first
introduced in Cisco IOS Software versions 12.4(15)XZ and 12.4(20)T.

Cisco IOS Firewall CBAC support for SIP inspection by way of the "ip
inspect name [inspection_name] sip" is not vulnerable. Additional
information regarding Cisco IOS Firewall CBAC support for SIP
inspection is available in the document "Firewall Support for SIP" at
the following link:

http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_fwall_sip_supp.html

Additional information regarding Cisco IOS Zone-Based Policy Firewall
SIP inspection is available in the document "Cisco IOS Firewall: SIP
Enhancements: ALG and AIC" at the following link:

http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_sip_alg_aic.html

This vulnerability is documented in the following Cisco Bug ID: 
CSCsr18691 and has been assigned the Common Vulnerabilities and Exposures
(CVE) identifier CVE-2009-2867.

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

CSCsr18691 - Cisco IOS Software Zone-Based Policy Firewall

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

Impact
======

Successful exploitation of the vulnerability may result in a reload
of the affected device. Repeated exploit attempts may result in a
sustained DoS attack.

Software Versions and Fixes
===========================

When considering software upgrades, also consult:

http://www.cisco.com/go/psirt

and any subsequent advisories to determine exposure and a complete
upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|  Major Release  |        Availability of Repaired Releases        |
|-----------------+-------------------------------------------------|
|    Affected     |                           |                     |
|   12.0-Based    |    First Fixed Release    | Recommended Release |
|    Releases     |                           |                     |
|-------------------------------------------------------------------|
| There are no affected 12.0 based releases                         |
|-------------------------------------------------------------------|
|    Affected     |                           |                     |
|   12.1-Based    |    First Fixed Release    | Recommended Release |
|    Releases     |                           |                     |
|-------------------------------------------------------------------|
| There are no affected 12.1 based releases                         |
|-------------------------------------------------------------------|
|    Affected     |                           |                     |
|   12.2-Based    |    First Fixed Release    | Recommended Release |
|    Releases     |                           |                     |
|-------------------------------------------------------------------|
| There are no affected 12.2 based releases                         |
|-------------------------------------------------------------------|
|    Affected     |                           |                     |
|   12.3-Based    |    First Fixed Release    | Recommended Release |
|    Releases     |                           |                     |
|-------------------------------------------------------------------|
| There are no affected 12.3 based releases                         |
|-------------------------------------------------------------------|
|    Affected     |                           |                     |
|   12.4-Based    |    First Fixed Release    | Recommended Release |
|    Releases     |                           |                     |
|-----------------+---------------------------+---------------------|
| 12.4            | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4GC          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4JA          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4JDA         | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4JDC         | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4JDD         | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4JK          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4JL          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4JMA         | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4JMB         | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4JX          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4MD          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4MDA         | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4MR          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4SW          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
|                 | Releases prior to 12.4    | 12.4(20)T4          |
|                 | (20)T are not vulnerable; |                     |
|                 |                           | 12.4(22)T3          |
| 12.4T           | 12.4(20)T2                |                     |
|                 |                           | 12.4(24)T2;         |
|                 | 12.4(22)T1                | Available on        |
|                 |                           | 23-OCT-2009         |
|                 | 12.4(24)T                 |                     |
|-----------------+---------------------------+---------------------|
| 12.4XA          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XB          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XC          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XD          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XE          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XF          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XG          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XJ          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XK          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XL          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XM          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XN          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XP          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XQ          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XR          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XT          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XV          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XW          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4XY          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
|                 |                           | 12.4(20)T4          |
|                 |                           |                     |
|                 | Vulnerable; first fixed   | 12.4(22)T3          |
| 12.4XZ          | in 12.4T                  |                     |
|                 |                           | 12.4(24)T2;         |
|                 |                           | Available on        |
|                 |                           | 23-OCT-2009         |
|-----------------+---------------------------+---------------------|
|                 |                           | 12.4(22)T3          |
|                 | Vulnerable; first fixed   |                     |
| 12.4YA          | in 12.4T                  | 12.4(24)T2;         |
|                 |                           | Available on        |
|                 |                           | 23-OCT-2009         |
|-----------------+---------------------------+---------------------|
|                 |                           | 12.4(22)YB4         |
|                 |                           |                     |
| 12.4YB          | 12.4(22)YB4               | 12.4(22)YB5;        |
|                 |                           | Available on        |
|                 |                           | 19-OCT-2009         |
|-----------------+---------------------------+---------------------|
| 12.4YD          | Not Vulnerable            |                     |
|-----------------+---------------------------+---------------------|
| 12.4YE          | Not Vulnerable            |                     |
+-------------------------------------------------------------------+

Workarounds
===========

The only workaround for this vulnerability is to disable Cisco IOS
zone-based policy firewall SIP inspection in the affected device's
configuration. Disabling SIP inspection will allow the rest of the
firewall features to continue to function until a software upgrade
can be implemented. All other firewall features will continue to
perform normally. Disabling SIP Inspection will vary depending on the
implementation of the SIP inspection firewall.

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. 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
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was discovered by Cisco internal testing.

Status of this Notice: FINAL
============================

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-20090923-ios-fw.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 |                   | Initial |
| 1.0      | 2009-September-23 | 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
-----BEGIN PGP SIGNATURE-----

iD8DBQFKukGO86n/Gc8U/uARAiwEAKCXGG7xSxS+kMllVPDdOacuAZV9vACfcVVG
3Lm0u0kNPpfW4oxa9PNOUA8=
=f0Hj
-----END PGP SIGNATURE-----



From psirt at cisco.com  Wed Sep 23 11:15:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 23 Sep 2009 12:15:00 -0400
Subject: Cisco Security Advisory: Cisco IOS Software Internet Key Exchange
	Resource Exhaustion Vulnerability
Message-ID: <200909231215.ipsec@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS Software Internet Key Exchange
Resource Exhaustion Vulnerability

Advisory ID: cisco-sa-20090923-ipsec

Revision 1.0

For Public Release 2009 September 23

+---------------------------------------------------------------------

Summary
=======

Cisco IOS? devices that are configured for Internet Key Exchange
(IKE) protocol and certificate based authentication are vulnerable to
a resource exhaustion attack. Successful exploitation of this
vulnerability may result in the allocation of all available Phase 1
security associations (SA) and prevent the establishment of new IPsec
sessions.

Cisco has released free software updates that address this
vulnerability.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-ipsec.shtml

Note: The September 23, 2009, Cisco IOS Security Advisory bundled
publication includes eleven Security Advisories. Ten of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the releases that correct the
vulnerability or vulnerabilities detailed in the advisory. The
following table lists releases that correct all Cisco IOS Software
vulnerabilities that have been published on September 23, 2009, or
earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090923-bundle.shtml

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Advisory Bundled Publication" at the following
link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep09.html

Affected Products
=================

Cisco IOS devices that are configured for IKE and certificate based
authentication are affected.

Vulnerable Products
+------------------

IKE is enabled by default if IPsec is used. Cisco IOS devices that
are configured for IKE will listen on UDP port 500, UDP port 4500 if
the device is configured for NAT Traversal (NAT-T), or UDP ports 848
or 4848 if the device is configured for Group Domain of
Interpretation (GDOI). The following outputs show a router that is
listening on UDP port 500:

    Router#show ip sockets 
    Proto    Remote      Port      Local       Port  In Out Stat TTY OutputIF
    ....
     17   --listen--          192.168.66.129    500   0   0   11   0 
    ....

Or

    Router-#show udp
    Proto        Remote      Port      Local       Port  In Out  Stat TTY OutputIF
     17       --listen--          192.0.2.1         500   0   0  1011   0 
     17(v6)   --listen--          --any--           500   0   0 20011   0 
    Router#

IKE configurations that are performing certificate based
authentication will display "Rivest-Shamir-Adleman Signature" as the
authentication method in the output of the "show crypto isakmp policy"
command. This output is shown in the following example:

    Router#show crypto isakmp policy                               
    
    Global IKE policy
    Default protection suite
            encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
            hash algorithm:         Secure Hash Standard
            authentication method:  Rivest-Shamir-Adleman Signature
            Diffie-Hellman group:   #1 (768 bit)
            lifetime:               86400 seconds, no volume limit

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the 
"show version" command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name displays in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the "show version" command or may provide
different output.

The following example identifies a Cisco 6500 Series device that is
running Cisco IOS Software release 12.2(18)SXF7 with an installed
image name of s72033_rp-IPSERVICESK9_WAN-M:

    Router#show version 
    Cisco Internetwork Operating System Software 
    IOS (tm) s72033_rp Software (s72033_rp-IPSERVICESK9_WAN-M), Version 12.2(18)SXF7, RELEASE SOFTWARE (fc1)
    Technical Support: http://www.cisco.com/techsupport
    Copyright ?) 1986-2006 by cisco Systems, Inc.
    Compiled Thu 23-Nov-06 06:42 by kellythw
    

Additional information about Cisco IOS Software release naming
conventions is available in "White Paper: Cisco IOS Reference Guide"
at the following link:

http://www.cisco.com/warp/public/620/1.html

Products Confirmed Not Vulnerable
+--------------------------------

Cisco IOS XR Software is not affected by this vulnerability.

No other Cisco products are currently known to be affected by this
vulnerability.

Details
=======

IPsec is an IP security feature that provides robust authentication
and encryption of IP packets. IKE is a key management protocol
standard that is used in conjunction with the IPsec standard.

IKE is a hybrid protocol that implements the Oakley and SKEME key
exchanges inside the Internet Security Association and Key Management
Protocol (ISAKMP) framework. (ISAKMP, Oakley, and SKEME are security
protocols that are implemented by IKE.). More information on IKE is
available at the following link:

http://www.cisco.com/en/US/docs/ios/12_1/security/configuration/guide/scdike.html

A vulnerability exists in the IKE implementation of Cisco IOS
Software, if the certificate based authentication method is used.
Successful exploitation of this vulnerability may result in the
allocation of all available Phase 1 SAs, which may prevent new IPSec
sessions from being established.

Administrators can view Phase 1 SAs that are allocated as a result of
exploitation by issuing the "show crypto isakmp sa" command. The
following example displays sample output for this command:

    Router#show crypto isakmp sa
    IPv4 Crypto ISAKMP SA
    dst             src             state          conn-id slot status
    10.48.66.77     10.48.66.6      MM_KEY_EXCH       1004 ACTIVE
    10.48.66.77     10.48.66.6      MM_KEY_EXCH       1003 ACTIVE
    10.48.66.77     10.48.66.6      MM_KEY_EXCH       1002 ACTIVE
    ....

Any allocated SA can be de-allocated up manually by using the "clear
crypto isakmp " command.

This vulnerability is addressed by the Cisco Bug IDs CSCsy07555 and
CSCee72997 and has been assigned Common Vulnerabilities and Exposures
(CVE) ID CVE-2009-2868.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerabilities 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

CSCsy07555 - P1 SA stuck in KEY_EXCH forever

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

CSCee72997 - P1 SA stuck in KEY_EXCH forever

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

Impact
======

Successful exploitation of this vulnerability may result in the
allocation of all available Phase 1 SAs, which may prevent new IPsec
sessions from being established.

Software Versions and Fixes
===========================

When considering software upgrades, also consult:

http://www.cisco.com/go/psirt

and any subsequent advisories to determine exposure and a complete
upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|   Major    |          Availability of Repaired Releases           |
|  Release   |                                                      |
|------------+------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.0-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.0 based releases                         |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.1-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.1 based releases                         |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.2-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|------------+---------------------------------------+--------------|
| 12.2       | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2B      | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2BC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2BW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2BX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2BY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2BZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2CX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2CY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2CZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2DA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2DD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2DX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2EW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2EWA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Releases prior to 12.2(44)EX are      | 12.2(50)SE3  |
|            | vulnerable, release 12.2(44)EX and    |              |
| 12.2EX     | later are not vulnerable; migrate to  | 12.2(52)SE;  |
|            | any release in 12.2SEG                | Available on |
|            |                                       | 13-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.2EY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2EZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2FX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2FY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2FZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IRA    | Vulnerable; first fixed in 12.2SRD    | 12.2(33)SRD3 |
|------------+---------------------------------------+--------------|
| 12.2IRB    | Vulnerable; first fixed in 12.2SRD    | 12.2(33)SRD3 |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.2IRC    | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
| 12.2IXA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXE    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXF    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXG    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2IXH    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2JA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2JK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2MB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2MC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2S      | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.2(31)SB16 |
| 12.2SB     | 12.2(33)SB6                           |              |
|            |                                       | 12.2(33)SB7  |
|------------+---------------------------------------+--------------|
| 12.2SBC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SCA    | Vulnerable; first fixed in 12.2SCB    | 12.2(33)SCB4 |
|------------+---------------------------------------+--------------|
| 12.2SCB    | 12.2(33)SCB4                          | 12.2(33)SCB4 |
|------------+---------------------------------------+--------------|
|            |                                       | 12.2(50)SE3  |
|            | 12.2(50)SE3                           |              |
| 12.2SE     |                                       | 12.2(52)SE;  |
|            | 12.2(52)SE; Available on 13-OCT-2009  | Available on |
|            |                                       | 13-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.2SEA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SEB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SEC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SED    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SEE    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SEF    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SEG    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SGA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SM     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SO     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SRA    | Vulnerable; first fixed in 12.2SRD    | 12.2(33)SRD3 |
|------------+---------------------------------------+--------------|
| 12.2SRB    | Vulnerable; first fixed in 12.2SRD    | 12.2(33)SRD3 |
|------------+---------------------------------------+--------------|
| 12.2SRC    | 12.2(33)SRC5; Available on            | 12.2(33)SRD3 |
|            | 29-OCT-2009                           |              |
|------------+---------------------------------------+--------------|
|            | 12.2(33)SRD3                          |              |
| 12.2SRD    |                                       | 12.2(33)SRD3 |
|            | 12.2(33)SRD2a                         |              |
|------------+---------------------------------------+--------------|
| 12.2STE    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SV     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SVA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SVC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SVD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SVE    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXE    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SXF    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | 12.2(33)SXH6; Available on            | 12.2(33)     |
|            | 30-OCT-2009                           | SXH6;        |
| 12.2SXH    |                                       | Available on |
|            | Please see IOS Software Modularity    | 30-OCT-2009  |
|            | Patch                                 |              |
|------------+---------------------------------------+--------------|
| 12.2SXI    | 12.2(33)SXI2a                         | 12.2(33)     |
|            |                                       | SXI2a        |
|------------+---------------------------------------+--------------|
| 12.2SY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2SZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2T      | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2TPC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XE     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XH     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XI     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XM     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XNA    | Please see Cisco IOS-XE Software      |              |
|            | Availability                          |              |
|------------+---------------------------------------+--------------|
| 12.2XNB    | Please see Cisco IOS-XE Software      |              |
|            | Availability                          |              |
|------------+---------------------------------------+--------------|
| 12.2XNC    | Please see Cisco IOS-XE Software      |              |
|            | Availability                          |              |
|------------+---------------------------------------+--------------|
| 12.2XND    | Please see Cisco IOS-XE Software      |              |
|            | Availability                          |              |
|------------+---------------------------------------+--------------|
| 12.2XO     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XS     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XT     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XV     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2XW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YE     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YH     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YM     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YN     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YO     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YP     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YS     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YT     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YV     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2YZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZE     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZH     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZP     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.2ZYA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|  Affected  |                                       | Recommended  |
| 12.3-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|------------+---------------------------------------+--------------|
| 12.3       | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3B      | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3BC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3BW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3EU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JEA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JEB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JEC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; first fixed in 12.4       | 12.4(25b)    |
| 12.3T      |                                       |              |
|            | Releases up to and including 12.3(8)  | 12.4(23b)    |
|            | T11 are not vulnerable.               |              |
|------------+---------------------------------------+--------------|
| 12.3TPC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3VA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XE     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XI     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
|            |                                       | 12.4(22)T3   |
| 12.3XL     | Vulnerable; first fixed in 12.4T      |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.3XQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XR     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XS     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
| 12.3XU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3XX     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
| 12.3XY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(25b)    |
| 12.3YA     | Vulnerable; first fixed in 12.4       |              |
|            |                                       | 12.4(23b)    |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YD     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            | Vulnerable; migrate to any release in | 12.4(15)XR7  |
| 12.3YF     | 12.4XN                                |              |
|            |                                       | 12.4(22)XR   |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YG     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YH     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YI     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.3YJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YK     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.3YM     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YQ     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YS     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YT     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YU     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            | Vulnerable; migrate to any release in | 12.4(15)XR7  |
| 12.3YX     | 12.4XN                                |              |
|            |                                       | 12.4(22)XR   |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.3YZ     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
| 12.3ZA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|  Affected  |                                       | Recommended  |
| 12.4-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|------------+---------------------------------------+--------------|
|            | Releases prior to 12.4(7) are         | 12.4(25b)    |
| 12.4       | vulnerable; Releases 12.4(7a) and     |              |
|            | later are not vulnerable.             | 12.4(23b)    |
|------------+---------------------------------------+--------------|
| 12.4GC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JMA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JMB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4MD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4MDA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4MR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4SW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            | 12.4(4)T8                             | 12.4(20)T4   |
|            |                                       |              |
| 12.4T      | 12.4(9)T                              | 12.4(22)T3   |
|            |                                       |              |
|            | 12.4(6)T1                             | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XA     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XB     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XC     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XD     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4XE     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XM     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XN     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XP     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XT     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XV     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4YA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4YB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4YD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4YE     | Not Vulnerable                        |              |
+-------------------------------------------------------------------+

Cisco IOS XE Software
+--------------------

+-------------------------------------------------------------------+
|     Cisco IOS XE Software Release     |    First Fixed Release    |
|---------------------------------------+---------------------------|
| 2.1.x                                 | 2.3.0t                    |
|---------------------------------------+---------------------------|
| 2.2.x                                 | 2.3.0t                    |
|---------------------------------------+---------------------------|
| 2.3.x                                 | Not Vulnerable            |
|---------------------------------------+---------------------------|
| 2.4.x                                 | Not Vulnerable            |
+-------------------------------------------------------------------+

Cisco IOS Software Modularity - Maintenance Packs
+------------------------------------------------

Customers who are using Cisco IOS Software Modularity can apply the
respective maintenance packs. More information on Cisco IOS Software
Modularity can be found at the following link:

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_bulletin0900aecd80313e15.html

The Maintenance Packs listed below can be downloaded at:

http://www.cisco.com/go/pn

Cisco IOS Software Modularity Maintenance Pack for 12.2SXH
+---------------------------------------------------------

+-------------------------------------------------------------------+
|  Cisco IOS Software Release   |   Solution Maintenance Pack(MP)   |
|-------------------------------+-----------------------------------|
| 12.2(33)SXH3                  | MP003                             |
|-------------------------------+-----------------------------------|
| 12.2(33)SXH4                  | MP002                             |
|-------------------------------+-----------------------------------|
| 12.2(33)SXH5                  | MP001                             |
+-------------------------------------------------------------------+

Workarounds
===========

There are no workarounds for this vulnerability.

Additional mitigations that can be deployed on Cisco devices in the
network are available in the Cisco Applied Mitigation Bulletin
companion document for this advisory, which is available at the
following link:

http://www.cisco.com/warp/public/707/cisco-amb-20090923-ipsec.shtml

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. 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
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was reported to Cisco by a customer.

Status of this Notice: FINAL
============================

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-20090923-ipsec.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 |                   | Initial |
| 1.0      | 2009-September-23 | 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
-----BEGIN PGP SIGNATURE-----

iD8DBQFKukGS86n/Gc8U/uARAra6AJ0TewwCLaVWd9M++iaztx1+pEWi6QCfdP8l
OST6ldrzEu8BBhfiZe0wApg=
=9J0c
-----END PGP SIGNATURE-----



From psirt at cisco.com  Wed Sep 23 11:15:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 23 Sep 2009 12:15:00 -0400
Subject: Cisco Security Advisory: Cisco IOS Software Network Time Protocol
	Packet Vulnerability
Message-ID: <200909231215.ntp@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS Software Network Time Protocol
Packet Vulnerability

Advisory ID: cisco-sa-20090923-ntp

Revision 1.0

For Public Release 2009 September 23

+---------------------------------------------------------------------

Summary
=======

Cisco IOS? Software with support for Network Time Protocol (NTP)
version (v4) contains a vulnerability processing specific NTP packets
that will result in a reload of the device. This results in a remote
denial of service (DoS) condition on the affected device.

Cisco has released free software updates that address this
vulnerability.

Workarounds that mitigate this vulnerability are available.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-ntp.shtml

Note: The September 23, 2009, Cisco IOS Security Advisory bundled
publication includes eleven Security Advisories. Ten of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the releases that correct the
vulnerability or vulnerabilities detailed in the advisory. The
following table lists releases that correct all Cisco IOS Software
vulnerabilities that have been published on September 23, 2009, or
earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090923-bundle.shtml

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Advisory Bundled Publication" at the following
link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep09.html

Affected Products
=================

Vulnerable Products
+------------------

Cisco IOS Software devices are vulnerable if they support NTPv4 and
are configured for NTP operations. NTP is not enabled in Cisco IOS
Software by default.

To see if a device supports NTPv4, log into the device and via
configuration mode of the command line interface (CLI), enter the
command "ntp peer 127.0.0.1 version ?". If the output has the number "4"
as an option, then the device supports NTPv4. The following example
identifies a Cisco device that is running a Cisco IOS Software
release that does support NTPv4:

    Router#configure terminal
    Router(config)#ntp peer 127.0.0.1 version ?
      <2-4>  NTP version number

The following example identifies a Cisco device that is running a
Cisco IOS Software release that does not support NTPv4:

    Router(config)#ntp peer 127.0.0.1 version ?
      <1-3>  NTP version number

To see if a device is configured with NTP, log into the device and
issue the CLI command "show running-config | include ntp". If the
output returns either of the following commands listed then the
device is vulnerable:

    ntp master 
    ntp peer 
    ntp server 
    ntp broadcast client
    ntp multicast client

The following example identifies a Cisco device that is configured
with NTP:

    router#show running-config | include ntp
    ntp peer 192.168.0.12

The following example identifies a Cisco device that is not
configured with NTP:

    router#show running-config | include ntp
    router#

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the 
"show version" command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name displays in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the "show version" command or may provide
different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.3(26) with an installed image name of
C2500-IS-L:

    Router#show version
     Cisco Internetwork Operating System Software
     IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2)
     Technical Support: http://www.cisco.com/techsupport
     Copyright ?) 1986-2008 by cisco Systems, Inc.
     Compiled Mon 17-Mar-08 14:39 by dchih
    
     

The following example shows a product that is running Cisco IOS
Software release 12.4(20)T with an image name of
C1841-ADVENTERPRISEK9-M:

    Router#show version
    Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
    Technical Support: http://www.cisco.com/techsupport
    Copyright ?) 1986-2008 by Cisco Systems, Inc.
    Compiled Thu 10-Jul-08 20:25 by prod_rel_team
    
    

Additional information about Cisco IOS Software release naming
conventions is available in "White Paper: Cisco IOS Reference Guide"
at the following link:

http://www.cisco.com/warp/public/620/1.html

Products Confirmed Not Vulnerable
+--------------------------------

The following products and features are not affected by this
vulnerability:

  * Cisco IOS Software devices without support for NTPv4
  * Cisco IOS Software devices configured with only Simple NTP (SNTP)
    feature
  * Cisco IOS XE Software
  * Cisco IOS XR Software

No other Cisco products are currently known to be affected by this
vulnerability.

Details
=======

The Network Time Protocol (NTP) is a protocol designed to
time-synchronize a network of machines. NTP runs over UDP, which in
turn runs over IP. NTPv3 is documented in RFC1305 leavingcisco.com .
NTPv4 is a significant revision of the NTP standard, and is the
current development version, but has not been formalized into an RFC
at the time of publication of this advisory. NTPv4 is currently
documented in draft-ietf-ntp-ntpv4-proto-11 leavingcisco.com

When a Cisco IOS Software device supporting NTPv4 receives a specific
NTP packet it will crash while creating the NTP reply packet. The NTP
packet can be sent from any remote device, and does not require
authentication. Cisco IOS devices supporting NTPv4 and configured
with NTP peer authentication are still vulnerable. The device does
not have to be explicitly configured for NTPv4 peers. For example a
device configured with all NTP peers being explicitly labeled as
version 2 would still be vulnerable, as shown in the following
example:

    Router#show running-config | include ntp
    ntp peer 192.168.0.254 version 2
    ntp peer 192.168.0.1 version 2
    Router#

For further information on the Cisco implementation of NTP, consult
the configuration guide "Cisco IOS and NX-OS Software - Performing
Basic System Management" at the following link:

http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_basic_sys_manage.html#wp1001170

This vulnerability is documented in the following Cisco Bug IDs: 
CSCsu24505 and CSCsv75948 and has been assigned the Common Vulnerabilities
and Exposures (CVE) identifier CVE-2009-2869. Both Cisco bug IDs are
required for a full fix to this vulnerability.

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

CSCsu24505, CSCsv75948 - Cisco IOS Software NTP Packet Vulnerability

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

Impact
======

Successful exploitation of the vulnerability may result in a reload
of the device. The vulnerability could be repeatedly exploited to
cause an extended DoS condition.

Software Versions and Fixes
===========================

When considering software upgrades, also consult:

http://www.cisco.com/go/psirt

and any subsequent advisories to determine exposure and a complete
upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|   Major    |          Availability of Repaired Releases           |
|  Release   |                                                      |
|------------+------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.0-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.0 based releases                         |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.1-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.1 based releases                         |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.2-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.2 based releases                         |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.3-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.3 based releases                         |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.4-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|------------+---------------------------------------+--------------|
| 12.4       | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4GC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JMA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JMB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Releases prior to 12.4(22)MD are not  |              |
| 12.4MD     | vulnerable, vulnerability was first   | 12.4(22)MD1  |
|            | introduced in 12.4(22)MD, first fixed |              |
|            | in 12.4(22)MD1.                       |              |
|------------+---------------------------------------+--------------|
| 12.4MDA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4MR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4SW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Releases prior to 12.4(20)T are not   |              |
|            | vulnerable.                           |              |
|            |                                       | 12.4(20)T4   |
|            | 12.4(20)T and 12.4(20)T1 are          |              |
|            | vulnerable, vulnerability is first    | 12.4(22)T3   |
| 12.4T      | fixed in 12.4(20)T2.                  |              |
|            |                                       | 12.4(24)T2;  |
|            | 12.4(22)T is vulnerable,              | Available on |
|            | vulnerability is first fixed in 12.4  | 23-OCT-2009  |
|            | (22)T1                                |              |
|            |                                       |              |
|            | 12.4(24)T is not vulnerable.          |              |
|------------+---------------------------------------+--------------|
| 12.4XA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XE     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XM     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XN     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XP     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XT     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XV     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
|            |                                       | 12.4(22)T3   |
| 12.4XZ     | Vulnerable; first fixed in 12.4T      |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
|            |                                       | 12.4(22)T3   |
| 12.4YA     | Vulnerable; first fixed in 12.4T      |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4YB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4YD     | 12.4(22)YD1                           | 12.4(22)YD1  |
|------------+---------------------------------------+--------------|
| 12.4YE     | 12.4(22)YE1                           | 12.4(22)YE1  |
+-------------------------------------------------------------------+

Workarounds
===========

There are no workarounds other than disabling NTP on the device. The
following mitigations have been identified for this vulnerability;
only packets destined for any configured IP address on the device can
exploit this vulnerability. Transit traffic will not exploit this
vulnerability.

Note: NTP peer authentication is not a workaround and is still a
vulnerable configuration.

NTP Access Group
+---------------

Warning: Because the feature in this vulnerability utilizes
UDP as a transport, it is possible to spoof the sender's IP address,
which may defeat access control lists (ACLs) that permit
communication to these ports from trusted IP addresses. Unicast
Reverse Path Forwarding (Unicast RPF) should be considered to be used
in conjunction to offer a better mitigation solution.

    
    !--- Configure trusted peers for allowed access
    
    
    access-list 1 permit 171.70.173.55
    
    
    !--- Apply ACE to the NTP configuration
    
    
    ntp access-group 1

For additional information on NTP access control groups, consult the
document titled "Performing Basic System Management" at the following
link:

http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_basic_sys_manage.html#wp1034942

Infrastructure Access Control Lists
+----------------------------------

warning Warning: Because the feature in this vulnerability utilizes
UDP as a transport, it is possible to spoof the sender's IP address,
which may defeat ACLs that permit communication to these ports from
trusted IP addresses. Unicast RPF should be considered to be used in
conjunction to offer a better mitigation solution.

Although it is often difficult to block traffic that transits a
network, it is possible to identify traffic that should never be
allowed to target infrastructure devices and block that traffic at
the border of networks. Infrastructure ACLs (iACLs) are a network
security best practice and should be considered as a long-term
addition to good network security as well as a workaround for this
specific vulnerability. The iACL example below should be included as
part of the deployed infrastructure access-list, which will help
protect all devices with IP addresses in the infrastructure IP
address range:

    
    !---
    !--- Feature: Network Time Protocol (NTP)
    !---
    
    
    access-list 150 permit udp TRUSTED_SOURCE_ADDRESSES WILDCARD 
        INFRASTRUCTURE_ADDRESSES WILDCARD eq 123
    
    
    !--- Note: If the router is acting as a NTP broadcast client
    !---   via the interface command "ntp broadcast client"
    !---   then broadcast and directed broadcasts must be 
    !---   filtered as well.  The following example covers
    !---   an infrastructure address space of 192.168.0.X
    
    
    access-list 150 permit udp TRUSTED_SOURCE_ADDRESSES WILDCARD 
        host 192.168.0.255 eq ntp
    access-list 150 permit udp TRUSTED_SOURCE_ADDRESSES WILDCARD 
        host 255.255.255.255 eq ntp
    
    
    !--- Note: If the router is acting as a NTP multicast client
    !---   via the interface command "ntp multicast client"
    !---   then multicast IP packets to the mutlicast group must
    !---   be filtered as well.  The following example covers
    !---   a NTP multicast group of 239.0.0.1 (Default is
    !---   224.0.1.1)
    
    
    access-list 150 permit udp TRUSTED_SOURCE_ADDRESSES WILDCARD 
        host 239.0.0.1 eq ntp
    
    
    !--- Deny NTP traffic from all other sources destined
    !--- to infrastructure addresses.
    
    
    access-list 150 deny udp any 
        INFRASTRUCTURE_ADDRESSES WILDCARD eq 123
    
    
    !--- Permit/deny all other Layer 3 and Layer 4 traffic in
    !--- accordance with existing security policies and
    !--- configurations.  Permit all other traffic to transit the
    !--- device.
    
    
    access-list 150 permit ip any any
    
    
    !--- Apply access-list to all interfaces (only one example
    !--- shown)
     
    
    interface fastEthernet 2/0
     ip access-group 150 in

The white paper entitled "Protecting Your Core: Infrastructure
Protection Access Control Lists" presents guidelines and recommended
deployment techniques for infrastructure protection access lists and
is available at the following link:

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml

Control Plane Policing
+---------------------

Warning: Because the feature in this vulnerability utilizes UDP as a
transport, it is possible to spoof the sender's IP address, which may
defeat ACLs that permit communication to these ports from trusted IP
addresses. Unicast RPF should be considered to be used in conjunction
to offer a better mitigation solution.

Control Plane Policing (CoPP) can be used to block untrusted UDP
traffic to the device. Cisco IOS software releases 12.0S, 12.2SX,
12.2S, 12.3T, 12.4, and 12.4T support the CoPP feature. CoPP can be
configured on a device to help protect the management and control
planes and minimize the risk and effectiveness of direct
infrastructure attacks by explicitly permitting only authorized
traffic that is sent to infrastructure devices in accordance with
existing security policies and configurations. The CoPP example below
should be included as part of the deployed CoPP, which will help
protect all devices with IP addresses in the infrastructure IP
address range.

    
    !--- Feature: Network Time Protocol (NTP)
    
    
    access-list 150 deny udp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any eq 123
    
    
    !--- Deny NTP traffic from all other sources destined
    !--- to the device control plane.
    
    
    access-list 150 permit udp any any eq 123
    
    
    !--- Permit (Police or Drop)/Deny (Allow) all other Layer3 and 
    !--- Layer4 traffic in accordance with existing security policies
    !--- and configurations for traffic that is authorized to be sent
    !--- to infrastructure devices
    !--- Create a Class-Map for traffic to be policed by
    !--- the CoPP feature
    
    
    class-map match-all drop-udp-class
     match access-group 150
    
    
    !--- Create a Policy-Map that will be applied to the
    !--- Control-Plane of the device.
    
    
    policy-map drop-udp-traffic
     class drop-udp-class
      drop
    
    
    !--- Apply the Policy-Map to the 
    !--- Control-Plane of the device
    
    
    control-plane
     service-policy input drop-udp-traffic

In the above CoPP example, the access control list entries (ACEs)
that match the potential exploit packets with the "permit" action
result in these packets being discarded by the policy-map "drop"
function, while packets that match the "deny" action (not shown) are
not affected by the policy-map drop function. Please note that the
policy-map syntax is different in the 12.2S and 12.0S Cisco IOS
Software trains:

    policy-map drop-udp-traffic
    class drop-udp-class
    police 32000 1500 1500 conform-action drop exceed-action drop

Additional information on the configuration and use of the CoPP
feature can be found in the documents, "Control Plane Policing
Implementation Best Practices" and "Cisco IOS Software Releases 12.2
S - Control Plane Policing" at the following links:

http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html

and

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. 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
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was discovered by Cisco when handling customer
support calls.

Status of this Notice: FINAL
============================

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-20090923-ntp.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 |                   | Initial |
| 1.0      | 2009-September-23 | 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
-----BEGIN PGP SIGNATURE-----

iD8DBQFKukGW86n/Gc8U/uARAjmYAJ0f6SVZp7qLXI0HFG5I0cYzxtFfAACeIvG2
juvYatuemQrQUj8hfg2v0lQ=
=KnSP
-----END PGP SIGNATURE-----



From psirt at cisco.com  Wed Sep 23 11:15:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 23 Sep 2009 12:15:00 -0400
Subject: Cisco Security Advisory: Cisco IOS Software Session Initiation
	Protocol Denial of Service Vulnerability
Message-ID: <200909231215.sip@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS Software Session Initiation
Protocol Denial of Service Vulnerability

Advisory ID: cisco-sa-20090923-sip

Revision 1.0

For Public Release 2009 September 23

+---------------------------------------------------------------------

Summary
=======

A vulnerability exists in the Session Initiation Protocol (SIP)
implementation in Cisco IOS? Software that could allow an
unauthenticated attacker to cause a denial of service (DoS) condition
on an affected device when the Cisco Unified Border Element feature
is enabled.

Cisco has released free software updates that address this
vulnerability. For devices that must run SIP there are no
workarounds; however, mitigations are available to limit exposure of
the vulnerability.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-sip.shtml

Note: The September 23, 2009, Cisco IOS Security Advisory bundled
publication includes eleven Security Advisories. Ten of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the releases that correct the
vulnerability or vulnerabilities detailed in the advisory. The
following table lists releases that correct all Cisco IOS Software
vulnerabilities that have been published on September 23, 2009, or
earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090923-bundle.shtml

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Advisory Bundled Publication" at the following
link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep09.html

Affected Products
=================

This vulnerability only affects devices running Cisco IOS Software
with SIP voice services enabled.

Vulnerable Products
+------------------

Cisco devices running affected Cisco IOS Software versions that are
configured to process SIP messages with the Cisco Unified Border
Element feature are affected. Cisco IOS devices that are not
configured for SIP and Cisco Unified Border Element feature are not
affected by this vulnerability.

Note: Cisco Unified Border Element feature (previously known as the
Cisco Multiservice IP-to-IP Gateway) is a special Cisco IOS Software
image that runs on Cisco multiservice gateway platforms. It provides
a network-to-network interface point for billing, security, call
admission control, quality of service, and signaling interworking.

Cisco Unified Border Element feature requires the "voice service voip" 
command and the "allow-connections" subcommand. An example of an
affected configuration is as follows:

     voice service voip
       allow-connections from-type to to-type 
    ...
    !

Recent versions of Cisco IOS Software do not process SIP messages by
default. Creating a dial peer by issuing the command "dial-peer voice"
will start the SIP processes, causing the Cisco IOS device to process
SIP messages. In addition, several features within Cisco Unified
Communications Manager Express, such as ePhones, once configured will
also automatically start the SIP process, which will cause the device
to start processing SIP messages. An example of an affected
configuration is as follows:

    dial-peer voice  voip
     ...
    !

In addition to inspecting the Cisco IOS device configuration for a
dial-peer command that causes the device to process SIP messages,
administrators can also use the command show processes | include SIP
to determine whether Cisco IOS Software is running the processes that
handle SIP messages. In the following example, the presence of the
processes CCSIP_UDP_SOCKET or CCSIP_TCP_SOCKET indicates that the
Cisco IOS device is processing SIP messages:

        Router#show processes | include SIP
         149 Mwe 40F48254            4          1    400023108/24000  0 CCSIP_UDP_SOCKET
         150 Mwe 40F48034            4          1    400023388/24000  0 CCSIP_TCP_SOCKET

warning Warning: Since there are several ways a device running Cisco
IOS Software can start processing SIP messages, it is recommended
that the "show processes | include SIP" command be used to determine
whether the device is processing SIP messages instead of relying on
the presence of specific configuration commands.

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the
show version command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name displays in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the show version command or may provide
different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.3(26) with an installed image name of
C2500-IS-L:

    Router#show version
    Cisco Internetwork Operating System Software
    IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by cisco Systems, Inc.
    Compiled Mon 17-Mar-08 14:39 by dchih
    
    
    !--- output truncated
    

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.4(20)T with an installed image name of
C1841-ADVENTERPRISEK9-M:

    Router#show version
    Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by Cisco Systems, Inc.
    Compiled Thu 10-Jul-08 20:25 by prod_rel_team
    
    
    !--- output truncated
    

Additional information about Cisco IOS Software release naming
conventions is available in "White Paper: Cisco IOS Reference Guide"
at the following link:

http://www.cisco.com/warp/public/620/1.html

Products Confirmed Not Vulnerable
+--------------------------------

The SIP Application Layer Gateway (ALG), which is used by the Cisco
IOS NAT and firewall features of Cisco IOS Software, is not affected
by this vulnerability. Cisco IOS XE Software and Cisco IOS XR
Software are not affected by this vulnerability. No other Cisco
products are currently known to be affected by this vulnerability.

Details
=======

SIP is a popular signaling protocol that is used to manage voice and
video calls across IP networks such as the Internet. SIP is
responsible for handling all aspects of call setup and termination.
Voice and video are the most popular types of sessions that SIP
handles, but the protocol has the flexibility to accommodate other
applications that require call setup and termination. SIP call
signaling can use UDP (port 5060), TCP (port 5060), or TLS (TCP port
5061) as the underlying transport protocol.

The Cisco Unified Border Element (previously known as the Cisco
Multiservice IP-to-IP Gateway) is a special Cisco IOS Software image
that runs on Cisco multiservice gateway platforms. It provides a
network-to-network interface point for billing, security, call
admission control, quality of service, and signaling interworking.

For more information about Cisco Unified Border Element refer to the
following link:

http://www.cisco.com/en/US/products/sw/voicesw/ps5640/index.html

A DoS vulnerability exists in the SIP implementation in Cisco IOS
Software when devices are running a Cisco IOS image that contains the
Cisco Unified Border Element feature. This vulnerability is triggered
by processing a series of crafted SIP messages.

This vulnerability is documented in Cisco Bug ID CSCsx25880 and has been
assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2009-2870.

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

CSCsx25880 - Crafted SIP packet may cause device reload

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

Impact
======

Successful exploitation of the vulnerability described in this
document may result in a reload of the device. The issue could be
repeatedly exploited to cause an extended DoS condition.

Software Versions and Fixes
===========================

When considering software upgrades, also consult:

http://www.cisco.com/go/psirt

and any subsequent advisories to determine exposure and a complete
upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS Software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|   Major    |          Availability of Repaired Releases           |
|  Release   |                                                      |
|------------+------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.0-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.0 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.1-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.1 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.2-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|-------------------------------------------------------------------|
| There are no affected 12.2 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                       | Recommended  |
| 12.3-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|------------+---------------------------------------+--------------|
| 12.3       | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3B      | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3BC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3BW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3EU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JEA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JEB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JEC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3JX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3T      | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3TPC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3VA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XB     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XC     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XE     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XI     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XS     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XY     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3XZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YH     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YI     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YJ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            | Releases prior to 12.3(11)YK3 are     | 12.4(20)T4   |
|            | vulnerable, release 12.3(11)YK3 and   |              |
| 12.3YK     | later are not vulnerable; first fixed | 12.4(22)T3   |
|            | in 12.4T                              |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.3YM     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            | Vulnerable; first fixed in 12.4T      | 12.4(20)T4   |
|            |                                       |              |
| 12.3YS     | Releases up to and including 12.3(11) | 12.4(22)T3   |
|            | YS1 are not vulnerable.               |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.3YT     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.3YU     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3YZ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.3ZA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|  Affected  |                                       | Recommended  |
| 12.4-Based |          First Fixed Release          |   Release    |
|  Releases  |                                       |              |
|------------+---------------------------------------+--------------|
| 12.4       | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4GC     | 12.4(24)GC1                           |              |
|------------+---------------------------------------+--------------|
| 12.4JA     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDC    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JDD    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JL     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JMA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JMB    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4JX     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4MD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4MDA    | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4MR     | 12.4(19)MR3                           | 12.4(19)MR3  |
|------------+---------------------------------------+--------------|
| 12.4SW     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            | 12.4(24)T1                            |              |
|            |                                       | 12.4(20)T4   |
|            | 12.4(15)T10                           |              |
| 12.4T      |                                       | 12.4(22)T3   |
|            | 12.4(20)T3                            |              |
|            |                                       | 12.4(24)T2;  |
|            | 12.4(22)T2                            | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XA     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XB     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XC     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XD     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XE     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4XF     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XG     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XJ     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4XK     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XL     | 12.4(15)XL5                           |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            | Vulnerable; first fixed in 12.4T      | 12.4(20)T4   |
|            |                                       |              |
| 12.4XM     | Releases up to and including 12.4(15) | 12.4(22)T3   |
|            | XM are not vulnerable.                |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4XN     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.4XP     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
| 12.4XQ     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4XR     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XT     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            | Vulnerable; Contact your support      |              |
| 12.4XV     | organization per the instructions in  |              |
|            | Obtaining Fixed Software section of   |              |
|            | this advisory                         |              |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XW     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XY     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4XZ     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
|            |                                       | 12.4(15)T10  |
|            |                                       |              |
|            |                                       | 12.4(20)T4   |
|            |                                       |              |
| 12.4YA     | Vulnerable; first fixed in 12.4T      | 12.4(22)T3   |
|            |                                       |              |
|            |                                       | 12.4(24)T2;  |
|            |                                       | Available on |
|            |                                       | 23-OCT-2009  |
|------------+---------------------------------------+--------------|
| 12.4YB     | 12.4(22)YB1                           | 12.4(22)YB4  |
|------------+---------------------------------------+--------------|
| 12.4YD     | Not Vulnerable                        |              |
|------------+---------------------------------------+--------------|
| 12.4YE     | Not Vulnerable                        |              |
+-------------------------------------------------------------------+

Note: No Cisco IOS-XE or Cisco IOS Software Modularity releases are
affected by this vulnerability.

Workarounds
===========

If the affected Cisco IOS device requires SIP for VoIP services, SIP
cannot be disabled, and therefore, no workarounds are available.
Users are advised to apply mitigation techniques to help limit
exposure to the vulnerability. Mitigation consists of allowing only
legitimate devices to connect to the routers. To increase
effectiveness, the mitigation must be coupled with anti-spoofing
measures on the network edge. This action is required because SIP can
use UDP as the transport protocol.

Additional mitigations that can be deployed on Cisco devices within
the network are available in the companion document "Cisco Applied
Mitigation Bulletin: Identifying and Mitigating Exploitation of the
Denial of Service Vulnerabilities in Cisco Unified Communications
Manager and Cisco IOS Software", which is available at the following
location:

http://www.cisco.com/warp/public/707/cisco-amb-20090923-voice.shtml

Disable SIP Listening Ports
+--------------------------

For devices that do not require SIP to be enabled, the simplest and
most effective workaround is to disable SIP processing on the device.
Some versions of Cisco IOS Software allow administrators to
accomplish this with the following commands:

    sip-ua
     no transport udp
     no transport tcp
     no transport tcp tls

Warning: When applying this workaround to devices that are
processing Media Gateway Control Protocol (MGCP) or H.323 calls, the
device will not stop SIP processing while active calls are being
processed. Under these circumstances, this workaround should be
implemented during a maintenance window when active calls can be
briefly stopped.

The "show udp connections", "show tcp brief all", and "show processes |
include SIP" commands can be used to confirm that the SIP UDP and TCP
ports are closed after applying this workaround.

Depending on the Cisco IOS Software version in use, the output of
"show ip sockets" still showed UDP port 5060 open, but sending
something to that port caused the SIP process to emit the following
message:

    *Feb  2 11:36:47.691: sip_udp_sock_process_read: SIP UDP Listener is
    DISABLED 

Control Plane Policing
+---------------------

For devices that need to offer SIP services it is possible to use
Control Plane Policing (CoPP) to block SIP traffic to the device from
untrusted sources. Cisco IOS Releases 12.0S, 12.2SX, 12.2S, 12.3T,
12.4, and 12.4T support the CoPP feature. CoPP may be configured on a
device to protect the management and control planes to minimize the
risk and effectiveness of direct infrastructure attacks by explicitly
permitting only authorized traffic sent to infrastructure devices in
accordance with existing security policies and configurations. The
following example can be adapted to the network

    
    !-- The 192.168.1.0/24 network and the 172.16.1.1 host are trusted.
    !-- Everything else is not trusted. The following access list is used
    !-- to determine what traffic needs to be dropped by a control plane
    !-- policy (the CoPP feature.) If the access list matches (permit)
    !-- then traffic will be dropped and if the access list does not
    !-- match (deny) then traffic will be processed by the router.
    
    
    access-list 100 deny udp 192.168.1.0 0.0.0.255 any eq 5060
    access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 5060
    access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 5061
    access-list 100 deny udp host 172.16.1.1 any eq 5060
    access-list 100 deny tcp host 172.16.1.1 any eq 5060
    access-list 100 deny tcp host 172.16.1.1 any eq 5061
    access-list 100 permit udp any any eq 5060
    access-list 100 permit tcp any any eq 5060
    access-list 100 permit tcp any any eq 5061
    
    
    !-- Permit (Police or Drop)/Deny (Allow) all other Layer3 and Layer4
    !-- traffic in accordance with existing security policies and
    !-- configurations for traffic that is authorized to be sent
    !-- to infrastructure devices.
    !-- Create a Class-Map for traffic to be policed by
    !-- the CoPP feature.
    
    
    class-map match-all drop-sip-class
      match access-group 100
    
    
    !-- Create a Policy-Map that will be applied to the
    !-- Control-Plane of the device.
    
    
    policy-map drop-sip-traffic
     class drop-sip-class
      drop
    
    
    !-- Apply the Policy-Map to the Control-Plane of the
    !-- device.
    
    
    control-plane
     service-policy input drop-sip-traffic

Warning: Because SIP can use UDP as a transport protocol, it
is possible to easily spoof the IP address of the sender, which may
defeat access control lists that permit communication to these ports
from trusted IP addresses.

In the above CoPP example, the access control entries (ACEs) that
match the potential exploit packets with the "permit" action result
in these packets being discarded by the policy-map "drop" function,
while packets that match the "deny" action (not shown) are not
affected by the policy-map drop function. Additional information on
the configuration and use of the CoPP feature can be found at:

http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html

and

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. 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
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was discovered during internal testing.

Status of this Notice: FINAL
============================

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-20090923-sip.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 |                   | Initial |
| 1.0      | 2009-September-23 | 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
-----BEGIN PGP SIGNATURE-----

iD8DBQFKukGZ86n/Gc8U/uARAh54AJ4jQJCLVMauxJXj00WMu822+kH1TQCfTzA6
2++Xtx6BvyycWfoy75Zjtx0=
=nUyE
-----END PGP SIGNATURE-----



From psirt at cisco.com  Wed Sep 23 11:15:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 23 Sep 2009 12:15:00 -0400
Subject: Cisco Security Advisory: Cisco IOS Software Crafted Encryption Packet
	Denial of Service Vulnerability
Message-ID: <200909231215.tls@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS Software Crafted Encryption Packet
Denial of Service Vulnerability

Advisory ID: cisco-sa-20090923-tls

Revision 1.0

For Public Release 2009 September 23

+---------------------------------------------------------------------

Summary
=======

Cisco IOS? Software contains a vulnerability that could allow an
attacker to cause a Cisco IOS device to reload by remotely sending a
crafted encryption packet.

Cisco has released free software updates that address this
vulnerability.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20090923-tls.shtml

Note: The September 23, 2009, Cisco IOS Security Advisory bundled
publication includes eleven Security Advisories. Ten of the
advisories address vulnerabilities in Cisco IOS Software, and one
advisory addresses a vulnerability in Cisco Unified Communications
Manager. Each advisory lists the releases that correct the
vulnerability or vulnerabilities detailed in the advisory. The
following table lists releases that correct all Cisco IOS Software
vulnerabilities that have been published on September 23, 2009, or
earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090923-bundle.shtml

Individual publication links are in "Cisco Event Response: Semiannual
Cisco IOS Software Advisory Bundled Publication" at the following
link:

http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep09.html

Affected Products
=================

Vulnerable Products
+------------------

Devices running affected versions of Cisco IOS Software are
susceptible if configured with any of the following features:

  * Secure Socket Layer (SSL) Virtual Private Network (VPN)
  * Secure Shell (SSH)
  * Internet Key Exchange (IKE) Encrypted Nonces

Note: Other SSL/HTTPS related features than WebVPN and SSL VPN are
not affected by this vulnerability.

To determine whether SSLVPN is enabled on a device, log in to the
device and issue the command-line interface (CLI) command "show
running-config | include webvpn". If the device returns any output
then SSLVPN is configured and the device may be vulnerable.
Vulnerable configurations vary depending on whether the device is
supporting Cisco IOS WebVPN (introduced in Release 12.3(14)T) or
Cisco IOS SSLVPNs (introduced in Release 12.4(6)T). The following
methods describe how to confirm if the device is vulnerable:

If the output from "show running-config | include webvpn" contains
"webvpn enable" then the device is configured with the original Cisco
IOS WebVPN. The only way to determine whether the device is
vulnerable is to examine the output of "show running-config" to
confirm that webvpn is enabled via the command "webvpn enable" and
that a "ssl trustpoint" has been configured. The following example
shows a vulnerable device configured with Cisco IOS WebVPN:

    webvpn enable
    !
    webvpn
     ssl trustpoint TP-self-signed-29742012

If the output from "show running-config | include webvpn" contains
"webvpn gateway " then the device is supporting the Cisco IOS
SSLVPN feature. A device is vulnerable if it has the "inservice"
command in at least one of the "webvpn gateway" sections. The
following example shows a vulnerable device configured with Cisco IOS
SSLVPN:

    Router# show running | section webvpn        
    webvpn gateway Gateway
     ip address 10.1.1.1 port 443  
     ssl trustpoint Gateway-TP
     inservice
     !
    Router#

A device that supports the Cisco IOS SSLVPN is not vulnerable if it
has no "webvpn gateways" configured or all the configured "webvpn
gateways" contain the "no inservice" webvpn gateway command.

To determine if SSH is enabled use the "show ip ssh" command, as shown
in the following example:

    Router#show ip ssh 
    SSH Enabled - version 1.99
    Authentication timeout: 120 secs; Authentication retries: 3
    Minimum expected Diffie Hellman key size : 1024 bits

To determine if the IKE encrypted nonces feature is enabled, use the 
"show running-config | include rsa-encr" command as follows:

    Router#show running-config | inc rsa-encr
     authentication rsa-encr

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the
show version command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name displays in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the show version command or may provide
different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.3(26) with an installed image name of
C2500-IS-L:

    Router#show version
    Cisco Internetwork Operating System Software
    IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by cisco Systems, Inc.
    Compiled Mon 17-Mar-08 14:39 by dchih
    
    
    !--- output truncated
    

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.4(20)T with an installed image name of
C1841-ADVENTERPRISEK9-M:

    Router#show version
    Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by Cisco Systems, Inc.
    Compiled Thu 10-Jul-08 20:25 by prod_rel_team
    
    
    !--- output truncated
    

Additional information about Cisco IOS Software release naming
conventions is available in "White Paper: Cisco IOS Reference Guide"
at the following link:

http://www.cisco.com/warp/public/620/1.html

Products Confirmed Not Vulnerable
+--------------------------------

The Cisco ASA 5500 Series Adaptive Security Appliances are not
affected by this vulnerability.

Cisco IOS XR Software is not affected by this vulnerability.

No other Cisco products are currently known to be affected by this
vulnerability.

Details
=======

A Cisco IOS device that is configured for SSLVPN or SSH may reload
when it receives a specially crafted TCP packet on TCP port 443
(SSLVPN) or TCP port 22 (SSH). Completion of the three-way handshake
to the associated TCP port number of these features is required for
the vulnerability to be successfully exploited; however,
authentication is not required. A Cisco IOS device that is configured
for IKE encrypted nonces may reload when it receives a specially
crafted UDP packet on port 500 or 4500 (if configured for NAT
Traversal (NAT-T)).

This vulnerability is documented in Cisco bug ID CSCsq24002 and has
been assigned the Common Vulnerabilities and Exposures (CVE) identifier
CVE-2009-2871.

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

CSCsq24002 - Crafted Encrypted packet may cause device reload

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

Impact
======

Successful exploitation of the vulnerability described in this
document may result in a reload of the device. The issue could be
repeatedly exploited to cause an extended DoS condition.

Software Versions and Fixes
===========================

When considering software upgrades, also consult:

http://www.cisco.com/go/psirt

and any subsequent advisories to determine exposure and a complete
upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|   Major    |          Availability of Repaired Releases           |
|  Release   |                                                      |
|------------+------------------------------------------------------|
|  Affected  |                                        | Recommended |
| 12.0-Based |          First Fixed Release           |   Release   |
|  Releases  |                                        |             |
|-------------------------------------------------------------------|
| There are no affected 12.0 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                        | Recommended |
| 12.1-Based |          First Fixed Release           |   Release   |
|  Releases  |                                        |             |
|-------------------------------------------------------------------|
| There are no affected 12.1 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                        | Recommended |
| 12.2-Based |          First Fixed Release           |   Release   |
|  Releases  |                                        |             |
|------------+----------------------------------------+-------------|
| 12.2       | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2B      | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2BC     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2BW     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2BX     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2BY     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2BZ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2CX     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2CY     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2CZ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2DA     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2DD     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2DX     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2EW     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2EWA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2EX     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2EY     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2EZ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2FX     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2FY     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2FZ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2IRA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2IRB    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2IRC    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2IXA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2IXB    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2IXC    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2IXD    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2IXE    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2IXF    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2IXG    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2IXH    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2JA     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2JK     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2MB     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2MC     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2S      | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SB     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SBC    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SCA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SCB    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SE     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SEA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SEB    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SEC    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SED    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SEE    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SEF    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SEG    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SG     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SGA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SL     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SM     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SO     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SQ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SRA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SRB    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SRC    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SRD    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2STE    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SU     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SV     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SVA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SVC    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SVD    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SVE    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SW     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SX     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SXA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SXB    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SXD    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SXE    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SXF    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SXH    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SXI    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SY     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2SZ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2T      | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2TPC    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XA     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XB     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XC     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XD     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XE     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XF     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XG     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XH     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XI     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XJ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XK     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XL     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XM     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XNA    | Please see Cisco IOS-XE Software       |             |
|            | Availability                           |             |
|------------+----------------------------------------+-------------|
| 12.2XNB    | Please see Cisco IOS-XE Software       |             |
|            | Availability                           |             |
|------------+----------------------------------------+-------------|
| 12.2XNC    | Please see Cisco IOS-XE Software       |             |
|            | Availability                           |             |
|------------+----------------------------------------+-------------|
| 12.2XND    | Please see Cisco IOS-XE Software       |             |
|            | Availability                           |             |
|------------+----------------------------------------+-------------|
| 12.2XO     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XQ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XR     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XS     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XT     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XU     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XV     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2XW     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YA     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YB     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YC     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YD     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YE     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YF     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YG     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YH     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YJ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YK     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YL     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YM     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YN     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YO     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YP     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YQ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YR     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YS     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YT     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YU     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YV     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YW     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YX     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YY     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2YZ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZA     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZB     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZC     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZD     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZE     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZF     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZG     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZH     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZJ     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZL     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZP     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZU     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZX     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZY     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.2ZYA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
|  Affected  |                                        | Recommended |
| 12.3-Based |          First Fixed Release           |   Release   |
|  Releases  |                                        |             |
|-------------------------------------------------------------------|
| There are no affected 12.3 based releases.                        |
|-------------------------------------------------------------------|
|  Affected  |                                        | Recommended |
| 12.4-Based |          First Fixed Release           |   Release   |
|  Releases  |                                        |             |
|------------+----------------------------------------+-------------|
| 12.4       | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4GC     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4JA     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4JDA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4JDC    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4JDD    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4JK     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4JL     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4JMA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4JMB    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4JX     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4MD     | 12.4(15)MD3                            | 12.4(15)MD3 |
|------------+----------------------------------------+-------------|
| 12.4MDA    | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4MR     | 12.4(19)MR3                            | 12.4(19)MR3 |
|------------+----------------------------------------+-------------|
|            |                                        | 12.4(15)T10 |
| 12.4SW     | Vulnerable; first fixed in 12.4T       |             |
|            |                                        | 12.4(20)T4  |
|------------+----------------------------------------+-------------|
|            | 12.4(22)T2                             |             |
|            |                                        | 12.4(15)T10 |
| 12.4T      | 12.4(20)T3                             |             |
|            |                                        | 12.4(20)T4  |
|            | 12.4(24)T                              |             |
|------------+----------------------------------------+-------------|
| 12.4XA     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4XB     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4XC     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4XD     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4XE     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
|            |                                        | 12.4(15)T10 |
| 12.4XF     | Vulnerable; first fixed in 12.4T       |             |
|            |                                        | 12.4(20)T4  |
|------------+----------------------------------------+-------------|
| 12.4XG     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
|            |                                        | 12.4(15)T10 |
| 12.4XJ     | Vulnerable; first fixed in 12.4T       |             |
|            |                                        | 12.4(20)T4  |
|------------+----------------------------------------+-------------|
|            |                                        | 12.4(15)T10 |
| 12.4XK     | Vulnerable; first fixed in 12.4T       |             |
|            |                                        | 12.4(20)T4  |
|------------+----------------------------------------+-------------|
| 12.4XL     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4XM     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4XN     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4XP     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4XQ     | 12.4(15)XQ3                            | 12.4(15)T10 |
|------------+----------------------------------------+-------------|
|            |                                        | 12.4(15)XR7 |
| 12.4XR     | 12.4(15)XR5                            |             |
|            |                                        | 12.4(22)XR  |
|------------+----------------------------------------+-------------|
| 12.4XT     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
|            | Vulnerable; Contact your support       |             |
| 12.4XV     | organization per the instructions in   |             |
|            | Obtaining Fixed Software section of    |             |
|            | this advisory                          |             |
|------------+----------------------------------------+-------------|
|            |                                        | 12.4(15)T10 |
| 12.4XW     | Vulnerable; first fixed in 12.4T       |             |
|            |                                        | 12.4(20)T4  |
|------------+----------------------------------------+-------------|
|            |                                        | 12.4(15)T10 |
| 12.4XY     | Vulnerable; first fixed in 12.4T       |             |
|            |                                        | 12.4(20)T4  |
|------------+----------------------------------------+-------------|
|            |                                        | 12.4(15)T10 |
| 12.4XZ     | Vulnerable; first fixed in 12.4T       |             |
|            |                                        | 12.4(20)T4  |
|------------+----------------------------------------+-------------|
|            |                                        | 12.4(15)T10 |
| 12.4YA     | Vulnerable; first fixed in 12.4T       |             |
|            |                                        | 12.4(20)T4  |
|------------+----------------------------------------+-------------|
| 12.4YB     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4YD     | Not Vulnerable                         |             |
|------------+----------------------------------------+-------------|
| 12.4YE     | Not Vulnerable                         |             |
+-------------------------------------------------------------------+

Note: No Cisco IOS Software Modularity releases are affected by this
vulnerability.

Cisco IOS XE Software

+-------------------------------------------------------------------+
|       IOS XE Release       |         First Fixed Release          |
|----------------------------+--------------------------------------|
| 2.1.x                      | Not Vulnerable                       |
|----------------------------+--------------------------------------|
| 2.2.x                      | Not Vulnerable                       |
|----------------------------+--------------------------------------|
| 2.3.x                      | 2.3.2                                |
|----------------------------+--------------------------------------|
| 2.4.x                      | Not Vulnerable                       |
+-------------------------------------------------------------------+

Workarounds
===========

There are no available workarounds other than disabling the affected
features and protecting SSH access with the use of VTY access control
lists.

Use the "no webvpn enable" command to disable SSL VPN use.

For Cisco IOS the SSH server can be disabled by applying the command 
"crypto key zeroize rsa" while in configuration mode. The SSH server is
enabled automatically upon generating an RSA key pair. Zeroing the
RSA keys is the only way to completely disable the SSH server.

Access to the SSH server on Cisco IOS Software may also be disabled
by removing SSH as a valid transport protocol. This action can be
done by reapplying the transport input command with 'ssh' removed
from the list of permitted transports on vty lines while in
configuration mode. For example:

    line vty 0 4                                                                    
          transport input telnet                                                        
        end

If SSH server functionality is desired, access to the server can be
restricted to specific source IP addresses or blocked entirely
through the use of Access Control Lists (ACLs) on the vty lines as
shown in the following URL:

http://www.cisco.com/en/US/docs/switches/lan/catalyst2950/software/release/12.1_9_ea1/configuration/guide/swacl.html#xtocid14

More information on configuring ACLs can be found on Cisco's public
website:

http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a00800a5b9a.shtml

The following is an example of a vty access-list:

    access-list 2 permit 10.1.1.0 0.0.0.255
    access-list 2 deny any
    
    line vty 0 4
     access-class 2 in

In the previous example, only the 10.1.1.0/24 network is allowed to
SSH to the Cisco IOS device.

To disable IKE encrypted nonces use the "no authentication rsa-encr"
command under an ISAKMP policy, as shown in the following example:

    crypto isakmp policy
     no authentication rsa-encr

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. 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
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was found during internal testing.

Status of this Notice: FINAL
============================

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-20090923-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 |                   | Initial |
| 1.0      | 2009-September-23 | 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
-----BEGIN PGP SIGNATURE-----

iD8DBQFKukGd86n/Gc8U/uARAltxAJsHsWKROOB5Ph8mcFs+ZUIYygRoEgCePeZX
A9ezksakGzQynAYZbBjJ+uE=
=n8Uh
-----END PGP SIGNATURE-----



From tme at americafree.tv  Wed Sep 23 11:22:31 2009
From: tme at americafree.tv (Marshall Eubanks)
Date: Wed, 23 Sep 2009 12:22:31 -0400
Subject: BT US to UK
In-Reply-To: <3BBF8BBA-257F-41C6-8D43-9ADEFE116106@americafree.tv>
References: <3BBF8BBA-257F-41C6-8D43-9ADEFE116106@americafree.tv>
Message-ID: <347D4CFB-004C-44F0-A42B-5826AFA32D93@americafree.tv>

Ah, I have heard that whatever the problem was, it has been cleared  
up. Sorry for the noise.

Regards
Marshall

On Sep 23, 2009, at 12:14 PM, Marshall Eubanks wrote:

> Is anyone else seeing issues with British Telecom from UK to the US ?
>
> I have heard rumors that undersea fiber links might be involved.
>
> Regards
> Marshall
>
>




From marian at stasney.org  Wed Sep 23 16:39:50 2009
From: marian at stasney.org (Marian Stasney)
Date: Wed, 23 Sep 2009 14:39:50 -0700 (PDT)
Subject: American Fiber Systems
Message-ID: <145643.74673.qm@web504.biz.mail.mud.yahoo.com>

If any HTTP or last mile providers have worked with this provider, please contact me off-list at the addresses below.

Your quick response is greatly appreciated.
mks

Marian Stasney   ?  Desk: 512-853-9598   Cell: 512-845-1546   marian at stasney.org

From aaron at wholesaleinternet.net  Wed Sep 23 17:04:19 2009
From: aaron at wholesaleinternet.net (Aaron Wendel)
Date: Wed, 23 Sep 2009 17:04:19 -0500
Subject: American Fiber Systems
In-Reply-To: <145643.74673.qm@web504.biz.mail.mud.yahoo.com>
References: <145643.74673.qm@web504.biz.mail.mud.yahoo.com>
Message-ID: <027701ca3c99$d0680020$71380060$@net>

I have experiences with AFS going back 5 years.  None of them good.  Where
would you like me to start?

Aaron

-----Original Message-----
From: Marian Stasney [mailto:marian at stasney.org] 
Sent: Wednesday, September 23, 2009 4:40 PM
To: nanog at nanog.org
Subject: American Fiber Systems

If any HTTP or last mile providers have worked with this provider, please
contact me off-list at the addresses below.

Your quick response is greatly appreciated.
mks

Marian Stasney   ?  Desk: 512-853-9598   Cell: 512-845-1546
marian at stasney.org




From rens at autempspourmoi.be  Thu Sep 24 01:38:14 2009
From: rens at autempspourmoi.be (Rens)
Date: Thu, 24 Sep 2009 08:38:14 +0200
Subject: hotmail.com admin
Message-ID: 

Somebody here that is administrator of mails servers of hotmail.com?

Or if anyone knows how to contact them?

 

Please contact my offline



From rens at autempspourmoi.be  Thu Sep 24 01:49:03 2009
From: rens at autempspourmoi.be (Rens)
Date: Thu, 24 Sep 2009 08:49:03 +0200
Subject: hotmail admin
Message-ID: 

Somebody here that is administrator of mails servers of hotmail?

Or if anyone knows how to contact them?
 

Please contact my offline




From bbillon-ml at splio.fr  Thu Sep 24 02:05:28 2009
From: bbillon-ml at splio.fr (Benjamin Billon)
Date: Thu, 24 Sep 2009 09:05:28 +0200
Subject: hotmail admin
In-Reply-To: 
References: 
Message-ID: <4ABB1A38.30800@splio.fr>

Unfortunately, that doesn't work that way with hotmail.

https://postmaster.live.com/
and
https://support.msn.com/eform.aspx?productKey=edfsmsbl&ct=eformts

are the ways to go.

Rens a ?crit :
> Somebody here that is administrator of mails servers of hotmail?
>
> Or if anyone knows how to contact them?
>  
>
> Please contact my offline
>
>
>   



From chris at uplogon.com  Thu Sep 24 10:08:07 2009
From: chris at uplogon.com (Chris Gotstein)
Date: Thu, 24 Sep 2009 10:08:07 -0500
Subject: Gmail Down?
Message-ID: <4ABB8B57.3020600@uplogon.com>

Anyone else seeing Google's Gmail down right now?  Seems to have been
down since 10am CST.  We are connected through Chicago.
downforeveryoneorjustme.com is also reporting it's down.

-- 
---- ---- ---- ----
Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP
http://uplogon.com | +1 906 774 4847 | chris at uplogon.com



From dhetzel at gmail.com  Thu Sep 24 10:10:20 2009
From: dhetzel at gmail.com (Dorn Hetzel)
Date: Thu, 24 Sep 2009 11:10:20 -0400
Subject: Gmail Down?
In-Reply-To: <4ABB8B57.3020600@uplogon.com>
References: <4ABB8B57.3020600@uplogon.com>
Message-ID: <7db2dcf90909240810r1e4cd2f6o1898045473de49c0@mail.gmail.com>

My google hosted domain mail is up but access to my contact list is down.

On Thu, Sep 24, 2009 at 11:08 AM, Chris Gotstein  wrote:

> Anyone else seeing Google's Gmail down right now?  Seems to have been
> down since 10am CST.  We are connected through Chicago.
> downforeveryoneorjustme.com is also reporting it's down.
>
> --
> ---- ---- ---- ----
> Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP
> http://uplogon.com | +1 906 774 4847 | chris at uplogon.com
>
>


From yoann at ext.mdpns.org  Thu Sep 24 10:11:27 2009
From: yoann at ext.mdpns.org (YLB)
Date: Thu, 24 Sep 2009 17:11:27 +0200
Subject: Gmail Down?
In-Reply-To: <4ABB8B57.3020600@uplogon.com>
References: <4ABB8B57.3020600@uplogon.com>
Message-ID: 

Yes, the same here (Paris, France)!

YLB.
yoann at yoann.info


2009/9/24 Chris Gotstein :
> Anyone else seeing Google's Gmail down right now? ?Seems to have been
> down since 10am CST. ?We are connected through Chicago.
> downforeveryoneorjustme.com is also reporting it's down.
>
> --
> ---- ---- ---- ----
> Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP
> http://uplogon.com | +1 906 774 4847 | chris at uplogon.com
>
>



From chris at uplogon.com  Thu Sep 24 10:11:56 2009
From: chris at uplogon.com (Chris Gotstein)
Date: Thu, 24 Sep 2009 10:11:56 -0500
Subject: Gmail Down?
In-Reply-To: <4ABB8B57.3020600@uplogon.com>
References: <4ABB8B57.3020600@uplogon.com>
Message-ID: <4ABB8C3C.2090306@uplogon.com>

It was short-lived, seems to be back up now, but a little flaky.

---- ---- ---- ----
Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP
http://uplogon.com | +1 906 774 4847 | chris at uplogon.com

Chris Gotstein wrote:
> Anyone else seeing Google's Gmail down right now?  Seems to have been
> down since 10am CST.  We are connected through Chicago.
> downforeveryoneorjustme.com is also reporting it's down.
> 



From shrdlu at deaddrop.org  Thu Sep 24 10:14:13 2009
From: shrdlu at deaddrop.org (Etaoin Shrdlu)
Date: Thu, 24 Sep 2009 08:14:13 -0700
Subject: Gmail Down?
In-Reply-To: <4ABB8B57.3020600@uplogon.com>
References: <4ABB8B57.3020600@uplogon.com>
Message-ID: <4ABB8CC5.5080204@deaddrop.org>

Chris Gotstein wrote:
> Anyone else seeing Google's Gmail down right now?  Seems to have been
> down since 10am CST.  We are connected through Chicago.
> downforeveryoneorjustme.com is also reporting it's down.

They're having an issue or two. Notably, the inability to display or 
access Contacts, and certain other things (such as the ability to change 
to the "older version", which only gives errors). Crazy world, when a 
public mail provider can have such an effect on folks. So it goes.

-- 
You've confused equality of opportunity for equality of outcomes,
and have seriously confused justice with equality.
                                 -- Woodchuck




From Stefan.Fouant at neustar.biz  Thu Sep 24 10:16:07 2009
From: Stefan.Fouant at neustar.biz (Fouant, Stefan)
Date: Thu, 24 Sep 2009 11:16:07 -0400
Subject: Gmail Down?
Message-ID: <01B071CE08A7514CB72950074134151AE288F7@STNTEXCH12.cis.neustar.com>

Donw here in Northern Virgina.  GMAIL for Mobile is not working as well.

Stefan Fouant 
Neustar, Inc. / Principal Engineer
46000 Center Oak Plaza Sterling, VA 20166
Office: +1.571.434.5656 ? Mobile: +1.202.210.2075 ? GPG ID: 0xB5E3803D ? stefan.fouant at neustar.biz

----- Original Message -----
From: YLB 
To: Chris Gotstein 
Cc: nanog at nanog.org 
Sent: Thu Sep 24 11:11:27 2009
Subject: Re: Gmail Down?

Yes, the same here (Paris, France)!

YLB.
yoann at yoann.info


2009/9/24 Chris Gotstein :
> Anyone else seeing Google's Gmail down right now? ?Seems to have been
> down since 10am CST. ?We are connected through Chicago.
> downforeveryoneorjustme.com is also reporting it's down.
>
> --
> ---- ---- ---- ----
> Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP
> http://uplogon.com | +1 906 774 4847 | chris at uplogon.com
>
>


From spanogi at gmail.com  Thu Sep 24 10:16:13 2009
From: spanogi at gmail.com (=?ISO-8859-1?Q?Giuseppe_Span=F2?=)
Date: Thu, 24 Sep 2009 17:16:13 +0200
Subject: Gmail Down?
In-Reply-To: 
References: <4ABB8B57.3020600@uplogon.com>
	
Message-ID: <53dd0b380909240816m3f6672fcta1adbc6bae0c465f@mail.gmail.com>

The same in Italy (only contact list is down)!

Giuseppe

On Thu, Sep 24, 2009 at 5:11 PM, YLB  wrote:

> Yes, the same here (Paris, France)!
>
> YLB.
> yoann at yoann.info
>
>
> 2009/9/24 Chris Gotstein :
> > Anyone else seeing Google's Gmail down right now?  Seems to have been
> > down since 10am CST.  We are connected through Chicago.
> > downforeveryoneorjustme.com is also reporting it's down.
> >
> > --
> > ---- ---- ---- ----
> > Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP
> > http://uplogon.com | +1 906 774 4847 | chris at uplogon.com
> >
> >
>
>


From zaid at zaidali.com  Thu Sep 24 10:15:47 2009
From: zaid at zaidali.com (Zaid Ali)
Date: Thu, 24 Sep 2009 08:15:47 -0700
Subject: Gmail Down?
In-Reply-To: <4ABB8B57.3020600@uplogon.com>
References: <4ABB8B57.3020600@uplogon.com>
Message-ID: <2364DE34-CBDC-4BAE-9D54-9CEAEDF3CBEA@zaidali.com>

Seems like the contact portion only.

Gmail is temporarily unable to access your Contacts. You may  
experience issues while this persists.

Zaid

On Sep 24, 2009, at 8:08 AM, Chris Gotstein wrote:

> Anyone else seeing Google's Gmail down right now?  Seems to have been
> down since 10am CST.  We are connected through Chicago.
> downforeveryoneorjustme.com is also reporting it's down.
>
> -- 
> ---- ---- ---- ----
> Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP
> http://uplogon.com | +1 906 774 4847 | chris at uplogon.com
>




From matt.taber.nanog at gmail.com  Thu Sep 24 10:17:30 2009
From: matt.taber.nanog at gmail.com (Matt Taber)
Date: Thu, 24 Sep 2009 11:17:30 -0400
Subject: Gmail Down?
In-Reply-To: <4ABB8B57.3020600@uplogon.com>
References: <4ABB8B57.3020600@uplogon.com>
Message-ID: 

http://www.google.com/appsstatus#hl=en

Oddly, my nanog mails to gmail.com are fine...

-----Original Message-----
From: Chris Gotstein [mailto:chris at uplogon.com] 
Sent: Thursday, September 24, 2009 11:08 AM
To: nanog at nanog.org
Subject: Gmail Down?

Anyone else seeing Google's Gmail down right now?  Seems to have been
down since 10am CST.  We are connected through Chicago.
downforeveryoneorjustme.com is also reporting it's down.

-- 
---- ---- ---- ----
Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP
http://uplogon.com | +1 906 774 4847 | chris at uplogon.com





From lan.man.wan at gmail.com  Thu Sep 24 10:17:34 2009
From: lan.man.wan at gmail.com (Masa)
Date: Fri, 25 Sep 2009 00:17:34 +0900
Subject: Gmail Down?
In-Reply-To: <4ABB8C3C.2090306@uplogon.com>
References: <4ABB8B57.3020600@uplogon.com> <4ABB8C3C.2090306@uplogon.com>
Message-ID: <45b4152c0909240817y5c2ed9acs8b0ef3b31aabdfdc@mail.gmail.com>

Really? I can see / send this mail from gmail. :-)

@Yokohama, Japan.


2009/9/25 Chris Gotstein :
> It was short-lived, seems to be back up now, but a little flaky.
>
> ---- ---- ---- ----
> Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP
> http://uplogon.com | +1 906 774 4847 | chris at uplogon.com
>
> Chris Gotstein wrote:
>> Anyone else seeing Google's Gmail down right now? ?Seems to have been
>> down since 10am CST. ?We are connected through Chicago.
>> downforeveryoneorjustme.com is also reporting it's down.
>>
>
>



-- 
----------
Masa 
mixi http://mixi.jp/show_friend.pl?id=797271 / Skype r-u-s-h
Messenger ieee802_3af at hotmail.com / Yahoo! m_a_s_aa



From jhodges at simplexity.com  Thu Sep 24 10:19:01 2009
From: jhodges at simplexity.com (John Hodges)
Date: Thu, 24 Sep 2009 11:19:01 -0400
Subject: Gmail Down?
In-Reply-To: <4ABB8C3C.2090306@uplogon.com>
References: <4ABB8B57.3020600@uplogon.com> <4ABB8C3C.2090306@uplogon.com>
Message-ID: 

http://www.google.com/appsstatus#rm=1&di=1&hl=en



-----Original Message-----
From: Chris Gotstein [mailto:chris at uplogon.com] 
Sent: Thursday, September 24, 2009 11:12 AM
To: nanog at nanog.org
Subject: Re: Gmail Down?

It was short-lived, seems to be back up now, but a little flaky.

---- ---- ---- ----
Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP
http://uplogon.com | +1 906 774 4847 | chris at uplogon.com

Chris Gotstein wrote:
> Anyone else seeing Google's Gmail down right now?  Seems to have been
> down since 10am CST.  We are connected through Chicago.
> downforeveryoneorjustme.com is also reporting it's down.
> 




From tme at americafree.tv  Thu Sep 24 10:19:44 2009
From: tme at americafree.tv (Marshall Eubanks)
Date: Thu, 24 Sep 2009 11:19:44 -0400
Subject: Gmail Down?
In-Reply-To: <4ABB8B57.3020600@uplogon.com>
References: <4ABB8B57.3020600@uplogon.com>
Message-ID: <6527DD60-EF8C-423B-B829-EF9AB6D0B7D7@americafree.tv>

It is up for me at 11:19 AM EST - Cox Cable / Virginia.

On Sep 24, 2009, at 11:08 AM, Chris Gotstein wrote:

> Anyone else seeing Google's Gmail down right now?  Seems to have been
> down since 10am CST.  We are connected through Chicago.
> downforeveryoneorjustme.com is also reporting it's down.
>
> -- 
> ---- ---- ---- ----
> Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP
> http://uplogon.com | +1 906 774 4847 | chris at uplogon.com
>
>




From michael.holstein at csuohio.edu  Thu Sep 24 10:20:06 2009
From: michael.holstein at csuohio.edu (Michael Holstein)
Date: Thu, 24 Sep 2009 11:20:06 -0400
Subject: Gmail Down?
In-Reply-To: <4ABB8B57.3020600@uplogon.com>
References: <4ABB8B57.3020600@uplogon.com>
Message-ID: <4ABB8E26.2060001@csuohio.edu>


> Anyone else seeing Google's Gmail down right now?  

I dunno boss, just ask "the cloud" .. you're the one that wanted to 
compute there instead of here.

/dilbert :)

Anyway .. it's just contacts that's broken atm. See here : 
http://mail.google.com/support/bin/answer.py?hl=en&ctx=mail&answer=106432

Cheers,

Michael Holstein
Cleveland State University




From asusag at indianafiber.net  Thu Sep 24 10:16:30 2009
From: asusag at indianafiber.net (Andy Susag)
Date: Thu, 24 Sep 2009 11:16:30 -0400
Subject: Gmail Down?
In-Reply-To: <4ABB8CC5.5080204@deaddrop.org>
Message-ID: <34616BF851BA724F89193B3F1F27BFD73F66F2@sauron.IndianaFiberNetwork.local>

http://thenextweb.com/2009/09/24/breaking-gmail-problems-arise-downtime/

Here, gmail is accessible but contacts are not.

-----Original Message-----
From: Etaoin Shrdlu [mailto:shrdlu at deaddrop.org] 
Sent: Thursday, September 24, 2009 11:14 AM
To: nanog at nanog.org
Subject: Re: Gmail Down?

Chris Gotstein wrote:
> Anyone else seeing Google's Gmail down right now?  Seems to have been
> down since 10am CST.  We are connected through Chicago.
> downforeveryoneorjustme.com is also reporting it's down.

They're having an issue or two. Notably, the inability to display or 
access Contacts, and certain other things (such as the ability to change

to the "older version", which only gives errors). Crazy world, when a 
public mail provider can have such an effect on folks. So it goes.

-- 
You've confused equality of opportunity for equality of outcomes,
and have seriously confused justice with equality.
                                 -- Woodchuck





From dhetzel at gmail.com  Thu Sep 24 10:21:55 2009
From: dhetzel at gmail.com (Dorn Hetzel)
Date: Thu, 24 Sep 2009 11:21:55 -0400
Subject: Gmail Down?
In-Reply-To: <4ABB8CC5.5080204@deaddrop.org>
References: <4ABB8B57.3020600@uplogon.com> <4ABB8CC5.5080204@deaddrop.org>
Message-ID: <7db2dcf90909240821vbaac138qf13a345103b1d74c@mail.gmail.com>

I don't stress about it.  I backup my google hosted mail weekly.  If they're
only down for a couple hours now and then it's no biggie to me, just a
gentle hint from the universe that maybe it's time to deal with some offline
tasks :)

On Thu, Sep 24, 2009 at 11:14 AM, Etaoin Shrdlu  wrote:

> Chris Gotstein wrote:
>
>> Anyone else seeing Google's Gmail down right now?  Seems to have been
>> down since 10am CST.  We are connected through Chicago.
>> downforeveryoneorjustme.com is also reporting it's down.
>>
>
> They're having an issue or two. Notably, the inability to display or access
> Contacts, and certain other things (such as the ability to change to the
> "older version", which only gives errors). Crazy world, when a public mail
> provider can have such an effect on folks. So it goes.
>
> --
> You've confused equality of opportunity for equality of outcomes,
> and have seriously confused justice with equality.
>                                -- Woodchuck
>
>
>


From cabenth at gmail.com  Thu Sep 24 10:29:58 2009
From: cabenth at gmail.com (cabenth)
Date: Thu, 24 Sep 2009 08:29:58 -0700
Subject: Gmail Down?
In-Reply-To: <4ABB8B57.3020600@uplogon.com>
References: <4ABB8B57.3020600@uplogon.com>
Message-ID: <5b602b520909240829m38edb8c6i36c4c25061f792e1@mail.gmail.com>

Gmail is definitely been having a hard time this morning.

Stand by for the comments from the peanut gallery about allowing google to
scan your e-mail, etc.... like last time Gmail had an issue.


On Thu, Sep 24, 2009 at 8:08 AM, Chris Gotstein  wrote:

> Anyone else seeing Google's Gmail down right now?  Seems to have been
> down since 10am CST.  We are connected through Chicago.
> downforeveryoneorjustme.com is also reporting it's down.
>
> --
> ---- ---- ---- ----
> Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP
> http://uplogon.com | +1 906 774 4847 | chris at uplogon.com
>
>


From gustavo at nexthop.com.br  Thu Sep 24 10:28:49 2009
From: gustavo at nexthop.com.br (gustavo)
Date: Thu, 24 Sep 2009 12:28:49 -0300
Subject: Gmail Down?
In-Reply-To: <4ABB8B57.3020600@uplogon.com>
References: <4ABB8B57.3020600@uplogon.com>
Message-ID: <73d1f88a0909240828w6060cf2cx3019f87ca951a369@mail.gmail.com>

Try it out for outages updates: http://www.google.com/appsstatus#hl=en

Gustavo.


On Thu, Sep 24, 2009 at 12:08 PM, Chris Gotstein  wrote:
> Anyone else seeing Google's Gmail down right now? ?Seems to have been
> down since 10am CST. ?We are connected through Chicago.
> downforeveryoneorjustme.com is also reporting it's down.



From chk at pobox.com  Thu Sep 24 10:44:39 2009
From: chk at pobox.com (Harald Koch)
Date: Thu, 24 Sep 2009 11:44:39 -0400
Subject: Gmail Down?
In-Reply-To: <7db2dcf90909240821vbaac138qf13a345103b1d74c@mail.gmail.com>
References: <4ABB8B57.3020600@uplogon.com> <4ABB8CC5.5080204@deaddrop.org>
	<7db2dcf90909240821vbaac138qf13a345103b1d74c@mail.gmail.com>
Message-ID: <4ABB93E7.1020702@pobox.com>

It does appear that gmail going down leads to a DoS against the NANOG 
list. :-)

-- 
Harald




From chris at uplogon.com  Thu Sep 24 10:52:20 2009
From: chris at uplogon.com (Chris Gotstein)
Date: Thu, 24 Sep 2009 10:52:20 -0500
Subject: Gmail Down?
In-Reply-To: <4ABB93E7.1020702@pobox.com>
References: <4ABB8B57.3020600@uplogon.com>
	<4ABB8CC5.5080204@deaddrop.org>	<7db2dcf90909240821vbaac138qf13a345103b1d74c@mail.gmail.com>
	<4ABB93E7.1020702@pobox.com>
Message-ID: <4ABB95B4.5070602@uplogon.com>

We don't use gmail for any of our services, but a lot of our ISP
customers use gmail.  So when they see gmail being down, they assume
that their internet connection is down or that we are the reason that
gmail is not working.

---- ---- ---- ----
Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP
http://uplogon.com | +1 906 774 4847 | chris at uplogon.com

Harald Koch wrote:
> It does appear that gmail going down leads to a DoS against the NANOG
> list. :-)
> 



From jam at zoidtechnologies.com  Thu Sep 24 10:53:32 2009
From: jam at zoidtechnologies.com (Jeff MacDonald)
Date: Thu, 24 Sep 2009 11:53:32 -0400
Subject: Gmail Down?
In-Reply-To: <4ABB8E26.2060001@csuohio.edu>
References: <4ABB8B57.3020600@uplogon.com> <4ABB8E26.2060001@csuohio.edu>
Message-ID: <200909241153.32531.jam@zoidtechnologies.com>

On Thursday 24 September 2009 11:20:06 Michael Holstein wrote:
> > Anyone else seeing Google's Gmail down right now?
>

I am not able to use "google talk" at the moment. each time I try to send an 
IM, I get a "500" error.

> Cheers,
>
> Michael Holstein
> Cleveland State University

regards,
-- 
Jeff MacDonald
Zoid Technologies: Custom Information Systems
http://zoidtechnologies.com/



From mpetach at netflight.com  Thu Sep 24 11:00:13 2009
From: mpetach at netflight.com (Matthew Petach)
Date: Thu, 24 Sep 2009 09:00:13 -0700
Subject: Gmail Down?
In-Reply-To: <4ABB93E7.1020702@pobox.com>
References: <4ABB8B57.3020600@uplogon.com> <4ABB8CC5.5080204@deaddrop.org>
	<7db2dcf90909240821vbaac138qf13a345103b1d74c@mail.gmail.com>
	<4ABB93E7.1020702@pobox.com>
Message-ID: <63ac96a50909240900o51199dbbn3dbf6de54cfc5d37@mail.gmail.com>

On Thu, Sep 24, 2009 at 8:44 AM, Harald Koch  wrote:

> It does appear that gmail going down leads to a DoS against the NANOG list.
> :-)
>
> --
> Harald
>
>
>
Thank goodness my Yahoo email account is still working.  Don't we have
enough
conversations here about diversity and redundancy at the network layer for
people
to realize it's good to have similar diversity and redundancy at the
application layer
as well?  (yes, I have accounts on both systems, and use them both actively)

Matt


From pfunix at gmail.com  Thu Sep 24 11:05:08 2009
From: pfunix at gmail.com (Beavis)
Date: Thu, 24 Sep 2009 10:05:08 -0600
Subject: Gmail Down?
In-Reply-To: <4ABB8B57.3020600@uplogon.com>
References: <4ABB8B57.3020600@uplogon.com>
Message-ID: 

mine is showing up "temporarily unable to access your contacts" mail
seems to work ok.


On Thu, Sep 24, 2009 at 9:08 AM, Chris Gotstein  wrote:
> Anyone else seeing Google's Gmail down right now? ?Seems to have been
> down since 10am CST. ?We are connected through Chicago.
> downforeveryoneorjustme.com is also reporting it's down.
>
> --
> ---- ---- ---- ----
> Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP
> http://uplogon.com | +1 906 774 4847 | chris at uplogon.com
>
>



-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments



From vixie at isc.org  Thu Sep 24 11:08:28 2009
From: vixie at isc.org (Paul Vixie)
Date: Thu, 24 Sep 2009 16:08:28 +0000
Subject: Gmail Down?
In-Reply-To: <5b602b520909240829m38edb8c6i36c4c25061f792e1@mail.gmail.com>
	(cabenth@gmail.com's message of "Thu\,
	24 Sep 2009 08\:29\:58 -0700")
References: <4ABB8B57.3020600@uplogon.com>
	<5b602b520909240829m38edb8c6i36c4c25061f792e1@mail.gmail.com>
Message-ID: 

cabenth  writes:

> Gmail is definitely been having a hard time this morning.
>
> Stand by for the comments from the peanut gallery about allowing google
> to scan your e-mail, etc.... like last time Gmail had an issue.

i recently explored webmail for my family and found "prayer", which is a
pure C application (no php, no perl) built on the uw-imap c-client library.
it's blindingly fast even for thousands of huge mailboxes stored in MH
format.  anyone who was using "the cloud" because they couldn't stand the
poor performance of the apache-based webmail systems should take a look.

 is the home page.  though i
found it in freebsd .
-- 
Paul Vixie
KI6YSY



From leothelion.murtaza at gmail.com  Thu Sep 24 11:18:14 2009
From: leothelion.murtaza at gmail.com (Murtaza)
Date: Thu, 24 Sep 2009 22:18:14 +0600
Subject: Gmail Down?
In-Reply-To: 
References: <4ABB8B57.3020600@uplogon.com>
	
Message-ID: <949b74980909240918h48c7ccces867b25c77a3ffd62@mail.gmail.com>

same is the case here with me in Pakistan....

On Thu, Sep 24, 2009 at 10:05 PM, Beavis  wrote:

> mine is showing up "temporarily unable to access your contacts" mail
> seems to work ok.
>
>
> On Thu, Sep 24, 2009 at 9:08 AM, Chris Gotstein  wrote:
> > Anyone else seeing Google's Gmail down right now?  Seems to have been
> > down since 10am CST.  We are connected through Chicago.
> > downforeveryoneorjustme.com is also reporting it's down.
> >
> > --
> > ---- ---- ---- ----
> > Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP
> > http://uplogon.com | +1 906 774 4847 | chris at uplogon.com
> >
> >
>
>
>
> --
> ()  ascii ribbon campaign - against html e-mail
> /\  www.asciiribbon.org   - against proprietary attachments
>
>


-- 
Ghulam Murtaza
Lahore University of Management Sciences


From aaron at coinet.com  Thu Sep 24 11:22:37 2009
From: aaron at coinet.com (Aaron L. Meehan)
Date: Thu, 24 Sep 2009 09:22:37 -0700
Subject: Gmail Down?
In-Reply-To: <63ac96a50909240900o51199dbbn3dbf6de54cfc5d37@mail.gmail.com>
References: <4ABB8B57.3020600@uplogon.com> <4ABB8CC5.5080204@deaddrop.org>
	<7db2dcf90909240821vbaac138qf13a345103b1d74c@mail.gmail.com>
	<4ABB93E7.1020702@pobox.com>
	<63ac96a50909240900o51199dbbn3dbf6de54cfc5d37@mail.gmail.com>
Message-ID: <20090924162237.GF29709@earth.coinet.com>

On Thu, Sep 24, 2009 at 09:00:13AM -0700, Matthew Petach wrote:
> Thank goodness my Yahoo email account is still working.  Don't we have
> enough
> conversations here about diversity and redundancy at the network layer for
> people
> to realize it's good to have similar diversity and redundancy at the
> application layer
> as well?  (yes, I have accounts on both systems, and use them both actively)

And what a splendid job your webmail does of formatting your text!
Why, that's beautiful.

Who bloody cares if gmail's contacts aren't working, anyway?






From leothelion.murtaza at gmail.com  Thu Sep 24 11:22:27 2009
From: leothelion.murtaza at gmail.com (Murtaza)
Date: Thu, 24 Sep 2009 22:22:27 +0600
Subject: Gmail Down?
In-Reply-To: <949b74980909240918h48c7ccces867b25c77a3ffd62@mail.gmail.com>
References: <4ABB8B57.3020600@uplogon.com>
	
	<949b74980909240918h48c7ccces867b25c77a3ffd62@mail.gmail.com>
Message-ID: <949b74980909240922m5d98eaay590cfce33bff28db@mail.gmail.com>

not able to access ny chat logs and some of the contacts are not showing up
in chat window...

On Thu, Sep 24, 2009 at 10:18 PM, Murtaza wrote:

> same is the case here with me in Pakistan....
>
>
> On Thu, Sep 24, 2009 at 10:05 PM, Beavis  wrote:
>
>> mine is showing up "temporarily unable to access your contacts" mail
>> seems to work ok.
>>
>>
>> On Thu, Sep 24, 2009 at 9:08 AM, Chris Gotstein 
>> wrote:
>> > Anyone else seeing Google's Gmail down right now?  Seems to have been
>> > down since 10am CST.  We are connected through Chicago.
>> > downforeveryoneorjustme.com is also reporting it's down.
>> >
>> > --
>> > ---- ---- ---- ----
>> > Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP
>> > http://uplogon.com | +1 906 774 4847 | chris at uplogon.com
>> >
>> >
>>
>>
>>
>> --
>> ()  ascii ribbon campaign - against html e-mail
>> /\  www.asciiribbon.org   - against proprietary attachments
>>
>>
>
>
> --
> Ghulam Murtaza
> Lahore University of Management Sciences
>



-- 
Ghulam Murtaza
Lahore University of Management Sciences


From sharp at sharpone.net  Thu Sep 24 11:22:27 2009
From: sharp at sharpone.net (Justin Sharp)
Date: Thu, 24 Sep 2009 10:22:27 -0600
Subject: Gmail Down?
Message-ID: <2364DE34-CBDC-4BAE-9D54-9CEAEDF3CBEA@zaidali.com>

Not sure if its related, but the I'M portion seems broke too.. all of my contacts are offline which is extremely unusual..

Zaid Ali  wrote:

>Seems like the contact portion only.
>
>Gmail is temporarily unable to access your Contacts. You may  
>experience issues while this persists.
>
>Zaid
>
>On Sep 24, 2009, at 8:08 AM, Chris Gotstein wrote:
>
>> Anyone else seeing Google's Gmail down right now?  Seems to have been
>> down since 10am CST.  We are connected through Chicago.
>> downforeveryoneorjustme.com is also reporting it's down.
>>
>> -- 
>> ---- ---- ---- ----
>> Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP
>> http://uplogon.com | +1 906 774 4847 | chris at uplogon.com
>>
>
>

From a.harrowell at gmail.com  Thu Sep 24 12:27:43 2009
From: a.harrowell at gmail.com (Alexander Harrowell)
Date: Thu, 24 Sep 2009 18:27:43 +0100
Subject: Gmail Down?
In-Reply-To: <200909241153.32531.jam@zoidtechnologies.com>
References: <4ABB8B57.3020600@uplogon.com> <4ABB8E26.2060001@csuohio.edu>
	<200909241153.32531.jam@zoidtechnologies.com>
Message-ID: <200909241827.56130.alexander.harrowell@stlpartners.com>

On Thursday 24 September 2009 16:53:32 Jeff MacDonald wrote:
> On Thursday 24 September 2009 11:20:06 Michael Holstein wrote:
> > > Anyone else seeing Google's Gmail down right now?
>
> I am not able to use "google talk" at the moment. each time I try to send
> an IM, I get a "500" error.
>

London (UK) - mail is up over IMAP. The "contacts list"/chatbox in Gmail is a 
Web wrapper around their Google Talk XMPP server, which I use through a 
standalone IM client. And guess what? I can log in but presence-and-
availability info isn't being updated. talk.google.com returns "Your message 
could not be delivered - reason:""" 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: 

From tb at tburke.us  Thu Sep 24 11:36:11 2009
From: tb at tburke.us (Tim Burke)
Date: Thu, 24 Sep 2009 12:36:11 -0400
Subject: Gmail Down?
In-Reply-To: <200909241827.56130.alexander.harrowell@stlpartners.com>
References: <4ABB8B57.3020600@uplogon.com> <4ABB8E26.2060001@csuohio.edu>
	<200909241153.32531.jam@zoidtechnologies.com>,
	<200909241827.56130.alexander.harrowell@stlpartners.com>
Message-ID: 

Mail via the web interface appears to be working from here. XMPP is firewalled off where I am at right now so I can not check the status of that.
________________________________________
From: Alexander Harrowell [a.harrowell at gmail.com]
Sent: Thursday, September 24, 2009 12:27 PM
To: nanog at nanog.org
Subject: Re: Gmail Down?

On Thursday 24 September 2009 16:53:32 Jeff MacDonald wrote:
> On Thursday 24 September 2009 11:20:06 Michael Holstein wrote:
> > > Anyone else seeing Google's Gmail down right now?
>
> I am not able to use "google talk" at the moment. each time I try to send
> an IM, I get a "500" error.
>

London (UK) - mail is up over IMAP. The "contacts list"/chatbox in Gmail is a
Web wrapper around their Google Talk XMPP server, which I use through a
standalone IM client. And guess what? I can log in but presence-and-
availability info isn't being updated. talk.google.com returns "Your message
could not be delivered - reason:"""



From dot at dotat.at  Thu Sep 24 12:00:23 2009
From: dot at dotat.at (Tony Finch)
Date: Thu, 24 Sep 2009 18:00:23 +0100
Subject: Gmail Down?
In-Reply-To: 
References: <4ABB8B57.3020600@uplogon.com>
	<5b602b520909240829m38edb8c6i36c4c25061f792e1@mail.gmail.com>
	
Message-ID: 

On Thu, 24 Sep 2009, Paul Vixie wrote:
>
> i recently explored webmail for my family and found "prayer", which is a
> pure C application (no php, no perl) built on the uw-imap c-client library.
> it's blindingly fast even for thousands of huge mailboxes stored in MH
> format.  anyone who was using "the cloud" because they couldn't stand the
> poor performance of the apache-based webmail systems should take a look.

We have about 41,000 registered users of which about 25,000 log in to
webmail in a busy week (about 850,000 logins per week, 6 or 7 million HTTP
requests per day). We run Prayer on a single PC with 8GB RAM and one dual
code 2GHz Xeon CPU. Mailboxes live on separate Cyrus IMAP servers.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.



From shahlatabarzadi at gmail.com  Thu Sep 24 12:08:35 2009
From: shahlatabarzadi at gmail.com (Shahla Tabarzadi)
Date: Thu, 24 Sep 2009 13:08:35 -0400
Subject: Gmail Down?
In-Reply-To: 
References: <4ABB8B57.3020600@uplogon.com>
	<5b602b520909240829m38edb8c6i36c4c25061f792e1@mail.gmail.com>
	
	
Message-ID: <7389cd920909241008i1203081dh71cbe38d7e8c4da1@mail.gmail.com>

gmail is working in the U.S

On Thu, Sep 24, 2009 at 1:00 PM, Tony Finch  wrote:

> On Thu, 24 Sep 2009, Paul Vixie wrote:
> >
> > i recently explored webmail for my family and found "prayer", which is a
> > pure C application (no php, no perl) built on the uw-imap c-client
> library.
> > it's blindingly fast even for thousands of huge mailboxes stored in MH
> > format.  anyone who was using "the cloud" because they couldn't stand the
> > poor performance of the apache-based webmail systems should take a look.
>
> We have about 41,000 registered users of which about 25,000 log in to
> webmail in a busy week (about 850,000 logins per week, 6 or 7 million HTTP
> requests per day). We run Prayer on a single PC with 8GB RAM and one dual
> code 2GHz Xeon CPU. Mailboxes live on separate Cyrus IMAP servers.
>
> Tony.
> --
> f.anthony.n.finch    http://dotat.at/
> GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
> MODERATE OR GOOD.
>
>


-- 
Shahla


From mruiz at telwestservices.com  Thu Sep 24 12:30:44 2009
From: mruiz at telwestservices.com (Michael Ruiz)
Date: Thu, 24 Sep 2009 12:30:44 -0500
Subject: 
Message-ID: <9F285BFE1D7757499D9FF095B4EE347D0452632C@tw-xchange01.TWC.local>

Hello Folks,

 

                I am a different problem here this time It is on my Cisco 12008.  I currently have two types of access cards installed into the chassis.  I have a CHOC12-DS1/IR-SC card and a 6-CT3-SMB card.  I am running QOS on the unit.  I get this error when I do apply this command "tx-cos DS1-TX."  What brought this about was when t he service policy was entered the Queing strategy did not change. It still said FIFO. In slot 1 I have a channelized 6-CT3-SMB card installed.  Our previous engineer discovered that because the 6-CT3 card is an Engine 1 card and not an Engine 3 card, there are limitation of what you can do with the QOS of the line card itself.  So you have to setup almost like frame-relay type setup.   The question I have, is there limitation on the number of queuing strategies you can run at one time?

 

ar1.DLLSTXHW#show int ser 1/0/1:0

Serial1/0/1:0 is up, line protocol is up 

  Hardware is Channelized-T3

  Description:

  Internet address is 

  MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec, rely 255/255, load 35/255

  Encapsulation PPP, crc 16, loopback not set

  Keepalive set (10 sec)

  LCP Open

  Open: IPCP

  Last input 00:00:01, output 00:00:01, output hang never

  Last clearing of "show interface" counters 00:13:45

  Queueing strategy: fifo --?

  Output queue 0/40, 0 drops; input queue 0/75, 0 drops

  5 minute input rate 97000 bits/sec, 56 packets/sec

  5 minute output rate 214000 bits/sec, 80 packets/sec

     45738 packets input, 9931625 bytes, 0 no buffer

     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

     67213 packets output, 22609196 bytes, 0 underruns

     0 output errors, 0 collisions, 0 interface resets

     0 output buffer failures, 0 output buffers swapped out

     0 carrier transitions alarm present

  Timeslot(s) Used: 1-24, Transmitter delay is 0 flags

  non-inverted data

ar1.DLLSTXHW#show run int ser 1/0/1:0

Building configuration...

 

Current configuration : 271 bytes

!

interface Serial1/0/1:0

no ip redirects

 no ip unreachables

 no ip directed-broadcast

 no ip proxy-arp

 encapsulation ppp

 no cdp enable

 service-policy output VOICE

end

 

 

ar1.DLLSTXHW(config-if)#tx-cos DS1-TX

service-policy is already configured on interface, tx-cos is not allowed

 

On my Channelized OC12 facilities I use the service policy command to add my Policy MAP to the interface.

 

ar1.DLLSTXHW#show policy-map 

  Policy Map VOICE

    Class VOICE

      priority 

    Class class-default

      random-detect precedence-based

ar1.DLLSTXHW#show class

ar1.DLLSTXHW#show class-map 

 Class Map match-any class-default (id 0)

   Match any 

 

 Class Map match-any VOICE (id 7)

   Match ip  precedence 5 

 

ar1.DLLSTXHW#show access

ar1.DLLSTXHW#show access-lists VOICE

Extended IP access list VOICE

    permit tcp any any eq 1720

    permit udp any any eq 5060

    permit udp any any range 4000 6000

    permit udp any any range 16384 32767

    permit udp any any range 60000 65531

    permit udp any any range 6001 6300

    permit udp any any range 58000 59999

    permit udp any any range 32768 33000

    permit udp any host 206.193.221.32

    permit udp host 206.193.221.32 any

    permit udp any host 206.193.221.36

    permit udp host 206.193.221.36 any

    permit udp any eq 5060 any eq 5060

    permit udp any host 206.193.221.35

    permit udp host 206.193.221.35 any

 

 

 

 

Michael Ruiz mruiz at telwestservices.com  

 

 

 



From phiber at phiber.org  Thu Sep 24 14:42:49 2009
From: phiber at phiber.org (Christopher Rogers)
Date: Thu, 24 Sep 2009 12:42:49 -0700
Subject: connectivity issues between ATTWS and 207.188.0.0/19
Message-ID: 

Hi all, we are having some issues with users attempting to reach our
public netblocks via ATTWS.  Our advertised ranges appear to be
completely unreachable from their wireless network.  The
route-server.ip.att.net verifies our netblocks are seen and reachable,
but this probably has something to do with the cingular network
infrastructure.  Connections via other providers- tmo, etc, all work
fine.

We are attempting to contact attws for support, but aren't making it
beyond the 'is your ipsec client configured properly?'  Could a
clueful engineer please contact me off-list at their earliest
convenience?

Thanks kindly
Chris



From ml at kenweb.org  Thu Sep 24 15:42:25 2009
From: ml at kenweb.org (ML)
Date: Thu, 24 Sep 2009 16:42:25 -0400
Subject: Dark Fiber in Orlando
Message-ID: <4ABBD9B1.8090704@kenweb.org>

Can anyone on the list share experience with dark fiber providers in 
Orlando, Florida?




From mruiz at telwestservices.com  Thu Sep 24 18:57:55 2009
From: mruiz at telwestservices.com (Michael Ruiz)
Date: Thu, 24 Sep 2009 18:57:55 -0500
Subject: 
Message-ID: <9F285BFE1D7757499D9FF095B4EE347D045265F4@tw-xchange01.TWC.local>

I found the issue.  I found that one of the techs had applied the
service-policy against an interface that is on the 6-CT3 line card.
This caused the error I found.  I took out the service policy applied
and applied the tx-cos command and problem fixed. 

 

 

Michael Ruiz  mruiz at telwestservices.com
 

 



From devangnp at gmail.com  Thu Sep 24 23:24:29 2009
From: devangnp at gmail.com (devang patel)
Date: Thu, 24 Sep 2009 22:24:29 -0600
Subject: bgp best path compare-routerid implementation example
Message-ID: 

Hello Nanog,

I am looking for the *bgp best path compare*-*routerid* implementation
example? I know the function of it but looking for some scenario where its
been used...

Thanks,
Dev


From andy at nosignal.org  Fri Sep 25 02:21:22 2009
From: andy at nosignal.org (Andy Davidson)
Date: Fri, 25 Sep 2009 08:21:22 +0100
Subject: bgp best path compare-routerid implementation example
In-Reply-To: 
References: 
Message-ID: <9ECCE458-2840-478F-8523-45D8CED2F83A@nosignal.org>


On 25 Sep 2009, at 05:24, devang patel wrote:

> I am looking for the *bgp best path compare*-*routerid* implementation
> example? I know the function of it but looking for some scenario  
> where its
> been used...

Hi, Devang

This option is really only used in order to instruct a router to skip  
the option before it in best path selection algorithm (prefer the path  
learned from the older established session).

I don't think you'd use it if you ran a normal network (or knew what  
you were doing ;-) ) because you'd typically use much more  
deterministic decisions to send traffic to specific and predictable  
paths, or you'd use hot-potato routing and send the traffic to the  
nearest equivalent exit ('prefer ebgp over ibgp' and 'prefer path with  
lowest igp metric' comes before 'use the oldest path').

Andy



-- 
Regards, Andy Davidson       +44 (0)20 7993 1700       www.netsumo.com
NetSumo  Specialist networks consultancy for ISPs, Whitelabel 24/7 NOC










From Valdis.Kletnieks at vt.edu  Fri Sep 25 09:41:08 2009
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 25 Sep 2009 10:41:08 -0400
Subject: Gmail Down?
In-Reply-To: Your message of "Thu, 24 Sep 2009 11:20:06 EDT."
	<4ABB8E26.2060001@csuohio.edu>
References: <4ABB8B57.3020600@uplogon.com> <4ABB8E26.2060001@csuohio.edu>
Message-ID: <3209.1253889668@turing-police.cc.vt.edu>

On Thu, 24 Sep 2009 11:20:06 EDT, Michael Holstein said:
> I dunno boss, just ask "the cloud" .. you're the one that wanted to 
> compute there instead of here.
> 
> /dilbert :)

Actually, yes, there *is* a rather recent Dilbert about it.

http://www.dilbert.com/strips/comic/2009-08-30/

:)



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: 

From sburford at google.com  Fri Sep 25 12:38:28 2009
From: sburford at google.com (Sean Burford)
Date: Fri, 25 Sep 2009 10:38:28 -0700
Subject: Repair of Sydney CBD's worst ever cable cut
Message-ID: 

Hi,

Interesting PR piece about the repairs after a jackhammer went through 8
fibers and 4800, 4200, 3600 pair cables in Sydney:
http://www.youtube.com/watch?v=wT2jMUCVdJU
Thanks,
Sean


From austinw at bandcon.com  Fri Sep 25 12:50:44 2009
From: austinw at bandcon.com (Austin Wilson)
Date: Fri, 25 Sep 2009 10:50:44 -0700
Subject: bgp best path compare-routerid implementation example
In-Reply-To: 
References: 
Message-ID: <67B864FDA9789F4FA1A854AFD6A1F3C80CB86F7E00@devo>

Dev,


This is usually used to offset the oldest route metric. The problem is that when a link fails and comes back online, traffic can shift from one provider to another in the middle of your billing cycle. This then could mean you get double billed for that traffic. People use the command to basically turn off the oldest route metric and use the routerid (not peering ip) to make the last decision on where to send your traffic. This is commonly called "tie breaker" traffic. If a peer fails with this command enabled, when the peer comes back online, traffic should be restored to the original level before the failure. 

A possible issue with this command is that if a local peer's route/session flaps it could have more of an effect on your network/router as it will always try move those routes back to the FIB. That's probably why they implemented this metric in the first place, the oldest route is the most stable. Another issue is that you are at the mercy of vendor's routerid when your router decides where to send your "tie breaker" traffic. Level3 gets most of this traffic since they have such low routeids.

There are ways to get around this problem and take back control of your tie breaker traffic. Dani did a pretty good tutorial on this issue and its located here:

http://nanog.org/meetings/nanog46/abstracts.php?pt=MTM3MiZuYW5vZzQ2&nm=nanog46

Basically he suggests using MEDs to change the tie breaker as part of a complete BGP traffic engineering solution. Doing the things listed there and elsewhere will mean you won't even have to use this command. 



Austin Wilson


-----Original Message-----
From: devang patel [mailto:devangnp at gmail.com] 
Sent: Thursday, September 24, 2009 9:24 PM
To: nanog at nanog.org
Subject: bgp best path compare-routerid implementation example

Hello Nanog,

I am looking for the *bgp best path compare*-*routerid* implementation
example? I know the function of it but looking for some scenario where its
been used...

Thanks,
Dev



From devangnp at gmail.com  Fri Sep 25 13:07:13 2009
From: devangnp at gmail.com (devang patel)
Date: Fri, 25 Sep 2009 12:07:13 -0600
Subject: bgp best path compare-routerid implementation example
In-Reply-To: <67B864FDA9789F4FA1A854AFD6A1F3C80CB86F7E00@devo>
References: 
	<67B864FDA9789F4FA1A854AFD6A1F3C80CB86F7E00@devo>
Message-ID: 

Hi...

So according to command it will select the path received from lowest router
id right... so if you are sure about the path selection pattern then its
good idea to use it...
And true that path selection change based on own network design...

is it good idea to set all received route attribute to particular origin
code "i" as Dani showed in presentation... well again I guess answer will be
depends on network design...

Thanks,
Dev

On Fri, Sep 25, 2009 at 11:50 AM, Austin Wilson  wrote:

> Dev,
>
>
> This is usually used to offset the oldest route metric. The problem is that
> when a link fails and comes back online, traffic can shift from one provider
> to another in the middle of your billing cycle. This then could mean you get
> double billed for that traffic. People use the command to basically turn off
> the oldest route metric and use the routerid (not peering ip) to make the
> last decision on where to send your traffic. This is commonly called "tie
> breaker" traffic. If a peer fails with this command enabled, when the peer
> comes back online, traffic should be restored to the original level before
> the failure.
>
> A possible issue with this command is that if a local peer's route/session
> flaps it could have more of an effect on your network/router as it will
> always try move those routes back to the FIB. That's probably why they
> implemented this metric in the first place, the oldest route is the most
> stable. Another issue is that you are at the mercy of vendor's routerid when
> your router decides where to send your "tie breaker" traffic. Level3 gets
> most of this traffic since they have such low routeids.
>
> There are ways to get around this problem and take back control of your tie
> breaker traffic. Dani did a pretty good tutorial on this issue and its
> located here:
>
>
> http://nanog.org/meetings/nanog46/abstracts.php?pt=MTM3MiZuYW5vZzQ2&nm=nanog46
>
> Basically he suggests using MEDs to change the tie breaker as part of a
> complete BGP traffic engineering solution. Doing the things listed there and
> elsewhere will mean you won't even have to use this command.
>
>
>
> Austin Wilson
>
>
> -----Original Message-----
> From: devang patel [mailto:devangnp at gmail.com]
> Sent: Thursday, September 24, 2009 9:24 PM
> To: nanog at nanog.org
> Subject: bgp best path compare-routerid implementation example
>
> Hello Nanog,
>
> I am looking for the *bgp best path compare*-*routerid* implementation
> example? I know the function of it but looking for some scenario where its
> been used...
>
> Thanks,
> Dev
>


From austinw at bandcon.com  Fri Sep 25 13:21:39 2009
From: austinw at bandcon.com (Austin Wilson)
Date: Fri, 25 Sep 2009 11:21:39 -0700
Subject: bgp best path compare-routerid implementation example
In-Reply-To: 
References: 
	<67B864FDA9789F4FA1A854AFD6A1F3C80CB86F7E00@devo>
	
Message-ID: <67B864FDA9789F4FA1A854AFD6A1F3C80CB86F7E06@devo>

Dev,

Yes, using that command, it will use the lowest routerid as its preferred tie breaker path. Though, if all of your providers have different MEDs and you are using MEDs to engineer you traffic, your router should never have to tie break any traffic. Also any of the higher preference metrics will interfere with what you are trying to accomplish with a lower metric. Dani suggested changing the origin code so it wouldn't affect what you are trying to do with MEDs.

Everything else is dependent on how you want to manage your network.


Austin Wilson


From: devang patel [mailto:devangnp at gmail.com]
Sent: Friday, September 25, 2009 11:07 AM
To: Austin Wilson
Cc: nanog at nanog.org
Subject: Re: bgp best path compare-routerid implementation example

Hi...

So according to command it will select the path received from lowest router id right... so if you are sure about the path selection pattern then its good idea to use it...

And true that path selection change based on own network design...

is it good idea to set all received route attribute to particular origin code "i" as Dani showed in presentation... well again I guess answer will be depends on network design...

Thanks,
Dev
On Fri, Sep 25, 2009 at 11:50 AM, Austin Wilson > wrote:
Dev,


This is usually used to offset the oldest route metric. The problem is that when a link fails and comes back online, traffic can shift from one provider to another in the middle of your billing cycle. This then could mean you get double billed for that traffic. People use the command to basically turn off the oldest route metric and use the routerid (not peering ip) to make the last decision on where to send your traffic. This is commonly called "tie breaker" traffic. If a peer fails with this command enabled, when the peer comes back online, traffic should be restored to the original level before the failure.

A possible issue with this command is that if a local peer's route/session flaps it could have more of an effect on your network/router as it will always try move those routes back to the FIB. That's probably why they implemented this metric in the first place, the oldest route is the most stable. Another issue is that you are at the mercy of vendor's routerid when your router decides where to send your "tie breaker" traffic. Level3 gets most of this traffic since they have such low routeids.

There are ways to get around this problem and take back control of your tie breaker traffic. Dani did a pretty good tutorial on this issue and its located here:

http://nanog.org/meetings/nanog46/abstracts.php?pt=MTM3MiZuYW5vZzQ2&nm=nanog46

Basically he suggests using MEDs to change the tie breaker as part of a complete BGP traffic engineering solution. Doing the things listed there and elsewhere will mean you won't even have to use this command.



Austin Wilson


-----Original Message-----
From: devang patel [mailto:devangnp at gmail.com]
Sent: Thursday, September 24, 2009 9:24 PM
To: nanog at nanog.org
Subject: bgp best path compare-routerid implementation example

Hello Nanog,

I am looking for the *bgp best path compare*-*routerid* implementation
example? I know the function of it but looking for some scenario where its
been used...

Thanks,
Dev



From cscora at apnic.net  Fri Sep 25 13:28:47 2009
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 26 Sep 2009 04:28:47 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <200909251828.n8PISlSL031732@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 26 Sep, 2009

Report Website:     http://thyme.apnic.net
Detailed Analysis:  http://thyme.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              298894
    Prefixes after maximum aggregation:                          140069
    Deaggregation factor:                                          2.13
    Unique aggregates announced to Internet:                     148203
Total ASes present in the Internet Routing Table:                 32275
    Prefixes per ASN:                                              9.26
Origin-only ASes present in the Internet Routing Table:           28043
Origin ASes announcing only one prefix:                           13693
Transit ASes present in the Internet Routing Table:                4232
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:                                      31
    Max AS path prepend of ASN (45127)                               27
Prefixes from unregistered ASNs in the Routing Table:               456
    Unregistered ASNs in the Routing Table:                         122
Number of 32-bit ASNs allocated by the RIRs:                        283
Prefixes from 32-bit ASNs in the Routing Table:                     145
Special use prefixes present in the Routing Table:                    0
Prefixes being announced from unallocated address space:            204
Number of addresses announced to Internet:                   2108932864
    Equivalent to 125 /8s, 179 /16s and 195 /24s
    Percentage of available address space announced:               56.9
    Percentage of allocated address space announced:               64.5
    Percentage of available address space allocated:               88.2
    Percentage of address space in use by end-sites:               79.0
Total number of prefixes smaller than registry allocations:      143732

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                    71419
    Total APNIC prefixes after maximum aggregation:               25067
    APNIC Deaggregation factor:                                    2.85
Prefixes being announced from the APNIC address blocks:           67834
    Unique aggregates announced from the APNIC address blocks:    30294
APNIC Region origin ASes present in the Internet Routing Table:    3806
    APNIC Prefixes per ASN:                                       17.82
APNIC Region origin ASes announcing only one prefix:               1047
APNIC Region transit ASes present in the Internet Routing Table:    585
Average APNIC Region AS path length visible:                        3.5
    Max APNIC Region AS path length visible:                         31
Number of APNIC addresses announced to Internet:              460581408
    Equivalent to 27 /8s, 115 /16s and 234 /24s
    Percentage of available APNIC address space announced:         78.4

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:                    126988
    Total ARIN prefixes after maximum aggregation:                66741
    ARIN Deaggregation factor:                                     1.90
Prefixes being announced from the ARIN address blocks:           101421
    Unique aggregates announced from the ARIN address blocks:     38445
ARIN Region origin ASes present in the Internet Routing Table:    13258
    ARIN Prefixes per ASN:                                         7.65
ARIN Region origin ASes announcing only one prefix:                5136
ARIN Region transit ASes present in the Internet Routing Table:    1295
Average ARIN Region AS path length visible:                         3.3
    Max ARIN Region AS path length visible:                          24
Number of ARIN addresses announced to Internet:               706192256
    Equivalent to 42 /8s, 23 /16s and 163 /24s
    Percentage of available ARIN address space announced:          61.9

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       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:                     68650
    Total RIPE prefixes after maximum aggregation:                40175
    RIPE Deaggregation factor:                                     1.71
Prefixes being announced from the RIPE address blocks:            62346
    Unique aggregates announced from the RIPE address blocks:     41701
RIPE Region origin ASes present in the Internet Routing Table:    13513
    RIPE Prefixes per ASN:                                         4.61
RIPE Region origin ASes announcing only one prefix:                7037
RIPE Region transit ASes present in the Internet Routing Table:    2041
Average RIPE Region AS path length visible:                         3.9
    Max RIPE Region AS path length visible:                          21
Number of RIPE addresses announced to Internet:               399869888
    Equivalent to 23 /8s, 213 /16s and 135 /24s
    Percentage of available RIPE address space announced:          74.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:                   25598
    Total LACNIC prefixes after maximum aggregation:               6262
    LACNIC Deaggregation factor:                                   4.09
Prefixes being announced from the LACNIC address blocks:          23876
    Unique aggregates announced from the LACNIC address blocks:   13335
LACNIC Region origin ASes present in the Internet Routing Table:   1184
    LACNIC Prefixes per ASN:                                      20.17
LACNIC Region origin ASes announcing only one prefix:               380
LACNIC Region transit ASes present in the Internet Routing Table:   193
Average LACNIC Region AS path length visible:                       4.1
    Max LACNIC Region AS path length visible:                        21
Number of LACNIC addresses announced to Internet:              66545152
    Equivalent to 3 /8s, 247 /16s and 102 /24s
    Percentage of available LACNIC address space announced:        66.1

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:                   5853
    Total AfriNIC prefixes after maximum aggregation:              1554
    AfriNIC Deaggregation factor:                                  3.77
Prefixes being announced from the AfriNIC address blocks:          4236
    Unique aggregates announced from the AfriNIC address blocks:   1535
AfriNIC Region origin ASes present in the Internet Routing Table:   319
    AfriNIC Prefixes per ASN:                                     13.28
AfriNIC Region origin ASes announcing only one prefix:               93
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:                       14
Number of AfriNIC addresses announced to Internet:             12467968
    Equivalent to 0 /8s, 190 /16s and 63 /24s
    Percentage of available AfriNIC address space announced:       37.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     1762       6995         453   Korea Telecom (KIX)
17488     1505        137         104   Hathway IP Over Cable Interne
 4755     1260        292         144   TATA Communications formerly 
 9583     1101         87         530   Sify Limited
 4134     1009      18168         391   CHINANET-BACKBONE
18101      975        204          33   Reliance Infocom Ltd Internet
 7545      869        198          97   TPG Internet Pty Ltd
 9829      813        626          19   BSNL National Internet Backbo
 4808      788       1518         181   CNCGROUP IP network: China169
24560      774        285         164   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     4168       3627         312   bellsouth.net, inc. 
 4323     3700       1045         384   Time Warner Telecom
 1785     1751        714         138   PaeTec Communications, Inc.
 7018     1507       5875        1056   AT&T WorldNet Services
20115     1479       1477         668   Charter Communications 
 6478     1411        279         301   AT&T Worldnet Services 
 2386     1321        657         951   AT&T Data Communications Serv
 3356     1234      10964         441   Level 3 Communications, LLC 
11492     1128        208          12   Cable One 
22773     1111       2604          67   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      493         93         202   Evolva Telecom
 3292      446       1900         393   TDC Tele Danmark
  702      425       1822         343   UUNET - Commercial IP service
12479      425        578           6   Uni2 Autonomous System
35805      415         40           5   United Telecom of Georgia
 9198      376        138          12   Kazakhtelecom Data Network Ad
 8866      358        110          23   Bulgarian Telecommunication C
 3320      353       7068         304   Deutsche Telekom AG
 3301      351       1412         308   TeliaNet Sweden
 3215      348       3128         110   France Telecom Transpac

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     1478       2899         246   UniNet S.A. de C.V. 
10620     1015        227          95   TVCABLE BOGOTA 
28573      709        622          62   NET Servicos de Comunicao S.A
 7303      640        338          94   Telecom Argentina Stet-France
22047      544        302          14   VTR PUNTO NET S.A. 
11830      475        310          61   Instituto Costarricense de El
11172      440         99          70   Servicios Alestra S.A de C.V 
14117      435         29          11   Telefonica del Sur S.A. 
 7738      424        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      954        188           7   TEDATA
24863      939         97          62   LINKdotNET AS number
 3741      272        856         234   The Internet Solution 
 2018      197        187         116   Tertiary Education Network 
 6713      175        166          16   Itissalat Al-MAGHRIB
29571      139         14           6   Ci Telecom Autonomous system 
24835      123         46           9   RAYA Telecom - Egypt
 5536      122          8          13   Internet Egypt Network
 5713      118        520          69   Telkom SA Ltd 
20858      106         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     4168       3627         312   bellsouth.net, inc. 
 4323     3700       1045         384   Time Warner Telecom
 4766     1762       6995         453   Korea Telecom (KIX)
 1785     1751        714         138   PaeTec Communications, Inc.
 7018     1507       5875        1056   AT&T WorldNet Services
17488     1505        137         104   Hathway IP Over Cable Interne
20115     1479       1477         668   Charter Communications 
 8151     1478       2899         246   UniNet S.A. de C.V. 
 6478     1411        279         301   AT&T Worldnet Services 
 2386     1321        657         951   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      3700        3316      Time Warner Telecom
 1785      1751        1613      PaeTec Communications, Inc.
17488      1505        1401      Hathway IP Over Cable Interne
 4766      1762        1309      Korea Telecom (KIX)
 8151      1478        1232      UniNet S.A. de C.V. 
 4755      1260        1116      TATA Communications formerly 
11492      1128        1116      Cable One 
 6478      1411        1110      AT&T Worldnet Services 
18566      1062        1052      Covad Communications 
22773      1111        1044      Cox Communications, Inc.

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.189.0/24      26452     Local Communications Networks
43.245.0.0/16         7502     Internetwork Kyoto
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:24      /11:63      /12:176     
/13:354     /14:625     /15:1199    /16:10676   /17:4832    /18:8367    
/19:17456   /20:20856   /21:20870   /22:27113   /23:26778   /24:156686  
/25:933     /26:1063    /27:562     /28:169     /29:40      /30:15      
/31:0       /32:8       

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
 6389     2700          4168      bellsouth.net, inc. 
 4323     2360          3700      Time Warner Telecom
 4766     1435          1762      Korea Telecom (KIX)
17488     1259          1505      Hathway IP Over Cable Interne
 1785     1217          1751      PaeTec Communications, Inc.
11492     1054          1128      Cable One 
18566     1043          1062      Covad Communications 
 9583      953          1101      Sify Limited
10620      921          1015      TVCABLE BOGOTA 
 8452      878           954      TEDATA

Complete listing at http://thyme.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   2:1         4:14        8:227      12:2145     13:7        15:22     
  16:3        17:5        20:36       24:1169     32:52       34:2      
  38:604      40:97       41:1670     43:1        44:2        46:1      
  47:16       52:6        55:2        56:2        57:25       58:569    
  59:648      60:454      61:1075     62:1029     63:2018     64:3740   
  65:2398     66:4086     67:1776     68:964      69:2768     70:578    
  71:156      72:1680     73:2        74:1944     75:179      76:319    
  77:882      78:584      79:395      80:908      81:802      82:505    
  83:432      84:531      85:1028     86:382      87:683      88:388    
  89:1485     90:61       91:2563     92:404      93:1246     94:1207   
  95:1100     96:168      97:267      98:308      99:30      109:42     
 110:206     111:440     112:138     113:145     114:260     115:350    
 116:1126    117:571     118:325     119:782     120:132     121:775    
 122:1289    123:777     124:1048    125:1345    128:222     129:216    
 130:129     131:424     132:75      133:10      134:173     135:42     
 136:240     137:164     138:177     139:85      140:441     141:121    
 142:383     143:336     144:350     145:49      146:390     147:170    
 148:549     149:213     150:209     151:183     152:215     153:155    
 154:2       155:270     156:165     157:307     158:113     159:354    
 160:291     161:164     162:270     163:171     164:280     165:521    
 166:474     167:375     168:789     169:166     170:473     171:43     
 172:2       173:417     174:359     175:1       178:1       180:28     
 182:1       186:143     187:157     188:1011    189:581     190:3063   
 192:5775    193:4260    194:3290    195:2757    196:1150    198:3557   
 199:3350    200:5218    201:1320    202:7848    203:8263    204:3932   
 205:2201    206:2439    207:2988    208:3955    209:3488    210:2555   
 211:1123    212:1611    213:1621    214:176     215:40      216:4396   
 217:1311    218:412     219:450     220:1127    221:441     222:317    


End of report



From dholmes at mwdh2o.com  Fri Sep 25 14:17:12 2009
From: dholmes at mwdh2o.com (Holmes,David A)
Date: Fri, 25 Sep 2009 12:17:12 -0700
Subject: bgp best path compare-routerid implementation example
In-Reply-To: <67B864FDA9789F4FA1A854AFD6A1F3C80CB86F7E06@devo>
References: <67B864FDA9789F4FA1A854AFD6A1F3C80CB86F7E00@devo>
	<67B864FDA9789F4FA1A854AFD6A1F3C80CB86F7E06@devo>
Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E09B91808@usmsxt104.mwd.h2o>

BGP load-balancing appliances such as the old Routescience Pathcontrol
provided a deterministic end-to-end solution by measuring the RTTs of
the second and third packets of the TCP 3-way handshake between the
commercial web site and user destination networks. A full BGP feed was
required from each ISP in the commercial web site's border routers. Over
time, by measuring the 3-way handshake's RTTs, Pathcontrol would
statistically determine the best route to destination networks, and
cause that route to be injected into the border router's BGP table using
a BGP route-reflector configuration wherein the Pathcontrol was a
route-reflector client that advertised the calculated best route. 

I think that this scientific approach to BGP load-balancing is
intuitively and formally superior to other methods, although bandwidth
scalability may be a drawback of the appliance load-balancing approach.


-----Original Message-----
From: Austin Wilson [mailto:austinw at bandcon.com] 
Sent: Friday, September 25, 2009 11:22 AM
To: devang patel
Cc: nanog at nanog.org
Subject: RE: bgp best path compare-routerid implementation example

Dev,

Yes, using that command, it will use the lowest routerid as its
preferred tie breaker path. Though, if all of your providers have
different MEDs and you are using MEDs to engineer you traffic, your
router should never have to tie break any traffic. Also any of the
higher preference metrics will interfere with what you are trying to
accomplish with a lower metric. Dani suggested changing the origin code
so it wouldn't affect what you are trying to do with MEDs.

Everything else is dependent on how you want to manage your network.


Austin Wilson


From: devang patel [mailto:devangnp at gmail.com]
Sent: Friday, September 25, 2009 11:07 AM
To: Austin Wilson
Cc: nanog at nanog.org
Subject: Re: bgp best path compare-routerid implementation example

Hi...

So according to command it will select the path received from lowest
router id right... so if you are sure about the path selection pattern
then its good idea to use it...

And true that path selection change based on own network design...

is it good idea to set all received route attribute to particular origin
code "i" as Dani showed in presentation... well again I guess answer
will be depends on network design...

Thanks,
Dev
On Fri, Sep 25, 2009 at 11:50 AM, Austin Wilson
> wrote:
Dev,


This is usually used to offset the oldest route metric. The problem is
that when a link fails and comes back online, traffic can shift from one
provider to another in the middle of your billing cycle. This then could
mean you get double billed for that traffic. People use the command to
basically turn off the oldest route metric and use the routerid (not
peering ip) to make the last decision on where to send your traffic.
This is commonly called "tie breaker" traffic. If a peer fails with this
command enabled, when the peer comes back online, traffic should be
restored to the original level before the failure.

A possible issue with this command is that if a local peer's
route/session flaps it could have more of an effect on your
network/router as it will always try move those routes back to the FIB.
That's probably why they implemented this metric in the first place, the
oldest route is the most stable. Another issue is that you are at the
mercy of vendor's routerid when your router decides where to send your
"tie breaker" traffic. Level3 gets most of this traffic since they have
such low routeids.

There are ways to get around this problem and take back control of your
tie breaker traffic. Dani did a pretty good tutorial on this issue and
its located here:

http://nanog.org/meetings/nanog46/abstracts.php?pt=MTM3MiZuYW5vZzQ2&nm=n
anog46

Basically he suggests using MEDs to change the tie breaker as part of a
complete BGP traffic engineering solution. Doing the things listed there
and elsewhere will mean you won't even have to use this command.



Austin Wilson


-----Original Message-----
From: devang patel
[mailto:devangnp at gmail.com]
Sent: Thursday, September 24, 2009 9:24 PM
To: nanog at nanog.org
Subject: bgp best path compare-routerid implementation example

Hello Nanog,

I am looking for the *bgp best path compare*-*routerid* implementation
example? I know the function of it but looking for some scenario where
its
been used...

Thanks,
Dev




From kev.edmunds at googlemail.com  Fri Sep 25 15:30:08 2009
From: kev.edmunds at googlemail.com (Kevin Edmunds)
Date: Fri, 25 Sep 2009 21:30:08 +0100
Subject: Rapidswitch
Message-ID: 

Does anyone know whats going on over at Rapidswitch? Been having problems
getting hold of them and my servers.

Cheers,

Kev


From tim at broadlinenetworks.com  Fri Sep 25 15:36:16 2009
From: tim at broadlinenetworks.com (Tim Lampman)
Date: Fri, 25 Sep 2009 16:36:16 -0400
Subject: Rapidswitch
In-Reply-To: 
References: 
Message-ID: <4ABD29C0.8090303@broadlinenetworks.com>

They were doing some sort of a network repair yesterday and have been 
having issues since.

Kevin Edmunds wrote:
> Does anyone know whats going on over at Rapidswitch? Been having problems
> getting hold of them and my servers.
>
> Cheers,
>
> Kev
>
>   

-- 
Tim Lampman
Co-Owner/CTO
*Broadline Networks Inc.*
57 Colborne Street West, Brantford, ON, N3T 1K6
*c.* 905-746-3114
www.broadlinenetworks.com  | 
tim at broadlinenetworks.com 


From cidr-report at potaroo.net  Fri Sep 25 17:00:02 2009
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 25 Sep 2009 22:00:02 GMT
Subject: BGP Update Report
Message-ID: <200909252200.n8PM02LZ052330@wattle.apnic.net>

BGP Update Report
Interval: 19-Sep-09 -to- 24-Sep-09 (5 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS9198            58898  3.5%     155.8 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration
 2 - AS9531            20135  1.2%    4027.0 -- GEDU-AS-KR Kwangju City Office Of Education
 3 - AS4323            17532  1.0%       4.0 -- TWTC - tw telecom holdings, inc.
 4 - AS6389            17271  1.0%       4.1 -- BELLSOUTH-NET-BLK - BellSouth.net Inc.
 5 - AS17488           12276  0.7%       7.9 -- HATHWAY-NET-AP Hathway IP Over Cable Internet
 6 - AS8452             9992  0.6%      10.2 -- TEDATA TEDATA
 7 - AS20115            9922  0.6%       5.8 -- CHARTER-NET-HKY-NC - Charter Communications
 8 - AS680              8937  0.5%      33.5 -- DFN-IP service X-WiN
 9 - AS4755             8827  0.5%       7.0 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
10 - AS8151             8149  0.5%       5.5 -- Uninet S.A. de C.V.
11 - AS7018             7654  0.5%       5.1 -- ATT-INTERNET4 - AT&T WorldNet Services
12 - AS35805            7381  0.4%      17.3 -- UTG-AS United Telecom AS
13 - AS24863            7336  0.4%       7.8 -- LINKdotNET-AS
14 - AS11492            6508  0.4%       5.8 -- CABLEONE - CABLE ONE, INC.
15 - AS1785             6458  0.4%       3.7 -- AS-PAETEC-NET - PaeTec Communications, Inc.
16 - AS17974            6404  0.4%       8.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
17 - AS4766             6211  0.4%       3.3 -- KIXS-AS-KR Korea Telecom
18 - AS15706            5717  0.3%      77.3 -- Sudatel
19 - AS6478             5717  0.3%       4.0 -- ATT-INTERNET3 - AT&T WorldNet Services
20 - AS7738             5655  0.3%      13.3 -- Telecomunicacoes da Bahia S.A.


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS9531            20135  1.2%    4027.0 -- GEDU-AS-KR Kwangju City Office Of Education
 2 - AS48728            3920  0.2%     980.0 -- VODAFONEQATAR Vodafone Qatar Q.S.C.
 3 - AS43880             893  0.1%     893.0 -- LITECH-AS Laboratory of Information Technologies LLC
 4 - AS49517            1375  0.1%     687.5 -- TEIKHOS-AS Teikhos
 5 - AS33769             651  0.0%     651.0 -- IMANAFOODS
 6 - AS15145             572  0.0%     572.0 -- GLOBALSCAPE - GlobalSCAPE, Inc.
 7 - AS27667             519  0.0%     519.0 -- Universidad Autonoma de la Laguna
 8 - AS29526             380  0.0%     380.0 -- RRC-AS Saratov Regional Resource Center (RRC)
 9 - AS38857             379  0.0%     379.0 -- ESOFT-TRANSIT-AS-AP e.Soft Technologies Ltd.
10 - AS26414             327  0.0%     327.0 -- LVCINT - LVC International, LLC
11 - AS45210             278  0.0%     278.0 -- METRO-IN-AS Metro C&C
12 - AS43864             263  0.0%     263.0 -- INTEGRA-MEDIA-AS Integra-Media Ltd
13 - AS5050             4353  0.3%     256.1 -- PSC-EXT - Pittsburgh Supercomputing Center
14 - AS18163            1016  0.1%     254.0 -- JINJU18163-AS-KR jinju national university
15 - AS28478             237  0.0%     237.0 -- ESCUELA BANCARIA Y COMERCIAL SC
16 - AS41890             225  0.0%     225.0 -- PACI Public Authority for Civil Information
17 - AS2642             1088  0.1%     217.6 -- LEG-CA-GOV - State of California
18 - AS41313            4911  0.3%     213.5 -- NOVATEL-AS Novatel Bulgaria
19 - AS47640             754  0.0%     188.5 -- TRICOMPAS Tricomp Sp. z. o. o.
20 - AS30969            2855  0.2%     178.4 -- TAN-NET TransAfrica Networks


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 89.218.218.0/23    6429  0.4%   AS9198  -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration
 2 - 89.218.220.0/23    6427  0.4%   AS9198  -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration
 3 - 95.59.4.0/22       6408  0.4%   AS9198  -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration
 4 - 95.59.2.0/23       6407  0.4%   AS9198  -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration
 5 - 95.59.3.0/24       6404  0.4%   AS9198  -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration
 6 - 95.59.8.0/23       6401  0.4%   AS9198  -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration
 7 - 92.46.244.0/23     6394  0.4%   AS9198  -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration
 8 - 88.204.221.0/24    6240  0.4%   AS9198  -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration
 9 - 95.59.1.0/24       6221  0.4%   AS9198  -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration
10 - 84.1.45.0/24       4699  0.3%   AS41313 -- NOVATEL-AS Novatel Bulgaria
11 - 72.23.246.0/24     4292  0.2%   AS5050  -- PSC-EXT - Pittsburgh Supercomputing Center
12 - 210.218.64.0/19    4027  0.2%   AS9531  -- GEDU-AS-KR Kwangju City Office Of Education
13 - 211.253.68.0/22    4027  0.2%   AS9531  -- GEDU-AS-KR Kwangju City Office Of Education
14 - 211.253.72.0/21    4027  0.2%   AS9531  -- GEDU-AS-KR Kwangju City Office Of Education
15 - 210.217.224.0/19   4027  0.2%   AS9531  -- GEDU-AS-KR Kwangju City Office Of Education
16 - 210.218.0.0/18     4027  0.2%   AS9531  -- GEDU-AS-KR Kwangju City Office Of Education
17 - 192.12.120.0/24    1786  0.1%   AS5691  -- MITRE-AS-5 - The MITRE Corporation
18 - 85.60.208.0/21     1766  0.1%   AS12479 -- UNI2-AS Uni2 Autonomous System
19 - 85.60.208.0/22     1668  0.1%   AS12479 -- UNI2-AS Uni2 Autonomous System
20 - 203.129.254.0/24   1325  0.1%   AS7633  -- SOFTNET-AS-AP Software Technology Parks of India - Bangalore

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 Sep 25 17:00:00 2009
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 25 Sep 2009 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <200909252200.n8PM00X0052298@wattle.apnic.net>

This report has been generated at Fri Sep 25 21:16:17 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
        18-09-09    303315      181866
        19-09-09    303692      183272
        20-09-09    303702      183711
        21-09-09    303761      184153
        22-09-09    304027      184231
        23-09-09    304022      183800
        24-09-09    304040      183745
        25-09-09    304228      184066


AS Summary
         32427  Number of ASes in routing system
         13800  Number of ASes announcing only one prefix
          4315  Largest number of prefixes announced by an AS
                AS4323 : TWTC - tw telecom holdings, inc.
      89622016  Largest address span announced by an AS (/32s)
                AS27064: DNIC-ASBLK-27032-27159 - DoD Network Information Center


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 25Sep09 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     304541   184083   120458    39.6%   All ASes

AS6389      4164      324     3840    92.2%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS4323      4315     1623     2692    62.4%   TWTC - tw telecom holdings,
                                               inc.
AS4766      1877      577     1300    69.3%   KIXS-AS-KR Korea Telecom
AS17488     1505      278     1227    81.5%   HATHWAY-NET-AP Hathway IP Over
                                               Cable Internet
AS18566     1062       10     1052    99.1%   COVAD - Covad Communications
                                               Co.
AS22773     1109       71     1038    93.6%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS1785      1751      839      912    52.1%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS8151      1480      575      905    61.1%   Uninet S.A. de C.V.
AS18101      976       75      901    92.3%   RIL-IDC Reliance Infocom Ltd
                                               Internet Data Centre,
AS4755      1260      389      871    69.1%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS10620     1015      149      866    85.3%   TV Cable S.A.
AS19262     1043      235      808    77.5%   VZGNI-TRANSIT - Verizon
                                               Internet Services Inc.
AS6478      1412      653      759    53.8%   ATT-INTERNET3 - AT&T WorldNet
                                               Services
AS8452       954      231      723    75.8%   TEDATA TEDATA
AS3356      1236      514      722    58.4%   LEVEL3 Level 3 Communications
AS4808       788      188      600    76.1%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS4804       680       90      590    86.8%   MPX-AS Microplex PTY LTD
AS24560      773      210      563    72.8%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS7303       641       96      545    85.0%   Telecom Argentina S.A.
AS9498       646      102      544    84.2%   BBIL-AP BHARTI Airtel Ltd.
AS11492     1128      585      543    48.1%   CABLEONE - CABLE ONE, INC.
AS22047      544       17      527    96.9%   VTR BANDA ANCHA S.A.
AS4134      1009      488      521    51.6%   CHINANET-BACKBONE
                                               No.31,Jin-rong Street
AS7018      1508     1056      452    30.0%   ATT-INTERNET4 - AT&T WorldNet
                                               Services
AS17676      564      125      439    77.8%   GIGAINFRA Softbank BB Corp.
AS17908      496       58      438    88.3%   TCISL Tata Communications
AS5668       799      373      426    53.3%   AS-5668 - CenturyTel Internet
                                               Holdings, Inc.
AS4780       563      143      420    74.6%   SEEDNET Digital United Inc.
AS855        622      210      412    66.2%   CANET-ASN-4 - Bell Aliant
                                               Regional Communications, Inc.
AS7011      1017      611      406    39.9%   FRONTIER-AND-CITIZENS -
                                               Frontier Communications of
                                               America, Inc.

Total      36937    10895    26042    70.5%   Top 30 total


Possible Bogus Routes

        24.245.128.0/17      AS11492 CABLEONE - CABLE ONE, INC.
        41.223.92.0/22       AS36936 CELTEL-GABON Celtel Gabon Internet Service
        41.223.189.0/24      AS26452 BRING-AS - BringCom, Inc.
        43.245.0.0/16        AS7502  IP-KYOTO Internetwork Kyoto
        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
        64.72.112.0/20       AS19166 
        64.89.128.0/20       AS10397 SINGLEPIPE - SinglePipe Communications, Inc.
        66.6.80.0/20         AS23350 
        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
        68.234.16.0/20       AS40430 COLO4JAX-AS - colo4jax, 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 
        74.120.160.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.161.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.162.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.163.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.164.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.165.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.166.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.167.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.168.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.169.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.170.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.171.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.172.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.173.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.174.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        74.120.175.0/24      AS19262 VZGNI-TRANSIT - Verizon Internet Services Inc.
        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 
        96.8.127.0/24        AS19166 
        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
        122.128.120.0/22     AS38456 PACTEL-AS-AP Pacific Teleports. 
        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.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.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.
        195.225.58.0/24      AS6714  ATOMNET ATOM SA
        196.6.108.0/24       AS5713  SAIX-NET
        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.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.0.0/21       AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center
        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.134.0/24     AS3541  ITSDN-U4 - 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.84.10.0/23       AS9308  CHINA-ABITCOOL Abitcool(China) Inc.
        202.86.252.0/22      AS4748  RESOLINK-AS-AP Resources Link Network Limited
        202.86.252.0/24      AS9304  HUTCHISON-AS-AP Hutchison Global Communications
        202.86.253.0/24      AS9304  HUTCHISON-AS-AP Hutchison Global Communications
        202.86.254.0/24      AS9304  HUTCHISON-AS-AP Hutchison Global Communications
        202.86.255.0/24      AS9304  HUTCHISON-AS-AP Hutchison Global Communications
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.94.70.0/24       AS2764  AAPT AAPT Limited
        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.160.0/24     AS4841  
        202.140.162.0/24     AS4841  
        202.140.168.0/24     AS4841  
        202.140.170.0/24     AS4841  
        202.140.171.0/24     AS4841  
        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.150.227.0/24     AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa
        202.174.70.0/24      AS21175 M-LINK Wind International Services SA  (previously known as M-LINK)
        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.34.37.0/24       AS38818 
        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.89.139.0/24      AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd.
        203.112.111.0/24     AS7474  OPTUSCOM-AS01-AU SingTel Optus Pty Ltd
        203.112.113.0/24     AS7474  OPTUSCOM-AS01-AU SingTel Optus Pty Ltd
        203.112.114.0/24     AS4802  ASN-IINET iiNet Limited
        203.112.116.0/24     AS7474  OPTUSCOM-AS01-AU SingTel Optus Pty Ltd
        203.112.117.0/24     AS7474  OPTUSCOM-AS01-AU SingTel Optus Pty Ltd
        203.112.118.0/24     AS7474  OPTUSCOM-AS01-AU SingTel Optus Pty Ltd
        203.112.119.0/24     AS7474  OPTUSCOM-AS01-AU SingTel Optus Pty Ltd
        203.112.120.0/24     AS7474  OPTUSCOM-AS01-AU SingTel Optus Pty Ltd
        203.112.121.0/24     AS7474  OPTUSCOM-AS01-AU SingTel Optus Pty Ltd
        203.112.127.0/24     AS7474  OPTUSCOM-AS01-AU SingTel Optus Pty Ltd
        203.128.128.0/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.19.14.0/23       AS577   BACOM - Bell Canada
        204.89.214.0/24      AS4323  TWTC - tw telecom holdings, inc.
        204.138.167.0/24     AS18990 AIRBAND-DALLAS - Airband Communications, 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.217.224.0/19     AS6130  AIS-WEST - American Internet Services, LLC.
        209.222.5.0/24       AS26699 PSI-CT - Printing For Systems Inc
        210.5.128.0/20       AS4837  CHINA169-BACKBONE CNCGROUP China169 Backbone
        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.24.192.0/20      AS10397 SINGLEPIPE - SinglePipe Communications, 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
        217.78.71.0/24       AS12491 IPPLANET-AS Gilat Satcom
        217.78.72.0/24       AS12491 IPPLANET-AS Gilat Satcom
        217.78.73.0/24       AS12491 IPPLANET-AS Gilat Satcom


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 mpetach at netflight.com  Fri Sep 25 17:40:19 2009
From: mpetach at netflight.com (Matthew Petach)
Date: Fri, 25 Sep 2009 15:40:19 -0700
Subject: Gmail Down?
In-Reply-To: <20090924162237.GF29709@earth.coinet.com>
References: <4ABB8B57.3020600@uplogon.com> <4ABB8CC5.5080204@deaddrop.org>
	<7db2dcf90909240821vbaac138qf13a345103b1d74c@mail.gmail.com>
	<4ABB93E7.1020702@pobox.com>
	<63ac96a50909240900o51199dbbn3dbf6de54cfc5d37@mail.gmail.com>
	<20090924162237.GF29709@earth.coinet.com>
Message-ID: <63ac96a50909251540j46254291mf6c9ec01fcbc3cdf@mail.gmail.com>

On Thu, Sep 24, 2009 at 9:22 AM, Aaron L. Meehan  wrote:

> On Thu, Sep 24, 2009 at 09:00:13AM -0700, Matthew Petach wrote:
> > Thank goodness my Yahoo email account is still working.  Don't we have
> > enough
> > conversations here about diversity and redundancy at the network layer
> for
> > people
> > to realize it's good to have similar diversity and redundancy at the
> > application layer
> > as well?  (yes, I have accounts on both systems, and use them both
> actively)
>
> And what a splendid job your webmail does of formatting your text!
> Why, that's beautiful.
>
> Who bloody cares if gmail's contacts aren't working, anyway?
>

*heh*  I'll be sure to pass that feedback
along to the gmail developers the next
time I see them.  :P

(I never said which provider I used for
that particular message--but since you
don't like gmail's default wraplength,
just for you I'm wrapping this one at
40 characters, just to be safe--that way
it should still fit cleanly on the screen
for those of you still using CGA displays).

Matt


From raapidtechnical at gmail.com  Sat Sep 26 02:35:03 2009
From: raapidtechnical at gmail.com (RAAPID Technical)
Date: Sat, 26 Sep 2009 02:35:03 -0500
Subject: Hurricane Electric, Fremont-2 down?
Message-ID: <7bfcb0350909260035w4382c226p4da7dd6dfc930a3f@mail.gmail.com>

Hi all,
Looks like HE.net's core router and/or power at Fremont-2 is down, affecting
me and many others. No response from them by email, phone.

$ ping core1.fmt2.he.net
PING core1.fmt2.he.net (216.218.252.162): 56 data bytes
^C
--- core1.fmt2.he.net ping statistics ---
896 packets transmitted, 0 packets received, 100% packet loss

$ traceroute core1.fmt2.he.net
traceroute to core1.fmt2.he.net (216.218.252.162), 64 hops max, 40 byte
packets

10  pos1-2.gsr12416.ash.he.net (66.160.128.117)  36.484 ms  36.015 ms
 36.333 ms
11  10gigabitethernet2-1.core1.ash1.he.net (72.52.92.5)  40.787 ms  36.492
ms  36.835 ms
12  * * *
13  * * *


From raapidtechnical at gmail.com  Sat Sep 26 02:59:53 2009
From: raapidtechnical at gmail.com (RAAPID Technical)
Date: Sat, 26 Sep 2009 02:59:53 -0500
Subject: Hurricane Electric, Fremont-2 down?
In-Reply-To: <7bfcb0350909260035w4382c226p4da7dd6dfc930a3f@mail.gmail.com>
References: <7bfcb0350909260035w4382c226p4da7dd6dfc930a3f@mail.gmail.com>
Message-ID: <7bfcb0350909260059g743dd783ndfcb678062f7a8c5@mail.gmail.com>

Confirmed total power outage at Fremont-2 building:
http://www.webhostingtalk.com/showthread.php?t=695888

On Sat, Sep 26, 2009 at 2:35 AM, RAAPID Technical  wrote:

> Hi all,
> Looks like HE.net's core router and/or power at Fremont-2 is down,
> affecting me and many others. No response from them by email, phone.
>
> $ ping core1.fmt2.he.net
> PING core1.fmt2.he.net (216.218.252.162): 56 data bytes
> ^C
> --- core1.fmt2.he.net ping statistics ---
> 896 packets transmitted, 0 packets received, 100% packet loss
>
> $ traceroute core1.fmt2.he.net
> traceroute to core1.fmt2.he.net (216.218.252.162), 64 hops max, 40 byte
> packets
>
> 10  pos1-2.gsr12416.ash.he.net (66.160.128.117)  36.484 ms  36.015 ms
>  36.333 ms
> 11  10gigabitethernet2-1.core1.ash1.he.net (72.52.92.5)  40.787 ms  36.492
> ms  36.835 ms
> 12  * * *
> 13  * * *
>


From nenolod at systeminplace.net  Sat Sep 26 03:12:43 2009
From: nenolod at systeminplace.net (William Pitcock)
Date: Sat, 26 Sep 2009 03:12:43 -0500
Subject: Hurricane Electric, Fremont-2 down?
In-Reply-To: <7bfcb0350909260059g743dd783ndfcb678062f7a8c5@mail.gmail.com>
References: <7bfcb0350909260035w4382c226p4da7dd6dfc930a3f@mail.gmail.com>
	<7bfcb0350909260059g743dd783ndfcb678062f7a8c5@mail.gmail.com>
Message-ID: <1253952763.31140.115.camel@petrie>

On Sat, 2009-09-26 at 02:59 -0500, RAAPID Technical wrote:
> Confirmed total power outage at Fremont-2 building:
> http://www.webhostingtalk.com/showthread.php?t=695888

That is from 2008...

William





From stef-list at memberwebs.com  Sat Sep 26 03:15:53 2009
From: stef-list at memberwebs.com (Stef Walter)
Date: Sat, 26 Sep 2009 03:15:53 -0500
Subject: Hurricane Electric, Fremont-2 down?
In-Reply-To: <7bfcb0350909260059g743dd783ndfcb678062f7a8c5@mail.gmail.com>
References: <7bfcb0350909260035w4382c226p4da7dd6dfc930a3f@mail.gmail.com>
	<7bfcb0350909260059g743dd783ndfcb678062f7a8c5@mail.gmail.com>
Message-ID: <4ABDCDB9.30004@memberwebs.com>

RAAPID Technical wrote:
> Confirmed total power outage at Fremont-2 building:
> http://www.webhostingtalk.com/showthread.php?t=695888

Back up now.

Cheers,

Stef




From scott at doc.net.au  Sat Sep 26 03:17:01 2009
From: scott at doc.net.au (Scott Howard)
Date: Sat, 26 Sep 2009 01:17:01 -0700
Subject: Hurricane Electric, Fremont-2 down?
In-Reply-To: <7bfcb0350909260035w4382c226p4da7dd6dfc930a3f@mail.gmail.com>
References: <7bfcb0350909260035w4382c226p4da7dd6dfc930a3f@mail.gmail.com>
Message-ID: 

Just came back up!

  Scott



On Sat, Sep 26, 2009 at 12:35 AM, RAAPID Technical <
raapidtechnical at gmail.com> wrote:

> Hi all,
> Looks like HE.net's core router and/or power at Fremont-2 is down,
> affecting
> me and many others. No response from them by email, phone.
>
> $ ping core1.fmt2.he.net
> PING core1.fmt2.he.net (216.218.252.162): 56 data bytes
> ^C
> --- core1.fmt2.he.net ping statistics ---
> 896 packets transmitted, 0 packets received, 100% packet loss
>
> $ traceroute core1.fmt2.he.net
> traceroute to core1.fmt2.he.net (216.218.252.162), 64 hops max, 40 byte
> packets
>
> 10  pos1-2.gsr12416.ash.he.net (66.160.128.117)  36.484 ms  36.015 ms
>  36.333 ms
> 11  10gigabitethernet2-1.core1.ash1.he.net (72.52.92.5)  40.787 ms  36.492
> ms  36.835 ms
> 12  * * *
> 13  * * *
>


From scott at doc.net.au  Sat Sep 26 03:19:58 2009
From: scott at doc.net.au (Scott Howard)
Date: Sat, 26 Sep 2009 01:19:58 -0700
Subject: Hurricane Electric, Fremont-2 down?
In-Reply-To: <4ABDCDB9.30004@memberwebs.com>
References: <7bfcb0350909260035w4382c226p4da7dd6dfc930a3f@mail.gmail.com>
	<7bfcb0350909260059g743dd783ndfcb678062f7a8c5@mail.gmail.com>
	<4ABDCDB9.30004@memberwebs.com>
Message-ID: 

Looks like it was power...

 01:19:20 up 3 min,  1 user,  load average: 1.34, 1.16, 0.51

  Scott.


On Sat, Sep 26, 2009 at 1:15 AM, Stef Walter wrote:

> RAAPID Technical wrote:
> > Confirmed total power outage at Fremont-2 building:
> > http://www.webhostingtalk.com/showthread.php?t=695888
>
> Back up now.
>
> Cheers,
>
> Stef
>
>
>


From mike at m5computersecurity.com  Sat Sep 26 03:22:30 2009
From: mike at m5computersecurity.com (Michael J McCafferty)
Date: Sat, 26 Sep 2009 01:22:30 -0700
Subject: Hurricane Electric, Fremont-2 down?
In-Reply-To: <1253952763.31140.115.camel@petrie>
References: <7bfcb0350909260035w4382c226p4da7dd6dfc930a3f@mail.gmail.com>
	<7bfcb0350909260059g743dd783ndfcb678062f7a8c5@mail.gmail.com>
	<1253952763.31140.115.camel@petrie>
Message-ID: <1253953351.6803.717.camel@mike-desktop>

On Sat, 2009-09-26 at 03:12 -0500, William Pitcock wrote:
> On Sat, 2009-09-26 at 02:59 -0500, RAAPID Technical wrote:
> > Confirmed total power outage at Fremont-2 building:
> > http://www.webhostingtalk.com/showthread.php?t=695888
> 
> That is from 2008...
> 
> William
> 

Try this thread instead:
http://www.webhostingtalk.com/showthread.php?t=892778 
Not much info, but it's from today (never mind the thread name)

Mike

-- 
************************************************************
Michael J. McCafferty
Principal
M5 Hosting
http://www.m5hosting.com
************************************************************




From peter at peter-dambier.de  Sun Sep 27 15:47:44 2009
From: peter at peter-dambier.de (Peter Dambier)
Date: Sun, 27 Sep 2009 22:47:44 +0200
Subject: [funsec] Bluehost kicks german Pirates Party
Message-ID: <4ABFCF70.6060303@peter-dambier.de>

I know, it was no good idea in the first place to host a site about
the german elections overseas. Living overseas it is difficult to
say what is a slashdot and what a script :)

   Domain Name: NORDPIRATEN.NET
   Registrar: FASTDOMAIN, INC.
   Whois Server: whois.fastdomain.com
   Referral URL: http://www.fastdomain.com
   Name Server: NS1.BLUEHOST.COM
   Name Server: NS2.BLUEHOST.COM
   Status: clientTransferProhibited
   Updated Date: 14-apr-2009
   Creation Date: 06-jun-2007
   Expiration Date: 06-jun-2010

>>> Last update of whois database: Sun, 27 Sep 2009 18:42:08 UTC <<<

No need to hurry. The results are in the press already.

Good night
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 peter at peter-dambier.de  Mon Sep 28 04:37:10 2009
From: peter at peter-dambier.de (Peter Dambier)
Date: Mon, 28 Sep 2009 11:37:10 +0200
Subject: Thankyou: [funsec] Bluehost kicks german Pirates Party
In-Reply-To: 
References: <4ABFCF70.6060303@peter-dambier.de>
	
Message-ID: <4AC083C6.2040703@peter-dambier.de>

They have come back early in the morning (4:00 UTC or 6 localtime) probably much earlier.

It is not Bluehosts fault after all, I guess.

Choosing a virtual host for a site that was known to slashdot during the elections
was not a bright idea.

I don't think we warned Bluehost in advance about the elections.

It rarely happens that the boys running a party and the boys who are running
the computers are the same. But when it happens - be prepared for the worst :)

Kind regards and a big THANKYOU to everybody.

Sorry, sent this to the wrong address first.

Peter



> 
> -----Original Message-----
> From: Peter Dambier [mailto:peter at peter-dambier.de] 
> Sent: Sunday, September 27, 2009 1:48 PM
> To: NANOG
> Subject: [funsec] Bluehost kicks german Pirates Party
> 
> I know, it was no good idea in the first place to host a site about
> the german elections overseas. Living overseas it is difficult to
> say what is a slashdot and what a script :)
> 
>    Domain Name: NORDPIRATEN.NET
>    Registrar: FASTDOMAIN, INC.
>    Whois Server: whois.fastdomain.com
>    Referral URL: http://www.fastdomain.com
>    Name Server: NS1.BLUEHOST.COM
>    Name Server: NS2.BLUEHOST.COM
>    Status: clientTransferProhibited
>    Updated Date: 14-apr-2009
>    Creation Date: 06-jun-2007
>    Expiration Date: 06-jun-2010
> 
>>>> Last update of whois database: Sun, 27 Sep 2009 18:42:08 UTC <<<
> 
> No need to hurry. The results are in the press already.
> 
> Good night
> 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 source_route at yahoo.com  Mon Sep 28 12:35:17 2009
From: source_route at yahoo.com (Philip Lavine)
Date: Mon, 28 Sep 2009 10:35:17 -0700 (PDT)
Subject: Reliance globalcom issues in NYC/NJ?
Message-ID: <45959.38757.qm@web30803.mail.mud.yahoo.com>





      



From mhuff at ox.com  Mon Sep 28 13:14:39 2009
From: mhuff at ox.com (Matthew Huff)
Date: Mon, 28 Sep 2009 14:14:39 -0400
Subject: Reliance globalcom issues in NYC/NJ?
In-Reply-To: <45959.38757.qm@web30803.mail.mud.yahoo.com>
References: <45959.38757.qm@web30803.mail.mud.yahoo.com>
Message-ID: <483E6B0272B0284BA86D7596C40D29F9D7738E68D8@PUR-EXCH07.ox.com>

Yeah, we got hit hard too.

It's back up, but no RFO yet. NOC was overloaded and not answering.



----
Matthew Huff?????? | One Manhattanville Rd
OTA Management LLC | Purchase, NY 10577
http://www.ox.com  | Phone: 914-460-4039
aim: matthewbhuff? | Fax:?? 914-460-4139



> -----Original Message-----
> From: Philip Lavine [mailto:source_route at yahoo.com]
> Sent: Monday, September 28, 2009 1:35 PM
> To: nanog
> Subject: Reliance globalcom issues in NYC/NJ?
> 
> 
> 
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Matthew Huff.vcf
Type: application/octet-stream
Size: 1595 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4229 bytes
Desc: not available
URL: 

From bburke at merit.edu  Mon Sep 28 13:53:44 2009
From: bburke at merit.edu (Betty Burke)
Date: Mon, 28 Sep 2009 14:53:44 -0400 (EDT)
Subject: First Draft of NANOG47 Survey
In-Reply-To: <403434961.3143611254164020982.JavaMail.root@crono>
Message-ID: <1367429095.3143631254164024891.JavaMail.root@crono>


Hi Everyone:

First Draft of NANOG47 survey attached.

Quick blush
Removed question regarding Keynote presentation
Added question from MLC
Have not added any question about Wed am.

Let me know your thoughts suggestions, changes, additions etc....

I need to have in final form no later than October 9.

All best.
Betty

Merit Network Inc.
NANOG Community Project Manager
(734) 527-5763 Office
(734) 395-1724 Cell



From dmm at 1-4-5.net  Mon Sep 28 15:30:43 2009
From: dmm at 1-4-5.net (David Meyer)
Date: Mon, 28 Sep 2009 13:30:43 -0700
Subject: In the event you had a lightning talk rejected for NANOG 47
Message-ID: <20090928203043.GA2366@1-4-5.net>

	Folks,

	We found a bug in our submission tool that was rejecting
	lightning talk submissions with a "Lightning talks closed"
	error message. We believe we have it fixed now. In the event
	you were erroneously rejected, please resubmit your
	lightning talk for NANOG 47. 

	Thanks, and look forward to seeing you all in Dearborn.

	Dave

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: 

From Skeeve at eintellego.net  Tue Sep 29 04:51:04 2009
From: Skeeve at eintellego.net (Skeeve Stevens)
Date: Tue, 29 Sep 2009 19:51:04 +1000
Subject: Bell Canada - Old Bogon maybe - NOC contact
Message-ID: <292AF25E62B8894C921B893B53A19D973957E7F670@BUSINESSEX.business.ad>

Hey guys,

Could someone from Bell Canada who can deal with an old Bogon issue please contact me off list.

It is re: 180.x.x.x

...Skeeve

--
Skeeve Stevens, CEO/Technical Director
eintellego Pty Ltd - The Networking Specialists
skeeve at eintellego.net / www.eintellego.net
Phone: 1300 753 383, Fax: (+612) 8572 9954
Cell +61 (0)414 753 383 / skype://skeeve
www.linkedin.com/in/skeeve ; facebook.com/eintellego
--
NOC, NOC, who's there?

Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks.  Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments are virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced.



From randy at psg.com  Tue Sep 29 05:15:30 2009
From: randy at psg.com (Randy Bush)
Date: Tue, 29 Sep 2009 19:15:30 +0900
Subject: Bell Canada - Old Bogon maybe - NOC contact
In-Reply-To: <292AF25E62B8894C921B893B53A19D973957E7F670@BUSINESSEX.business.ad>
References: <292AF25E62B8894C921B893B53A19D973957E7F670@BUSINESSEX.business.ad>
Message-ID: 

> Hey guys,
> 
> Could someone from Bell Canada who can deal with an old Bogon issue please contact me off list.
> 
> It is re: 180.x.x.x
> 
> ...Skeeve
> 
> --
> Skeeve Stevens, CEO/Technical Director
> eintellego Pty Ltd - The Networking Specialists
> skeeve at eintellego.net / www.eintellego.net
> Phone: 1300 753 383, Fax: (+612) 8572 9954
> Cell +61 (0)414 753 383 / skype://skeeve
> www.linkedin.com/in/skeeve ; facebook.com/eintellego
> --
> NOC, NOC, who's there?
> 
> Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks.  Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments ar
 e virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced.

obviously lawers are there.  which is fine.  but they should not be
here.

randy



From owen at delong.com  Tue Sep 29 17:30:36 2009
From: owen at delong.com (Owen DeLong)
Date: Tue, 29 Sep 2009 15:30:36 -0700
Subject: Dearborn: Calling all CAcert and/or Thawte Notaries
Message-ID: <4F7EBD6A-477A-4DCA-817E-9D8EEE5F1BDA@delong.com>

It occurs to me that in addition to the PGP key signings that tend to  
happen at NANOG
meetings it might be worth having a group notary event for CAcert and/ 
or Thawte
notarizations.

I'm currently a 10 point notary with Thawte and hope to be a CAcert  
notary before
the Dearborn meeting.

I suspect there are other notaries on the list attending the meeting.   
If you're a notary
and will be attending the meeting, please contact me off list if you'd  
be interested/willing
to participate in a notary get together.

If there's enough support to make it feasible, I'll try to put  
together a way we can
do it. (Perhaps we can take a corner of the PGP key signing or such).

If you're looking to get notarized, here's what you will need to bring:


Thawte:
	1.	Your original IDs. One has to be the ID you provided the Thawte
		web site. Two IDs are ideal.  At least one of the IDs must be
		government issue and must have your picture. (It helps if you look
		like the picture, too).

	2.	Photocopies of your IDs (one for each notary that will provide
		an on-line assurance of your ID).


CAcert:
	1.	Print out one copy of the pre-filled out assurance form from the
		CAcert web site for each notary.

	2.	Bring your original ID(s).  One government issued ID is required.
		Additional ID is also preferred.

If there is enough interest from notaries, I will post back to the  
list when
I get arrangements made.

Owen




From Valdis.Kletnieks at vt.edu  Tue Sep 29 17:46:52 2009
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 29 Sep 2009 18:46:52 -0400
Subject: Dearborn: Calling all CAcert and/or Thawte Notaries
In-Reply-To: Your message of "Tue, 29 Sep 2009 15:30:36 PDT."
	<4F7EBD6A-477A-4DCA-817E-9D8EEE5F1BDA@delong.com>
References: <4F7EBD6A-477A-4DCA-817E-9D8EEE5F1BDA@delong.com>
Message-ID: <23972.1254264412@turing-police.cc.vt.edu>

On Tue, 29 Sep 2009 15:30:36 PDT, Owen DeLong said:
> It occurs to me that in addition to the PGP key signings that tend to  
> happen at NANOG
> meetings it might be worth having a group notary event for CAcert and/ 
> or Thawte
> notarizations.

Umm.. aren't the Thawte web-of-trust going belly-up in a few months?

https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=SO12658

But yes, CAcert may be a good idea.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: 

From rs at seastrom.com  Tue Sep 29 20:22:03 2009
From: rs at seastrom.com (Robert E. Seastrom)
Date: Tue, 29 Sep 2009 21:22:03 -0400
Subject: SMS
In-Reply-To: <3c3e3fca0909220929w7b4ea46bvcd21f10efc897122@mail.gmail.com>
	(William Herrin's message of "Tue, 22 Sep 2009 12:29:13 -0400")
References: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>
	<067601ca3b98$0fd53820$2f7fa860$@com>
	
	<4AB8F2D6.90107@evaristesys.com> <004401ca3b9d$b80ca0a0$2825e1e0$@net>
	<3c3e3fca0909220929w7b4ea46bvcd21f10efc897122@mail.gmail.com>
Message-ID: <86zl8d5iro.fsf@seastrom.com>


William Herrin  writes:

> The Multitech Multimodem GPRS model MTCBA-G-EN-F4 has an ethernet
> port. Add a SIM card from your favorite wireless carrier and you can
> send and receive SMS messages via "AT" commands over a TCP socket.
> Problem is, it seizes up or otherwise founders every few weeks and has
> to be power cycled.
>
> Has anyone heard of other products with a good reliability record?

Sorry to be late to add to the hate, but the MacOSX drivers for the
USB flavor (MTCBA-G-U-F4) have issues.  Finally got it running on a
standalone Intel mini that we use just for text messages.  :-P

-r




From AOsgood at Streamline-Solutions.net  Wed Sep 30 19:24:50 2009
From: AOsgood at Streamline-Solutions.net (Aaron D. Osgood)
Date: Wed, 30 Sep 2009 20:24:50 -0400
Subject: SMS
In-Reply-To: <86zl8d5iro.fsf@seastrom.com>
References: <7EF30F70B022EF45A36F59FEB1D91217037E97010A@SERVER.smallbiz.local>	<067601ca3b98$0fd53820$2f7fa860$@com>		<4AB8F2D6.90107@evaristesys.com>
	<004401ca3b9d$b80ca0a0$2825e1e0$@net>	<3c3e3fca0909220929w7b4ea46bvcd21f10efc897122@mail.gmail.com>
	<86zl8d5iro.fsf@seastrom.com>
Message-ID: <00a801ca422d$988e3ae0$c9aab0a0$@net>

We have created a workaround to that issue with our package when used with
the MultiTech line of modems (ALL flavors - GSM and CDMA - USB, Serial, or
Ethernet)

Aaron D. Osgood

Streamline Solutions L.L.C

P.O. Box 6115
Falmouth, ME 04105 

TEL: 207-781-5561
FAX: 615-704-8067
MOBILE: 207-831-5829
AOsgood at Streamline-Solutions.net
http://www.streamline-solutions.net

Introducing Efficiency to Business since 1986.

-----Original Message-----
From: Robert E. Seastrom [mailto:rs at seastrom.com] 
Sent: Tuesday, September 29, 2009 9:22 PM
To: William Herrin
Cc: nanog at nanog.org
Subject: Re: SMS


William Herrin  writes:

> The Multitech Multimodem GPRS model MTCBA-G-EN-F4 has an ethernet
> port. Add a SIM card from your favorite wireless carrier and you can
> send and receive SMS messages via "AT" commands over a TCP socket.
> Problem is, it seizes up or otherwise founders every few weeks and has
> to be power cycled.
>
> Has anyone heard of other products with a good reliability record?

Sorry to be late to add to the hate, but the MacOSX drivers for the
USB flavor (MTCBA-G-U-F4) have issues.  Finally got it running on a
standalone Intel mini that we use just for text messages.  :-P

-r