From fw at deneb.enyo.de Wed Jan 1 00:02:04 2014 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 01 Jan 2014 01:02:04 +0100 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: (Warren Bailey's message of "Tue, 31 Dec 2013 23:04:00 +0000") References: <877gak27az.fsf@mid.deneb.enyo.de> Message-ID: <871u0swow3.fsf@mid.deneb.enyo.de> * Warren Bailey: > Explaining, not a denial written by their legal department. I find it > insanely difficult to believe cisco systems has a backdoor into some of > their product lines with no knowledge or participation. As far as I understand it, these are firmware tweaks or implants sitting on a privileged bus (think PCI with busmaster DMA). Such things can be added after the device has left the factory by a sufficiently knowledgeable third party. From fergdawgster at mykolab.com Wed Jan 1 00:10:45 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Tue, 31 Dec 2013 16:10:45 -0800 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <871u0swow3.fsf@mid.deneb.enyo.de> References: <877gak27az.fsf@mid.deneb.enyo.de> <871u0swow3.fsf@mid.deneb.enyo.de> Message-ID: <52C35D05.7080303@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/31/2013 4:02 PM, Florian Weimer wrote: > * Warren Bailey: > >> Explaining, not a denial written by their legal department. I find it >> insanely difficult to believe cisco systems has a backdoor into some of >> their product lines with no knowledge or participation. > > As far as I understand it, these are firmware tweaks or implants > sitting on a privileged bus (think PCI with busmaster DMA). Such > things can be added after the device has left the factory by a > sufficiently knowledgeable third party. > That's really interesting. Where are these Cisco devices manufactured? - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 10.2.0 (Build 2317) Charset: utf-8 wj8DBQFSw1z/q1pz9mNUZTMRAvbIAKCYZn3slg1wMak/nlc/hb3ZHkS29wCg3ucb OJTl+SLgBtQDMGi+cTdDRtQ= =VAdw -----END PGP SIGNATURE----- -- Paul Ferguson PGP Public Key ID: 0x63546533 From mpalmer at hezmatt.org Wed Jan 1 00:34:01 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Wed, 1 Jan 2014 11:34:01 +1100 Subject: Juniper SSL VPN In-Reply-To: <8543.1388524764@turing-police.cc.vt.edu> References: <20131231.144546.74654601.sthaug@nethelp.no> <20131231143229.GA6690@pob.ytti.fi> <247429C70AB9D948A4DDECDFA5C23390DB6AB675@DDCEP50018.na.corp.mckesson.com> <252643.1388511107@turing-police.cc.vt.edu> <8543.1388524764@turing-police.cc.vt.edu> Message-ID: <20140101003353.GC497@hezmatt.org> On Tue, Dec 31, 2013 at 04:19:24PM -0500, Valdis.Kletnieks at vt.edu wrote: > On Tue, 31 Dec 2013 23:09:58 +0200, Eugeniu Patrascu said: > > > > We need an emergency fix because a piece of software unexpectedly hit > > > an end-of-life date? Didn't we learn anything 14 years ago??!? > > > > > > > > Juniper just posted a technical note saying the issue is fixed and a new > > ESAP package is out. > > Right. The question is why it's coming out on the last day of December, > rather than the last day of November, or even October... To punish you for having the gall to think you could celebrate the new year like a normal human being, instead of doing what you *should* be doing, tending to the machines. (At the risk of crossing the streams, I'll observe that I've not spent a new year's eve or day patching my Linux-based VPN servers...) - Matt -- "You keep using that word. I do not think it means what you think it means." -- Inigo, The Princess Bride From eugen at imacandi.net Wed Jan 1 00:45:59 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Wed, 1 Jan 2014 02:45:59 +0200 Subject: Juniper SSL VPN In-Reply-To: <8543.1388524764@turing-police.cc.vt.edu> References: <20131231.144546.74654601.sthaug@nethelp.no> <20131231143229.GA6690@pob.ytti.fi> <247429C70AB9D948A4DDECDFA5C23390DB6AB675@DDCEP50018.na.corp.mckesson.com> <252643.1388511107@turing-police.cc.vt.edu> <8543.1388524764@turing-police.cc.vt.edu> Message-ID: On Tue, Dec 31, 2013 at 11:19 PM, wrote: > On Tue, 31 Dec 2013 23:09:58 +0200, Eugeniu Patrascu said: > > > > We need an emergency fix because a piece of software unexpectedly hit > > > an end-of-life date? Didn't we learn anything 14 years ago??!? > > > > > > > > Juniper just posted a technical note saying the issue is fixed and a new > > ESAP package is out. > > Right. The question is why it's coming out on the last day of December, > rather than the last day of November, or even October... > >From what I understood from the tech note, they had no clue this would happen on the 31st of December :) From christopher.morrow at gmail.com Wed Jan 1 01:55:00 2014 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Tue, 31 Dec 2013 20:55:00 -0500 Subject: Juniper SSL VPN In-Reply-To: References: <20131231.144546.74654601.sthaug@nethelp.no> <20131231143229.GA6690@pob.ytti.fi> <247429C70AB9D948A4DDECDFA5C23390DB6AB675@DDCEP50018.na.corp.mckesson.com> <252643.1388511107@turing-police.cc.vt.edu> <8543.1388524764@turing-police.cc.vt.edu> Message-ID: Had no clue? Didn't they build it? On Dec 31, 2013 7:46 PM, "Eugeniu Patrascu" wrote: > On Tue, Dec 31, 2013 at 11:19 PM, wrote: > > > On Tue, 31 Dec 2013 23:09:58 +0200, Eugeniu Patrascu said: > > > > > > We need an emergency fix because a piece of software unexpectedly hit > > > > an end-of-life date? Didn't we learn anything 14 years ago??!? > > > > > > > > > > > Juniper just posted a technical note saying the issue is fixed and a > new > > > ESAP package is out. > > > > Right. The question is why it's coming out on the last day of December, > > rather than the last day of November, or even October... > > > > From what I understood from the tech note, they had no clue this would > happen on the 31st of December :) > From j at arpa.com Wed Jan 1 05:38:22 2014 From: j at arpa.com (jamie rishaw) Date: Tue, 31 Dec 2013 23:38:22 -0600 Subject: First! [?] Message-ID: Happy New Year to all, and to all a good lawful interception. From hank at efes.iucc.ac.il Wed Jan 1 05:42:05 2014 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 01 Jan 2014 07:42:05 +0200 Subject: Juniper SSL VPN In-Reply-To: References: <20131231.144546.74654601.sthaug@nethelp.no> <20131231143229.GA6690@pob.ytti.fi> <247429C70AB9D948A4DDECDFA5C23390DB6AB675@DDCEP50018.na.corp.mckesson.com> <252643.1388511107@turing-police.cc.vt.edu> <8543.1388524764@turing-police.cc.vt.edu> Message-ID: <5.1.1.6.2.20140101074005.05003618@efes.iucc.ac.il> At 20:55 31/12/2013 -0500, Christopher Morrow wrote: >Had no clue? Didn't they build it? > > > > From what I understood from the tech note, they had no clue this would > > happen on the 31st of December :) Perhaps it is a left over somehow from their Netscreen purchase (April 2004)? -Hank From contact at nullivex.com Wed Jan 1 05:45:05 2014 From: contact at nullivex.com (Bryan Tong) Date: Tue, 31 Dec 2013 22:45:05 -0700 Subject: First! [?] In-Reply-To: References: Message-ID: Happy New Year guys! On Tue, Dec 31, 2013 at 10:38 PM, jamie rishaw wrote: > Happy New Year to all, and to all a good lawful interception. > -- eSited LLC (701) 390-9638 From christopher.morrow at gmail.com Wed Jan 1 05:48:24 2014 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 01 Jan 2014 05:48:24 +0000 Subject: Juniper SSL VPN References: <20131231.144546.74654601.sthaug@nethelp.no> <20131231143229.GA6690@pob.ytti.fi> <247429C70AB9D948A4DDECDFA5C23390DB6AB675@DDCEP50018.na.corp.mckesson.com> <252643.1388511107@turing-police.cc.vt.edu> <8543.1388524764@turing-police.cc.vt.edu> <5.1.1.6.2.20140101074005.05003618@efes.iucc.ac.il> Message-ID: <-1266202195292790288@gmail297201516> and in ~10 yrs no one did a code review? or refactor? or dependency check? On Wed Jan 01 2014 at 12:42:09 AM, Hank Nussbacher wrote: > At 20:55 31/12/2013 -0500, Christopher Morrow wrote: > >Had no clue? Didn't they build it? > > > > > > From what I understood from the tech note, they had no clue this would > > > happen on the 31st of December :) > > Perhaps it is a left over somehow from their Netscreen purchase (April > 2004)? > > -Hank > > > From owen at delong.com Wed Jan 1 06:57:26 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 31 Dec 2013 22:57:26 -0800 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <56080469-490B-41C3-84F1-765671C87F3E@uchicago.edu> Message-ID: > > Please note that Ryan?s ?manage their IPv6 systems? really means ?run their business?. In many organizations the routing network is managed by a different group with different business goals and procedures than end systems. Allowing flexibility for this, if it is not overwhelmingly costly, is a reasonable goal. > I guess in that case, one must ask one's self whether setting the default (or any other) route entries in the host routing tables qualifies as a "end system" issue or a "routing network" issue. My inclination is to think that it really is a "routing network" issue more than a "end system" issue, but I can see some valid arguments in either direction. It seems to me that no matter what solution one uses to deliver the default route information to the end system's routing table, this is an area which will inherently require cooperation and interaction between the group that manages the end systems and the group that manages the routers. I have yet to see an environment where this can be avoided in IPv4 and I wouldn't expect it to work out particularly well in IPv6, though I think we can come closer to having it work by having the network group control the prefix assignment and routing information delivered to the hosts than we could otherwise. > On my part, I see adding a default route parameter to DHCPv6 about as earth shaking as adding a default NTP server list. In other words, cut the crap and do it so we can save NANOG electrons and get on with solving more important network problems. Personally, I'd hate to see us waste the effort on such a half-assed measure. If we're going to add routing information to DHCPv6, then I think it should be roughly equivalent to what is contained in an RIO within an RA (Prefix, Mask, Next Hop, Metric). (Though in the case of RA, the Next Hop is implicitly the router providing the RIO, obviously in DHCPv6, it would have to be explicit) With such an option added to DHCPv6, then default router could simply be one case, but the flexibility for more complex routing situations to be addressed would also exist. Owen From pfunix at gmail.com Wed Jan 1 07:09:09 2014 From: pfunix at gmail.com (Beavis) Date: Wed, 1 Jan 2014 01:09:09 -0600 Subject: First! [?] In-Reply-To: References: Message-ID: happy new year. On Tue, Dec 31, 2013 at 11:45 PM, Bryan Tong wrote: > Happy New Year guys! > > > On Tue, Dec 31, 2013 at 10:38 PM, jamie rishaw wrote: > > > Happy New Year to all, and to all a good lawful interception. > > > > > > -- > eSited LLC > (701) 390-9638 > -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Disclaimer: http://goldmark.org/jeff/stupid-disclaimers/ From wbailey at satelliteintelligencegroup.com Wed Jan 1 07:17:48 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 1 Jan 2014 07:17:48 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <52C35D05.7080303@mykolab.com> References: <877gak27az.fsf@mid.deneb.enyo.de> <871u0swow3.fsf@mid.deneb.enyo.de>,<52C35D05.7080303@mykolab.com> Message-ID: China. ;) lol Sent from my Mobile Device. -------- Original message -------- From: Paul Ferguson Date: 12/31/2013 4:13 PM (GMT-08:00) To: nanog at nanog.org Subject: Re: NSA able to compromise Cisco, Juniper, Huawei switches -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/31/2013 4:02 PM, Florian Weimer wrote: > * Warren Bailey: > >> Explaining, not a denial written by their legal department. I find it >> insanely difficult to believe cisco systems has a backdoor into some of >> their product lines with no knowledge or participation. > > As far as I understand it, these are firmware tweaks or implants > sitting on a privileged bus (think PCI with busmaster DMA). Such > things can be added after the device has left the factory by a > sufficiently knowledgeable third party. > That's really interesting. Where are these Cisco devices manufactured? - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 10.2.0 (Build 2317) Charset: utf-8 wj8DBQFSw1z/q1pz9mNUZTMRAvbIAKCYZn3slg1wMak/nlc/hb3ZHkS29wCg3ucb OJTl+SLgBtQDMGi+cTdDRtQ= =VAdw -----END PGP SIGNATURE----- -- Paul Ferguson PGP Public Key ID: 0x63546533 From chris.young at intermetro.net Wed Jan 1 07:41:54 2014 From: chris.young at intermetro.net (Christopher Young) Date: Wed, 1 Jan 2014 07:41:54 +0000 Subject: First! [?] In-Reply-To: References: Message-ID: <851013360-1388562115-cardhu_decombobulator_blackberry.rim.net-851771212-@b18.c5.bise6.blackberry> Happy new year! Regards, Christopher Young Network Operations InterMetro Communications, Inc. 805-433-8000 Main 805-433-0050 Direct 805-433-2589 Mobile 805-582-1006 Fax *** Contact our NOC at 866-446-2662 or via email ' network.operations at intermetro.net' *** *** The information contained within this E-Mail and any attached document(s) is confidential and/or privileged. It is intended solely for the use of the addressee(s) named above. Unauthorized disclosure, photocopying, distribution or use of the information contained herein is prohibited. If you believe that you have received this E-Mail in error, please notify the sender by reply transmission or call 805-433-8000 and delete the message without reviewing, copying or disclosing the message, any attachments or any contents thereof. -----Original Message----- From: Beavis Date: Wed, 1 Jan 2014 01:09:09 To: Bryan Tong Cc: NANOG list Subject: Re: First! [?] happy new year. On Tue, Dec 31, 2013 at 11:45 PM, Bryan Tong wrote: > Happy New Year guys! > > > On Tue, Dec 31, 2013 at 10:38 PM, jamie rishaw wrote: > > > Happy New Year to all, and to all a good lawful interception. > > > > > > -- > eSited LLC > (701) 390-9638 > -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Disclaimer: http://goldmark.org/jeff/stupid-disclaimers/ From amekkaoui at mektel.ca Wed Jan 1 07:45:01 2014 From: amekkaoui at mektel.ca (A Mekkaoui) Date: Wed, 1 Jan 2014 02:45:01 -0500 Subject: First! [?] In-Reply-To: <851013360-1388562115-cardhu_decombobulator_blackberry.rim.net-851771212-@b18.c5.bise6.blackberry> References: <851013360-1388562115-cardhu_decombobulator_blackberry.rim.net-851771212-@b18.c5.bise6.blackberry> Message-ID: <000001cf06c5$61664510$2432cf30$@ca> Happy new year to all of you, all the best! Karim -----Original Message----- From: Christopher Young [mailto:chris.young at intermetro.net] Sent: January 1, 2014 2:42 AM To: Beavis; Bryan Tong Cc: NANOG list Subject: Re: First! [?] Happy new year! Regards, Christopher Young Network Operations InterMetro Communications, Inc. 805-433-8000 Main 805-433-0050 Direct 805-433-2589 Mobile 805-582-1006 Fax *** Contact our NOC at 866-446-2662 or via email ' network.operations at intermetro.net' *** *** The information contained within this E-Mail and any attached document(s) is confidential and/or privileged. It is intended solely for the use of the addressee(s) named above. Unauthorized disclosure, photocopying, distribution or use of the information contained herein is prohibited. If you believe that you have received this E-Mail in error, please notify the sender by reply transmission or call 805-433-8000 and delete the message without reviewing, copying or disclosing the message, any attachments or any contents thereof. -----Original Message----- From: Beavis Date: Wed, 1 Jan 2014 01:09:09 To: Bryan Tong Cc: NANOG list Subject: Re: First! [?] happy new year. On Tue, Dec 31, 2013 at 11:45 PM, Bryan Tong wrote: > Happy New Year guys! > > > On Tue, Dec 31, 2013 at 10:38 PM, jamie rishaw wrote: > > > Happy New Year to all, and to all a good lawful interception. > > > > > > -- > eSited LLC > (701) 390-9638 > -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Disclaimer: http://goldmark.org/jeff/stupid-disclaimers/ From faisal at snappytelecom.net Wed Jan 1 07:55:30 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Wed, 1 Jan 2014 07:55:30 +0000 (GMT) Subject: First! [?] In-Reply-To: <000001cf06c5$61664510$2432cf30$@ca> References: <851013360-1388562115-cardhu_decombobulator_blackberry.rim.net-851771212-@b18.c5.bise6.blackberry> <000001cf06c5$61664510$2432cf30$@ca> Message-ID: <1449479701.378243.1388562930932.JavaMail.root@snappytelecom.net> Happy New Year ! Best Wishes for 2014 to Everyone. Faisal Imtiaz ----- Original Message ----- > From: "A Mekkaoui" > To: "chris young" , "Beavis" , "Bryan Tong" > Cc: "NANOG list" > Sent: Wednesday, January 1, 2014 2:45:01 AM > Subject: RE: First! [?] > > Happy new year to all of you, all the best! > > Karim > > -----Original Message----- > From: Christopher Young [mailto:chris.young at intermetro.net] > Sent: January 1, 2014 2:42 AM > To: Beavis; Bryan Tong > Cc: NANOG list > Subject: Re: First! [?] > > Happy new year! > > > Regards, > Christopher Young > Network Operations > InterMetro Communications, Inc. > > 805-433-8000 Main > 805-433-0050 Direct > 805-433-2589 Mobile > 805-582-1006 Fax > > *** Contact our NOC at > 866-446-2662 or via email ' > network.operations at intermetro.net' *** > > *** The information contained within this E-Mail and any attached > document(s) is confidential and/or privileged. It is intended solely for the > use of the addressee(s) named above. Unauthorized disclosure, photocopying, > distribution or use of the information contained herein is prohibited. If > you believe that you have received this E-Mail in error, please notify the > sender by reply transmission or call > 805-433-8000 and delete the message without reviewing, copying or disclosing > the message, any attachments or any contents thereof. > > -----Original Message----- > From: Beavis > Date: Wed, 1 Jan 2014 01:09:09 > To: Bryan Tong > Cc: NANOG list > Subject: Re: First! [?] > > happy new year. > > > On Tue, Dec 31, 2013 at 11:45 PM, Bryan Tong wrote: > > > Happy New Year guys! > > > > > > On Tue, Dec 31, 2013 at 10:38 PM, jamie rishaw wrote: > > > > > Happy New Year to all, and to all a good lawful interception. > > > > > > > > > > > -- > > eSited LLC > > (701) 390-9638 > > > > > > -- > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments > > Disclaimer: > http://goldmark.org/jeff/stupid-disclaimers/ > > > From tritran at cox.net Wed Jan 1 07:58:14 2014 From: tritran at cox.net (Tri Tran) Date: Wed, 1 Jan 2014 07:58:14 +0000 Subject: First! [?] In-Reply-To: <8Xmb1n01Y1Una3W01XmcPU> References: <851013360-1388562115-cardhu_decombobulator_blackberry.rim.net-851771212-@b18.c5.bise6.blackberry> <8Xmb1n01Y1Una3W01XmcPU> Message-ID: <648909690-1388563096-cardhu_decombobulator_blackberry.rim.net-1914566786-@b12.c19.bise6.blackberry> Happy New Year! Tri Tran -----Original Message----- From: "A Mekkaoui" Date: Wed, 1 Jan 2014 02:45:01 To: ; 'Beavis'; 'Bryan Tong' Cc: 'NANOG list' Subject: RE: First! [?] Happy new year to all of you, all the best! Karim -----Original Message----- From: Christopher Young [mailto:chris.young at intermetro.net] Sent: January 1, 2014 2:42 AM To: Beavis; Bryan Tong Cc: NANOG list Subject: Re: First! [?] Happy new year! Regards, Christopher Young Network Operations InterMetro Communications, Inc. 805-433-8000 Main 805-433-0050 Direct 805-433-2589 Mobile 805-582-1006 Fax *** Contact our NOC at 866-446-2662 or via email ' network.operations at intermetro.net' *** *** The information contained within this E-Mail and any attached document(s) is confidential and/or privileged. It is intended solely for the use of the addressee(s) named above. Unauthorized disclosure, photocopying, distribution or use of the information contained herein is prohibited. If you believe that you have received this E-Mail in error, please notify the sender by reply transmission or call 805-433-8000 and delete the message without reviewing, copying or disclosing the message, any attachments or any contents thereof. -----Original Message----- From: Beavis Date: Wed, 1 Jan 2014 01:09:09 To: Bryan Tong Cc: NANOG list Subject: Re: First! [?] happy new year. On Tue, Dec 31, 2013 at 11:45 PM, Bryan Tong wrote: > Happy New Year guys! > > > On Tue, Dec 31, 2013 at 10:38 PM, jamie rishaw wrote: > > > Happy New Year to all, and to all a good lawful interception. > > > > > > -- > eSited LLC > (701) 390-9638 > -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Disclaimer: http://goldmark.org/jeff/stupid-disclaimers/ From saku at ytti.fi Wed Jan 1 09:55:37 2014 From: saku at ytti.fi (Saku Ytti) Date: Wed, 1 Jan 2014 11:55:37 +0200 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <877gak27az.fsf@mid.deneb.enyo.de> Message-ID: <20140101095537.GA21572@pob.ytti.fi> On (2013-12-31 23:04 +0000), Warren Bailey wrote: > that RSA had a check cut for their participation (sell outs..), would it > be out of the realm of possibility cisco knowingly placed this into their > product line? And would it be their mistake to come out with a ?we had no > idea!? rather than ?guys with badges and court orders made us do it!?? Is this legal? Can NSA walk in to US based company and legally coerce to install such backdoor? If not, what is the incentive for private company to cooperate? If legal, consider risk to NSA. Official product ran inside company to add requested feature, hundred of people aware of it. Seems both expensive to order such feature and almost guaranteed to be exposed by some of the employees. Alternative method is to presume all software is insecure, hire 1 expert whose day job is to search for vulnerabilities in IOS. Much cheaper, insignificant risk. Which method would you use? > techniques isn?t a surprise to me, what is a surprise to me is the level > of acceptance the IT community has shown thus far on NANOG. This seems like generalization, majority opinion seems to be, government has no business spying on us. Someone contacted me yesterday, after reading how I'd love to see some of these attacks dissected and analysed to gain higher quality data than screenshot of PDF. He told me, he and his employer are cooperating with their vendor right now looking at attack done against router they operate and claimed they are aware of other operators being targeted. Unfortunately he couldn't share any specifics, so hopefully we'll soon have situation where someone can dissect publicly any of the attacks. If this is as widespread as claimed, and if we'll gain knowledge how to see if you are affected, there are potentially repercussions on geopolitical scale, as I'm sure many on these lists would go public and share information if they'd find being targeted. -- ++ytti From brandon at rd.bbc.co.uk Wed Jan 1 14:37:11 2014 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Wed, 1 Jan 2014 14:37:11 GMT Subject: NSA able to compromise Cisco, Juniper, Huawei switches Message-ID: <201401011437.OAA15114@sunf10.rd.bbc.co.uk> > If legal, consider risk to NSA. Official product ran inside company to add > requested feature, hundred of people aware of it. Seems both expensive to > order such feature and almost guaranteed to be exposed by some of the > employees. > > Alternative method is to presume all software is insecure, hire 1 expert whose > day job is to search for vulnerabilities in IOS. Much cheaper, insignificant > risk. > > Which method would you use? I'd also look at having people work in the factory in china designing test or at (/own) the QA/test equipment manufacturer as when they connect the product jtag to test you can give a little extra. Both smaller groups of people and nobody knows what they do anyway but they do get legit access to the product perhaps with low level details handed on a plate. > If this is as widespread as claimed, and if we'll gain knowledge how to see if > you are affected, there are potentially repercussions on geopolitical scale, > as I'm sure many on these lists would go public and share information if > they'd find being targeted. Would they leave them out there gathering data for as long as possible or remove the evidence as soon as people start looking (then put some back later once the fuss has died down)? brandon From admin at marcoteixeira.com Wed Jan 1 17:21:47 2014 From: admin at marcoteixeira.com (Marco Teixeira) Date: Wed, 1 Jan 2014 17:21:47 +0000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <20131230100632.GA15285@pob.ytti.fi> <20131230111851.GA24557@pob.ytti.fi> <7B8244D9-DD8A-4CF0-80D6-09810D4F868E@arbor.net> <1F6B9A72-392E-4634-B904-598F8C531BC3@arbor.net> <152239.1388418248@turing-police.cc.vt.edu> <9B3DCE32-A71C-4DD1-8B63-2FCE83A5F520@arbor.net> <20131230161635.GA16611@ernw.de> Message-ID: Thank you Randy for pointing that out. However take into account the NANOG list is moderated, and my comment was delayed for moderation. I was commenting on posts about trivial things, before that nice post with nice codenames. A good year to all. May this be a smoother year to you all that have short SLAs to keep :) Em 30/12/2013 20:57, "Randy Bush" escreveu: > > These are not backdoor issues, NSA related, whatever... This is noise. > > Trying to get this thread on track, can the original poster provide any > > proof of this so called ability of the so called inteligence agency > beeing > > able to access cisco/juniper, taking into account that management access > > has been correctly configured ? > > since you don't seem to read the articles, perhaps an info-graphic > > http://www.spiegel.de/international/world/a-941262.html > > randy > From randy at psg.com Wed Jan 1 18:23:35 2014 From: randy at psg.com (Randy Bush) Date: Wed, 01 Jan 2014 08:23:35 -1000 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <20140101095537.GA21572@pob.ytti.fi> References: <877gak27az.fsf@mid.deneb.enyo.de> Message-ID: Warren Bailey > I find it insanely difficult to believe cisco systems has a backdoor > into some of their product lines with no knowledge or participation. actually, i suspect a mix of both, the usg encouraging calea gone bad (while committing to bad-mouth huawei), and the TAO crew developing serious attacks based on unintended product vulnerabilities. > Google has some deniability, as their networks were compromised > without their knowledge. i doubt we will ever learn the extent of surprise vs culpability of google, apple, twitter, msoft, ... Saku Ytti > Is this legal? ROFL > If this is as widespread as claimed, and if we'll gain knowledge how > to see if you are affected, there are potentially repercussions on > geopolitical scale, as I'm sure many on these lists would go public > and share information if they'd find being targeted. we are dealing with a world in which there are attackers and victims and very few white hats to be seen. exposure via journalism, thanks @ioerror, wikileaks, ... and constructive hacking to make protocols and products more resistant are the main paths available to us. and if you want to be ambarrassed for our peers, see the ietf pissing all over itself deciding whether they can make simple statements that these things are attacks and the ietf needs to do something about its protocols. --- https://www.youtube.com/watch?v=cOCWTRJCnf0 randy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 527 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Wed Jan 1 18:29:07 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 01 Jan 2014 13:29:07 -0500 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: Your message of "Wed, 01 Jan 2014 11:55:37 +0200." <20140101095537.GA21572@pob.ytti.fi> References: <877gak27az.fsf@mid.deneb.enyo.de> <20140101095537.GA21572@pob.ytti.fi> Message-ID: <77291.1388600947@turing-police.cc.vt.edu> On Wed, 01 Jan 2014 11:55:37 +0200, Saku Ytti said: > Is this legal? Can NSA walk in to US based company and legally coerce to > install such backdoor? Well, legal or not... we will probably never know exactly what was said, but apparently the NSA was able to convince/coerce many of the 800 pound telecom gorillas to install taps and backdoors at the server end. > If not, what is the incentive for private company to cooperate? The same incentive that was used to enforce secrecy on National Security Letters for many years - play nice or you'll end up in an oublette, with a trial to (maybe) be held behind closed doors, where you won't see any of the evidence against you because it's classified. Remember, the US sprouted this "indefinite detention" concept a while back, and still hasn't backtracked on it, because of its enormous usefulness as a cudgel to deal with "enemies of the State". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From mysidia at gmail.com Wed Jan 1 19:06:59 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 1 Jan 2014 13:06:59 -0600 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <20140101095537.GA21572@pob.ytti.fi> References: <877gak27az.fsf@mid.deneb.enyo.de> <20140101095537.GA21572@pob.ytti.fi> Message-ID: On Wed, Jan 1, 2014 at 3:55 AM, Saku Ytti wrote: > Is this legal? Can NSA walk in to US based company and legally coerce to > install such backdoor? If not, what is the incentive for private company to > cooperate? > As evidenced by "Lavabit"; apparently, one thing that they CAN do is issue an order to the US based company to release their secret cryptography keys such as RSA secret keys to the government, including the secret keys that correspond to the public keys on their X509 certificates; possibly including certificates used for code signing and code distribution to users. AND maintain confidentiality that they were required to release keys. Recall, Lavabit was deemed in violation of the order: due to halting their service, after being forced to release the cryptography keys. The RSA secret keys can then be used to forge the company's signature on a payload containing a malicious copy of the firmware or operating system. And perform man in the middle attacks against web sites, and other software update infrastructure --- in order to distributed tampered with software with forged code signatures. -- -JH From rsk at gsp.org Wed Jan 1 21:44:34 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 1 Jan 2014 16:44:34 -0500 Subject: Query: fate of ipdeny.com Message-ID: <20140101214434.GB11592@gsp.org> ipdeny.com provided a highly useful service: IP address allocations on a per-country basis. The site's still live but all (or nearly all) the data files are empty. The blog hasn't been updated, and email via their contact form goes unanswered. I'd like to know if anybody here has a clue as to what happened, why, whether they'll be back, etc. Thanks, ---rsk From eugen at imacandi.net Wed Jan 1 21:51:15 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Wed, 1 Jan 2014 23:51:15 +0200 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <20140101095537.GA21572@pob.ytti.fi> References: <877gak27az.fsf@mid.deneb.enyo.de> <20140101095537.GA21572@pob.ytti.fi> Message-ID: On Wed, Jan 1, 2014 at 11:55 AM, Saku Ytti wrote: > On (2013-12-31 23:04 +0000), Warren Bailey wrote: > > > that RSA had a check cut for their participation (sell outs..), would it > > be out of the realm of possibility cisco knowingly placed this into their > > product line? And would it be their mistake to come out with a ?we had no > > idea!? rather than ?guys with badges and court orders made us do it!?? > > Is this legal? Can NSA walk in to US based company and legally coerce to > install such backdoor? If not, what is the incentive for private company to > cooperate? > As you might have seen from the beginning of time, people in power assume anything can go until proven otherwise. From ml at kenweb.org Wed Jan 1 23:26:46 2014 From: ml at kenweb.org (ML) Date: Wed, 01 Jan 2014 18:26:46 -0500 Subject: Query: fate of ipdeny.com In-Reply-To: <20140101214434.GB11592@gsp.org> References: <20140101214434.GB11592@gsp.org> Message-ID: <52C4A436.9010008@kenweb.org> On 1/1/2014 4:44 PM, Rich Kulawiec wrote: > ipdeny.com provided a highly useful service: IP address allocations > on a per-country basis. The site's still live but all (or nearly > all) the data files are empty. The blog hasn't been updated, and > email via their contact form goes unanswered. I'd like to know if > anybody here has a clue as to what happened, why, whether they'll > be back, etc. > > Thanks, > ---rsk > I can still grab: http://www.ipdeny.com/ipblocks/data/countries/us.zone From lists at mtin.net Thu Jan 2 02:50:04 2014 From: lists at mtin.net (Justin Wilson) Date: Wed, 01 Jan 2014 21:50:04 -0500 Subject: Catalyst IOS refresher site? In-Reply-To: <4100472.664.1386968370819.JavaMail.root@benjamin.baylink.com> References: <52AB6D2F.5040501@brezworks.com> <4100472.664.1386968370819.JavaMail.root@benjamin.baylink.com> Message-ID: If it were me I would pickup a SupIII or SupIV off ebay. They are pretty cheap. Justin --- Justin Wilson MTIN Consulting Mikrotik ? UBNT ? Climbing ? Network Design http://www.mtin.net/ http://www.thebrotherswisp.com -----Original Message----- From: Jay Ashworth Date: Friday, December 13, 2013 at 3:59 PM To: NANOG Subject: Re: Catalyst IOS refresher site? >----- Original Message ----- >> From: "Jeremy Bresley" > >> Might help if you said what type of line cards and sup you've got. A >> SupII era card is CatOS, SupIII and newer are IOS, command sets are >> completely different, and depending on the line cards you've got, you >> might have some of the really old L2 only cards (can't remember if you >> could do L3 on the bastard Gig/FE cards only, or if it was dependent >> on the particular Sup installed). That said, if it's an IOS Sup, I'd >> start here: >> >>http://www.cisco.com/en/US/products/hw/switches/ps4324/prod_command_refer >>ence_list.html > >Hmm. I wasn't smart enough to shoot a pic of the front panel, and I'm >not picking it up til Monday, so I don't know. I have some background >in Catalyst IOS, but it's old and on 3500-class switches, not the >bigger iron. > >Thanks, >-- jra >-- >Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by >12/14 > >Jay R. Ashworth Baylink >jra at baylink.com >Designer The Things I Think RFC >2100 >Ashworth & Associates http://baylink.pitas.com 2000 Land >Rover DII >St Petersburg FL USA #natog +1 727 647 >1274 > From saku at ytti.fi Thu Jan 2 08:01:15 2014 From: saku at ytti.fi (Saku Ytti) Date: Thu, 2 Jan 2014 10:01:15 +0200 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: References: <877gak27az.fsf@mid.deneb.enyo.de> <20140101095537.GA21572@pob.ytti.fi> Message-ID: <20140102080115.GA28822@pob.ytti.fi> On (2014-01-01 23:51 +0200), Eugeniu Patrascu wrote: > > Is this legal? Can NSA walk in to US based company and legally coerce to > > install such backdoor? If not, what is the incentive for private company to > > cooperate? > > > > As you might have seen from the beginning of time, people in power assume > anything can go until proven otherwise. This is mostly academic, as being legal or not being legal it's not appealing attack vector due to difficulties containing the information. But what I implied is, if it is legal, you'd have paper trail, like legal document from court. -- ++ytti From eugen at imacandi.net Thu Jan 2 09:07:24 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Thu, 2 Jan 2014 11:07:24 +0200 Subject: NSA able to compromise Cisco, Juniper, Huawei switches In-Reply-To: <20140102080115.GA28822@pob.ytti.fi> References: <877gak27az.fsf@mid.deneb.enyo.de> <20140101095537.GA21572@pob.ytti.fi> <20140102080115.GA28822@pob.ytti.fi> Message-ID: On Thu, Jan 2, 2014 at 10:01 AM, Saku Ytti wrote: > On (2014-01-01 23:51 +0200), Eugeniu Patrascu wrote: > > > > Is this legal? Can NSA walk in to US based company and legally coerce > to > > > install such backdoor? If not, what is the incentive for private > company to > > > cooperate? > > > > > > > As you might have seen from the beginning of time, people in power assume > > anything can go until proven otherwise. > > This is mostly academic, as being legal or not being legal it's not > appealing > attack vector due to difficulties containing the information. > But what I implied is, if it is legal, you'd have paper trail, like legal > document from court. > > I can't speak for NSA practices, but for example FBI asserted that they are entitled to put GPS trackers on cars owned by people they suspected of something without a court order. And they fought to the death in courts when the suspects brought suits against them for violating their rights with these practices. It would assume that other agencies employ the same tactics and strong-arm companies into doing their bidding with minimal paperwork. Let's not forget that NSA vets all the security vendors and products that the USG uses and it would be pretty easy for them to stop recommending SecurID tokens (main RSA business is authentication) for government use. The above presumption would have sounded crazy six months ago, but now... From rs at seastrom.com Thu Jan 2 12:15:33 2014 From: rs at seastrom.com (Rob Seastrom) Date: Thu, 02 Jan 2014 07:15:33 -0500 Subject: [SPAM]RE: [SPAM]RE: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: (Justin Wilson's message of "Tue, 31 Dec 2013 11:33:34 -0500") References: <075801cf030c$c4002b30$4c008190$@oneunified.net> <50710E9A7E64454C974049FC998EB655018DDD93@03-exchange.lti.local> Message-ID: <86ha9m1swq.fsf@valhalla.seastrom.com> Justin Wilson writes: > The biggest problem with Mikrotik is you just can?t call them up for > support on buggy code. In a critical network this can be a major problem. I've contacted them (via email) and the experience seems to be exactly the same as dealing with first level TAC at the big guys: the guy you contact doesn't care much about your problem once he realizes that it's a legitimate issue with their stuff and not simply a case of pilot error for which he can refer you to the documentation, and eventually you give up and develop a workaround, such as it is. -r From dmburgess at linktechs.net Thu Jan 2 14:04:12 2014 From: dmburgess at linktechs.net (Dennis Burgess) Date: Thu, 2 Jan 2014 08:04:12 -0600 Subject: [SPAM]RE: [SPAM]RE: Mikrotik Cloud Core Router and BGP real life experiences? References: <075801cf030c$c4002b30$4c008190$@oneunified.net> <50710E9A7E64454C974049FC998EB655018DDD93@03-exchange.lti.local> <86ha9m1swq.fsf@valhalla.seastrom.com> Message-ID: <50710E9A7E64454C974049FC998EB655018DDEAA@03-exchange.lti.local> Mikrotik really relies on its list of consultants and trainers, these are all outside companies, yes such as mine, that provide the higher class of "support" than MikroTik own e-mail. . While their e-mail does have a lack of responsiveness, I was told the volume that they do get form other parts of the world, not saying that's an excuse, but it is what it is. Many people in the WISP and smaller ISP markets rely on these consulting companies to not only help them with MikroTik but other hardware/software and business decisions, LTI (yes the company I work for) has more certified trainers and engineers for MikroTik than any other in North America, but there is a list from MikroTik that lists certified consultants available as well. Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition"???????????????????????????????? ?Link Technologies, Inc -- Mikrotik & WISP Support Services??????????????????????????????????????????????????????????????????????????????????? ?Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs???????????????????????????????????????????????????? ?-- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace? -----Original Message----- From: Rob Seastrom [mailto:rs at seastrom.com] Sent: Thursday, January 02, 2014 6:16 AM To: Justin Wilson Cc: NANOG list Subject: Re: [SPAM]RE: [SPAM]RE: Mikrotik Cloud Core Router and BGP real life experiences? Justin Wilson writes: > The biggest problem with Mikrotik is you just can?t call them up for > support on buggy code. In a critical network this can be a major problem. I've contacted them (via email) and the experience seems to be exactly the same as dealing with first level TAC at the big guys: the guy you contact doesn't care much about your problem once he realizes that it's a legitimate issue with their stuff and not simply a case of pilot error for which he can refer you to the documentation, and eventually you give up and develop a workaround, such as it is. -r From jra at baylink.com Thu Jan 2 15:39:10 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 2 Jan 2014 10:39:10 -0500 (EST) Subject: Catalyst IOS refresher site? In-Reply-To: Message-ID: <16421164.2358.1388677150459.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Justin Wilson" > If it were me I would pickup a SupIII or SupIV off ebay. They are > pretty cheap. In fact, my vendor is an old client, so when the 4507 turned out to have 240-only power supplies (I rent), they swapped me out for a 4006, and we card-swapped to leave me with: * WS-X4515 Supervisor Engine IV * An empty slot with a cover; 2 empty slots without covers * WS-X4248-RJ45V 48-port POE * WS-X4232-L3 Routing Engine, with 32 10/100 plus 2 of those large optical transceiver ports for which I have none of whatever we used to call GBICs before they got tiny. :-) Holidays being what they are, I'm still digging out the bench, but I want to say that the one time I consoled it and booted it on theirs, it said 12.5(20), or something thereabouts, before complaining it had no image to boot from. More fun to follow; everyone needs a New Year's resolution, right? I mean, other than 3840x2160. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From daniel.crompton at gmail.com Thu Jan 2 15:48:39 2014 From: daniel.crompton at gmail.com (=?UTF-8?Q?Dani=C3=ABl_W=2E_Crompton?=) Date: Thu, 2 Jan 2014 16:48:39 +0100 Subject: Open source hardware Message-ID: Hi, a friend of mine mentioned he wants to migrate away from carrier grade equipment such as Juniper and Cisco to open source hardware. Both of us haven't been able to find anything that would fulfill the requirements that a smallish ISP might have. Does anybody here have any advise? Kind regards and best wishes for the new year, Dani?l Oplerno is built upon empowering faculty and students We want you to found (and fund) Oplerno with us [image: Support Us Here] -- Dani?l W. Crompton http://specialbrands.net/ From faisal at snappytelecom.net Thu Jan 2 15:53:29 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 2 Jan 2014 15:53:29 +0000 (GMT) Subject: Open source hardware In-Reply-To: References: Message-ID: <409783563.384871.1388678009422.JavaMail.root@snappytelecom.net> Have you looked at Mikrotik.com (Software) and Routerboard.com (Hardware) Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Dani?l W. Crompton" > To: "nanog" > Sent: Thursday, January 2, 2014 10:48:39 AM > Subject: Open source hardware > > Hi, > > a friend of mine mentioned he wants to migrate away from carrier grade > equipment such as Juniper and Cisco to open source hardware. Both of us > haven't been able to find anything that would fulfill the requirements that > a smallish ISP might have. > > Does anybody here have any advise? > > Kind regards and best wishes for the new year, > Dani?l > > > > Oplerno is built upon empowering faculty and students We want you to found > (and fund) Oplerno with > us > [image: Support Us > Here] > -- > Dani?l W. Crompton > > > > > http://specialbrands.net/ > > > > From lathama at gmail.com Thu Jan 2 16:00:49 2014 From: lathama at gmail.com (Andrew Latham) Date: Thu, 2 Jan 2014 10:00:49 -0600 Subject: Open source hardware In-Reply-To: References: Message-ID: Maybe http://imagestream.com/ and their nice little toys like the http://imagestream.com/samurai.php On Thu, Jan 2, 2014 at 9:48 AM, Dani?l W. Crompton wrote: > Hi, > > a friend of mine mentioned he wants to migrate away from carrier grade > equipment such as Juniper and Cisco to open source hardware. Both of us > haven't been able to find anything that would fulfill the requirements that > a smallish ISP might have. > > Does anybody here have any advise? > > Kind regards and best wishes for the new year, > Dani?l > > > > Oplerno is built upon empowering faculty and students We want you to found > (and fund) Oplerno with > us > [image: Support Us > Here] > -- > Dani?l W. Crompton > > > > > http://specialbrands.net/ > > > -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From matthew at walster.org Thu Jan 2 16:15:18 2014 From: matthew at walster.org (Matthew Walster) Date: Thu, 2 Jan 2014 16:15:18 +0000 Subject: Open source hardware In-Reply-To: <409783563.384871.1388678009422.JavaMail.root@snappytelecom.net> References: <409783563.384871.1388678009422.JavaMail.root@snappytelecom.net> Message-ID: On 2 January 2014 15:53, Faisal Imtiaz wrote: > Have you looked at Mikrotik.com (Software) and Routerboard.com (Hardware) > That's not Open Source. M?? From chris at nifry.com Thu Jan 2 16:37:57 2014 From: chris at nifry.com (Chris Russell) Date: Thu, 02 Jan 2014 16:37:57 +0000 Subject: Open source hardware In-Reply-To: References: Message-ID: > haven't been able to find anything that would fulfill the > requirements that > a smallish ISP might have. The Cumulus guys might be able to provide some pointers ? http://cumulusnetworks.com/ Chris From bzs at world.std.com Thu Jan 2 17:40:02 2014 From: bzs at world.std.com (Barry Shein) Date: Thu, 2 Jan 2014 12:40:02 -0500 (EST) Subject: What's up at AOL? Message-ID: <201401021740.s02He2wL002250@world.std.com> They've been accepting email only occasionally for a few days now. We're on FBL, check reputation is good/green. Sometimes we get DYN:T2 (according to AOL that's their code for it's our, AOL's, problem), sometimes just various forms of try later, Service not available, deferred, etc. typically after the DATA is sent so MAIL FROM and RCPT TO are ok or no error. I did get one response from postmaster at aol.com which said it was all fixed yesterday which it was for several hours and today thousands of msgs backed up for them again. I am just asking if anyone knows what's going on even in general terms. That is, should we stop fussing with this (everyone's hosed w/ AOL this week?) or is it just us? -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From nick at flhsi.com Thu Jan 2 18:24:23 2014 From: nick at flhsi.com (Nick Olsen) Date: Thu, 2 Jan 2014 13:24:23 -0500 Subject: What's up at AOL? Message-ID: <54b61618$11afacbf$3c5c56e4$@flhsi.com> We're seeing mail backup toward AOL as well. All coming back Service Unavailable. Postmaster at aol.com has not responded to our inquiry yet. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Barry Shein" Sent: Thursday, January 02, 2014 12:46 PM To: nanog at nanog.org Subject: What's up at AOL? They've been accepting email only occasionally for a few days now. We're on FBL, check reputation is good/green. Sometimes we get DYN:T2 (according to AOL that's their code for it's our, AOL's, problem), sometimes just various forms of try later, Service not available, deferred, etc. typically after the DATA is sent so MAIL FROM and RCPT TO are ok or no error. I did get one response from postmaster at aol.com which said it was all fixed yesterday which it was for several hours and today thousands of msgs backed up for them again. I am just asking if anyone knows what's going on even in general terms. That is, should we stop fussing with this (everyone's hosed w/ AOL this week?) or is it just us? -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From lists at tigertech.com Thu Jan 2 18:34:32 2014 From: lists at tigertech.com (Robert L Mathews) Date: Thu, 02 Jan 2014 10:34:32 -0800 Subject: What's up at AOL? In-Reply-To: <201401021740.s02He2wL002250@world.std.com> References: <201401021740.s02He2wL002250@world.std.com> Message-ID: <52C5B138.1070502@tigertech.com> On 1/2/14, 9:40 AM, Barry Shein wrote: > They've been accepting email only occasionally for a few days now. > > We're on FBL, check reputation is good/green. > > [...] > > I am just asking if anyone knows what's going on even in general > terms. > > That is, should we stop fussing with this (everyone's hosed w/ AOL > this week?) or is it just us? It's probably not just you. It's been happening intermittently to many people since December 26. See, for example: http://sitedown.co/aol/aol-smtp-in-appears-to-be-down And lots of recent, not-too-helpful Twitter conversations like: https://twitter.com/TboneRyan/status/416577803752984578 We saw this problem on December 26, 27, and 28, and are now seeing it again for the last 3 hours. -- Robert L Mathews, Tiger Technologies, http://www.tigertech.net/ From petebaldridge at gmail.com Thu Jan 2 19:29:23 2014 From: petebaldridge at gmail.com (Peter Baldridge) Date: Thu, 2 Jan 2014 11:29:23 -0800 Subject: What's up at AOL? In-Reply-To: <52C5B138.1070502@tigertech.com> References: <201401021740.s02He2wL002250@world.std.com> <52C5B138.1070502@tigertech.com> Message-ID: There was a note on the mailop list Dec 27 that mentioned they were unofficially having a malware/virus issue but not much further. On Thu, Jan 2, 2014 at 10:34 AM, Robert L Mathews wrote: > On 1/2/14, 9:40 AM, Barry Shein wrote: >> They've been accepting email only occasionally for a few days now. >> >> We're on FBL, check reputation is good/green. >> >> [...] >> >> I am just asking if anyone knows what's going on even in general >> terms. >> >> That is, should we stop fussing with this (everyone's hosed w/ AOL >> this week?) or is it just us? > > It's probably not just you. It's been happening intermittently to many > people since December 26. See, for example: > > http://sitedown.co/aol/aol-smtp-in-appears-to-be-down > > And lots of recent, not-too-helpful Twitter conversations like: > > https://twitter.com/TboneRyan/status/416577803752984578 > > We saw this problem on December 26, 27, and 28, and are now seeing it > again for the last 3 hours. > > -- > Robert L Mathews, Tiger Technologies, http://www.tigertech.net/ > From rs at seastrom.com Thu Jan 2 20:04:09 2014 From: rs at seastrom.com (Rob Seastrom) Date: Thu, 02 Jan 2014 15:04:09 -0500 Subject: [SPAM]RE: [SPAM]RE: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: <50710E9A7E64454C974049FC998EB655018DDEAA@03-exchange.lti.local> (Dennis Burgess's message of "Thu, 2 Jan 2014 08:04:12 -0600") References: <075801cf030c$c4002b30$4c008190$@oneunified.net> <50710E9A7E64454C974049FC998EB655018DDD93@03-exchange.lti.local> <86ha9m1swq.fsf@valhalla.seastrom.com> <50710E9A7E64454C974049FC998EB655018DDEAA@03-exchange.lti.local> Message-ID: <868uuygngm.fsf@valhalla.seastrom.com> "Dennis Burgess" writes: > Mikrotik really relies on its list of consultants and trainers, > these are all outside companies, yes such as mine, that provide the > higher class of "support" than MikroTik own e-mail. . While their > e-mail does have a lack of responsiveness, I was told the volume > that they do get form other parts of the world, not saying that's an > excuse, but it is what it is. This wasn't a support issue; it was bug reports. Things such as: * your CLI has an incomplete implementation of the Emacs key bindings (detailed list elided here on nanog at for brevity's sake but if you've ever used Mikrotik kit and are a seasoned CLI user on C and J platforms you know what I'm talking about); please consider fixing or adopting libcli, gnu readline, or somesuch in future releases. * your GRE implementation always has a protocol type of 0x0800 in the GRE header even when it is forwarding an IPv6 packet (packet dumps attached). * ssh sessions crash when ServerAliveInterval SSH application layer keepalives kick off. See http://www.openssh.org/faq.html section 2.12 or http://www.kehlet.cx/articles/129.html To replicate: ssh -o ServerAliveInterval=120 admin at myrouter (to their credit this was eventually fixed in 5.x - this behavior was observed in 5.0rc4) * /ping and /tool/traceroute fail for a DNS name for which there is no A record, only an AAAA record (although both commands will accept an IPv6 address as digits). This is still a problem today. * When trying to remove files, it seems that they are not removed by number, but rather by name, despite what the online help says. There was more stuff along those lines. "Thanks for the bug reports; I made sure to open tickets for them but we can't commit to when or if they'll get addressed due to competing priorities but they've absolutely been documented" would have been a fine reply; I completely understand the Real World considerations involved and that my priorities were not necessarily their priorities. Unfortunately the return email left me with the impression that nobody cared and that they were not equipped to handle issues brought to their attention by people with field experience, hence the unfavorable parallels to the "big guys". Note that this has not kept my from speccing their kit when the task calls for something that's surprisingly good considering how inexpensive it is! So maybe from a business perspective they were entirely correct to blow me off - at least where it comes to "revenue attributable to Rob Seastrom", the negative impact has been nil. -r From geraint at koding.com Thu Jan 2 20:26:21 2014 From: geraint at koding.com (Geraint Jones) Date: Thu, 02 Jan 2014 12:26:21 -0800 Subject: Mikrotik Cloud Core Router and BGP real life experiences? In-Reply-To: <868uuygngm.fsf@valhalla.seastrom.com> Message-ID: As an update we put the first two into production on NYE Everything working as expected so far... From jra at baylink.com Fri Jan 3 01:02:26 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 2 Jan 2014 20:02:26 -0500 (EST) Subject: What's up at AOL? In-Reply-To: <52C5B138.1070502@tigertech.com> Message-ID: <12331933.2456.1388710946160.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Robert L Mathews" > > That is, should we stop fussing with this (everyone's hosed w/ AOL > > this week?) or is it just us? > > It's probably not just you. It's been happening intermittently to many > people since December 26. See, for example: Any chance this is related to the NoVa fiber outage being discussed on Outages? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jay+NANOG at tp.org Fri Jan 3 01:06:45 2014 From: jay+NANOG at tp.org (Jay Moran) Date: Thu, 2 Jan 2014 20:06:45 -0500 Subject: What's up at AOL? In-Reply-To: <12331933.2456.1388710946160.JavaMail.root@benjamin.baylink.com> References: <52C5B138.1070502@tigertech.com> <12331933.2456.1388710946160.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, Jan 2, 2014 at 8:02 PM, Jay Ashworth wrote: > Any chance this is related to the NoVa fiber outage being discussed on > Outages? > Not related. With the best non-answer I can muster right now: I decided not to reply after Peter replied. -- Jay Moran From frnkblk at iname.com Fri Jan 3 01:35:05 2014 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 2 Jan 2014 19:35:05 -0600 Subject: What's up at AOL? In-Reply-To: <54b61618$11afacbf$3c5c56e4$@flhsi.com> References: <54b61618$11afacbf$3c5c56e4$@flhsi.com> Message-ID: <009701cf0824$07e9ee50$17bdcaf0$@iname.com> We saw noticeable AOL email delivery issues on the 26th and 27th, but not since then. I saw nothing queued up New Year's Eve or New Year's Day. Today we saw a very few delivery delays, but that cleared up by 2:45 pm Central. The message we get is: Site aol.com () said after data sent: 421 4.2.1 "Service unavailable. Please try again later." Frank P.S. I'd encourage folk to join the mailop listserv (http://chilli.nosignal.org/mailman/listinfo/mailop) if they want to stay abreast of such issues (note that the listserv tries its hardest to avoid mail abuse issues, encouraging those folk to discuss those topics in avenues that specialize in them). I can't say that the mailop listserv has email admins for all the major freemail providers (if they do, they're lurking), but there's a reasonably sized community of ISPs and dotcom companies. -----Original Message----- From: Nick Olsen [mailto:nick at flhsi.com] Sent: Thursday, January 02, 2014 12:24 PM To: Barry Shein; nanog at nanog.org Subject: re: What's up at AOL? We're seeing mail backup toward AOL as well. All coming back Service Unavailable. Postmaster at aol.com has not responded to our inquiry yet. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Barry Shein" Sent: Thursday, January 02, 2014 12:46 PM To: nanog at nanog.org Subject: What's up at AOL? They've been accepting email only occasionally for a few days now. We're on FBL, check reputation is good/green. Sometimes we get DYN:T2 (according to AOL that's their code for it's our, AOL's, problem), sometimes just various forms of try later, Service not available, deferred, etc. typically after the DATA is sent so MAIL FROM and RCPT TO are ok or no error. I did get one response from postmaster at aol.com which said it was all fixed yesterday which it was for several hours and today thousands of msgs backed up for them again. I am just asking if anyone knows what's going on even in general terms. That is, should we stop fussing with this (everyone's hosed w/ AOL this week?) or is it just us? -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From andrew.duey at widerangebroadband.net Fri Jan 3 02:53:51 2014 From: andrew.duey at widerangebroadband.net (Andrew Duey) Date: Thu, 2 Jan 2014 20:53:51 -0600 Subject: Open source hardware In-Reply-To: References: Message-ID: I'm surprised nobody's mentioned vyatta.org or the new fork of VyOs. We are currently using the vyatta community edition and so far it's been good to to us. It depends on your hardware and how small of an ISP you are but it might be a great open source fit for you. --Andrew Duey On Jan 2, 2014, at 10:37 AM, Chris Russell wrote: > >> haven't been able to find anything that would fulfill the requirements that >> a smallish ISP might have. > > The Cumulus guys might be able to provide some pointers ? > > http://cumulusnetworks.com/ > > Chris > > From wingcomm at hotmail.com Fri Jan 3 04:18:10 2014 From: wingcomm at hotmail.com (R W) Date: Thu, 2 Jan 2014 23:18:10 -0500 Subject: Comcast/Level3 issues In-Reply-To: References: Message-ID: I'm seeing the same as well. Can anyone from Comcast/Level(3) reach out to me or provide comment. We're seeing heavy jitter and some packet loss most noticeable in NYC area connections between Level(3) and Comcast. -Rob > Date: Tue, 31 Dec 2013 09:45:00 -0800 > Subject: Comcast/Level3 issues > From: dwheet at gmail.com > To: nanog at nanog.org > > Looking for a networking contact at comcast and/or level3. I've been > having some slow speed issues with hitting some sites that's going through > level3 and I think there might be some congestion. > > Doug From matthew at matthew.at Fri Jan 3 04:57:14 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 02 Jan 2014 20:57:14 -0800 Subject: turning on comcast v6 In-Reply-To: <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> Message-ID: <52C6432A.3070608@matthew.at> On 12/30/2013 4:56 PM, Owen DeLong wrote: > You can accomplish the same thing in IPv4?. > > > Plug in Sally?s PC with Internet Connection Sharing turned on and watch as her > DHCP server takes over your network. Not nearly as fast as bad RAs do (as others have pointed out). > > Yes, you have to pay attention when you plug in a router just like you?d have to pay attention if you plugged in a DHCP server you were getting ready to recycle. But the ability to plug in a not-router and break things is oh so much greater. > > Incompetence in execution really isn?t the protocol?s fault. But it is the protocol designer's fault... and once shipped, the protocol's fault. There's all sorts of things that were known at the time IPv6 was designed that the designers failed to build solutions for. As an example, routers *could* be a lot smarter about sending RAs on a network where routers are already present, but that's not in the spec. Neither the ND DOS attack nor the need to protect against bogus RAs on every port of your switch but one (or rarely, two) are things that should have been a post-deployment surprise (to name just a couple pet peeves of mine... there's more design flaws that could have been easily avoided had enough people cared to do so). Matthew Kaufman From mysidia at gmail.com Fri Jan 3 05:01:52 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 2 Jan 2014 23:01:52 -0600 Subject: Open source hardware In-Reply-To: References: Message-ID: On Thu, Jan 2, 2014 at 8:53 PM, Andrew Duey < andrew.duey at widerangebroadband.net> wrote: > I'm surprised nobody's mentioned vyatta.org or the new fork of VyOs. We > are currently using the vyatta community edition and so far it's been good > to to us. It depends on your hardware and how small of an ISP you are but > it might be a great open source fit for you. The orig. author has potentially set course for a world of hurt -- if the plan is to scrap robust packaged highly-validated gear having separate hardware forwarding planes and ASIC-driven filtering, to stick cheap x86 servers in the SP core and internet borders. Sure... anyone can install Vyatta on a x86 server, but assembly of all the pieces and full validation for a resilient platform comparable to carrier grade gear, for a mission critical network, should be a bit more involved than that. Next up.... how to build your own 10-Gigabit SFPs to avoid paying for expensive brand-name SFPs, by putting together some chips, wires, fiber, and tying it all together with a piece of duck tape.... just saying... :) > --Andrew Duey > -- -JH From jmamodio at gmail.com Fri Jan 3 05:31:07 2014 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 2 Jan 2014 23:31:07 -0600 Subject: Open source hardware In-Reply-To: <409783563.384871.1388678009422.JavaMail.root@snappytelecom.net> References: <409783563.384871.1388678009422.JavaMail.root@snappytelecom.net> Message-ID: I use a RouterBoard with RouterOS and afaik not the hardware nor the software are open -Jorge > On Jan 2, 2014, at 9:53 AM, Faisal Imtiaz wrote: > > Have you looked at Mikrotik.com (Software) and Routerboard.com (Hardware) > From trejrco at gmail.com Fri Jan 3 06:30:03 2014 From: trejrco at gmail.com (TJ) Date: Fri, 3 Jan 2014 01:30:03 -0500 Subject: turning on comcast v6 In-Reply-To: <52C6432A.3070608@matthew.at> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> Message-ID: I'd argue that while the timing may be different, RA and DHCP attacks are largely the same and are simply variations on a theme. And, regardless of the protocol in question, represent attacks which should be defended against. As is often (always?) the case, there are tradeoffs - and the pros and cons of those tradeoffs will be weighted differently by different parties. /TJ On Jan 3, 2014 12:00 AM, "Matthew Kaufman" wrote: > > On 12/30/2013 4:56 PM, Owen DeLong wrote: >> >> You can accomplish the same thing in IPv4?. >> >> >> Plug in Sally?s PC with Internet Connection Sharing turned on and watch as her >> DHCP server takes over your network. > > > Not nearly as fast as bad RAs do (as others have pointed out). > > >> >> Yes, you have to pay attention when you plug in a router just like you?d have to pay attention if you plugged in a DHCP server you were getting ready to recycle. > > > But the ability to plug in a not-router and break things is oh so much greater. > >> >> Incompetence in execution really isn?t the protocol?s fault. > > > But it is the protocol designer's fault... and once shipped, the protocol's fault. There's all sorts of things that were known at the time IPv6 was designed that the designers failed to build solutions for. As an example, routers *could* be a lot smarter about sending RAs on a network where routers are already present, but that's not in the spec. > > Neither the ND DOS attack nor the need to protect against bogus RAs on every port of your switch but one (or rarely, two) are things that should have been a post-deployment surprise (to name just a couple pet peeves of mine... there's more design flaws that could have been easily avoided had enough people cared to do so). > > Matthew Kaufman > > > From erey at ernw.de Fri Jan 3 07:35:00 2014 From: erey at ernw.de (Enno Rey) Date: Fri, 3 Jan 2014 08:35:00 +0100 Subject: turning on comcast v6 In-Reply-To: <52C6432A.3070608@matthew.at> References: <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> Message-ID: <20140103073500.GG52430@ernw.de> Hi, On Thu, Jan 02, 2014 at 08:57:14PM -0800, Matthew Kaufman wrote: > On 12/30/2013 4:56 PM, Owen DeLong wrote: > > You can accomplish the same thing in IPv4?. > > > > > > Plug in Sally?s PC with Internet Connection Sharing turned on and watch as her > > DHCP server takes over your network. for the record it should be noted that this particular issue was fixed by Microsoft a while ago (see http://support.microsoft.com/kb/2750841/en-us). best Enno > > Not nearly as fast as bad RAs do (as others have pointed out). > > > > > Yes, you have to pay attention when you plug in a router just like you?d have to pay attention if you plugged in a DHCP server you were getting ready to recycle. > > But the ability to plug in a not-router and break things is oh so much > greater. > > > > Incompetence in execution really isn?t the protocol?s fault. > > But it is the protocol designer's fault... and once shipped, the > protocol's fault. There's all sorts of things that were known at the > time IPv6 was designed that the designers failed to build solutions for. > As an example, routers *could* be a lot smarter about sending RAs on a > network where routers are already present, but that's not in the spec. > > Neither the ND DOS attack nor the need to protect against bogus RAs on > every port of your switch but one (or rarely, two) are things that > should have been a post-deployment surprise (to name just a couple pet > peeves of mine... there's more design flaws that could have been easily > avoided had enough people cared to do so). > > Matthew Kaufman > > > -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de ======================================================= From dougb at dougbarton.us Fri Jan 3 08:40:42 2014 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 03 Jan 2014 00:40:42 -0800 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> Message-ID: <52C6778A.5070309@dougbarton.us> On 01/02/2014 10:30 PM, TJ wrote: > I'd argue that while the timing may be different, RA and DHCP attacks > are largely the same and are simply variations on a theme. Utter nonsense. The ability to nearly-instantly switch traffic for nearly-all nodes on the network is a very different thing than what a rogue DHCP server could do, even if you have ridiculously short lease times, which most don't. Further, by far the common case is for network gear to _already_ be configured to avoid permitting hosts to act as DHCP servers unless they are supposed to be. It's rare to even find a network device that has RA Guard capabilities, never mind one that has them turned on. There is simply no good reason not to include default route in the configuration for DHCPv6, and it's long overdue. Doug From baldur.norddahl at gmail.com Fri Jan 3 09:15:38 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 3 Jan 2014 10:15:38 +0100 Subject: turning on comcast v6 In-Reply-To: <52C6778A.5070309@dougbarton.us> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> <52C6778A.5070309@dougbarton.us> Message-ID: On Fri, Jan 3, 2014 at 9:40 AM, Doug Barton wrote: > On 01/02/2014 10:30 PM, TJ wrote: > >> I'd argue that while the timing may be different, RA and DHCP attacks >> are largely the same and are simply variations on a theme. >> > > Utter nonsense. The ability to nearly-instantly switch traffic for > nearly-all nodes on the network is a very different thing than what a rogue > DHCP server could do, even if you have ridiculously short lease times, > which most don't. > The IPv6 protocol does not give you such an ability (by accident - a hacker can steal your IPv4 network too with your completely unprotected network). There seems to be a lack of detailed understanding of the RFCs in this thread. Adding a new router to an already running network will add a second router to all clients. But no clients will actually switch to the new router unless the old one fails. That is the behavior specified in the RFC. Actual implementations might do something different, but that is hardly the fault of the protocol designer. Have anyone here actually tested this, or are we just making up stuff? Another person claimed that there would be 15 minuttes or more until the network was fixed, after removing a rogue router. That too is completely wrong. Every client will monitor the currently used router. If it stops responding for 30 seconds, the clients will switch to an alternative router. Also, routers are supposed to monitor their uplink. If the uplink is down, no RA should be sent on the downlinks and any current active prefixed should be withdrawn. Not all routers implement this, but at the least the CPEs are starting to do it correctly. This whole thread builds on the assumption that you are using equipment with either bad implementation or bad configuration. Blocking RA from client ports is just one simple ACL rule on the switch. Many vendors have a very simple option to enable it. You are not running a clean ship if you skip this, just the same as you are required to block DHCP servers from client ports. Regards Baldur From dougb at dougbarton.us Fri Jan 3 09:24:22 2014 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 03 Jan 2014 01:24:22 -0800 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> <52C6778A.5070309@dougbarton.us> Message-ID: <52C681C6.3080402@dougbarton.us> On 01/03/2014 01:15 AM, Baldur Norddahl wrote: > On Fri, Jan 3, 2014 at 9:40 AM, Doug Barton wrote: > >> On 01/02/2014 10:30 PM, TJ wrote: >> >>> I'd argue that while the timing may be different, RA and DHCP attacks >>> are largely the same and are simply variations on a theme. >>> >> >> Utter nonsense. The ability to nearly-instantly switch traffic for >> nearly-all nodes on the network is a very different thing than what a rogue >> DHCP server could do, even if you have ridiculously short lease times, >> which most don't. >> > > The IPv6 protocol does not give you such an ability (by accident - a hacker > can steal your IPv4 network too with your completely unprotected network). ... and yet most IPv4 networks are not "completely unprotected." > There seems to be a lack of detailed understanding of the RFCs in this > thread. You can rest assured that I know them pretty well. > Adding a new router to an already running network will add a second > router to all clients. But no clients will actually switch to the new > router unless the old one fails. ... which is simple to accomplish with a DOS, even if the clients implement the protocol correctly. > That is the behavior specified in the RFC. Actual implementations might do > something different, but that is hardly the fault of the protocol designer. > Have anyone here actually tested this, or are we just making up stuff? It's been demonstrated several times at various venues, including at least 1 IETF meeting. > Another person claimed that there would be 15 minuttes or more until the > network was fixed, after removing a rogue router. That too is completely > wrong. Every client will monitor the currently used router. If it stops > responding for 30 seconds, the clients will switch to an alternative router. Again, you're assuming that the clients implement correctly, however I think this one is more common than not since this behavior has been prescribed long enough now. > Also, routers are supposed to monitor their uplink. If the uplink is down, > no RA should be sent on the downlinks and any current active prefixed > should be withdrawn. Not all routers implement this, but at the least the > CPEs are starting to do it correctly. This whole thread builds on the > assumption that you are using equipment with either bad implementation or > bad configuration. ... or old enough not to have the latest bells and whistles. And I would also argue that when it comes to IPv6 "bad configuration" is still more common than not. > Blocking RA from client ports is just one simple ACL rule on the switch. If your switch has that code. Given that RA Guard is a fairly recent invention, I would argue that at minimum the common case is that any random network device does not. And you still haven't provided an argument about why the default route should not be added to DHCPv6. Doug From mpalmer at hezmatt.org Fri Jan 3 09:55:13 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Fri, 3 Jan 2014 20:55:13 +1100 Subject: turning on comcast v6 In-Reply-To: <52C6778A.5070309@dougbarton.us> References: <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> <52C6778A.5070309@dougbarton.us> Message-ID: <20140103095513.GN497@hezmatt.org> On Fri, Jan 03, 2014 at 12:40:42AM -0800, Doug Barton wrote: > Further, by far the common case is for network gear to _already_ be > configured to avoid permitting hosts to act as DHCP servers unless > they are supposed to be. It's rare to even find a network device > that has RA Guard capabilities, never mind one that has them turned > on. Do devices commonly have DHCPv6 filtering capabilities? I would imagine they'd be about as common as RA guard, and if so, this is a moot argument. - Matt -- It fsck's the volume or it gets the format again. -- Don Quixote, in the Monastery From daniel.crompton at gmail.com Fri Jan 3 10:05:30 2014 From: daniel.crompton at gmail.com (=?UTF-8?Q?Dani=C3=ABl_W=2E_Crompton?=) Date: Fri, 3 Jan 2014 11:05:30 +0100 Subject: Open source hardware In-Reply-To: References: Message-ID: Good point Jimmy, there is a world of hurt involved, although it may be slightly less painless when you realize that the alternative is: "*the NSA [who] has modified the firmware of computers and network hardware?including systems shipped by Cisco, Dell, Hewlett-Packard, Huawei, and Juniper Networks?to give its operators both eyes and ears inside the offices the agency has targeted.*"[1] There's already a world of hurt involved when you can't trust your equipment because they potentially have backdoors in them. D. 1. http://arstechnica.com/information-technology/2013/12/inside-the-nsas-leaked-catalog-of-surveillance-magic/ Oplerno is built upon empowering faculty and students We want you to found (and fund) Oplerno with us [image: Support Us Here] -- Dani?l W. Crompton http://specialbrands.net/ On 3 January 2014 06:01, Jimmy Hess wrote: > On Thu, Jan 2, 2014 at 8:53 PM, Andrew Duey < > andrew.duey at widerangebroadband.net> wrote: > > > I'm surprised nobody's mentioned vyatta.org or the new fork of VyOs. We > > are currently using the vyatta community edition and so far it's been > good > > to to us. It depends on your hardware and how small of an ISP you are > but > > it might be a great open source fit for you. > > > The orig. author has potentially set course for a world of hurt -- if the > plan is to scrap robust packaged highly-validated gear having separate > hardware forwarding planes and ASIC-driven filtering, to stick cheap x86 > servers in the SP core and internet borders. > > Sure... anyone can install Vyatta on a x86 server, but assembly of all > the pieces and full validation for a resilient platform comparable to > carrier grade gear, for a mission critical network, should be a bit more > involved than that. > > Next up.... how to build your own 10-Gigabit SFPs to avoid paying for > expensive brand-name SFPs, by putting together some chips, wires, fiber, > and tying it all together with a piece of duck tape.... > > just saying... :) > > > > --Andrew Duey > > > -- > -JH > From baldur.norddahl at gmail.com Fri Jan 3 12:01:04 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 3 Jan 2014 13:01:04 +0100 Subject: turning on comcast v6 In-Reply-To: <52C681C6.3080402@dougbarton.us> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> <52C6778A.5070309@dougbarton.us> <52C681C6.3080402@dougbarton.us> Message-ID: On Fri, Jan 3, 2014 at 10:24 AM, Doug Barton wrote: > ... and yet most IPv4 networks are not "completely unprotected." > We are apparently talking about "completely unprotected" networks here. Otherwise there is simply no problem. You would be filtering RA and many other things, because that is best practice and required by many security standards besides. > > ... which is simple to accomplish with a DOS, even if the clients > implement the protocol correctly. If we are on an unprotected network and we have evil intend, all is lost. The hacker can simply steal the traffic with a simple arp ping or a ton of other methods. The original claim was not evil intend, but that of an accident. But it still requires three mistakes: bad clients, bad routers and bad configuration. > > > That is the behavior specified in the RFC. Actual implementations might do >> something different, but that is hardly the fault of the protocol >> designer. >> Have anyone here actually tested this, or are we just making up stuff? >> > > It's been demonstrated several times at various venues, including at least > 1 IETF meeting. Doesn't work when I try it. The clients just keep using the old gateway and prefix. But I can't rule out there are bad clients out there, just that it does not happen on my network. Can you give any examples of bad clients? > Another person claimed that there would be 15 minuttes or more until the >> network was fixed, after removing a rogue router. That too is completely >> wrong. Every client will monitor the currently used router. If it stops >> responding for 30 seconds, the clients will switch to an alternative >> router. >> > > Again, you're assuming that the clients implement correctly, however I > think this one is more common than not since this behavior has been > prescribed long enough now. This one is something that all major clients have correctly by now. It is a rather common use case for IPv6 after all. The user connects two gateways to his network and gets carefree automatic failover with a 30 seconds timer to detect failure. May not be good enough for your enterprise network, but sure is quite useful in the SOHO environment. And you still haven't provided an argument about why the default route >> should not be added to DHCPv6. > > I was not arguing that it didn't. Just that the perceived problem is not real. However, I might be inclined to believe that default route in DHCPv6 is a bad idea. It is a confusing concept, since we already no less than three methods (*) to discover default route and you want to add a fourth. This would be something that needs to be implemented in every client, and thus will not really be usable for at least a decade. By then everyone are used to RA. If you did add default route to DHCPv6, what is then supposed to happen to the other routes, that the client might discover? By the arguments in this thread, you do not really want default route from RA, but instead some security mechanism, that would prevent the client from obtaining routes and prefixes in addition to the one you provided. That seems to be a completely different issue. (*) prefix::, fe80:: and the one you get from RA. Regards, Baldur From rps at maine.edu Fri Jan 3 12:48:24 2014 From: rps at maine.edu (Ray Soucy) Date: Fri, 3 Jan 2014 07:48:24 -0500 Subject: Open source hardware In-Reply-To: References: Message-ID: You actually buy brand-name SFP's? That's like buying the gold-plated HDMI Monster Cable at Best Buy at markup ... I just find the the companies that the vendors contract to make their OEM SFP's and buy direct. Same SFP from the same factory except one has a Cisco sticker. ;-) You can even get them with the correct vendor code, been doing this for years and there is no difference in failure rate or quality and we go through hundreds of SFPs. It is nice to have a solution provider if you're only looking at one unit, but if you're deploying a large amount then building and testing your own configuration really isn't that hard and will save you a lot of money. You can even contract an OEM appliance vendor to take care of the actual build for you and they'll usually provide 3-year replacement on the hardware. (I've found "Sourcecode" to be the best price-wise for smaller projects). As a bonus they'll slap whatever branding you want on the thing for that professional touch. Vyatta and now VyOS are important projects for networking. We really need to get away from locked down non-free hardware and software for critical infrastructure. It's natural that most of the people in this community (myself included) will be fans of companies like Cisco and Juniper and dismiss anything else, but that mindset for me change when I deployed 100+ whitebox units 3 years ago and saved nearly a million in the process. Juniper is a FreeBSD shop, and Cisco's new OS lines are based on Linux. Ciena is largely based on Linux as well. In poking around at these platforms recently one of the big things I'm noticing is that there is a lot less done in hardware than we traditionally saw, especially from Cisco. Having your networking in silicon is great when you have a 100 MHz CPU; Cisco even conditioned us to be terrified of anything being punted to CPU by under-sizing and over-pricing their CPUs for years. But when you have a modern server-grade platform, multi-Gigabit performance, even with significant levels of packet processing and small packet sizes, is a joke. So at least for the low end of the spectrum there is a huge savings for equal (often better) performance. As I mentioned before I haven't done much with 10-Gigabit, but I imagine with Intel-based cards on a modern PCIe bus that you can at least get entry-level performance. Sometimes the biggest push for 10G is avoiding a 2G or 4G port-channel. With the new Intel DPDK stuff, Intel is claiming 80M PPS performance on a standard Xeon platform: http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/packet-processing-is-enhanced-with-software-from-intel-dpdk.html Eventually, DPDK support will likely start being included in projects like VyOS, perhaps in Linux in general. As for VyOS, the project is starting to get some momentum and is run by former Vyatta employees and even some people from UBNT. I think we'll see some good stuff from them in the future. The 1.0 release is solid from what I've seen (and even fixes some bugs Vyatta hasn't yet). On Fri, Jan 3, 2014 at 12:01 AM, Jimmy Hess wrote: > On Thu, Jan 2, 2014 at 8:53 PM, Andrew Duey < > andrew.duey at widerangebroadband.net> wrote: > > > I'm surprised nobody's mentioned vyatta.org or the new fork of VyOs. We > > are currently using the vyatta community edition and so far it's been > good > > to to us. It depends on your hardware and how small of an ISP you are > but > > it might be a great open source fit for you. > > > The orig. author has potentially set course for a world of hurt -- if the > plan is to scrap robust packaged highly-validated gear having separate > hardware forwarding planes and ASIC-driven filtering, to stick cheap x86 > servers in the SP core and internet borders. > > Sure... anyone can install Vyatta on a x86 server, but assembly of all > the pieces and full validation for a resilient platform comparable to > carrier grade gear, for a mission critical network, should be a bit more > involved than that. > > Next up.... how to build your own 10-Gigabit SFPs to avoid paying for > expensive brand-name SFPs, by putting together some chips, wires, fiber, > and tying it all together with a piece of duck tape.... > > just saying... :) > > > > --Andrew Duey > > > -- > -JH > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From ray at oneunified.net Fri Jan 3 13:10:48 2014 From: ray at oneunified.net (Raymond Burkholder) Date: Fri, 3 Jan 2014 09:10:48 -0400 Subject: Open source hardware In-Reply-To: References: Message-ID: <00dc01cf0885$38c60d90$aa5228b0$@oneunified.net> > > Vyatta and now VyOS are important projects for networking. We really need > to get away from locked down non-free hardware and software for critical > infrastructure. > > It's natural that most of the people in this community (myself included) > will be fans of companies like Cisco and Juniper and dismiss anything else, > but that mindset for me change when I deployed 100+ whitebox units 3 > years > ago and saved nearly a million in the process. > If all you want to do is push regular packets around, these opensource alternatives might be adequate to the task. But many networks catering to business endpoints deal with private circuit issues. Which generally leads to an MPLS/VPLS based infrastructure. Which I havn't seen in a reliable opensource flavor. But I could be mistaken. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From tnadeau at lucidvision.com Fri Jan 3 13:29:28 2014 From: tnadeau at lucidvision.com (Thomas Nadeau) Date: Fri, 3 Jan 2014 08:29:28 -0500 Subject: Open source hardware In-Reply-To: References: Message-ID: On Jan 3, 2014:12:01 AM, at 12:01 AM, Jimmy Hess wrote: > On Thu, Jan 2, 2014 at 8:53 PM, Andrew Duey < > andrew.duey at widerangebroadband.net> wrote: > >> I'm surprised nobody's mentioned vyatta.org or the new fork of VyOs. We >> are currently using the vyatta community edition and so far it's been good >> to to us. It depends on your hardware and how small of an ISP you are but >> it might be a great open source fit for you. > > > The orig. author has potentially set course for a world of hurt -- if the > plan is to scrap robust packaged highly-validated gear having separate > hardware forwarding planes and ASIC-driven filtering, to stick cheap x86 > servers in the SP core and internet borders. > > Sure... anyone can install Vyatta on a x86 server, but assembly of all > the pieces and full validation for a resilient platform comparable to > carrier grade gear, for a mission critical network, should be a bit more > involved than that. > > Next up.... how to build your own 10-Gigabit SFPs to avoid paying for > expensive brand-name SFPs, by putting together some chips, wires, fiber, > and tying it all together with a piece of duck tape.... > > just saying... :) That does seem a bit harsh given there are numerous examples of companies out there successfully putting together and deploying their own switches/routers in production. It may require significant resources and not be for the faint of heart, but from what I've seen, its far from a bailing wire and bubblegum operation. --Tom > > >> --Andrew Duey >> > -- > -JH > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From saku at ytti.fi Fri Jan 3 13:33:56 2014 From: saku at ytti.fi (Saku Ytti) Date: Fri, 3 Jan 2014 15:33:56 +0200 Subject: Open source hardware In-Reply-To: References: Message-ID: <20140103133356.GA25459@pob.ytti.fi> On (2014-01-03 07:48 -0500), Ray Soucy wrote: > > Juniper is a FreeBSD shop, and Cisco's new OS lines are based on Linux. > Ciena is largely based on Linux as well. In poking around at these > platforms recently one of the big things I'm noticing is that there is a > lot less done in hardware than we traditionally saw, especially from Cisco. I'm not sure which platforms you refer to. But if we look at SP segment we're talking about JNPR M, MX, T, PTX or Cisco ASR9k, NCS6k, CRS-1. JNPR is indeed FreeBSD, but FreeBSD is used very sparsely, to boot box up and to run RPD, which is essentially router-control-plane-in-a-process, it runs all routing protocols and configures hardware. ASR9k, CRS-1 run IOS-XR on QNX and NCS6k on Linux and there at least Cisco capitalizes on OS scheduling, it's not single fat process on top of OS. All of these boxes do all packet pushing in NPU (ezchip, trio, ichip...) For IOS XE boxes, it's almost same as JNPR, except instead of single process single threaded RPD, IOSd is actually running several threads. > by under-sizing and over-pricing their CPUs for years. But when you have a > modern server-grade platform, multi-Gigabit performance, even with > significant levels of packet processing and small packet sizes, is a joke. > So at least for the low end of the spectrum there is a huge savings for > equal (often better) performance. Low end has always been using COTS CPU, RISC, PPC etc, so not much has changed there. For low end, linux pc can be competitive in some applications. > With the new Intel DPDK stuff, Intel is claiming 80M PPS performance on a > standard Xeon platform: > http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/packet-processing-is-enhanced-with-software-from-intel-dpdk.html DPDK is super interesting and it shows Intel is looking at the NPU market, unfortunately these numbers have nothing to do with real-life application, lookup against million+ routes, ACLs, QoS etc. But maybe not in too distant future x86 Intel is usable as NPU, Intel seems to be looking NPU market demands when designing new x86 chips. Right now, if you need perfomance, you're going to have to buy something like bcom chip and then cumulusnetworks linux on top of it, it's as close to 'open source' as you're going to get with good performance. And this is more or less DC stuff, SP market needs more intelligent chips than those ASICs, and I don't think there anything 'open source' in the market place for NPU stuff. -- ++ytti From scott at sberkman.net Fri Jan 3 15:55:04 2014 From: scott at sberkman.net (Scott Berkman) Date: Fri, 03 Jan 2014 10:55:04 -0500 Subject: Comcast/Level3 issues In-Reply-To: References: Message-ID: <52C6DD58.9060802@sberkman.net> Comcast having saturated links to other providers is a common and frequently discussed issue. Here is one previous NANOG thread on the topic: http://mailman.nanog.org/pipermail/nanog/2010-December/029251.html And a related article: http://www.dslreports.com/shownews/Claims-Resurface-Concerning-Congested-Comcast-TATA-Links-111818 There are debates back and forth on the validity of the graphs from the NANOG post, but it is a fact that at that time Comcast was heavily pre-pending their Level BGP advertisements to force traffic over to Tata, and many many people noticed congestion at those links in a variety of markets. I wish you luck, but my personal opinion is that your fastest resolution would be to move to another provider. Comcast is a residential ISP that lives on extreme over-subscription and not actually being able to deliver what customers believe they have. You'll notice a lot of recent news about increased and more strict data caps for their subscribers, and that is the only thing they will likely be doing to relieve these types of recurring issues. -Scott On 01/02/2014 11:18 PM, R W wrote: > I'm seeing the same as well. Can anyone from Comcast/Level(3) reach out to me or provide comment. We're seeing heavy jitter and some packet loss most noticeable in NYC area connections between Level(3) and Comcast. > -Rob > >> Date: Tue, 31 Dec 2013 09:45:00 -0800 >> Subject: Comcast/Level3 issues >> From: dwheet at gmail.com >> To: nanog at nanog.org >> >> Looking for a networking contact at comcast and/or level3. I've been >> having some slow speed issues with hitting some sites that's going through >> level3 and I think there might be some congestion. >> >> Doug > From bicknell at ufp.org Fri Jan 3 16:09:54 2014 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 3 Jan 2014 10:09:54 -0600 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> Message-ID: On Jan 3, 2014, at 12:30 AM, TJ wrote: > I'd argue that while the timing may be different, RA and DHCP attacks are > largely the same and are simply variations on a theme. Rogue RA's can take down statically IPv6'ed boxes. Rogue DHCP servers will never affect a statically configured IPv4 box. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From gary.buhrmaster at gmail.com Fri Jan 3 17:35:16 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Fri, 3 Jan 2014 17:35:16 +0000 Subject: turning on comcast v6 In-Reply-To: References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> Message-ID: On Fri, Jan 3, 2014 at 4:09 PM, Leo Bicknell wrote: .... > Rogue RA's can take down statically IPv6'ed boxes. > > Rogue DHCP servers will never affect a statically configured IPv4 box. I believe that that would depend on whether your configuration of a static IPv6 address on your box also disabled accepting RA. On LInux, I believe it is something like net.ipv6.conf..autoconf=0 and net.ipv6.conf..accept_ra=0 (could easily be typos there, doing it from memory). As with much else, your devops scripts/processes may need to change for IPv6 vs IPv4 (which is why, especially for enterprises, it is not as easy as just turning it on). From cscora at apnic.net Fri Jan 3 18:12:26 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 4 Jan 2014 04:12:26 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201401031812.s03ICQTQ023065@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 04 Jan, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 477051 Prefixes after maximum aggregation: 190299 Deaggregation factor: 2.51 Unique aggregates announced to Internet: 236730 Total ASes present in the Internet Routing Table: 45828 Prefixes per ASN: 10.41 Origin-only ASes present in the Internet Routing Table: 35488 Origin ASes announcing only one prefix: 16270 Transit ASes present in the Internet Routing Table: 5982 Transit-only ASes present in the Internet Routing Table: 177 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 2654 Unregistered ASNs in the Routing Table: 627 Number of 32-bit ASNs allocated by the RIRs: 5637 Number of 32-bit ASNs visible in the Routing Table: 4358 Prefixes from 32-bit ASNs in the Routing Table: 13805 Number of bogon 32-bit ASNs visible in the Routing Table: 1 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 1728 Number of addresses announced to Internet: 2661253372 Equivalent to 158 /8s, 159 /16s and 128 /24s Percentage of available address space announced: 71.9 Percentage of allocated address space announced: 71.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 95.4 Total number of prefixes smaller than registry allocations: 166280 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 113324 Total APNIC prefixes after maximum aggregation: 34178 APNIC Deaggregation factor: 3.32 Prefixes being announced from the APNIC address blocks: 115676 Unique aggregates announced from the APNIC address blocks: 48507 APNIC Region origin ASes present in the Internet Routing Table: 4870 APNIC Prefixes per ASN: 23.75 APNIC Region origin ASes announcing only one prefix: 1210 APNIC Region transit ASes present in the Internet Routing Table: 841 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 28 Number of APNIC region 32-bit ASNs visible in the Routing Table: 797 Number of APNIC addresses announced to Internet: 730192064 Equivalent to 43 /8s, 133 /16s and 216 /24s Percentage of available APNIC address space announced: 85.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 163539 Total ARIN prefixes after maximum aggregation: 81812 ARIN Deaggregation factor: 2.00 Prefixes being announced from the ARIN address blocks: 164167 Unique aggregates announced from the ARIN address blocks: 75856 ARIN Region origin ASes present in the Internet Routing Table: 15928 ARIN Prefixes per ASN: 10.31 ARIN Region origin ASes announcing only one prefix: 5986 ARIN Region transit ASes present in the Internet Routing Table: 1673 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 53 Number of ARIN addresses announced to Internet: 1074982272 Equivalent to 64 /8s, 18 /16s and 237 /24s Percentage of available ARIN address space announced: 56.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, 62464-63487, 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, 23/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, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 120105 Total RIPE prefixes after maximum aggregation: 61366 RIPE Deaggregation factor: 1.96 Prefixes being announced from the RIPE address blocks: 123796 Unique aggregates announced from the RIPE address blocks: 79325 RIPE Region origin ASes present in the Internet Routing Table: 17586 RIPE Prefixes per ASN: 7.04 RIPE Region origin ASes announcing only one prefix: 8315 RIPE Region transit ASes present in the Internet Routing Table: 2840 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2550 Number of RIPE addresses announced to Internet: 654989700 Equivalent to 39 /8s, 10 /16s and 89 /24s Percentage of available RIPE address space announced: 95.2 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, 56320-58367 59392-61439, 61952-62463, 196608-200191 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 53686 Total LACNIC prefixes after maximum aggregation: 10068 LACNIC Deaggregation factor: 5.33 Prefixes being announced from the LACNIC address blocks: 59163 Unique aggregates announced from the LACNIC address blocks: 27528 LACNIC Region origin ASes present in the Internet Routing Table: 2059 LACNIC Prefixes per ASN: 28.73 LACNIC Region origin ASes announcing only one prefix: 552 LACNIC Region transit ASes present in the Internet Routing Table: 404 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 35 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 950 Number of LACNIC addresses announced to Internet: 147393336 Equivalent to 8 /8s, 201 /16s and 11 /24s Percentage of available LACNIC address space announced: 87.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 11799 Total AfriNIC prefixes after maximum aggregation: 2616 AfriNIC Deaggregation factor: 4.51 Prefixes being announced from the AfriNIC address blocks: 12521 Unique aggregates announced from the AfriNIC address blocks: 4190 AfriNIC Region origin ASes present in the Internet Routing Table: 698 AfriNIC Prefixes per ASN: 17.94 AfriNIC Region origin ASes announcing only one prefix: 207 AfriNIC Region transit ASes present in the Internet Routing Table: 143 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 8 Number of AfriNIC addresses announced to Internet: 48539392 Equivalent to 2 /8s, 228 /16s and 167 /24s Percentage of available AfriNIC address space announced: 48.2 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2945 11558 952 Korea Telecom 17974 2731 902 88 PT Telekomunikasi Indonesia 7545 2121 319 112 TPG Telecom Limited 4755 1812 392 191 TATA Communications formerly 9829 1563 1255 41 National Internet Backbone 9583 1295 101 537 Sify Limited 9498 1235 309 71 BHARTI Airtel Ltd. 7552 1226 1080 13 Viettel Corporation 4808 1141 2120 348 CNCGROUP IP network China169 24560 1098 382 167 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3029 3688 53 BellSouth.net Inc. 22773 2319 2939 138 Cox Communications Inc. 1785 2146 686 131 PaeTec Communications, Inc. 18566 2050 379 178 MegaPath Corporation 20115 1682 1665 593 Charter Communications 4323 1627 1081 411 tw telecom holdings, inc. 701 1506 11144 778 MCI Communications Services, 30036 1376 310 572 Mediacom Communications Corp 7018 1307 17746 847 AT&T Services, Inc. 6983 1294 756 580 ITC^Deltacom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1841 544 16 OJSC "Vimpelcom" 34984 1361 243 227 TELLCOM ILETISIM HIZMETLERI A 20940 1207 455 907 Akamai International B.V. 31148 1012 45 20 Freenet Ltd. 13188 922 100 26 TOV "Bank-Inform" 6849 857 361 35 JSC "Ukrtelecom" 8551 856 370 38 Bezeq International-Ltd 6830 770 2327 423 Liberty Global Operations B.V 12479 685 798 53 France Telecom Espana SA 35228 551 246 16 Telefonica UK Limited Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3438 1839 91 NET Servi?os de Comunica??o S 10620 2691 435 209 Telmex Colombia S.A. 18881 1790 908 20 Global Village Telecom 7303 1743 1163 230 Telecom Argentina S.A. 8151 1371 2857 429 Uninet S.A. de C.V. 11830 868 364 15 Instituto Costarricense de El 27947 858 93 89 Telconet S.A 7738 813 1562 37 Telemar Norte Leste S.A. 6503 792 434 60 Axtel, S.A.B. de C.V. 6147 780 373 27 Telefonica del Peru S.A.A. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1857 112 5 Sudanese Mobile Telephone (ZA 24863 893 338 26 Link Egypt (Link.NET) 6713 600 653 27 Office National des Postes et 8452 450 956 9 TE-AS 24835 299 144 9 Vodafone Data 3741 247 921 209 Internet Solutions 29571 240 21 14 Cote d'Ivoire Telecom 36992 226 505 27 ETISALAT MISR 15706 219 32 6 Sudatel (Sudan Telecom Co. Lt 29975 192 668 21 Vodacom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3438 1839 91 NET Servi?os de Comunica??o S 6389 3029 3688 53 BellSouth.net Inc. 4766 2945 11558 952 Korea Telecom 17974 2731 902 88 PT Telekomunikasi Indonesia 10620 2691 435 209 Telmex Colombia S.A. 22773 2319 2939 138 Cox Communications Inc. 1785 2146 686 131 PaeTec Communications, Inc. 7545 2121 319 112 TPG Telecom Limited 18566 2050 379 178 MegaPath Corporation 36998 1857 112 5 Sudanese Mobile Telephone (ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3029 2976 BellSouth.net Inc. 17974 2731 2643 PT Telekomunikasi Indonesia 10620 2691 2482 Telmex Colombia S.A. 22773 2319 2181 Cox Communications Inc. 1785 2146 2015 PaeTec Communications, Inc. 7545 2121 2009 TPG Telecom Limited 4766 2945 1993 Korea Telecom 18566 2050 1872 MegaPath Corporation 36998 1857 1852 Sudanese Mobile Telephone (ZA 8402 1841 1825 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.192.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.196.0/22 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.200.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.202.0/23 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 62828 UNALLOCATED 8.21.130.0/24 4323 tw telecom holdings, 62850 UNALLOCATED 8.25.147.0/24 46887 Lightower Fiber Netw 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.90.128.0/18 27418 OUTOFWALL INC. 23.91.0.0/19 40676 Psychz Networks 23.91.14.0/24 40676 Psychz Networks 23.91.32.0/19 36315 Servpac Inc. 23.91.80.0/20 21560 Netstream Communications, LLC 23.91.96.0/20 37958 Beijing Blue I.T Technologies 23.91.112.0/21 32475 SingleHop 23.91.120.0/21 36351 SoftLayer Technologies Inc. 23.91.160.0/19 36493 FIBERNETICS CORPORATION 23.91.160.0/22 36493 FIBERNETICS CORPORATION Complete listing at http://thyme.rand.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:16 /9:11 /10:31 /11:92 /12:254 /13:473 /14:937 /15:1636 /16:12856 /17:6785 /18:11435 /19:23329 /20:33183 /21:35757 /22:50722 /23:44179 /24:253010 /25:798 /26:953 /27:433 /28:47 /29:71 /30:28 /31:0 /32:15 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2005 2050 MegaPath Corporation 36998 1822 1857 Sudanese Mobile Telephone (ZA 6389 1699 3029 BellSouth.net Inc. 22773 1563 2319 Cox Communications Inc. 8402 1530 1841 OJSC "Vimpelcom" 30036 1217 1376 Mediacom Communications Corp 1785 1163 2146 PaeTec Communications, Inc. 11492 1152 1189 CABLE ONE, INC. 6983 1036 1294 ITC^Deltacom 22561 977 1252 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:935 2:843 3:3 4:16 5:840 6:21 8:638 12:1872 13:3 14:898 15:9 16:3 17:20 18:24 20:36 23:653 24:1752 27:1691 31:1514 32:44 33:2 34:5 36:111 37:1944 38:917 39:5 40:182 41:3329 42:246 44:14 46:2116 47:10 49:707 50:857 52:12 54:44 55:3 56:4 57:26 58:1141 59:590 60:369 61:1501 62:1202 63:1966 64:4375 65:2334 66:4133 67:2096 68:1084 69:3307 70:907 71:510 72:2023 74:2584 75:321 76:304 77:1146 78:1028 79:682 80:1283 81:1084 82:645 83:737 84:649 85:1215 86:400 87:1012 88:523 89:1581 90:152 91:5719 92:636 93:1614 94:2112 95:1466 96:531 97:351 98:1081 99:41 100:33 101:701 103:3890 105:534 106:142 107:348 108:548 109:2036 110:978 111:1140 112:602 113:814 114:767 115:1052 116:1015 117:833 118:1222 119:1292 120:325 121:774 122:1884 123:1290 124:1398 125:1456 128:654 129:236 130:356 131:665 132:341 133:159 134:320 135:73 136:277 137:271 138:354 139:174 140:202 141:353 142:551 143:405 144:499 145:92 146:566 147:428 148:789 149:361 150:152 151:481 152:410 153:208 154:50 155:526 156:316 157:418 158:287 159:809 160:360 161:465 162:976 163:232 164:663 165:586 166:281 167:639 168:1037 169:123 170:1162 171:185 172:12 173:1692 174:670 175:551 176:1361 177:2596 178:1924 179:345 180:1604 181:931 182:1424 183:479 184:633 185:1179 186:2790 187:1463 188:1957 189:1283 190:7318 191:16 192:7048 193:5431 194:4025 195:3404 196:1346 197:1063 198:4815 199:5527 200:6057 201:2557 202:9008 203:8926 204:4537 205:2638 206:2909 207:2820 208:3955 209:3708 210:3080 211:1630 212:2170 213:1952 214:869 215:83 216:5448 217:1723 218:608 219:323 220:1271 221:587 222:349 223:565 End of report From cidr-report at potaroo.net Fri Jan 3 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 Jan 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201401032200.s03M00fF090077@wattle.apnic.net> This report has been generated at Fri Jan 3 21:13:36 2014 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/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 27-12-13 487889 276126 28-12-13 487721 276123 29-12-13 488280 275996 30-12-13 488248 276380 31-12-13 488174 276235 01-01-14 488090 276393 02-01-14 487965 276293 03-01-14 488006 276292 AS Summary 45975 Number of ASes in routing system 18840 Number of ASes announcing only one prefix 4184 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 118702848 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 03Jan14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 487878 276297 211581 43.4% All ASes AS28573 3438 93 3345 97.3% NET Servi?os de Comunica??o S.A. AS6389 3029 56 2973 98.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS17974 2730 190 2540 93.0% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7029 4184 1731 2453 58.6% WINDSTREAM - Windstream Communications Inc AS4766 2945 961 1984 67.4% KIXS-AS-KR Korea Telecom AS18881 1790 31 1759 98.3% Global Village Telecom AS1785 2146 390 1756 81.8% AS-PAETEC-NET - PaeTec Communications, Inc. AS10620 2691 1080 1611 59.9% Telmex Colombia S.A. AS18566 2049 565 1484 72.4% MEGAPATH5-US - MegaPath Corporation AS36998 1857 400 1457 78.5% SDN-MOBITEL AS4323 2938 1513 1425 48.5% TWTC - tw telecom holdings, inc. AS7303 1744 462 1282 73.5% Telecom Argentina S.A. AS4755 1812 596 1216 67.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 2322 1157 1165 50.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS7552 1255 192 1063 84.7% VIETEL-AS-AP Viettel Corporation AS22561 1252 225 1027 82.0% AS22561 - CenturyTel Internet Holdings, Inc. AS9829 1563 646 917 58.7% BSNL-NIB National Internet Backbone AS7545 2122 1307 815 38.4% TPG-INTERNET-AP TPG Telecom Limited AS18101 990 186 804 81.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS35908 901 100 801 88.9% VPLSNET - Krypt Technologies AS4808 1141 386 755 66.2% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS701 1507 778 729 48.4% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS24560 1098 374 724 65.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS6983 1294 580 714 55.2% ITCDELTA - ITC^Deltacom AS13977 855 143 712 83.3% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS8151 1362 651 711 52.2% Uninet S.A. de C.V. AS4788 895 212 683 76.3% TMNET-AS-AP TM Net, Internet Service Provider AS855 733 57 676 92.2% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS7738 813 139 674 82.9% Telemar Norte Leste S.A. AS6147 781 113 668 85.5% Telefonica del Peru S.A.A. Total 54237 15314 38923 71.8% Top 30 total Possible Bogus Routes 23.92.208.0/20 AS31863 DACEN-2 - Dacentec, Inc. 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 41.73.2.0/24 AS37004 41.73.3.0/24 AS37004 41.73.4.0/24 AS37004 41.73.7.0/24 AS37004 41.73.8.0/24 AS37004 41.73.10.0/24 AS37004 41.73.11.0/24 AS37004 41.73.12.0/24 AS37004 41.73.13.0/24 AS37004 41.73.14.0/24 AS37004 41.73.15.0/24 AS37004 41.73.16.0/24 AS37004 41.73.17.0/24 AS37004 41.73.18.0/24 AS37004 41.73.20.0/24 AS37004 41.73.21.0/24 AS37004 41.76.48.0/21 AS36969 MTL-AS 41.78.120.0/23 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.87.32.0/19 AS37242 41.190.72.0/23 AS37451 CongoTelecom 41.190.74.0/23 AS37451 CongoTelecom 41.191.92.0/22 AS37245 41.191.108.0/22 AS37004 41.191.108.0/24 AS37004 41.191.109.0/24 AS37004 41.191.110.0/24 AS37004 41.191.111.0/24 AS37004 41.217.208.0/22 AS37158 49.0.4.0/24 AS55830 49.0.5.0/24 AS55830 49.0.6.0/24 AS55830 49.0.7.0/24 AS55830 49.156.20.0/24 AS55830 49.156.21.0/24 AS55830 49.156.22.0/24 AS55830 49.156.23.0/24 AS55830 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.122.216.0/22 AS48727 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos 63.247.0.0/24 AS27609 63.247.1.0/24 AS27609 63.247.2.0/24 AS27609 63.247.3.0/24 AS27609 63.247.4.0/24 AS27609 63.247.5.0/24 AS27609 63.247.6.0/24 AS27609 63.247.7.0/24 AS27609 63.247.8.0/24 AS27609 63.247.9.0/24 AS27609 63.247.10.0/24 AS27609 63.247.11.0/24 AS27609 63.247.13.0/24 AS27609 63.247.14.0/24 AS27609 63.247.15.0/24 AS27609 63.247.16.0/24 AS27609 63.247.17.0/24 AS27609 63.247.18.0/24 AS27609 63.247.19.0/24 AS27609 63.247.20.0/24 AS27609 63.247.21.0/24 AS27609 63.247.22.0/24 AS27609 63.247.23.0/24 AS27609 63.247.24.0/24 AS27609 63.247.25.0/24 AS27609 63.247.26.0/24 AS27609 63.247.27.0/24 AS27609 63.247.28.0/24 AS27609 63.247.29.0/24 AS27609 64.25.16.0/23 AS19535 64.25.20.0/24 AS19535 64.25.21.0/24 AS19535 64.25.22.0/24 AS19535 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 64.111.0.0/20 AS8039 CCC-ASN-1 - Cinergy Communications 64.111.160.0/20 AS40551 64.111.160.0/24 AS40551 64.111.161.0/24 AS40551 64.111.162.0/24 AS40551 64.111.167.0/24 AS40551 64.111.169.0/24 AS40551 64.111.170.0/24 AS40551 64.111.171.0/24 AS40551 64.111.172.0/24 AS40551 64.111.173.0/24 AS40551 64.111.174.0/24 AS40551 64.111.175.0/24 AS40551 64.119.240.0/22 AS26072 64.119.240.0/23 AS26072 64.119.242.0/23 AS26072 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.202.48.0/22 AS23380 64.202.52.0/23 AS23380 64.202.54.0/24 AS23380 64.202.55.0/24 AS23380 64.202.56.0/22 AS23380 64.202.60.0/24 AS23380 64.202.61.0/24 AS23380 64.202.62.0/24 AS23380 64.202.63.0/24 AS23380 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.11.112.0/20 AS14572 66.55.96.0/23 AS17203 66.55.98.0/24 AS17203 66.55.99.0/24 AS17203 66.55.100.0/22 AS17203 66.55.102.0/23 AS17203 66.55.104.0/21 AS17203 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc. 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 66.206.208.0/22 AS23380 66.206.211.0/24 AS14288 MPINET - MPInet 66.206.212.0/24 AS23380 66.206.213.0/24 AS14288 MPINET - MPInet 66.206.214.0/24 AS23380 66.206.215.0/24 AS23380 66.206.216.0/23 AS14288 MPINET - MPInet 66.206.218.0/23 AS23380 66.206.220.0/22 AS23380 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.254.160.0/20 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.176.0/21 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.184.0/22 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 67.21.144.0/22 AS174 COGENT Cogent/PSI 67.21.148.0/22 AS174 COGENT Cogent/PSI 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.232.0/21 AS6246 AVALONTEL - AvalonTel 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.112.100.0/22 AS16764 74.113.200.0/23 AS46939 74.114.52.0/22 AS40818 74.114.52.0/23 AS40818 74.114.52.0/24 AS40818 74.114.53.0/24 AS40818 74.114.54.0/23 AS40818 74.114.54.0/24 AS40818 74.114.55.0/24 AS40818 74.114.140.0/22 AS32757 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 74.118.132.0/22 AS5117 80.248.64.0/20 AS30982 CAFETG AS de CAFE Informatique 80.248.64.0/21 AS8513 SKYVISION SkyVision Global Networks Ltd 80.248.64.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.65.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.66.0/23 AS30982 CAFETG AS de CAFE Informatique 80.248.66.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.67.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.68.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.69.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.70.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.71.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.77.0/24 AS30982 CAFETG AS de CAFE Informatique 80.250.32.0/22 AS37106 ODUA-AS 91.193.60.0/22 AS3356 LEVEL3 Level 3 Communications 91.195.66.0/23 AS3356 LEVEL3 Level 3 Communications 91.197.36.0/22 AS43359 91.199.90.0/24 AS44330 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD 91.207.1.0/24 AS174 COGENT Cogent/PSI 91.207.152.0/24 AS64100 91.207.153.0/24 AS64100 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG 93.92.224.0/21 AS44582 93.190.8.0/24 AS47254 93.190.9.0/24 AS47254 93.190.10.0/24 AS47254 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.11.1.0/24 AS9822 AMNET-AU-AP Amnet IT Services Pty Ltd 103.11.216.0/24 AS13208 103.11.217.0/24 AS13208 103.11.218.0/23 AS13117 KINGCORP-AS-IX Opennet Internet Exchange 103.11.219.0/24 AS13208 103.13.184.0/23 AS58674 103.15.228.0/22 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.228.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.230.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 103.21.180.0/22 AS45352 IPSERVERONE-AS-AP IP ServerOne Solutions Sdn Bhd, 103.21.180.0/23 AS45352 IPSERVERONE-AS-AP IP ServerOne Solutions Sdn Bhd, 103.247.36.0/24 AS55830 103.247.37.0/24 AS55830 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 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 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange 164.40.184.0/24 AS19821 172.85.0.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 174.136.192.0/18 AS14572 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL 178.218.240.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.241.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.242.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.243.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.244.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.245.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.246.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.247.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.248.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.249.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.250.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.251.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.252.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.253.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.254.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.255.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 185.26.240.0/22 AS48030 CRYPT-LOGIC Crypt Logic LTD 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS 190.15.72.0/21 AS15146 CABLEBAHAMAS - Cable Bahamas 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A. 190.124.252.0/22 AS7303 Telecom Argentina S.A. 192.166.32.0/20 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.9.59.0/24 AS1257 TELE2 193.16.106.0/24 AS31539 193.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF 193.109.15.0/24 AS12690 MKSNET-AS MKS Autonomous System 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 193.178.217.0/24 AS20737 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.254.218.0/23 AS25229 VOLIA-AS Kyivski Telekomunikatsiyni Merezhi LLC 194.50.82.0/24 AS16276 OVH OVH Systems 194.63.152.0/22 AS3356 LEVEL3 Level 3 Communications 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service 194.126.219.0/24 AS34545 195.28.168.0/23 AS8655 195.114.4.0/23 AS41158 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB 195.130.208.0/24 AS16265 LEASEWEB LeaseWeb B.V. 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA 195.234.156.0/24 AS25028 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.18.112.0/20 AS1916 Associa??o Rede Nacional de Ensino e Pesquisa 200.23.189.0/24 AS57792 PROVITEX-AS PE Glazunov Yuriy Anatol'yevich 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 203.142.219.0/24 AS45149 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc. 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.115.110.0/23 AS53709 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc. 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp. 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 205.236.71.0/24 AS852 ASN852 - TELUS Communications Inc. 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.66.120.0/22 AS32757 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc. 208.74.224.0/22 AS174 COGENT Cogent/PSI 208.75.152.0/21 AS32146 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.84.232.0/24 AS33131 208.84.234.0/24 AS33131 208.84.237.0/24 AS33131 208.84.238.0/24 AS33131 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.164.0/22 AS46099 208.92.224.0/22 AS32757 208.92.226.0/24 AS32757 209.161.96.0/20 AS8039 CCC-ASN-1 - Cinergy Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.193.112.0/20 AS209 ASN-QWEST-US NOVARTIS-DMZ-US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 212.119.32.0/19 AS12550 213.184.64.0/24 AS13071 213.184.65.0/24 AS13071 213.184.66.0/24 AS13071 213.184.67.0/24 AS13071 213.184.68.0/24 AS13071 213.184.69.0/24 AS13071 213.184.70.0/24 AS13071 213.184.71.0/24 AS13071 213.184.72.0/24 AS13071 213.184.73.0/24 AS13071 213.184.74.0/24 AS13071 213.184.75.0/24 AS13071 213.184.76.0/24 AS13071 213.184.77.0/24 AS13071 213.184.78.0/24 AS13071 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.14.64.0/20 AS14728 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Jan 3 22:00:02 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 3 Jan 2014 22:00:02 GMT Subject: BGP Update Report Message-ID: <201401032200.s03M02Dh090087@wattle.apnic.net> BGP Update Report Interval: 26-Dec-13 -to- 02-Jan-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS30783 47548 2.8% 1398.5 -- RSD Rased Maral Ava Jonoob JSC 2 - AS35819 43311 2.6% 95.6 -- MOBILY-AS Etihad Etisalat Company (Mobily) 3 - AS14287 37356 2.2% 691.8 -- TRIAD-TELECOM - Triad Telecom, Inc. 4 - AS8402 34786 2.1% 63.8 -- CORBINA-AS OJSC "Vimpelcom" 5 - AS9829 32777 1.9% 41.1 -- BSNL-NIB National Internet Backbone 6 - AS3816 27847 1.6% 85.9 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 7 - AS7552 24698 1.5% 30.5 -- VIETEL-AS-AP Viettel Corporation 8 - AS34744 24085 1.4% 47.2 -- GVM S.C. GVM SISTEM 2003 S.R.L. 9 - AS12615 21761 1.3% 253.0 -- GCN-AS Global Communication Net Plc 10 - AS13118 21052 1.2% 1913.8 -- ASN-YARTELECOM OJSC Rostelecom 11 - AS18403 19971 1.2% 46.9 -- FPT-AS-AP The Corporation for Financing & Promoting Technology 12 - AS41691 19090 1.1% 636.3 -- SUMTEL-AS-RIPE Summa Telecom LLC 13 - AS4775 18133 1.1% 1295.2 -- GLOBE-TELECOM-AS Globe Telecoms 14 - AS7029 16799 1.0% 22.9 -- WINDSTREAM - Windstream Communications Inc 15 - AS45899 14532 0.9% 44.9 -- VNPT-AS-VN VNPT Corp 16 - AS49687 14054 0.8% 116.1 -- REQ SC RoSite Equipment SRL 17 - AS59217 12723 0.8% 12723.0 -- AZONNELIMITED-AS-AP Azonne Limited 18 - AS1221 12698 0.8% 453.5 -- ASN-TELSTRA Telstra Pty Ltd 19 - AS17974 12494 0.7% 6.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 20 - AS11976 12183 0.7% 143.3 -- FIDN - Fidelity Communication International Inc. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS59217 12723 0.8% 12723.0 -- AZONNELIMITED-AS-AP Azonne Limited 2 - AS54465 8392 0.5% 8392.0 -- QPM-AS-1 - QuickPlay Media Inc. 3 - AS41189 4661 0.3% 4661.0 -- ICONCEPT-AS Faroese Telecom 4 - AS28477 3573 0.2% 3573.0 -- UNIVERSIDAD AUTONOMA DEL ESTADO DE MORELOS 5 - AS22747 3018 0.2% 3018.0 -- TCIS - TulsaConnect, LLC 6 - AS30437 4983 0.3% 2491.5 -- GE-MS003 - General Electric Company 7 - AS45808 2215 0.1% 2215.0 -- UTP-MY Bandar Seri Iskandar 8 - AS32244 6538 0.4% 2179.3 -- LIQUID-WEB-INC - Liquid Web, Inc. 9 - AS62431 2023 0.1% 2023.0 -- NCSC-IE-AS National Cyber Security Centre 10 - AS13118 21052 1.2% 1913.8 -- ASN-YARTELECOM OJSC Rostelecom 11 - AS19406 3784 0.2% 1892.0 -- TWRS-MA - Towerstream I, Inc. 12 - AS18570 1806 0.1% 1806.0 -- ECHOSTAR-BROADCASTING-CORPORATION - EchoStar Broadcasting Corperation 13 - AS7202 8706 0.5% 1741.2 -- FAMU - Florida A & M University 14 - AS60932 1699 0.1% 1699.0 -- AVAYE-BANDAR DADE PARDAZAN AVAYE BANDAR COMPANY 15 - AS47870 1515 0.1% 1515.0 -- NEWBAY-ASN NewBay Software Ltd 16 - AS6629 10358 0.6% 1479.7 -- NOAA-AS - NOAA 17 - AS60345 2945 0.2% 1472.5 -- NBITI-AS Nahjol Balagheh International Research Institution 18 - AS30783 47548 2.8% 1398.5 -- RSD Rased Maral Ava Jonoob JSC 19 - AS40877 2640 0.2% 1320.0 -- PSCMETALS - PSC Metals, Inc. 20 - AS22895 1318 0.1% 1318.0 -- CMR1122 - CMR LLC TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/20 21042 1.2% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 103.243.164.0/22 12723 0.7% AS59217 -- AZONNELIMITED-AS-AP Azonne Limited 3 - 192.58.232.0/24 10327 0.6% AS6629 -- NOAA-AS - NOAA 4 - 85.249.160.0/20 9944 0.6% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 7 - 89.221.206.0/24 8646 0.5% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 8 - 206.152.15.0/24 8392 0.5% AS54465 -- QPM-AS-1 - QuickPlay Media Inc. 9 - 208.73.244.0/22 7423 0.4% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 10 - 208.88.232.0/22 7418 0.4% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 11 - 216.162.0.0/20 7417 0.4% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 12 - 208.78.116.0/22 7414 0.4% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 13 - 208.70.20.0/22 7377 0.4% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 14 - 148.218.0.0/16 6887 0.4% AS11172 -- Alestra, S. de R.L. de C.V. AS28477 -- UNIVERSIDAD AUTONOMA DEL ESTADO DE MORELOS 15 - 67.210.190.0/23 6681 0.4% AS11976 -- FIDN - Fidelity Communication International Inc. 16 - 183.87.110.0/24 5642 0.3% AS45194 -- SIPL-AS Syscon Infoway Pvt. Ltd., Internet Service Provider, India. 17 - 103.2.238.0/24 5640 0.3% AS45194 -- SIPL-AS Syscon Infoway Pvt. Ltd., Internet Service Provider, India. 18 - 115.170.128.0/17 5506 0.3% AS4847 -- CNIX-AP China Networks Inter-Exchange 19 - 165.156.25.0/24 4974 0.3% AS30437 -- GE-MS003 - General Electric Company 20 - 193.34.104.0/22 4661 0.3% AS41189 -- ICONCEPT-AS Faroese Telecom Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From nanog at bitfreak.org Fri Jan 3 23:49:47 2014 From: nanog at bitfreak.org (Darren Pilgrim) Date: Fri, 03 Jan 2014 15:49:47 -0800 Subject: Open source hardware In-Reply-To: References: Message-ID: <52C74C9B.30802@bitfreak.org> On 1/3/2014 2:05 AM, Dani?l W. Crompton wrote: > Good point Jimmy, there is a world of hurt involved, although it may be > slightly less painless when you realize that the alternative is: "*the NSA > [who] has modified the firmware of computers and network hardware?including > systems shipped by Cisco, Dell, Hewlett-Packard, Huawei, and Juniper > Networks?to give its operators both eyes and ears inside the offices the > agency has targeted.*"[1] Why would you think other platforms would be any safer? The NSA plants those bugs with interdiction operations. They could similarly install eavesdroppers in the USB/serial links of your KVM switches and terminal servers and capture your root/admin/console passwords. Dell, HP, Cisco, etc. were named because the leaked docs mention hardware-specific BIOS/firmware bugging such as ILO piggybacking in a Proliant. I think it's foolhardy believing they wouldn't have similar attacks for just about everything. From dougb at dougbarton.us Sat Jan 4 01:12:01 2014 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 03 Jan 2014 17:12:01 -0800 Subject: turning on comcast v6 In-Reply-To: References: <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> <52C6778A.5070309@dougbarton.us> <52C681C6.3080402@dougbarton.us> Message-ID: <52C75FE1.30704@dougbarton.us> On 01/03/2014 04:01 AM, Baldur Norddahl wrote: > On Fri, Jan 3, 2014 at 10:24 AM, Doug Barton wrote: > >> And you still haven't provided an argument about why the default route >> should not be added to DHCPv6. >> >> > I was not arguing that it didn't. Just that the perceived problem is not > real. Your opinion is that rogue RAs are not a problem. I, and others, disagree with you on that; but since that's not really the problem I'm trying to solve we can agree to disagree. What I (and many, many others) have been saying for over a decade is that we need to have parity with DHCPv4 in DHCPv6 in order to allow organizations that like and use DHCP to use that as their exclusive method of configuring IPv6 clients. Often this is to match existing administrative boundaries, sometimes it's just a preference (one could even say prejudice) against SLAAC/RA, but regardless, that's what is needed. > However, I might be inclined to believe that default route in DHCPv6 is a > bad idea. It is a confusing concept, It's not confusing in any way. It matches the well known mechanism already in widespread use in DHCPv4. > since we already no less than three > methods (*) to discover default route and you want to add a fourth. The first 2 you mention are rarely used, and not even implemented in many, if not most clients. However the fact that there are so many ways to do it in IPv6 now is an example of the "Anything but DHCP!" mindset of the early IPng architects. > This > would be something that needs to be implemented in every client, and thus > will not really be usable for at least a decade. Organizations that want this are prepared to do the work of making sure that their clients are upgraded, or wait to deploy IPv6 until it's available. For most existing organizations there is no urgency to deploy IPv6, their current infrastructure works for them. For those new organizations forced to deploy IPv6 they will be able to deploy new software that handles this option. ... and of course, the sooner we do it, the sooner it will be widely available. > By then everyone are used to RA. It's been over a decade already, and not only have the security problems with RA not yet been solved in a robust way, people are not only not yet used to it, they are actively opposing it. Your optimism, while admirable, is misplaced here. > If you did add default route to DHCPv6, what is then supposed to happen to > the other routes, that the client might discover? You would configure the client not to do RS, and to ignore any RAs that it receives. Simple. > (*) prefix::, fe80:: and the one you get from RA. Doug From owen at delong.com Sat Jan 4 01:52:25 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Jan 2014 17:52:25 -0800 Subject: turning on comcast v6 In-Reply-To: <52C6778A.5070309@dougbarton.us> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> <52C6778A.5070309@dougbarton.us> Message-ID: <9D39E329-B2C3-4F53-ABD9-19C3D3D83539@delong.com> On Jan 3, 2014, at 12:40 AM, Doug Barton wrote: > On 01/02/2014 10:30 PM, TJ wrote: >> I'd argue that while the timing may be different, RA and DHCP attacks >> are largely the same and are simply variations on a theme. > > Utter nonsense. The ability to nearly-instantly switch traffic for nearly-all nodes on the network is a very different thing than what a rogue DHCP server could do, even if you have ridiculously short lease times, which most don?t Not entirely true, actually? If you?re willing to work hard enough at it, most hosts can be ?encouraged? to renew early. > Further, by far the common case is for network gear to _already_ be configured to avoid permitting hosts to act as DHCP servers unless they are supposed to be. It's rare to even find a network device that has RA Guard capabilities, never mind one that has them turned on. Well? Sure, 15 years after DHCP attacks first started being a serious problem? I doubt it will take anywhere near 15 years for RA guard on by default to be the norm in switches, etc. > There is simply no good reason not to include default route in the configuration for DHCPv6, and it's long overdue. As I?ve said before, if we?re going to bother doing it, we should just include RIO options, but otherwise, I agree with you. Owen From fergdawgster at mykolab.com Sat Jan 4 02:27:05 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Fri, 03 Jan 2014 18:27:05 -0800 Subject: turning on comcast v6 In-Reply-To: <9D39E329-B2C3-4F53-ABD9-19C3D3D83539@delong.com> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> <52C6778A.5070309@dougbarton.us> <9D39E329-B2C3-4F53-ABD9-19C3D3D83539@delong.com> Message-ID: <52C77179.8040803@mykolab.com> What DHCP attacks? Humor me... What DHCP "attacks"? - ferg On 1/3/2014 5:52 PM, Owen DeLong wrote: > > On Jan 3, 2014, at 12:40 AM, Doug Barton wrote: > >> On 01/02/2014 10:30 PM, TJ wrote: >>> I'd argue that while the timing may be different, RA and DHCP attacks >>> are largely the same and are simply variations on a theme. >> >> Utter nonsense. The ability to nearly-instantly switch traffic for nearly-all nodes on the network is a very different thing than what a rogue DHCP server could do, even if you have ridiculously short lease times, which most don?t > > Not entirely true, actually? If you?re willing to work hard enough at it, most hosts can be ?encouraged? to renew early. > >> Further, by far the common case is for network gear to _already_ be configured to avoid permitting hosts to act as DHCP servers unless they are supposed to be. It's rare to even find a network device that has RA Guard capabilities, never mind one that has them turned on. > > Well? Sure, 15 years after DHCP attacks first started being a serious problem? I doubt it will take anywhere near 15 years for RA guard on by default to be the norm in switches, etc. > >> There is simply no good reason not to include default route in the configuration for DHCPv6, and it's long overdue. > > As I?ve said before, if we?re going to bother doing it, we should just include RIO options, but otherwise, I agree with you. > > Owen > > > > -- Paul Ferguson PGP Public Key ID: 0x63546533 From ray at oneunified.net Sat Jan 4 03:48:16 2014 From: ray at oneunified.net (Raymond Burkholder) Date: Fri, 3 Jan 2014 23:48:16 -0400 Subject: turning on comcast v6 In-Reply-To: <52C77179.8040803@mykolab.com> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> <52C6778A.5070309@dougbarton.us> <9D39E329-B2C3-4F53-ABD9-19C3D3D83539@delong.com> <52C77179! .8040803@mykolab.com> Message-ID: <018401cf08ff$cd95c120$68c14360$@oneunified.net> > >> There is simply no good reason not to include default route in the > configuration for DHCPv6, and it's long overdue. > > > > As I've said before, if we're going to bother doing it, we should just include > RIO options, but otherwise, I agree with you. > > Are DHCPv6 and/or NDP extendible for other stuff? For example, in IPv4, Cisco uses DHCP option 150 for advertising Callmanager addresses in their IP Telephony networks. I've been out of the Cisco IPT side of stuff for awhile, but wondered how that has been tackled. And I think things like NTP addresses have been delivered in DHCP packets. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From jfbeam at gmail.com Sat Jan 4 06:06:56 2014 From: jfbeam at gmail.com (Ricky Beam) Date: Sat, 04 Jan 2014 01:06:56 -0500 Subject: turning on comcast v6 In-Reply-To: <9D39E329-B2C3-4F53-ABD9-19C3D3D83539@delong.com> References: <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> <52C6778A.5070309@dougbarton.us> <9D39E329-B2C3-4F53-ABD9-19C3D3D83539@delong.com> Message-ID: On Fri, 03 Jan 2014 20:52:25 -0500, Owen DeLong wrote: > Not entirely true, actually? If you?re willing to work hard enough at > it, most hosts can be ?encouraged? to renew early. Short of commandline access, no there isn't. (crashing or otherwise triggering a reboot, isn't a "renew"; that's a full broadcast restart) And RENEW isn't at issue as that's a unicast request directly with the original DHCP server. Simply turning up your own instance will do nothing there. (attempting to impersonate the real server isn't what were talking about.) For IPv6, you can become a/the router for a segment with the origination of a single packet. Instantly. That's something you can never do with DHCPv4. > Well? Sure, 15 years after DHCP attacks first started being a serious > problem? I doubt it will take anywhere near 15 years for RA guard on by > default to be the norm in switches, etc. It'll **NEVER** be a default because it breaks too many clueless people's networks. Just like, surprise, DHCP "guard" isn't on by default in any gear I'm aware of. From av at nethead.de Sat Jan 4 07:34:25 2014 From: av at nethead.de (Arnd Vehling) Date: Sat, 04 Jan 2014 15:34:25 +0800 Subject: Open source hardware In-Reply-To: <52C74C9B.30802@bitfreak.org> References: <52C74C9B.30802@bitfreak.org> Message-ID: <52C7B981.5060303@nethead.de> On 04.01.2014 07:49, Darren Pilgrim wrote: > Dell, HP, Cisco, etc. were named because the leaked docs mention > hardware-specific BIOS/firmware bugging such as ILO piggybacking in a > Proliant. I think it's foolhardy believing they wouldn't have similar > attacks for just about everything. Highly unlickely they have similiar attacks for everything. They for sure can make em if they see fit but they dont have backdoors to everything. // Arnd From benno at NLnetLabs.nl Sat Jan 4 11:08:11 2014 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Sat, 04 Jan 2014 12:08:11 +0100 Subject: Open source hardware In-Reply-To: <20140103133356.GA25459@pob.ytti.fi> References: <20140103133356.GA25459@pob.ytti.fi> Message-ID: <52C7EB9B.9070105@NLnetLabs.nl> On 3-1-2014 14:33, Saku Ytti wrote: > Right now, if you need perfomance, you're going to have to buy something like > bcom chip and then cumulusnetworks linux on top of it, it's as close to 'open > source' as you're going to get with good performance. > And this is more or less DC stuff, SP market needs more intelligent chips than > those ASICs, and I don't think there anything 'open source' in the market > place for NPU stuff. No hands-on experience with Cumulus Networks equipment, but from what I have heard I like their approach to open hardware/software for routing equipment. It is flexible what you want to configure and run (all open source software). For the hardware switching support they license their Switch HAL module. Cheers, -- Benno From saku at ytti.fi Sat Jan 4 11:38:28 2014 From: saku at ytti.fi (Saku Ytti) Date: Sat, 4 Jan 2014 13:38:28 +0200 Subject: Open source hardware In-Reply-To: <52C7EB9B.9070105@NLnetLabs.nl> References: <20140103133356.GA25459@pob.ytti.fi> <52C7EB9B.9070105@NLnetLabs.nl> Message-ID: <20140104113828.GA2056@pob.ytti.fi> On (2014-01-04 12:08 +0100), Benno Overeinder wrote: > No hands-on experience with Cumulus Networks equipment, but from > what I have heard I like their approach to open hardware/software > for routing equipment. It is flexible what you want to configure > and run (all open source software). For the hardware switching > support they license their Switch HAL module. I love the notion of COTS control-plane software, it has potential to fundamentally change the market dynamics. COTS ASICs (bcom the most prominient) and COTS NPU (ezchip, xelerated/marvell) have done lot of good to the market in terms of features/performance/price. Right now some of the big name vendors are running really archaic and naive control-planes, and it's hard for them internally to justify project to rebuild it all, because customers will largely accept even the shitty control-plane, because that is only thing you get with that hardware. Company doing only COTS control-plane can't get away with shitty software, it's their only product. And conversely, they can get away having many generation of incompatible operating systems, as older customers will keep on wanting+paying on the development of the older version while newer greenfield customers will want to start with the latest generation. This creates pressure on the established companies to have great control-plane, not some 20 year old TTM house of cards. -- ++ytti From daniel.crompton at gmail.com Sat Jan 4 13:04:40 2014 From: daniel.crompton at gmail.com (=?UTF-8?Q?Dani=C3=ABl_W=2E_Crompton?=) Date: Sat, 4 Jan 2014 14:04:40 +0100 Subject: Open source hardware In-Reply-To: <52C74C9B.30802@bitfreak.org> References: <52C74C9B.30802@bitfreak.org> Message-ID: On 4 January 2014 00:49, Darren Pilgrim wrote: > Why would you think other platforms would be any safer? The NSA plants > those bugs with interdiction operations. They could similarly install > eavesdroppers in the USB/serial links of your KVM switches and terminal > servers and capture your root/admin/console passwords. In my opinion there is a clear difference between being targeted and having a backdoor in your network equipment by default. D. -- Dani?l W. Crompton http://specialbrands.net/ From daniel.crompton at gmail.com Sat Jan 4 13:07:05 2014 From: daniel.crompton at gmail.com (=?UTF-8?Q?Dani=C3=ABl_W=2E_Crompton?=) Date: Sat, 4 Jan 2014 14:07:05 +0100 Subject: Open source hardware In-Reply-To: <52C7B981.5060303@nethead.de> References: <52C74C9B.30802@bitfreak.org> <52C7B981.5060303@nethead.de> Message-ID: On 4 January 2014 08:34, Arnd Vehling wrote: > On 04.01.2014 07:49, Darren Pilgrim wrote: > > Dell, HP, Cisco, etc. were named because the leaked docs mention >> hardware-specific BIOS/firmware bugging such as ILO piggybacking in a >> Proliant. I think it's foolhardy believing they wouldn't have similar >> attacks for just about everything. >> > > Highly unlickely they have similiar attacks for everything. They for sure > can make em if they see fit but they dont have backdoors to everything. To my surprise I am seeing a theme fatalistic acceptance in this thread, it seems like some who have been kind enough to answer privately or publicly are of the opinion that either everything is already backdoored by the US designers and/or by the Chinese manufacturers. I doubt however that any of these people would hand over their root passwords to the US or Chinese government willingly. A number have mentioned that if you are targeted there is little you can do, and this is something that I agree with to a certain extent. This doesn't mean you leave the barndoor open. D. -- Dani?l W. Crompton http://specialbrands.net/ From baldur.norddahl at gmail.com Sat Jan 4 13:42:30 2014 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 4 Jan 2014 14:42:30 +0100 Subject: turning on comcast v6 In-Reply-To: <52C75FE1.30704@dougbarton.us> References: <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> <52C6778A.5070309@dougbarton.us> <52C681C6.3080402@dougbarton.us> <52C75FE1.30704@dougbarton.us> Message-ID: On Sat, Jan 4, 2014 at 2:12 AM, Doug Barton wrote: > >> If you did add default route to DHCPv6, what is then supposed to happen to >> the other routes, that the client might discover? >> > > You would configure the client not to do RS, and to ignore any RAs that it > receives. Simple. > > If you are going to modify the client, you can use any method you like, including having the client simply use fe80:: or prefix:: as default gateway. You want a secure way to configure the clients. That sounds more like Secure NDP (SEND) than it sounds like DHCPv6 with default gateway. Regards, From mfidelman at meetinghouse.net Sat Jan 4 15:05:15 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 04 Jan 2014 10:05:15 -0500 Subject: anybody seeing mail problems sending to yahoo.com? (and a yahoo email contact?) Message-ID: <52C8232B.6040504@meetinghouse.net> Hi Folks, I run a few small email lists that have some yahoo users on them - and I just started getting complaints about receiving multiple copies of messages. In looking into it, I've found 1000s of log entries along the following lines, all from the past 5 days or so: Jan 4 09:23:51 server1 postfix/smtp[1462]: 3BA39CC094: lost connection with mta7.am0.yahoodns.net[98.136.216.26] while sending end of data -- message may be sent more than once It's not one of their standard anti-spam errors, and mail is arriving (multiple copies no less) - so it doesn't look like this is intentional blocking. So... I'm wondering if anybody else is seeing this, and if anybody has a postmaster contact at yahoo (postmaster at yahoo.com, of course, auto-replies with a pointer to a useless web form). Thanks, Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From royce at techsolvency.com Sat Jan 4 16:08:13 2014 From: royce at techsolvency.com (Royce Williams) Date: Sat, 4 Jan 2014 07:08:13 -0900 Subject: anybody seeing mail problems sending to yahoo.com? (and a yahoo email contact?) In-Reply-To: <52C8232B.6040504@meetinghouse.net> References: <52C8232B.6040504@meetinghouse.net> Message-ID: Miles, I'm seeing it here too -- same conditions (small email list), same symptom. But interestingly, I'm not getting that message back from Yahoo's MXes; just a very high volume of of 'closed connection in response to end of data' and the usual occasional minor smattering of 'temporarily deferred due to user complaints'. Royce Williams On Sat, Jan 4, 2014 at 6:05 AM, Miles Fidelman wrote: > Hi Folks, > > I run a few small email lists that have some yahoo users on them - and I > just started getting complaints about receiving multiple copies of messages. > > In looking into it, I've found 1000s of log entries along the following > lines, all from the past 5 days or so: > > Jan 4 09:23:51 server1 postfix/smtp[1462]: 3BA39CC094: lost connection > with mta7.am0.yahoodns.net[98.136.216.26] while sending end of data -- > message may be sent more than once > > It's not one of their standard anti-spam errors, and mail is arriving > (multiple copies no less) - so it doesn't look like this is intentional > blocking. > > So... I'm wondering if anybody else is seeing this, and if anybody has a > postmaster contact at yahoo (postmaster at yahoo.com, of course, > auto-replies with a pointer to a useless web form). > > Thanks, > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > > From bicknell at ufp.org Sat Jan 4 16:10:24 2014 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 4 Jan 2014 10:10:24 -0600 Subject: turning on comcast v6 In-Reply-To: <9D39E329-B2C3-4F53-ABD9-19C3D3D83539@delong.com> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> <52C6778A.5070309@dougbarton.us> <9D39E329-B2C3-4F53-ABD9-19C3D3D83539@delong.com> Message-ID: On Jan 3, 2014, at 7:52 PM, Owen DeLong wrote: > Well? Sure, 15 years after DHCP attacks first started being a serious problem? I doubt it will take anywhere near 15 years for RA guard on by default to be the norm in switches, etc. I count over a dozen ethernet switches in my home that do not have DHCP guard. Indeed, half of them do not have a management interface at all. Even my "business class cable modem" does not implement DHCP guard on it's integrated switch. I also don't know of a single device, from any vendor, that turns DHCP guard on by default. I'd appreciate pointers if there is one. I know a half dozen people sent some form of "don't do that" when I gave the example of plugging in a "rogue" router with my corporate scenario. Maybe in a corporate scenario that's plausible, there will be intelligent admins (ha!). What happens when Joe Home User buys a new Linksys and wants to plug it in to get a firmware update before installing it? Are we really supposed to expect that every Joe Homeowner understands RA Guard and configures it for their home network? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From nick at foobar.org Sat Jan 4 17:18:33 2014 From: nick at foobar.org (Nick Hilliard) Date: Sat, 04 Jan 2014 17:18:33 +0000 Subject: Open source hardware In-Reply-To: <20140104113828.GA2056@pob.ytti.fi> References: <20140103133356.GA25459@pob.ytti.fi> <52C7EB9B.9070105@NLnetLabs.nl> <20140104113828.GA2056@pob.ytti.fi> Message-ID: <52C84269.8010106@foobar.org> On 04/01/2014 11:38, Saku Ytti wrote: > Right now some of the big name vendors are running really archaic and naive > control-planes, and it's hard for them internally to justify project to > rebuild it all, because customers will largely accept even the shitty > control-plane, because that is only thing you get with that hardware. Re: crappy control planes, I wouldn't particularly mind paying licensing fees if there were a choice about what software to use. But there isn't and you end up with with the worst of all worlds: no choice about which particular control plane software (and consequently which bug+feature set) you want to run, no incentive for vendors to deal with enhancements other than on the basis of how much revenue they'll create in the next quarter, and no option but to pay twice: once for the hardware and a second time if you actually want to use it. Open source control planes may not fix all these problems, but there is no doubt that they will put pressure on vendors to compete on uncomfortably close turf. Nick From adrian.minta at gmail.com Sat Jan 4 17:28:13 2014 From: adrian.minta at gmail.com (Adrian Minta) Date: Sat, 04 Jan 2014 19:28:13 +0200 Subject: anybody seeing mail problems sending to yahoo.com? (and a yahoo email contact?) In-Reply-To: <52C8232B.6040504@meetinghouse.net> References: <52C8232B.6040504@meetinghouse.net> Message-ID: <52C844AD.1050304@gmail.com> I'm seeing the same thing: Jan 4 19:13:20 mail2 postfix/error[21241]: 8C9BD1F20045: relay=none, delay=30958, delays=30835/121/0/2.1, dsn=4.4.2, status=deferred (delivery temporarily suspended: lost connection with mta5.am0.yahoodns.net[98.136.217.202] while sending end of data -- message may be sent more than once) Jan 4 19:19:44 mail2 postfix/smtp[21813]: 3993E1F20045: relay=mta7.am0.yahoodns.net[66.196.118.33]:25, delay=98, delays=0.58/0.03/46/51, dsn=4.4.2, status=deferred (lost connection with mta7.am0.yahoodns.net[66.196.118.33] while sending end of data -- message may be sent more than once) Jan 4 19:19:44 mail2 postfix/smtp[21813]: 3993E1F20045: relay=mta7.am0.yahoodns.net[66.196.118.33]:25, delay=98, delays=0.58/0.03/46/51, dsn=4.4.2, status=deferred (lost connection with mta7.am0.yahoodns.net[66.196.118.33] while sending end of data -- message may be sent more than once) -- Best regards, Adrian Minta From owen at delong.com Sat Jan 4 19:03:21 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 4 Jan 2014 11:03:21 -0800 Subject: turning on comcast v6 In-Reply-To: References: <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> <52C6778A.5070309@dougbarton.us> <9D39E329-B2C3-4F53-ABD9-19C3D3D83539@delong.com> Message-ID: > For IPv6, you can become a/the router for a segment with the origination of a single packet. Instantly. That?s something you can never do with DHCPv4. > A router, yes. THE router, not unless the network is very stupidly put together. >> Well? Sure, 15 years after DHCP attacks first started being a serious problem? I doubt it will take anywhere near 15 years for RA guard on by default to be the norm in switches, etc. > > It'll **NEVER** be a default because it breaks too many clueless people's networks. Just like, surprise, DHCP "guard" isn't on by default in any gear I'm aware of. I disagree. Unlike with DHCP guard, RA guard can make reasonable predictions in most cases. Switches with ?uplink? ports designated, for example, could easily default to permitting RAs only from those ports. Owen From mfidelman at meetinghouse.net Sat Jan 4 19:35:48 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 04 Jan 2014 14:35:48 -0500 Subject: Anybody here from yahoo, or a good contact? [was Re: anybody seeing mail problems sending to yahoo.com?] In-Reply-To: <52C8232B.6040504@meetinghouse.net> References: <52C8232B.6040504@meetinghouse.net> Message-ID: <52C86294.6080106@meetinghouse.net> Based on a couple of responses saying that other people are seeing this, and I'm still getting these.... - anybody here from yahoo who might be able to respond? Or does anybody have a good contact at Yahoo's postmaster dept? Thanks, Miles Fidelman Miles Fidelman wrote: > Hi Folks, > > I run a few small email lists that have some yahoo users on them - and > I just started getting complaints about receiving multiple copies of > messages. > > In looking into it, I've found 1000s of log entries along the > following lines, all from the past 5 days or so: > > Jan 4 09:23:51 server1 postfix/smtp[1462]: 3BA39CC094: lost > connection with mta7.am0.yahoodns.net[98.136.216.26] while sending end > of data -- message may be sent more than once > > It's not one of their standard anti-spam errors, and mail is arriving > (multiple copies no less) - so it doesn't look like this is > intentional blocking. > > So... I'm wondering if anybody else is seeing this, and if anybody > has a postmaster contact at yahoo (postmaster at yahoo.com, of course, > auto-replies with a pointer to a useless web form). > > Thanks, > > Miles Fidelman > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From scott at doc.net.au Sat Jan 4 19:52:56 2014 From: scott at doc.net.au (Scott Howard) Date: Sat, 4 Jan 2014 11:52:56 -0800 Subject: anybody seeing mail problems sending to yahoo.com? (and a yahoo email contact?) In-Reply-To: <52C844AD.1050304@gmail.com> References: <52C8232B.6040504@meetinghouse.net> <52C844AD.1050304@gmail.com> Message-ID: I've seen others reporting this elsewhere too, so it's clearly a problem at Yahoo's end. Someone on the mailops list reported that disabling TLS for yahoodns.nethosts fixed the problem so it may be worth trying that. Scott On Sat, Jan 4, 2014 at 9:28 AM, Adrian Minta wrote: > I'm seeing the same thing: > > Jan 4 19:13:20 mail2 postfix/error[21241]: 8C9BD1F20045: relay=none, > delay=30958, delays=30835/121/0/2.1, dsn=4.4.2, status=deferred (delivery > temporarily suspended: lost connection with mta5.am0.yahoodns.net[98.136.217.202] > while sending end of data -- message may be sent more than once) > Jan 4 19:19:44 mail2 postfix/smtp[21813]: 3993E1F20045: relay= > mta7.am0.yahoodns.net[66.196.118.33]:25, delay=98, > delays=0.58/0.03/46/51, dsn=4.4.2, status=deferred (lost connection with > mta7.am0.yahoodns.net[66.196.118.33] while sending end of data -- message > may be sent more than once) > Jan 4 19:19:44 mail2 postfix/smtp[21813]: 3993E1F20045: relay= > mta7.am0.yahoodns.net[66.196.118.33]:25, delay=98, > delays=0.58/0.03/46/51, dsn=4.4.2, status=deferred (lost connection with > mta7.am0.yahoodns.net[66.196.118.33] while sending end of data -- message > may be sent more than once) > > > -- > Best regards, > Adrian Minta > > > From mark.tinka at seacom.mu Sat Jan 4 21:35:57 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 4 Jan 2014 23:35:57 +0200 Subject: Open source hardware In-Reply-To: <20140103133356.GA25459@pob.ytti.fi> References: <20140103133356.GA25459@pob.ytti.fi> Message-ID: <201401042336.00896.mark.tinka@seacom.mu> On Friday, January 03, 2014 03:33:56 PM Saku Ytti wrote: > Right now, if you need perfomance, you're going to have > to buy something like bcom chip and then cumulusnetworks > linux on top of it, it's as close to 'open source' as > you're going to get with good performance. And this is > more or less DC stuff, SP market needs more intelligent > chips than those ASICs, and I don't think there anything > 'open source' in the market place for NPU stuff. Indeed. Broadcom are making lots of interesting cheap and fast ASIC's, but they're data centre focused, or serve a specific platform feature set with Cisco/Juniper that has a number of restrictions, just to keep the costs down. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From 2600hz at gmail.com Sun Jan 5 02:28:52 2014 From: 2600hz at gmail.com (jamie) Date: Sat, 4 Jan 2014 20:28:52 -0600 Subject: First! [?] In-Reply-To: <648909690-1388563096-cardhu_decombobulator_blackberry.rim.net-1914566786-@b12.c19.bise6.blackberry> References: <851013360-1388562115-cardhu_decombobulator_blackberry.rim.net-851771212-@b18.c5.bise6.blackberry> <648909690-1388563096-cardhu_decombobulator_blackberry.rim.net-1914566786-@b12.c19.bise6.blackberry> Message-ID: I just re-read this thread I have to lol. " Happy New Year!(*) (*)The information contained within this E-Mail and any attached document(s) is confidential and/or privileged. It is intended solely for the use of the addressee(s) named above. Unauthorized disclosure, photocopying, distribution or use of the information contained herein is prohibited. If you believe that you have received this E-Mail in error, please notify the sender by reply transmission or call haha. On Wed, Jan 1, 2014 at 1:58 AM, Tri Tran wrote: > Happy New Year! > Tri Tran > > -----Original Message----- > From: "A Mekkaoui" > Date: Wed, 1 Jan 2014 02:45:01 > To: ; 'Beavis'; 'Bryan > Tong' > Cc: 'NANOG list' > Subject: RE: First! [?] > > Happy new year to all of you, all the best! > > Karim > > -----Original Message----- > From: Christopher Young [mailto:chris.young at intermetro.net] > Sent: January 1, 2014 2:42 AM > To: Beavis; Bryan Tong > Cc: NANOG list > Subject: Re: First! [?] > > Happy new year! > > > Regards, > Christopher Young > Network Operations > InterMetro Communications, Inc. > > 805-433-8000 Main > 805-433-0050 Direct > 805-433-2589 Mobile > 805-582-1006 Fax > > *** Contact our NOC at > 866-446-2662 or via email ' > network.operations at intermetro.net' *** > > *** The information contained within this E-Mail and any attached > document(s) is confidential and/or privileged. It is intended solely for > the > use of the addressee(s) named above. Unauthorized disclosure, photocopying, > distribution or use of the information contained herein is prohibited. If > you believe that you have received this E-Mail in error, please notify the > sender by reply transmission or call > 805-433-8000 and delete the message without reviewing, copying or > disclosing > the message, any attachments or any contents thereof. > > -----Original Message----- > From: Beavis > Date: Wed, 1 Jan 2014 01:09:09 > To: Bryan Tong > Cc: NANOG list > Subject: Re: First! [?] > > happy new year. > > > On Tue, Dec 31, 2013 at 11:45 PM, Bryan Tong wrote: > > > Happy New Year guys! > > > > > > On Tue, Dec 31, 2013 at 10:38 PM, jamie rishaw wrote: > > > > > Happy New Year to all, and to all a good lawful interception. > > > > > > > > > > > -- > > eSited LLC > > (701) 390-9638 > > > > > > -- > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments > > Disclaimer: > http://goldmark.org/jeff/stupid-disclaimers/ > > > From pauldotwall at gmail.com Sun Jan 5 06:22:59 2014 From: pauldotwall at gmail.com (Paul WALL) Date: Sun, 5 Jan 2014 01:22:59 -0500 Subject: Comcast/Level3 issues In-Reply-To: <52C6DD58.9060802@sberkman.net> References: <52C6DD58.9060802@sberkman.net> Message-ID: The people pushing this policy are not without a face and name. They read this mailing list, and attend our conferences. You'll want to talk to John Schanz, Kevin McElearney, and Barry Tishgart. Drive Slow (like a Comcast peering port), Paul Wall On Fri, Jan 3, 2014 at 10:55 AM, Scott Berkman wrote: > Comcast having saturated links to other providers is a common and > frequently discussed issue. Here is one previous NANOG thread on the topic: > > http://mailman.nanog.org/pipermail/nanog/2010-December/029251.html > > And a related article: > http://www.dslreports.com/shownews/Claims-Resurface- > Concerning-Congested-Comcast-TATA-Links-111818 > > There are debates back and forth on the validity of the graphs from the > NANOG post, but it is a fact that at that time Comcast was heavily > pre-pending their Level BGP advertisements to force traffic over to Tata, > and many many people noticed congestion at those links in a variety of > markets. > > I wish you luck, but my personal opinion is that your fastest resolution > would be to move to another provider. Comcast is a residential ISP that > lives on extreme over-subscription and not actually being able to deliver > what customers believe they have. You'll notice a lot of recent news about > increased and more strict data caps for their subscribers, and that is the > only thing they will likely be doing to relieve these types of recurring > issues. > > -Scott > > > > On 01/02/2014 11:18 PM, R W wrote: > >> I'm seeing the same as well. Can anyone from Comcast/Level(3) reach out >> to me or provide comment. We're seeing heavy jitter and some packet loss >> most noticeable in NYC area connections between Level(3) and Comcast. >> -Rob >> >> Date: Tue, 31 Dec 2013 09:45:00 -0800 >>> Subject: Comcast/Level3 issues >>> From: dwheet at gmail.com >>> To: nanog at nanog.org >>> >>> Looking for a networking contact at comcast and/or level3. I've been >>> having some slow speed issues with hitting some sites that's going >>> through >>> level3 and I think there might be some congestion. >>> >>> Doug >>> >> >> > > From av at nethead.de Sun Jan 5 09:15:48 2014 From: av at nethead.de (Arnd Vehling) Date: Sun, 05 Jan 2014 17:15:48 +0800 Subject: Open source hardware In-Reply-To: References: <52C74C9B.30802@bitfreak.org> <52C7B981.5060303@nethead.de> Message-ID: <52C922C4.6070402@nethead.de> Hi, On 04.01.2014 21:07, Dani?l W. Crompton wrote: > To my surprise I am seeing a theme fatalistic acceptance in this thread, thats not really suprising. Then most poeple dont understand the implications "this" has. > A number have mentioned that if you are targeted there is little you can > do, and this is something that I agree with to a certain extent. Here i agree too. But i think it should be in possible to overload them by mass-creating fake data and honey pots. They dont have endless resources especially when it comes to decrypting. So, if just 10% of the "aware persons" start firing up "NSA honeypots" they get a resource problem and will fail at selecting targets. // Arnd From frnkblk at iname.com Sun Jan 5 23:46:16 2014 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 5 Jan 2014 17:46:16 -0600 Subject: anybody seeing mail problems sending to yahoo.com? (and a yahoo email contact?) In-Reply-To: References: <52C8232B.6040504@meetinghouse.net> <52C844AD.1050304@gmail.com> Message-ID: <007301cf0a70$5382a700$fa87f500$@iname.com> It looks like yahoodns.net has a NULL MX record, so anyone who emails to a host there will not get far. We saw these issues Thursday and Friday: Site yahoo.com (98.136.216.26) said after data sent: 399 TCP Read failed (Connection was closed. after 16 seconds) 16 sec" The next most frequent message is: Site yahoo.com (98.138.112.32) said in response to MAIL FROM (451 4.3.2 Internal error reading data) Frank -----Original Message----- From: Scott Howard [mailto:scott at doc.net.au] Sent: Saturday, January 04, 2014 1:53 PM To: Adrian Minta Cc: nanog at nanog.org Subject: Re: anybody seeing mail problems sending to yahoo.com? (and a yahoo email contact?) I've seen others reporting this elsewhere too, so it's clearly a problem at Yahoo's end. Someone on the mailops list reported that disabling TLS for yahoodns.net hosts fixed the problem so it may be worth trying that. Scott On Sat, Jan 4, 2014 at 9:28 AM, Adrian Minta wrote: > I'm seeing the same thing: > > Jan 4 19:13:20 mail2 postfix/error[21241]: 8C9BD1F20045: relay=none, > delay=30958, delays=30835/121/0/2.1, dsn=4.4.2, status=deferred (delivery > temporarily suspended: lost connection with mta5.am0.yahoodns.net[98.136.217.202] > while sending end of data -- message may be sent more than once) > Jan 4 19:19:44 mail2 postfix/smtp[21813]: 3993E1F20045: relay= > mta7.am0.yahoodns.net[66.196.118.33]:25, delay=98, > delays=0.58/0.03/46/51, dsn=4.4.2, status=deferred (lost connection with > mta7.am0.yahoodns.net[66.196.118.33] while sending end of data -- message > may be sent more than once) > Jan 4 19:19:44 mail2 postfix/smtp[21813]: 3993E1F20045: relay= > mta7.am0.yahoodns.net[66.196.118.33]:25, delay=98, > delays=0.58/0.03/46/51, dsn=4.4.2, status=deferred (lost connection with > mta7.am0.yahoodns.net[66.196.118.33] while sending end of data -- message > may be sent more than once) > > > -- > Best regards, > Adrian Minta > > > From techzone at greeleynet.com Mon Jan 6 01:32:13 2014 From: techzone at greeleynet.com (F.L. Whiteley) Date: Sun, 5 Jan 2014 18:32:13 -0700 Subject: anybody seeing mail problems sending to yahoo.com? (and a yahoo email contact?) In-Reply-To: <007301cf0a70$5382a700$fa87f500$@iname.com> References: <52C8232B.6040504@meetinghouse.net> <52C844AD.1050304@gmail.com> <007301cf0a70$5382a700$fa87f500$@iname.com> Message-ID: <098201cf0a7f$20c3f030$624bd090$@greeleynet.com> NPR (USA) reports that ads on Yahoo Mail were java exploits loaded on Dutch servers infecting 27,000/hour. Frank Whiteley -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Sunday, January 05, 2014 4:46 PM To: 'Scott Howard'; Adrian Minta Cc: nanog at nanog.org Subject: RE: anybody seeing mail problems sending to yahoo.com? (and a yahoo email contact?) It looks like yahoodns.net has a NULL MX record, so anyone who emails to a host there will not get far. We saw these issues Thursday and Friday: Site yahoo.com (98.136.216.26) said after data sent: 399 TCP Read failed (Connection was closed. after 16 seconds) 16 sec" The next most frequent message is: Site yahoo.com (98.138.112.32) said in response to MAIL FROM (451 4.3.2 Internal error reading data) Frank -----Original Message----- From: Scott Howard [mailto:scott at doc.net.au] Sent: Saturday, January 04, 2014 1:53 PM To: Adrian Minta Cc: nanog at nanog.org Subject: Re: anybody seeing mail problems sending to yahoo.com? (and a yahoo email contact?) I've seen others reporting this elsewhere too, so it's clearly a problem at Yahoo's end. Someone on the mailops list reported that disabling TLS for yahoodns.net hosts fixed the problem so it may be worth trying that. Scott On Sat, Jan 4, 2014 at 9:28 AM, Adrian Minta wrote: > I'm seeing the same thing: > > Jan 4 19:13:20 mail2 postfix/error[21241]: 8C9BD1F20045: relay=none, > delay=30958, delays=30835/121/0/2.1, dsn=4.4.2, status=deferred > (delivery temporarily suspended: lost connection with mta5.am0.yahoodns.net[98.136.217.202] > while sending end of data -- message may be sent more than once) Jan > 4 19:19:44 mail2 postfix/smtp[21813]: 3993E1F20045: relay= > mta7.am0.yahoodns.net[66.196.118.33]:25, delay=98, > delays=0.58/0.03/46/51, dsn=4.4.2, status=deferred (lost connection > with mta7.am0.yahoodns.net[66.196.118.33] while sending end of data -- > message may be sent more than once) Jan 4 19:19:44 mail2 > postfix/smtp[21813]: 3993E1F20045: relay= > mta7.am0.yahoodns.net[66.196.118.33]:25, delay=98, > delays=0.58/0.03/46/51, dsn=4.4.2, status=deferred (lost connection > with mta7.am0.yahoodns.net[66.196.118.33] while sending end of data -- > message may be sent more than once) > > > -- > Best regards, > Adrian Minta > > > From mysidia at gmail.com Mon Jan 6 01:49:50 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 5 Jan 2014 19:49:50 -0600 Subject: anybody seeing mail problems sending to yahoo.com? (and a yahoo email contact?) In-Reply-To: <098201cf0a7f$20c3f030$624bd090$@greeleynet.com> References: <52C8232B.6040504@meetinghouse.net> <52C844AD.1050304@gmail.com> <007301cf0a70$5382a700$fa87f500$@iname.com> <098201cf0a7f$20c3f030$624bd090$@greeleynet.com> Message-ID: On Sun, Jan 5, 2014 at 7:32 PM, F.L. Whiteley wrote: I observe successful deliveries to outgoing requests for @yahoo.com, with no host abruptly disconnected. about 2% deferral errors such as "Site yahoo.com (66.196.118.240) said after data sent: 451 Message temporarily deferred - [70]" > NPR (USA) reports that ads on Yahoo Mail were java exploits loaded on Dutch > servers infecting 27,000/hour. > hmm... http://arstechnica.com/security/2014/01/malware-attacks-thousands-of-yahoo-com-visitors-through-java-exploit/ Interesting... while this is surely a bad thing. Anyone who still has Java installed and enabled in the web browser that is used is just begging to get their system owned+bugged, and to a lesser extent, those who still have Adobe reader browser plugins turned on..... it is much safer operating to just assume it has already happened, than to wait for the news. :) > Frank Whiteley -- -JH From Valdis.Kletnieks at vt.edu Mon Jan 6 05:44:06 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 06 Jan 2014 00:44:06 -0500 Subject: turning on comcast v6 In-Reply-To: Your message of "Sat, 04 Jan 2014 10:10:24 -0600." References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> <52C6778A.5070309@dougbarton.us> <9D39E329-B2C3-4F53-ABD9-19C3D3D83539@delong.com> Message-ID: <30517.1388987046@turing-police.cc.vt.edu> On Sat, 04 Jan 2014 10:10:24 -0600, Leo Bicknell said: > What happens when Joe Home User buys a new Linksys and wants to plug it in to > get a firmware update before installing it? Are we really supposed to expect > that every Joe Homeowner understands RA Guard and configures it for their home > network? If Joe Home User has a rogue device spewing RA's, he probably has a bigger problem than just not having RA Guard enabled. He either has a badly misconfigured router (and one that's disobeying the mandate to not RA if you don't have an uplink), or he has a compromised malicious host. In either case, he's got bigger fish to fry. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From aledm at qix.co.uk Mon Jan 6 10:33:20 2014 From: aledm at qix.co.uk (Aled Morris) Date: Mon, 6 Jan 2014 10:33:20 +0000 Subject: turning on comcast v6 In-Reply-To: References: <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> <52C6778A.5070309@dougbarton.us> <9D39E329-B2C3-4F53-ABD9-19C3D3D83539@delong.com> Message-ID: On 4 January 2014 06:06, Ricky Beam wrote: > It'll **NEVER** be a default because it breaks too many clueless people's > networks. Just like, surprise, DHCP "guard" isn't on by default in any > gear I'm aware of. > > Spanning-tree portfast isn't on by default, and that breaks plenty of clueless people's networks with client DHCP timeouts. Just sayin'. I appreciate the view that IPv6 was designed in a certain way, partly to fix the problems and remove the kludges in IPv4; the reality is that IPv4 was wildly successful because it wasn't the proscriptive OSI. Whilst I would prefer not to see the mistakes of IPv4 repeated (especially NAT and RFC1918 addressing) trying to "help" people not shoot themselves in the foot will simply retard deployment and maybe result in even worse workarounds. Come on people - Postel's Law applies, let's be liberal in what we accept into the protocol design too. If users want DHCP served default gateway, fine. Nobody's forcing you to enable it on your network if you don't want to. Aled From bicknell at ufp.org Mon Jan 6 15:44:32 2014 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 6 Jan 2014 09:44:32 -0600 Subject: turning on comcast v6 In-Reply-To: <30517.1388987046@turing-police.cc.vt.edu> References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> <52C6778A.5070309@dougbarton.us> <9D39E329-B2C3-4F53-ABD9-19C3D3D83539@delong.com> <30517.1388987046@turing-police.cc.vt.edu> Message-ID: On Jan 5, 2014, at 11:44 PM, Valdis.Kletnieks at vt.edu wrote: > If Joe Home User has a rogue device spewing RA's, he probably has a bigger > problem than just not having RA Guard enabled. He either has a badly > misconfigured router (and one that's disobeying the mandate to not RA > if you don't have an uplink), or he has a compromised malicious host. > > In either case, he's got bigger fish to fry. "mandate" isn't the right description. http://tools.ietf.org/html/rfc6059 There is a ~3 year old _proposed standard_ for the behavior you describe. I have yet to see any compliant equipment at $LocalBigBox, but maybe I'm not purchasing the right gear. So yet again, the response I get to "ra's are fragile" is "deploy this brand new band-aid that can't be purchased yet". Can we just have DHCPv6, please? How many dozens of technologies are we going to invent to try and avoid putting a default route in DHCP? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Valdis.Kletnieks at vt.edu Mon Jan 6 17:10:54 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 06 Jan 2014 12:10:54 -0500 Subject: turning on comcast v6 In-Reply-To: Your message of "Mon, 06 Jan 2014 09:44:32 -0600." References: <86a9g64usr.fsf@valhalla.seastrom.com> <52B3C382.7080208@kenweb.org> <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> <52C6778A.5070309@dougbarton.us> <9D39E329-B2C3-4F53-ABD9-19C3D3D83539@delong.com> <30517.1388987046@turing-police.cc.vt.edu> Message-ID: <13119.1389028254@turing-police.cc.vt.edu> On Mon, 06 Jan 2014 09:44:32 -0600, Leo Bicknell said: > "mandate" isn't the right description. > > http://tools.ietf.org/html/rfc6059 > > There is a ~3 year old _proposed standard_ for the behavior you describe. I'll make the case that if a "router" becomes unable to forward packets because it has lost its uplink or connection to another subnet (so it's now homed on only one subnet), that's a router-to-host transition. RFC2461, sections 6.2.4 and 6.2.5 discuss the case of a router becoming a host - and it includes "thou shalt cease blabbing the RAs after a suitable amount of time". And that's a heck of a lot older than 3 years. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From nanog at data102.com Mon Jan 6 17:57:06 2014 From: nanog at data102.com (randal k) Date: Mon, 6 Jan 2014 10:57:06 -0700 Subject: 10gbps peering subscriber switch recommendation Message-ID: Good morning, We're in the market to move our IX peering off of our core (too much BGP/CPU :-/ ) and onto a dedicated switch. Anybody have a recommendation on a switch that can do the following without costing a fortune? I have scoured Cisco, and bang for the buck is ... ASR9k (way over powered for handling zero-feature IX traffic), 3-8x 10gbps ports 64k routes minimum, preferably 128k Must be able to speak BGP Native/functional IPv6 would be sharp! Basic QoS to police our ports The prefix count seems to be the killer, as our exchange table is getting pretty big (42k+ currently). I'm really tempted to build a vyatta box or similar, but would rather do something off the shelf -- especially if it can be 1-2 gens old and cost effective. I'm certain that this same situation is scratching many other folks as exchanges become more important. Thanks for your input in advance -- stay warm! Randal From adrian.minta at gmail.com Mon Jan 6 18:12:44 2014 From: adrian.minta at gmail.com (Adrian Minta) Date: Mon, 06 Jan 2014 20:12:44 +0200 Subject: 10gbps peering subscriber switch recommendation In-Reply-To: References: Message-ID: <52CAF21C.3090707@gmail.com> > Good morning, > We're in the market to move our IX peering off of our core (too much > BGP/CPU :-/ ) and onto a dedicated switch. Brocade ICX 7750 Switch seems to satisfy all the requirements. -- Best regards, Adrian Minta From aledm at qix.co.uk Mon Jan 6 18:24:19 2014 From: aledm at qix.co.uk (Aled Morris) Date: Mon, 6 Jan 2014 18:24:19 +0000 Subject: 10gbps peering subscriber switch recommendation In-Reply-To: References: Message-ID: On 6 January 2014 17:57, randal k wrote: > Good morning, > We're in the market to move our IX peering off of our core (too much > BGP/CPU :-/ ) and onto a dedicated switch. > > Anybody have a recommendation on a switch that can do the following > without costing a fortune? I have scoured Cisco, and bang for the buck > is ... ASR9k (way over powered for handling zero-feature IX traffic), > > 3-8x 10gbps ports > 64k routes minimum, preferably 128k > Must be able to speak BGP > Native/functional IPv6 would be sharp! > Basic QoS to police our ports > > The prefix count seems to be the killer, as our exchange table is > getting pretty big (42k+ currently). I'm really tempted to build a > vyatta box or similar, but would rather do something off the shelf -- > especially if it can be 1-2 gens old and cost effective. > > If you don't need to carry a full Internet table, the Cisco 4500-X has plenty of features and the 32 port model can accommodate 256k IPv4 routes. It also does IPv6 in hardware (128k routes) Aled From nick at foobar.org Mon Jan 6 18:24:22 2014 From: nick at foobar.org (Nick Hilliard) Date: Mon, 06 Jan 2014 18:24:22 +0000 Subject: 10gbps peering subscriber switch recommendation In-Reply-To: <52CAF21C.3090707@gmail.com> References: <52CAF21C.3090707@gmail.com> Message-ID: <52CAF4D6.8090908@foobar.org> On 06/01/2014 18:12, Adrian Minta wrote: > Brocade ICX 7750 Switch seems to satisfy all the requirements. except qos (which needs switch port buffer space). There are no cheap 10G boxes on the market at the moment which have reasonable numbers of 10G ports and reasonable sized. Plenty which have 2-4 10G ports with reasonable buffers and lots more which have plenty of 10G ports with hardly any buffer space. Nick From jra at baylink.com Mon Jan 6 18:29:18 2014 From: jra at baylink.com (Jay Ashworth) Date: Mon, 6 Jan 2014 13:29:18 -0500 (EST) Subject: Uverse Cleveland OH question Message-ID: <30276870.2820.1389032958661.JavaMail.root@benjamin.baylink.com> If there's anyone with firsthand knowledge of that system, could you shoot me a note off-list? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From dougb at dougbarton.us Mon Jan 6 18:37:39 2014 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 06 Jan 2014 10:37:39 -0800 Subject: turning on comcast v6 In-Reply-To: References: <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> <52C6778A.5070309@dougbarton.us> <52C681C6.3080402@dougbarton.us> <52C75FE1.30704@dougbarton.us> Message-ID: <52CAF7F3.6010809@dougbarton.us> On 01/04/2014 05:42 AM, Baldur Norddahl wrote: > On Sat, Jan 4, 2014 at 2:12 AM, Doug Barton wrote: > >> >>> If you did add default route to DHCPv6, what is then supposed to happen to >>> the other routes, that the client might discover? >>> >> >> You would configure the client not to do RS, and to ignore any RAs that it >> receives. Simple. >> >> > If you are going to modify the client, you can use any method you like, No, I can't, because the method I would like to use is not in the spec. > including having the client simply use fe80:: or prefix:: as default > gateway. > > You want a secure way to configure the clients. That sounds more like > Secure NDP (SEND) than it sounds like DHCPv6 with default gateway. Thank you for the textbook illustration of the "anything but DHCP!" mindset I was referring to earlier. Doug From owen at delong.com Mon Jan 6 19:40:29 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Jan 2014 11:40:29 -0800 Subject: turning on comcast v6 In-Reply-To: <52CAF7F3.6010809@dougbarton.us> References: <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> <52C6778A.5070309@dougbarton.us> <52C681C6.3080402@dougbarton.us> <52C75FE1.30704@dougbarton.us> <52CAF7F3! .6010809@dougbarton.us> Message-ID: <741B5A5F-3D87-4BA2-9349-F5BB94A8B483@delong.com> On Jan 6, 2014, at 10:37 , Doug Barton wrote: > On 01/04/2014 05:42 AM, Baldur Norddahl wrote: >> On Sat, Jan 4, 2014 at 2:12 AM, Doug Barton wrote: >> >>> >>>> If you did add default route to DHCPv6, what is then supposed to happen to >>>> the other routes, that the client might discover? >>>> >>> >>> You would configure the client not to do RS, and to ignore any RAs that it >>> receives. Simple. >>> >>> >> If you are going to modify the client, you can use any method you like, > > No, I can't, because the method I would like to use is not in the spec. Doesn't have to be... You can create any local DHCPv6 extension you like. That _IS_ in the spec. Owen From mark.tinka at seacom.mu Mon Jan 6 19:43:18 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 6 Jan 2014 21:43:18 +0200 Subject: 10gbps peering subscriber switch recommendation In-Reply-To: <52CAF4D6.8090908@foobar.org> References: <52CAF21C.3090707@gmail.com> <52CAF4D6.8090908@foobar.org> Message-ID: <201401062143.22474.mark.tinka@seacom.mu> On Monday, January 06, 2014 08:24:22 PM Nick Hilliard wrote: > except qos (which needs switch port buffer space). There > are no cheap 10G boxes on the market at the moment which > have reasonable numbers of 10G ports and reasonable > sized. Plenty which have 2-4 10G ports with reasonable > buffers and lots more which have plenty of 10G ports > with hardly any buffer space. FIB space requirements in a switch are also going to limit your options. Also, many "non-service provider" switches don't do egress policing (they might do shaping, but then if the buffers are small...). Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From hannigan at gmail.com Mon Jan 6 19:52:37 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 6 Jan 2014 14:52:37 -0500 Subject: IXP + government transparency report Message-ID: As well as being first to be open-ix certified, I think LINX hit a second first that is as interesting; https://www.linx.net/service/publicpeering/novafiles/nova-usgov-reports.html Applause +LINX Best, -M< From woody at pch.net Mon Jan 6 19:57:34 2014 From: woody at pch.net (Bill Woodcock) Date: Mon, 6 Jan 2014 11:57:34 -0800 Subject: IXP + government transparency report In-Reply-To: References: Message-ID: On Jan 6, 2014, at 11:52 AM, Martin Hannigan wrote: > As well as being first to be open-ix certified, I think LINX hit a second > first that is as interesting; > > > https://www.linx.net/service/publicpeering/novafiles/nova-usgov-reports.html ?and is this function being conducted completely without dependencies inside the U.S.? -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From hannigan at gmail.com Mon Jan 6 20:21:13 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 6 Jan 2014 15:21:13 -0500 Subject: IXP + government transparency report In-Reply-To: References: Message-ID: On Mon, Jan 6, 2014 at 2:57 PM, Bill Woodcock wrote: > > On Jan 6, 2014, at 11:52 AM, Martin Hannigan wrote: > > > As well as being first to be open-ix certified, I think LINX hit a second > > first that is as interesting; > > > > > > > https://www.linx.net/service/publicpeering/novafiles/nova-usgov-reports.html > > ?and is this function being conducted completely without dependencies > inside the U.S.? > Bill, OIX certified organizations must provide an accurate and monthly report on Government Information Requests and actions taken related to the requests. You can see an example here http://xmission.com/transparency With regards to Patriot 215 and FISA 701, there are recommendations for warrant canaries. Obviously, much trickier. I think the point is about leadership and taking small, but giant, steps. I hope that everyone in the infrastructure follows this lead and does exactly the same thing. Best, -M< From rdroms at cisco.com Mon Jan 6 20:30:11 2014 From: rdroms at cisco.com (Ralph Droms (rdroms)) Date: Mon, 6 Jan 2014 20:30:11 +0000 Subject: NANOG Digest, Vol 72, Issue 17 In-Reply-To: References: Message-ID: <5195BF4B-78FB-4553-B4B9-6DA5F4BF99A7@cisco.com> > Date: Mon, 6 Jan 2014 11:40:29 -0800 > From: Owen DeLong > To: Doug Barton > Cc: "nanog at nanog.org" > Subject: Re: turning on comcast v6 > Message-ID: <741B5A5F-3D87-4BA2-9349-F5BB94A8B483 at delong.com> > Content-Type: text/plain; charset=iso-8859-1 > > > [...] > Doesn't have to be... You can create any local DHCPv6 extension you like. That _IS_ in the spec. > > Owen Well, not exactly. The authors of RFC 3315, smarting (if I recall correctly) from the local options debacle in DHCPv4, didn't set aside any experimental option codes for DHCPv6. Oops and mea culpa. Having said that, I suppose I can't formally recommend that an implementor use an option code somewhere near the top of the range and implement a quick extension to a client and server for the default router option, which would result in some running code to point at. But running code isn't enough. The last time I took the default router option to the IETF, it died (in the 6man WG, again trusting to memory) for lack of support. More or less the same thing more recently in the mif WG (more support in mif, but it was the wrong WG). So, someone will have to do the hard work of shepherding and supporting the document through publication in the right WG. I understand Nick Hilliard may be undertaking that effort; those interested in the new option might want to lend Nick a hand (apologies to Nick if I've got that wrong). - Ralph From nitzan.tzelniker at gmail.com Mon Jan 6 20:36:29 2014 From: nitzan.tzelniker at gmail.com (Nitzan Tzelniker) Date: Mon, 6 Jan 2014 22:36:29 +0200 Subject: 10gbps peering subscriber switch recommendation In-Reply-To: <201401062143.22474.mark.tinka@seacom.mu> References: <52CAF21C.3090707@gmail.com> <52CAF4D6.8090908@foobar.org> <201401062143.22474.mark.tinka@seacom.mu> Message-ID: A little bit overkill in term of number of ports but you can consider the new Trident 2 switches Juniper EX-5100, Cisco Nexus 3100 ..... They have unified TCAM that can store 128K v4 routes Nitzan On Mon, Jan 6, 2014 at 9:43 PM, Mark Tinka wrote: > On Monday, January 06, 2014 08:24:22 PM Nick Hilliard wrote: > > > except qos (which needs switch port buffer space). There > > are no cheap 10G boxes on the market at the moment which > > have reasonable numbers of 10G ports and reasonable > > sized. Plenty which have 2-4 10G ports with reasonable > > buffers and lots more which have plenty of 10G ports > > with hardly any buffer space. > > FIB space requirements in a switch are also going to limit > your options. > > Also, many "non-service provider" switches don't do egress > policing (they might do shaping, but then if the buffers are > small...). > > Mark. > From jfbeam at gmail.com Mon Jan 6 20:57:00 2014 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 06 Jan 2014 15:57:00 -0500 Subject: turning on comcast v6 In-Reply-To: References: <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> <52C6778A.5070309@dougbarton.us> <9D39E329-B2C3-4F53-ABD9-19C3D3D83539@delong.com> Message-ID: On Sat, 04 Jan 2014 14:03:21 -0500, Owen DeLong wrote: > A router, yes. THE router, not unless the network is very stupidly put > together. Like every win7 and win8 machine on the planet? (IPv6 is installed and enabled by default. Few places have IPv6 enabled on their LAN, so a single RA would, indeed, 0wn3z those machines instantly.) > I disagree. Unlike with DHCP guard, RA guard can make reasonable > predictions in most cases. Switches with ?uplink? ports designated, for > example, could easily default to permitting RAs only from those ports. One cannot **GUESS** the security for a network. You must either *know* or *not know* what's on a port. What makes a port "uplink" (read: "trusted")? The only way to know for sure, without creating surprises or exploitable holes, is make the ADMIN explicitly SET EACH PORT. That's the way DHCP Guard works. That's the way spanning-tree portfast, bpdu guard, root guard, etc., etc. works. That's the way port security works. And that's the way RA Guard WILL be done. From owen at delong.com Mon Jan 6 21:08:35 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Jan 2014 13:08:35 -0800 Subject: turning on comcast v6 In-Reply-To: References: <465966A5F5B867419F604CD3E604C1E55932A915@PRA-DCA-MAIL.pra.ray.com> <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> <52C6778A.5070309@dougbarton.us> <9D39E329-B2C3-4F53-ABD9-19C3D3D83539@delong.com> Message-ID: On Jan 6, 2014, at 12:57 , Ricky Beam wrote: > On Sat, 04 Jan 2014 14:03:21 -0500, Owen DeLong wrote: >> A router, yes. THE router, not unless the network is very stupidly put together. > > Like every win7 and win8 machine on the planet? (IPv6 is installed and enabled by default. Few places have IPv6 enabled on their LAN, so a single RA would, indeed, 0wn3z those machines instantly.) > The obvious solution to that is to install real IPv6 routers. >> I disagree. Unlike with DHCP guard, RA guard can make reasonable predictions in most cases. Switches with ?uplink? ports designated, for example, could easily default to permitting RAs only from those ports. > > One cannot **GUESS** the security for a network. You must either *know* or *not know* what's on a port. What makes a port "uplink" (read: "trusted")? The only way to know for sure, without creating surprises or exploitable holes, is make the ADMIN explicitly SET EACH PORT. That's the way DHCP Guard works. That's the way spanning-tree portfast, bpdu guard, root guard, etc., etc. works. That's the way port security works. And that's the way RA Guard WILL be done. The port isn't particularly trusted, but it is allowed to send RAs which are forwarded to the network by default. Obviously a sane switch would allow this configuration to be changed. We're not talking about the security model for a network, we're talking about the default behavior of a switch. Defaults are, inherently guesses to some extent. Nonetheless, a switch must have some default behavior. It seems to me that in the case of switches which have otherwise designated uplink ports, it is logical to make those ports default to RA allowed while defaulting to not allowing RAs from other ports by default. Owen From fergdawgster at mykolab.com Mon Jan 6 21:22:27 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Mon, 06 Jan 2014 13:22:27 -0800 Subject: turning on comcast v6 In-Reply-To: References: <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> <52C6778A.5070309@dougbarton.us> <9D39E329-B2C3-4F53-ABD9-19C3D3D83539@delong.com> Message-ID: <52CB1E93.6030806@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 1/6/2014 1:08 PM, Owen DeLong wrote: > The port isn't particularly trusted, but it is allowed to send RAs > which are forwarded to the network by default. Obviously a sane > switch would allow this configuration to be changed. We're not > talking about the security model for a network, we're talking about > the default behavior of a switch. > > Defaults are, inherently guesses to some extent. Nonetheless, a > switch must have some default behavior. > > It seems to me that in the case of switches which have otherwise > designated uplink ports, it is logical to make those ports default > to RA allowed while defaulting to not allowing RAs from other ports > by default. Some people do not want switches making IP address assignments. That's all. :-) - - ferg - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLLHpMACgkQKJasdVTchbL6+gEApBli/t4RF4Eq3XroJkqrRmgn 9WYSy2ReVwo7Bx9l+PMA/16zyzwOgG4fdNc9zgt0A4Pb+dGpMBx8LkRY6Kj71F5t =J8uY -----END PGP SIGNATURE----- From pauldotwall at gmail.com Mon Jan 6 21:25:31 2014 From: pauldotwall at gmail.com (Paul WALL) Date: Mon, 6 Jan 2014 21:25:31 +0000 Subject: Comcast/Level3 issues In-Reply-To: <81119A7A9796404B9F7A403A5BD7F1D9A280FDDE@PACDCEXMB02.cable.comcast.com> References: <81119A7A9796404B9F7A403A5BD7F1D9A280FDDE@PACDCEXMB02.cable.comcast.com> Message-ID: Kevin, Thank you for the info. Can you say how many quarters or years until Comcast is resolved? I've seen references to that obscure whitepaper (co-authored, ironically, by Patrick Gilmore) before on the broadbandreports forums, by someone with a lot of knowledge on Comcast's network and internal politics/peering discussions. Do you know who the poster is? https://encrypted.google.com/search?q=28619103+dslreports+site:www.dslreports.com&biw=1000&bih=1000 Drive Slow, Paul WALL On Sun, Jan 5, 2014 at 6:17 PM, McElearney, Kevin wrote: > FWIW, we work with each issue and try to fix them as best we can. Several > are underway. Much of the ?traffic shifting? is happening external to > Comcast with very large traffic swings congesting AND uncongesting paths. > The beauty of adaptive routing via CDN and text book ?Creating Incentives > to Peer? - feel free to google that... > > - Kevin > > On 1/5/14, 1:22 AM, "Paul WALL" wrote: > >>The people pushing this policy are not without a face and name. They read >>this mailing list, and attend our conferences. You'll want to talk to >>John >>Schanz, Kevin McElearney, and Barry Tishgart. >> >>Drive Slow (like a Comcast peering port), >>Paul Wall >> >> >>On Fri, Jan 3, 2014 at 10:55 AM, Scott Berkman wrote: >> >>> Comcast having saturated links to other providers is a common and >>> frequently discussed issue. Here is one previous NANOG thread on the >>>topic: >>> >>> http://mailman.nanog.org/pipermail/nanog/2010-December/029251.html >>> >>> And a related article: >>> http://www.dslreports.com/shownews/Claims-Resurface- >>> Concerning-Congested-Comcast-TATA-Links-111818 >>> >>> There are debates back and forth on the validity of the graphs from the >>> NANOG post, but it is a fact that at that time Comcast was heavily >>> pre-pending their Level BGP advertisements to force traffic over to >>>Tata, >>> and many many people noticed congestion at those links in a variety of >>> markets. >>> >>> I wish you luck, but my personal opinion is that your fastest resolution >>> would be to move to another provider. Comcast is a residential ISP that >>> lives on extreme over-subscription and not actually being able to >>>deliver >>> what customers believe they have. You'll notice a lot of recent news >>>about >>> increased and more strict data caps for their subscribers, and that is >>>the >>> only thing they will likely be doing to relieve these types of recurring >>> issues. >>> >>> -Scott >>> >>> >>> >>> On 01/02/2014 11:18 PM, R W wrote: >>> >>>> I'm seeing the same as well. Can anyone from Comcast/Level(3) reach out >>>> to me or provide comment. We're seeing heavy jitter and some packet >>>>loss >>>> most noticeable in NYC area connections between Level(3) and Comcast. >>>> -Rob >>>> >>>> Date: Tue, 31 Dec 2013 09:45:00 -0800 >>>>> Subject: Comcast/Level3 issues >>>>> From: dwheet at gmail.com >>>>> To: nanog at nanog.org >>>>> >>>>> Looking for a networking contact at comcast and/or level3. I've been >>>>> having some slow speed issues with hitting some sites that's going >>>>> through >>>>> level3 and I think there might be some congestion. >>>>> >>>>> Doug >>>>> >>>> >>>> >>> >>> > From owen at delong.com Mon Jan 6 21:30:00 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Jan 2014 13:30:00 -0800 Subject: turning on comcast v6 In-Reply-To: <52CB1E93.6030806@mykolab.com> References: <465966A5F5B867419F604CD3E604C1E55932A93B@PRA-DCA-MAIL.pra.ray.com> <595B1A61-2198-44E9-91EB-827C7091EA9F@uchicago.edu> <6E9E84B3-0354-4E58-A5A0-3C28B3BAF61A@uchicago.edu> <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org> <178A1408-7966-4EB6-8A84-17E563F35508@delong.com> <52C6432A.3070608@matthew.at> <52C6778A.5070309@dougbarton.us> <9D39E329-B2C3-4F53-ABD9-19C3D3D83539@delong.com> <52CB1E93.603080! 6@mykolab.com> Message-ID: <192865F2-DDFB-4A84-ADE8-4EA564F881B9@delong.com> On Jan 6, 2014, at 13:22 , Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 1/6/2014 1:08 PM, Owen DeLong wrote: > >> The port isn't particularly trusted, but it is allowed to send RAs >> which are forwarded to the network by default. Obviously a sane >> switch would allow this configuration to be changed. We're not >> talking about the security model for a network, we're talking about >> the default behavior of a switch. >> >> Defaults are, inherently guesses to some extent. Nonetheless, a >> switch must have some default behavior. >> >> It seems to me that in the case of switches which have otherwise >> designated uplink ports, it is logical to make those ports default >> to RA allowed while defaulting to not allowing RAs from other ports >> by default. > > Some people do not want switches making IP address assignments. That's > all. :-) > Huh??? I don't think I said anything even remotely like that. Owen From randy at psg.com Mon Jan 6 21:53:14 2014 From: randy at psg.com (Randy Bush) Date: Mon, 06 Jan 2014 11:53:14 -1000 Subject: 10gbps peering subscriber switch recommendation In-Reply-To: References: <52CAF21C.3090707@gmail.com> <52CAF4D6.8090908@foobar.org> <201401062143.22474.mark.tinka@seacom.mu> Message-ID: > A little bit overkill in term of number of ports but you can consider > the new Trident 2 switches Juniper EX-5100, Cisco Nexus 3100 ..... > They have unified TCAM that can store 128K v4 routes the nice thing about buying bgp devices that can not hold a full table is that you can expense them in the year of purchase as opposed to amortizing them over 5 years or so. randy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 527 bytes Desc: not available URL: From Kevin_McElearney at cable.comcast.com Mon Jan 6 23:21:20 2014 From: Kevin_McElearney at cable.comcast.com (McElearney, Kevin) Date: Mon, 6 Jan 2014 23:21:20 +0000 Subject: Comcast/Level3 issues In-Reply-To: Message-ID: <81119A7A9796404B9F7A403A5BD7F1D9A2812B34@PACDCEXMB02.cable.comcast.com> ?Paul?, I don?t read this list often, and rarely have seen a private message reposted as you did, but at the risk of DFTT, give me some time to think through a discussion topic for this list which touches on some of these issues. - Kevin DISCLOSURE: On DSLR, I am ccneteng when I visit there. http://www.dslreports.com/profile?find=ccneteng From tglassey at earthlink.net Tue Jan 7 00:03:38 2014 From: tglassey at earthlink.net (TGLASSEY) Date: Mon, 06 Jan 2014 16:03:38 -0800 Subject: Open source hardware In-Reply-To: <52C922C4.6070402@nethead.de> References: <52C74C9B.30802@bitfreak.org> <52C7B981.5060303@nethead.de> <52C922C4.6070402@nethead.de> Message-ID: <52CB445A.7060604@earthlink.net> Arnd - the German Government is most likely a partner meaning overloading the NSA is pointless if you could. Todd On 1/5/2014 1:15 AM, Arnd Vehling wrote: > Hi, > > On 04.01.2014 21:07, Dani?l W. Crompton wrote: >> To my surprise I am seeing a theme fatalistic acceptance in this thread, > > thats not really suprising. Then most poeple dont understand the > implications "this" has. > >> A number have mentioned that if you are targeted there is little you can >> do, and this is something that I agree with to a certain extent. > > Here i agree too. But i think it should be in possible to overload > them by mass-creating fake data and honey pots. They dont have endless > resources especially when it comes to decrypting. So, if just 10% of > the "aware persons" start firing up "NSA honeypots" they get a > resource problem and will fail at selecting targets. > > // Arnd > > > -- ------------- Personal Email - Disclaimers Apply From blair.trosper at gmail.com Tue Jan 7 08:25:28 2014 From: blair.trosper at gmail.com (Blair Trosper) Date: Tue, 7 Jan 2014 02:25:28 -0600 Subject: Amazon help Message-ID: Can someone from AWS/Amazon netops contact me off-list for help an issue? From nick at foobar.org Tue Jan 7 10:47:45 2014 From: nick at foobar.org (Nick Hilliard) Date: Tue, 07 Jan 2014 10:47:45 +0000 Subject: 10gbps peering subscriber switch recommendation In-Reply-To: <201401062143.22474.mark.tinka@seacom.mu> References: <52CAF21C.3090707@gmail.com> <52CAF4D6.8090908@foobar.org> <201401062143.22474.mark.tinka@seacom.mu> Message-ID: <52CBDB51.70608@foobar.org> On 06/01/2014 19:43, Mark Tinka wrote: > FIB space requirements in a switch are also going to limit > your options. it's the merchant silicon boxes which are driving high density 10g prices down, but most of these boxes tends to come with small fibs and tiny buffers which limits their deployment usefulness. Still, if they work for your requirements, they are completely awesome. Nick From mehmet at akcin.net Tue Jan 7 14:19:42 2014 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 7 Jan 2014 06:19:42 -0800 Subject: DNS-OARC Call for Presentations Message-ID: Call for Presentations - DNS-OARC Spring Workshop, May 2014 Next OARC Spring Workshop will take place in Warsaw, Poland on May 10th and 11th, the weekend before RIPE68. OARC is requesting proposals for presentations, with a preference for DNS privacy and confidentiality work and ideas, and DNS over alternative (non UDP) transports. This workshop continues OARC's tradition of having meetings include a strong operational component. Presentations from DNS operators are particularly welcome. We'll also gladly accept talks from DNS researchers, as well as any other DNS-related subjects such as tools, visualizations and data analysis. If you are an OARC member, and have a sensitive topic you would like to present for members-only, we will accommodate those talks too. Adopting practice from other conferences, a section of lightning talks will be added for short presentations. Workshop Milestones * 20 December 2013, Call for Presentations posted * 6 January 2014, Open for submissions * 1 March 2014, Deadline for submission * 28 March 2014, Final Program published * May 9 2014, Final deadline for slideset submission Details for abstract submission will be published here: https://indico.dns-oarc.net/event/workshop-2014-05 at the beginning of January 2014. If you consider submitting a presentation, please let the Programme Committee know in advance to help us organize the presentations tracks. You can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via submissions at dns-oarc.net if you have questions or concerns. Mehmet Akcin, for the OARC Programme Committee (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) From vristevs at ramapo.edu Tue Jan 7 13:57:48 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Tue, 07 Jan 2014 08:57:48 -0500 Subject: Open source hardware In-Reply-To: References: Message-ID: <52CC07DC.4080903@ramapo.edu> Sorry to get off topic, but is there a company that you can recommend? The price of the Cisco single mode GLC-LH-SMD= is killing me. I see a bunch of third party ones on Amazon and CDW but I'd to love to get my hands one that has the correct vendor code without going and trying them all. On 1/3/2014 7:48 AM, Ray Soucy wrote: > You actually buy brand-name SFP's? That's like buying the gold-plated HDMI > Monster Cable at Best Buy at markup ... > > I just find the the companies that the vendors contract to make their OEM > SFP's and buy direct. Same SFP from the same factory except one has a > Cisco sticker. ;-) > > You can even get them with the correct vendor code, been doing this for > years and there is no difference in failure rate or quality and we go > through hundreds of SFPs. > > > > Vlad Network Manager From vristevs at ramapo.edu Tue Jan 7 14:24:59 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Tue, 07 Jan 2014 09:24:59 -0500 Subject: Vyatta to VyOS In-Reply-To: References: Message-ID: <52CC0E3B.1090707@ramapo.edu> This project looks interesting. Our 7206 VXR is at ends final days and replacing it with and ASR series is very expensive considering we're only pushing 600megs of Internet traffic with a full BGP table. When I go to the page linked below, I didn't see a mailing list, forum or very much documentation for it. Is there another site with this info? I'd love to test a few builds out but I never used Vyatta before. On 12/23/2013 10:18 AM, Ray Soucy wrote: > Many here might be interested, > > In response to Brocade not giving the community edition of Vyatta much > attention recently, some of the more active community members have created > a fork of the GPL code used in Vyatta. > > It's called VyOS, and yesterday they released 1.0. > > http://vyos.net/ > > I've been playing with the development builds and it seems to be every bit > as stable as the Vyatta releases. > > Will be interesting to see how the project unfolds :-) > -- Vlade Ristevski Network Manager IT Services Ramapo College (201)-684-6854 From jared at puck.nether.net Tue Jan 7 14:40:17 2014 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 7 Jan 2014 09:40:17 -0500 Subject: Vyatta to VyOS In-Reply-To: <52CC0E3B.1090707@ramapo.edu> References: <52CC0E3B.1090707@ramapo.edu> Message-ID: <3CA824E7-B253-4BFD-846E-A7B39E08ACFF@puck.nether.net> Reminder there is a mailing list for this: http://puck.nether.net/mailman/listinfo/vyatta-nsp > On Jan 7, 2014, at 9:24 AM, Vlade Ristevski wrote: > > This project looks interesting. Our 7206 VXR is at ends final days and replacing it with and ASR series is very expensive considering we're only pushing 600megs of Internet traffic with a full BGP table. > > When I go to the page linked below, I didn't see a mailing list, forum or very much documentation for it. Is there another site with this info? I'd love to test a few builds out but I never used Vyatta before. > > >> On 12/23/2013 10:18 AM, Ray Soucy wrote: >> Many here might be interested, >> >> In response to Brocade not giving the community edition of Vyatta much >> attention recently, some of the more active community members have created >> a fork of the GPL code used in Vyatta. >> >> It's called VyOS, and yesterday they released 1.0. >> >> http://vyos.net/ >> >> I've been playing with the development builds and it seems to be every bit >> as stable as the Vyatta releases. >> >> Will be interesting to see how the project unfolds :-) > > -- > Vlade Ristevski > Network Manager > IT Services > Ramapo College > (201)-684-6854 > From rps at maine.edu Tue Jan 7 14:43:22 2014 From: rps at maine.edu (Ray Soucy) Date: Tue, 7 Jan 2014 09:43:22 -0500 Subject: Vyatta to VyOS In-Reply-To: <52CC0E3B.1090707@ramapo.edu> References: <52CC0E3B.1090707@ramapo.edu> Message-ID: Unfortunately, vyos.net is the only website for VyOS, Brocade still has a commercial release of Vyatta "vRouter" that has all the Vyatta documentation etc. If you're nervous about the lack of resources from the community project you might opt to go with the paid version from Brocade. The VyOS project is still pretty new, so better documentation and forums etc will come in time I suspect. I'm not sure if Brocade has upped the pricing, but here is pricing info from over the summer. They had 1, 3, and 5 year commitments and different pricing for virtual vs bare metal and 24-7 vs. business hour support. MSRP pricing for Vyatta back in May 2013 For 24-7 Support: Bare Metal $2,600 (1 yr) $5,000 (3 yr) Virtual $2,000 (1 yr) $3,000 (3 yr) For Business Hours support: Bare Metal $2,000 (1 yr) $3,500 (3 yr) Virtual $1,800 (1 yr) $2,700 (3 yr) On Tue, Jan 7, 2014 at 9:24 AM, Vlade Ristevski wrote: > This project looks interesting. Our 7206 VXR is at ends final days and > replacing it with and ASR series is very expensive considering we're only > pushing 600megs of Internet traffic with a full BGP table. > > When I go to the page linked below, I didn't see a mailing list, forum or > very much documentation for it. Is there another site with this info? I'd > love to test a few builds out but I never used Vyatta before. > > > > On 12/23/2013 10:18 AM, Ray Soucy wrote: > >> Many here might be interested, >> >> In response to Brocade not giving the community edition of Vyatta much >> attention recently, some of the more active community members have created >> a fork of the GPL code used in Vyatta. >> >> It's called VyOS, and yesterday they released 1.0. >> >> http://vyos.net/ >> >> I've been playing with the development builds and it seems to be every bit >> as stable as the Vyatta releases. >> >> Will be interesting to see how the project unfolds :-) >> >> > -- > Vlade Ristevski > Network Manager > IT Services > Ramapo College > (201)-684-6854 > > > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From rps at maine.edu Tue Jan 7 14:58:55 2014 From: rps at maine.edu (Ray Soucy) Date: Tue, 7 Jan 2014 09:58:55 -0500 Subject: Open source hardware In-Reply-To: <52CC07DC.4080903@ramapo.edu> References: <52CC07DC.4080903@ramapo.edu> Message-ID: http://approvedoptics.com/ is a good starting point if you want correct vendor codes On Tue, Jan 7, 2014 at 8:57 AM, Vlade Ristevski wrote: > Sorry to get off topic, but is there a company that you can recommend? The > price of the Cisco single mode GLC-LH-SMD= is killing me. I see a bunch of > third party ones on Amazon and CDW but I'd to love to get my hands one > that has the correct vendor code without going and trying them all. > > > On 1/3/2014 7:48 AM, Ray Soucy wrote: > >> You actually buy brand-name SFP's? That's like buying the gold-plated HDMI >> Monster Cable at Best Buy at markup ... >> >> I just find the the companies that the vendors contract to make their OEM >> SFP's and buy direct. Same SFP from the same factory except one has a >> Cisco sticker. ;-) >> >> You can even get them with the correct vendor code, been doing this for >> years and there is no difference in failure rate or quality and we go >> through hundreds of SFPs. >> >> >> >> >> Vlad > Network Manager > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From BECHA at ripe.net Tue Jan 7 15:12:13 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 07 Jan 2014 16:12:13 +0100 Subject: Query: fate of ipdeny.com In-Reply-To: <20140101214434.GB11592@gsp.org> References: <20140101214434.GB11592@gsp.org> Message-ID: <52CC194D.1000102@ripe.net> Hi, On 01-jan.-14 22:44, Rich Kulawiec wrote: > ipdeny.com provided a highly useful service: IP address allocations > on a per-country basis. RIPEstat also provides IP per country information: - Data API: https://stat.ripe.net/data/country-resource-list/data.json?resource=us (faster) - web widget, that you can embed in your own site: https://stat.ripe.net/widget/country-resource-list#w.resource=US (heavy on the browser) General web interface & additional info: https://stat.ripe.net Regards, Vesna From aledm at qix.co.uk Tue Jan 7 15:12:38 2014 From: aledm at qix.co.uk (Aled Morris) Date: Tue, 7 Jan 2014 15:12:38 +0000 Subject: Open source hardware In-Reply-To: <52CC07DC.4080903@ramapo.edu> References: <52CC07DC.4080903@ramapo.edu> Message-ID: On 7 January 2014 13:57, Vlade Ristevski wrote: > Sorry to get off topic, but is there a company that you can recommend? The > price of the Cisco single mode GLC-LH-SMD= is killing me. I see a bunch of > third party ones on Amazon and CDW but I'd to love to get my hands one > that has the correct vendor code without going and trying them all. In Europe, http://www.flexoptix.net are recommended. They also sell blank modules and give you a programmer too, so you can stock fewer spares and program them for whatever vendor you need in an outage/rapid deployment situation. I'm sure they'd ship to the US. Aled From info at sox.rs Tue Jan 7 17:59:03 2014 From: info at sox.rs (Zoran Perovic) Date: Tue, 7 Jan 2014 18:59:03 +0100 Subject: 10gbps peering subscriber switch recommendation Message-ID: We at SOX (Serbian Open eXchange www.sox.rs) use a combination of Extreme Networks Summit X650 (24x10G), and CISCO 4948E-E (4x10G+48xGEth), and recently added Vyatta with 2xIntel 82599ES dual 10G NIC, built on HPDL180G6 with 2xE5620 Xeon, and for route servers we use 2 additional HP servers running Quagga. Both Extreme, CISCO, and Vyatta could speak BGP, and do the routing, but we prefer CISCO to do the routing, as well as aggregation of GEth customers, VLAN translation etc. Vyatta works like a charm, but in very limited rule, routing what CISCO could not handle due to limitation in number of prefixes. Routing in Extreme is very expensive due to high price of Core license which is required for routing features. Best Zoran Date: Mon, 06 Jan 2014 11:53:14 -1000 From: Randy Bush To: Nitzan Tzelniker Cc: North American Network Operators' Group Subject: Re: 10gbps peering subscriber switch recommendation Message-ID: > Content-Type: text/plain; charset="us-ascii" > A little bit overkill in term of number of ports but you can consider > the new Trident 2 switches Juniper EX-5100, Cisco Nexus 3100 ..... > They have unified TCAM that can store 128K v4 routes the nice thing about buying bgp devices that can not hold a full table is that you can expense them in the year of purchase as opposed to amortizing them over 5 years or so. randy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 527 bytes Desc: not available URL: ------------------------------ From henson at acm.org Wed Jan 8 02:56:55 2014 From: henson at acm.org (Paul B. Henson) Date: Tue, 7 Jan 2014 18:56:55 -0800 Subject: Verizon FIOS IPv6? Message-ID: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> So I was curious, has anyone managed to penetrate the black hole that appears to be surrounding any actual details on Verizon FIOS IPv6 deployment? Their last official announcement indicated they would start deploying it in 2012, and clearly that didn't happen. I've been asking on and off for a couple of years, and never been able to get any actual answer as to when it might be available or why it is being so delayed. Comcast has www.comcast6.net, which evidently tells you when you're going to get it, if you don't *already* have it. From what I can tell, most large providers, if not already providing it, at least have some reasonable timeline as to their progress... From dhubbard at dino.hostasaurus.com Wed Jan 8 03:06:48 2014 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 7 Jan 2014 22:06:48 -0500 Subject: Verizon FIOS IPv6? References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> Message-ID: We have fios for some office locations and can't get jack out of our sales rep; just the same well it's being tested bs. It's as if the only people at VZ that know IPv6 went to the wireless side, where I can do native dual stack all day long on my phone, tablet and hotspot, but the Fios folks have absolutely no clue. It's really quite annoying. Even a wait 24 months would be better than nothing at all. -----Original Message----- From: Paul B. Henson [mailto:henson at acm.org] Sent: Tuesday, January 07, 2014 9:57 PM To: nanog at nanog.org Subject: Verizon FIOS IPv6? So I was curious, has anyone managed to penetrate the black hole that appears to be surrounding any actual details on Verizon FIOS IPv6 deployment? Their last official announcement indicated they would start deploying it in 2012, and clearly that didn't happen. I've been asking on and off for a couple of years, and never been able to get any actual answer as to when it might be available or why it is being so delayed. Comcast has www.comcast6.net, which evidently tells you when you're going to get it, if you don't *already* have it. From what I can tell, most large providers, if not already providing it, at least have some reasonable timeline as to their progress... From morrowc.lists at gmail.com Wed Jan 8 03:13:38 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 7 Jan 2014 22:13:38 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> Message-ID: On Tue, Jan 7, 2014 at 10:06 PM, David Hubbard wrote: > We have fios for some office locations and can't get jack out of our > sales rep; just the same well it's being tested bs. It's as if the only ... snip... > Fios folks have absolutely no clue. It's really quite annoying. Even a > wait 24 months would be better than nothing at all. I think the word you are looking for here is 'shameful', not 'annoying'. From seitz at bsd-unix.net Wed Jan 8 03:17:04 2014 From: seitz at bsd-unix.net (Bryan Seitz) Date: Tue, 7 Jan 2014 22:17:04 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> Message-ID: <20140108031704.GA72951@bsd-unix.net> On Tue, Jan 07, 2014 at 10:13:38PM -0500, Christopher Morrow wrote: > On Tue, Jan 7, 2014 at 10:06 PM, David Hubbard > wrote: > > We have fios for some office locations and can't get jack out of our > > sales rep; just the same well it's being tested bs. It's as if the only > > ... snip... > > > Fios folks have absolutely no clue. It's really quite annoying. Even a > > wait 24 months would be better than nothing at all. > > I think the word you are looking for here is 'shameful', not 'annoying'. The only luck I've had with IPV6 on FIOS is via he.net :( You would think in 2014 they would have their act together, even Comcast has deployed it pretty widely. -- Bryan G. Seitz From asr at latency.net Wed Jan 8 03:56:15 2014 From: asr at latency.net (Adam Rothschild) Date: Tue, 7 Jan 2014 22:56:15 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> Message-ID: I've heard of folk in and around the NYC metro getting set up for v6 by escalating through their commercial account teams, or the field service managers who went out to their homes to supervise their early-adopter [X]GPON ONT installations. This isn't to say the process was particularly easy or fun for those involved, however there is a light at the end of the tunnel. It's not immediately clear the extent of configuration work needed behind the curtains -- whether routing and addressing needed to be set up in an ad hoc manner, or if there was merely a magic "allow v6 ethertype" checkbox in an OSS needing to be checked to make RAs start working, however I've heard various rumblings pointing at the latter. However you slice it, I agree their laid-back approach at implementation is shameful, and should be called out wherever possible. HTH, -a On Tue, Jan 7, 2014 at 10:13 PM, Christopher Morrow wrote: > On Tue, Jan 7, 2014 at 10:06 PM, David Hubbard > wrote: >> We have fios for some office locations and can't get jack out of our >> sales rep; just the same well it's being tested bs. It's as if the only > > ... snip... > >> Fios folks have absolutely no clue. It's really quite annoying. Even a >> wait 24 months would be better than nothing at all. > > I think the word you are looking for here is 'shameful', not 'annoying'. > From morrowc.lists at gmail.com Wed Jan 8 04:00:12 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 7 Jan 2014 23:00:12 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> Message-ID: On Tue, Jan 7, 2014 at 10:56 PM, Adam Rothschild wrote: > I've heard of folk in and around the NYC metro getting set up for v6 > by escalating through their commercial account teams, or the field 'commercial account teams' == business customers? > service managers who went out to their homes to supervise their > early-adopter [X]GPON ONT installations. This isn't to say the wow, sounds super scalable. > process was particularly easy or fun for those involved, however there > is a light at the end of the tunnel. ha! double joke! > It's not immediately clear the extent of configuration work needed > behind the curtains -- whether routing and addressing needed to be set > up in an ad hoc manner, or if there was merely a magic "allow v6 > ethertype" checkbox in an OSS needing to be checked to make RAs start if it's just some clicky thing in the OSS I'm betting 2yrs til the IT department gets that automated :( > working, however I've heard various rumblings pointing at the latter. > However you slice it, I agree their laid-back approach at 'laid-back'... you sir, have a way with words. > implementation is shameful, and should be called out wherever > possible. yes :( it's nice that the Networx contract didn't require any ipv6 readiness... > HTH, > -a > > On Tue, Jan 7, 2014 at 10:13 PM, Christopher Morrow > wrote: >> On Tue, Jan 7, 2014 at 10:06 PM, David Hubbard >> wrote: >>> We have fios for some office locations and can't get jack out of our >>> sales rep; just the same well it's being tested bs. It's as if the only >> >> ... snip... >> >>> Fios folks have absolutely no clue. It's really quite annoying. Even a >>> wait 24 months would be better than nothing at all. >> >> I think the word you are looking for here is 'shameful', not 'annoying'. >> From asr at latency.net Wed Jan 8 04:10:05 2014 From: asr at latency.net (Adam Rothschild) Date: Tue, 7 Jan 2014 23:10:05 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> Message-ID: On Tue, Jan 7, 2014 at 11:00 PM, Christopher Morrow wrote: >> I've heard of folk in and around the NYC metro getting set up for v6 >> by escalating through their commercial account teams, or the field > > 'commercial account teams' == business customers? Sorry, yes, that is correct: one way to get IPv6 FIOS at the home is to escalate through your (701/VZB) account team. I should probably add that there was a real router plugged into the ethernet port on the ONT, given a lack of support in the ActionTec code ... but what self-respecting network geek uses those in the first place? :-) YMMV, etc., -a From sfrost at snowman.net Wed Jan 8 04:28:51 2014 From: sfrost at snowman.net (Stephen Frost) Date: Tue, 7 Jan 2014 23:28:51 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> Message-ID: <20140108042850.GA2686@tamriel.snowman.net> * Christopher Morrow (morrowc.lists at gmail.com) wrote: > On Tue, Jan 7, 2014 at 10:56 PM, Adam Rothschild wrote: > > I've heard of folk in and around the NYC metro getting set up for v6 > > by escalating through their commercial account teams, or the field > > 'commercial account teams' == business customers? As a FIOS business customer, I can say that I've had no progress on that front, though I've bugged them about it often enough... Perhaps I shall try again though. I would truely love to hear from one of these folks in NYC who managed to get it... > > implementation is shameful, and should be called out wherever > > possible. > > yes :( it's nice that the Networx contract didn't require any ipv6 readiness... There's a US government mandate for government public websites to support IPv6 and quite a few of those do- in some cases through Networx. I don't recall agencies complaining about the inability to get IPv6 for public websites via Networx either. Additionally, most of the services under the Networx contract are more traditional telecom services which don't particularly care what you run over them. As for having Networx require IPv6 support for all services- some of us tried, and while a nice idea, I doubt it would have lasted terribly long post-award even if it had been included for the few IP-based services which were part of the original contract. Sadly, having been involved in government contracting, it's amazing what happens when the vendor says "we want to provide $awesome, but we need you to waive this *one* little thing" and there isn't a mandate (afair...) for agencies to run IPv6 internally (tho they're supposed to be buying devices which *support* it). I will say that the more the agencies complain to GSA the highest the chance of something being done about it. Thanks, Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From streiner at cluebyfour.org Wed Jan 8 02:02:10 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 7 Jan 2014 21:02:10 -0500 (EST) Subject: Verizon FIOS IPv6? In-Reply-To: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> Message-ID: On Tue, 7 Jan 2014, Paul B. Henson wrote: > So I was curious, has anyone managed to penetrate the black hole that > appears to be surrounding any actual details on Verizon FIOS IPv6 > deployment? If you find the answer, you win the prize. I've tried shaking numerous trees (front-line customer service, my VZB sales person for $dayjob, other people I know who work at Verizon, etc...) to get an answer on this and each time I got different responses. I heard everything from trials being done somewhere in Florida (about a year ago, but Florida does me no good), to the rollout was on hold because the set-top boxes didn't work with it (wasn't about to explain dual-stack to them), to "Verizon has plenty of version 4 addresses, so there's no rush to deploy IPv6". More than one response included the caveat that "we haven't been trained on any IPv6 stuff yet", so I guess any sort of large-scale rollout is not in the immediate future. I don't fault the front-line customer service folks for this. If they don't know, they don't know. What I do find fault with is that the people the front-line reps can escalate to either don't know, won't tell, or won't ask their escalation points. Attempts to speak directly to an escalation point were met with "well, I can put a note in your account that you asked about it...". It's 2014. Comcast is kicking Verizon's butt at v6 deployment (I've told VZ reps that several times as well...). There really is no excuse for total silence from Verizon on this. I have a tunnel through HE and it works very well, but it would be great to have native v6 at home. jms From andrew.fried at gmail.com Wed Jan 8 06:21:08 2014 From: andrew.fried at gmail.com (Andrew Fried) Date: Wed, 08 Jan 2014 01:21:08 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: <20140108042850.GA2686@tamriel.snowman.net> References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> <20140108042850.GA2686@tamriel.snowman.net> Message-ID: <52CCEE54.9060503@gmail.com> You fared better than I did. I also am a Verizon Business customer, and when I called and inquired about ipv6 I was told that they didn't carry that channel. :) Andrew Fried andrew.fried at gmail.com On 1/7/14, 11:28 PM, Stephen Frost wrote: > * Christopher Morrow (morrowc.lists at gmail.com) wrote: >> On Tue, Jan 7, 2014 at 10:56 PM, Adam Rothschild >> wrote: >>> I've heard of folk in and around the NYC metro getting set up >>> for v6 by escalating through their commercial account teams, or >>> the field >> >> 'commercial account teams' == business customers? > > As a FIOS business customer, I can say that I've had no progress on > that front, though I've bugged them about it often enough... > Perhaps I shall try again though. I would truely love to hear from > one of these folks in NYC who managed to get it... > >>> implementation is shameful, and should be called out wherever >>> possible. >> >> yes :( it's nice that the Networx contract didn't require any >> ipv6 readiness... > > There's a US government mandate for government public websites to > support IPv6 and quite a few of those do- in some cases through > Networx. I don't recall agencies complaining about the inability to > get IPv6 for public websites via Networx either. Additionally, > most of the services under the Networx contract are more > traditional telecom services which don't particularly care what you > run over them. > > As for having Networx require IPv6 support for all services- some > of us tried, and while a nice idea, I doubt it would have lasted > terribly long post-award even if it had been included for the few > IP-based services which were part of the original contract. Sadly, > having been involved in government contracting, it's amazing what > happens when the vendor says "we want to provide $awesome, but we > need you to waive this *one* little thing" and there isn't a > mandate (afair...) for agencies to run IPv6 internally (tho they're > supposed to be buying devices which *support* it). > > I will say that the more the agencies complain to GSA the highest > the chance of something being done about it. > > Thanks, > > Stephen > From mark.tinka at seacom.mu Wed Jan 8 12:34:58 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 8 Jan 2014 14:34:58 +0200 Subject: 10gbps peering subscriber switch recommendation In-Reply-To: <52CBDB51.70608@foobar.org> References: <201401062143.22474.mark.tinka@seacom.mu> <52CBDB51.70608@foobar.org> Message-ID: <201401081434.58923.mark.tinka@seacom.mu> On Tuesday, January 07, 2014 12:47:45 PM Nick Hilliard wrote: > it's the merchant silicon boxes which are driving high > density 10g prices down,... As they should, and good news for us all, but... > but most of these boxes tends > to come with small fibs and tiny buffers which limits > their deployment usefulness. Still, if they work for > your requirements, they are completely awesome. My thinking is that provided they don't limit themselves in the QoS side of things (particularly, how different services going into the CPE can be policed/SLA'd), then they'd make good FTTH access nodes that can compete with GPON. But yes, as an IP route, pretty useless. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Wed Jan 8 12:35:30 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 8 Jan 2014 14:35:30 +0200 Subject: 10gbps peering subscriber switch recommendation In-Reply-To: References: Message-ID: <201401081435.31027.mark.tinka@seacom.mu> On Monday, January 06, 2014 11:53:14 PM Randy Bush wrote: > the nice thing about buying bgp devices that can not hold > a full table is that you can expense them in the year of > purchase as opposed to amortizing them over 5 years or > so. If only the bean counter saw things our way :-). Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Wed Jan 8 12:38:11 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 8 Jan 2014 14:38:11 +0200 Subject: Open source hardware In-Reply-To: References: <52CC07DC.4080903@ramapo.edu> Message-ID: <201401081438.11690.mark.tinka@seacom.mu> On Tuesday, January 07, 2014 05:12:38 PM Aled Morris wrote: > In Europe, http://www.flexoptix.net are recommended. > > They also sell blank modules and give you a programmer > too, so you can stock fewer spares and program them for > whatever vendor you need in an outage/rapid deployment > situation. > > I'm sure they'd ship to the US. Yep, would recommend them. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From wesley.george at twcable.com Wed Jan 8 13:26:45 2014 From: wesley.george at twcable.com (George, Wes) Date: Wed, 8 Jan 2014 08:26:45 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> Message-ID: On 1/7/14, 11:10 PM, "Adam Rothschild" wrote: >I should probably add that there was a real router plugged into the >ethernet port on the ONT, given a lack of support in the ActionTec >code ... Interestingly, I have one of the later-generation ActionTecs, and VZ pushed a software update to it at some point and it sprouted IPv6 config. https://plus.google.com/u/0/+WesleyGeorge/posts/hZR5nRgKyQ4 And no, clicking ?enable? doesn?t do anything, least it didn?t last time I fiddled with it. They?ve at least updated this page from ?later in 2012? to ?starting in 2013? but clearly that?s still not very helpful. http://www.verizon.com/Support/Residential/Internet/HighSpeed/General+Suppo rt/Top+Questions/QuestionsOne/ATLAS8742.htm Wes George Anything below this line has been added by my company?s mail server, I have no control over it. ----------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From streiner at cluebyfour.org Wed Jan 8 10:29:06 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 8 Jan 2014 05:29:06 -0500 (EST) Subject: Verizon FIOS IPv6? In-Reply-To: References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> Message-ID: On Wed, 8 Jan 2014, George, Wes wrote: > Interestingly, I have one of the later-generation ActionTecs, and VZ > pushed a software update to it at some point and it sprouted IPv6 config. I noticed the same thing on my router several months ago, but when I called to see if I could get IPv6 turned on for my account, no go. jms From marine64 at gmail.com Wed Jan 8 14:34:54 2014 From: marine64 at gmail.com (Brian Henson) Date: Wed, 8 Jan 2014 09:34:54 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> Message-ID: The only major ISP that I seen so far that has rolled out is Comcast. Been probing the TW Cable people for months to see what their plans are for IPv6 in Ohio and all I have gotten is a million different stories. On Wed, Jan 8, 2014 at 5:29 AM, Justin M. Streiner wrote: > On Wed, 8 Jan 2014, George, Wes wrote: > > Interestingly, I have one of the later-generation ActionTecs, and VZ >> pushed a software update to it at some point and it sprouted IPv6 config. >> > > I noticed the same thing on my router several months ago, but when I > called to see if I could get IPv6 turned on for my account, no go. > > jms > > From herro91 at gmail.com Wed Jan 8 15:19:03 2014 From: herro91 at gmail.com (Herro91) Date: Wed, 8 Jan 2014 10:19:03 -0500 Subject: L2TPv3/MPLS (TP) Pseudowire to preserve Message-ID: Hi, We have a new requirement to load balance across a couple of point to point ethernet links. The previous solution was handled by a few TDM circuits and MLPPP so that traffic was load balanced and any fragmentation/reassembly was handled by ML/PPP. Load balancing per flow is not really an option because we have a single IPSec tunnel (ESP-mode) and there is Layer 4 information to make a better decision to balance the load. I have been considering the use of L2TPv3 or an MPLS Pseudowire as a potential solution as they seem to have mechanisms to ensure packets are not misordered. I would appreciate any feedback/suggestions that the community can offer. Best, -Doug From Lee at asgard.org Wed Jan 8 15:24:56 2014 From: Lee at asgard.org (Lee Howard) Date: Wed, 08 Jan 2014 10:24:56 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> Message-ID: On 1/8/14 9:34 AM, "Brian Henson" wrote: >The only major ISP that I seen so far that has rolled out is Comcast. Been >probing the TW Cable people for months to see what their plans are for >IPv6 >in Ohio and all I have gotten is a million different stories. TWC Ohio (residential service): Real Soon Now. For what it's worth, AT&T also has a significant rollout on U-Verse. http://www.worldipv6launch.org/measurements/ I've read in some forums that there are pockets of FiOS users with IPv6 running. I've seen LLA on ActionTec modems. Something tells me that they will sneak up on us with a sudden deployment. Lee > > >On Wed, Jan 8, 2014 at 5:29 AM, Justin M. Streiner >wrote: > >> On Wed, 8 Jan 2014, George, Wes wrote: >> >> Interestingly, I have one of the later-generation ActionTecs, and VZ >>> pushed a software update to it at some point and it sprouted IPv6 >>>config. >>> >> >> I noticed the same thing on my router several months ago, but when I >> called to see if I could get IPv6 turned on for my account, no go. >> >> jms >> >> > From mir at ripe.net Wed Jan 8 15:38:24 2014 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 8 Jan 2014 16:38:24 +0100 Subject: [service] RIPE NCC Technical Outage Message-ID: <7322E7A1-4B78-486D-9FAD-84E0CB1085AE@ripe.net> Dear colleagues, We are currently experiencing a technical outage. Our engineers are currently trying to resolve the issue. We will provide updates as the situation changes. Regards, Mirjam Kuehne RIPE NCC From morrowc.lists at gmail.com Wed Jan 8 15:42:53 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 8 Jan 2014 10:42:53 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> Message-ID: On Wed, Jan 8, 2014 at 10:24 AM, Lee Howard wrote: > I've read in some forums that there are pockets of FiOS users with IPv6 > running. I've seen LLA on ActionTec modems. Something tells me that they > will sneak up on us with a sudden deployment. would be grand if they'd let folk know it's coming :) # tcpdump -n -i em0 ip6 tcpdump: listening on em0, link-type EN10MB especially for business customers who don't have moca and don't use the actioncrap... From vristevs at ramapo.edu Wed Jan 8 17:26:10 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Wed, 08 Jan 2014 12:26:10 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> Message-ID: <52CD8A32.1060406@ramapo.edu> My actiontec router has had that IPv6 page for a while now. I'm 20 minutes outside NYC. However when I enable it, I still don't get a broadband IPv6 address in the System Monitoring tab. On 1/8/2014 8:26 AM, George, Wes wrote: > On 1/7/14, 11:10 PM, "Adam Rothschild" wrote: > >> I should probably add that there was a real router plugged into the >> ethernet port on the ONT, given a lack of support in the ActionTec >> code ... > Interestingly, I have one of the later-generation ActionTecs, and VZ > pushed a software update to it at some point and it sprouted IPv6 config. > > https://plus.google.com/u/0/+WesleyGeorge/posts/hZR5nRgKyQ4 > > And no, clicking ?enable? doesn?t do anything, least it didn?t last time I > fiddled with it. > > They?ve at least updated this page from ?later in 2012? to ?starting in > 2013? but clearly that?s still not very helpful. > http://www.verizon.com/Support/Residential/Internet/HighSpeed/General+Suppo > rt/Top+Questions/QuestionsOne/ATLAS8742.htm > > Wes George > > Anything below this line has been added by my company?s mail server, I > have no control over it. > ----------- > > > > > > > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > -- Vlade Ristevski Network Manager IT Services Ramapo College (201)-684-6854 From nick at flhsi.com Wed Jan 8 17:30:53 2014 From: nick at flhsi.com (Nick Olsen) Date: Wed, 8 Jan 2014 12:30:53 -0500 Subject: EIGRP support !Cisco Message-ID: <314081fe$4b51d1c$875b4a5$@flhsi.com> Looking for EIGRP support in a platform other than Cisco. Since it was opened up last year. We have a situation where we need to integrate into a network running EIGRP and would like to avoid cisco if at all possible. Any thoughts? Nick Olsen Network Operations (855) FLSPEED x106 From rdobbins at arbor.net Wed Jan 8 17:38:01 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 8 Jan 2014 17:38:01 +0000 Subject: EIGRP support !Cisco In-Reply-To: <314081fe$4b51d1c$875b4a5$@flhsi.com> References: <314081fe$4b51d1c$875b4a5$@flhsi.com> Message-ID: <6BCF4032-E216-427F-B591-2B2FEB41CA25@arbor.net> On Jan 9, 2014, at 12:30 AM, Nick Olsen wrote: > Any thoughts? ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From nick at foobar.org Wed Jan 8 17:50:31 2014 From: nick at foobar.org (Nick Hilliard) Date: Wed, 08 Jan 2014 17:50:31 +0000 Subject: EIGRP support !Cisco In-Reply-To: <314081fe$4b51d1c$875b4a5$@flhsi.com> References: <314081fe$4b51d1c$875b4a5$@flhsi.com> Message-ID: <52CD8FE7.40008@foobar.org> On 08/01/2014 17:30, Nick Olsen wrote: > Looking for EIGRP support in a platform other than Cisco. Since it was > opened up last year. We have a situation where we need to integrate into a > network running EIGRP and would like to avoid cisco if at all possible. Why not use isis or ospf? Both are fully vendor neutral, and they both support mpls networks properly. EIGRP has some interesting features, but the vendor tie-in cost is way too high to even consider using it. IGP migration is quite do-able, even for large networks, and all cisco devices which speak EIGRP will also speak at least ospf, if not isis. Nick From nick at flhsi.com Wed Jan 8 17:52:17 2014 From: nick at flhsi.com (Nick Olsen) Date: Wed, 8 Jan 2014 12:52:17 -0500 Subject: EIGRP support !Cisco Message-ID: <7e6435ef$3155a908$2d31daf4$@flhsi.com> Completely agree. But this is needed to integrate into an existing network. OSPF would've been my first choice. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Nick Hilliard" Sent: Wednesday, January 08, 2014 12:50 PM To: nick at flhsi.com, nanog at nanog.org Subject: Re: EIGRP support !Cisco On 08/01/2014 17:30, Nick Olsen wrote: > Looking for EIGRP support in a platform other than Cisco. Since it was > opened up last year. We have a situation where we need to integrate into a > network running EIGRP and would like to avoid cisco if at all possible. Why not use isis or ospf? Both are fully vendor neutral, and they both support mpls networks properly. EIGRP has some interesting features, but the vendor tie-in cost is way too high to even consider using it. IGP migration is quite do-able, even for large networks, and all cisco devices which speak EIGRP will also speak at least ospf, if not isis. Nick From rdobbins at arbor.net Wed Jan 8 17:53:51 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 8 Jan 2014 17:53:51 +0000 Subject: EIGRP support !Cisco In-Reply-To: <52CD8FE7.40008@foobar.org> References: <314081fe$4b51d1c$875b4a5$@flhsi.com> <52CD8FE7.40008@foobar.org> Message-ID: <4525DFFA-24AD-4DFB-AFBA-9A3F3976828F@arbor.net> On Jan 9, 2014, at 12:50 AM, Nick Hilliard wrote: > IGP migration is quite do-able, even for large networks, and all cisco +1 ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Wed Jan 8 18:02:25 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 8 Jan 2014 18:02:25 +0000 Subject: EIGRP support !Cisco In-Reply-To: <7e6435ef$3155a908$2d31daf4$@flhsi.com> References: <7e6435ef$3155a908$2d31daf4$@flhsi.com> Message-ID: <97084968-2457-4887-B2B8-CACB20778292@arbor.net> On Jan 9, 2014, at 12:52 AM, Nick Olsen wrote: > But this is needed to integrate into an existing network. Route redistribution? >cringe< or eBGP? ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From nick at foobar.org Wed Jan 8 18:03:41 2014 From: nick at foobar.org (Nick Hilliard) Date: Wed, 08 Jan 2014 18:03:41 +0000 Subject: EIGRP support !Cisco In-Reply-To: <7e6435ef$3155a908$2d31daf4$@flhsi.com> References: <7e6435ef$3155a908$2d31daf4$@flhsi.com> Message-ID: <52CD92FD.4030100@foobar.org> On 08/01/2014 17:52, Nick Olsen wrote: > Completely agree. But this is needed to integrate into an existing network. > OSPF would've been my first choice. you'll need to pay cisco tax then. Cisco opened up most of eigrp to the ietf as an informational rfc, but didn't release anything related to eigrp stub areas. This means that the ietf release is not that useful if a vendor wanted feature parity with cisco's implementation. So far I'm not aware of any vendors who have implemented it. Maybe some will do so in future. Nick From nick at flhsi.com Wed Jan 8 18:05:30 2014 From: nick at flhsi.com (Nick Olsen) Date: Wed, 8 Jan 2014 13:05:30 -0500 Subject: EIGRP support !Cisco Message-ID: <6434672$51e7277a$2af2e41c$@flhsi.com> This is what I figured from a quick googling. Just wanted to make sure I wasn't missing anything.. Thanks! Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Nick Hilliard" Sent: Wednesday, January 08, 2014 1:03 PM To: nick at flhsi.com, nanog at nanog.org Subject: Re: EIGRP support !Cisco On 08/01/2014 17:52, Nick Olsen wrote: > Completely agree. But this is needed to integrate into an existing network. > OSPF would've been my first choice. you'll need to pay cisco tax then. Cisco opened up most of eigrp to the ietf as an informational rfc, but didn't release anything related to eigrp stub areas. This means that the ietf release is not that useful if a vendor wanted feature parity with cisco's implementation. So far I'm not aware of any vendors who have implemented it. Maybe some will do so in future. Nick From morrowc.lists at gmail.com Wed Jan 8 18:14:12 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 8 Jan 2014 13:14:12 -0500 Subject: EIGRP support !Cisco In-Reply-To: <6434672$51e7277a$2af2e41c$@flhsi.com> References: <6434672$51e7277a$2af2e41c$@flhsi.com> Message-ID: On Wed, Jan 8, 2014 at 1:05 PM, Nick Olsen wrote: > This is what I figured from a quick googling. Just wanted to make sure I > wasn't missing anything.. > you could employ one of the several methods to migrate from 'less desirable igp' to 'more desirable igp' on all of the things in question... there's people that have done this before even :) > Thanks! > > Nick Olsen > Network Operations > (855) FLSPEED x106 > > ---------------------------------------- > From: "Nick Hilliard" > Sent: Wednesday, January 08, 2014 1:03 PM > To: nick at flhsi.com, nanog at nanog.org > Subject: Re: EIGRP support !Cisco > > On 08/01/2014 17:52, Nick Olsen wrote: >> Completely agree. But this is needed to integrate into an existing > network. >> OSPF would've been my first choice. > > you'll need to pay cisco tax then. Cisco opened up most of eigrp to the > ietf as an informational rfc, but didn't release anything related to eigrp > stub areas. This means that the ietf release is not that useful if a > vendor wanted feature parity with cisco's implementation. So far I'm not > aware of any vendors who have implemented it. Maybe some will do so in > future. > > Nick > > From joelja at bogus.com Wed Jan 8 18:16:49 2014 From: joelja at bogus.com (joel jaeggli) Date: Wed, 08 Jan 2014 10:16:49 -0800 Subject: EIGRP support !Cisco In-Reply-To: <97084968-2457-4887-B2B8-CACB20778292@arbor.net> References: <7e6435ef$3155a908$2d31daf4$@flhsi.com> <97084968-2457-4887-B2B8-CACB20778292@arbor.net> Message-ID: <52CD9611.90302@bogus.com> On 1/8/14, 10:02 AM, Dobbins, Roland wrote: > > On Jan 9, 2014, at 12:52 AM, Nick Olsen wrote: > >> But this is needed to integrate into an existing network. > > Route redistribution? I've done mixed eigrp ospf environments in places where I wasn't responsible for legacy decisions... it worked pretty much like you'd expect, which is fine more or less. but I also don't work there anymore so your mileage may vary... >> cringe< > > or eBGP? Is harder to screw up in my experience. > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From rps at maine.edu Wed Jan 8 18:25:51 2014 From: rps at maine.edu (Ray Soucy) Date: Wed, 8 Jan 2014 13:25:51 -0500 Subject: EIGRP support !Cisco In-Reply-To: <314081fe$4b51d1c$875b4a5$@flhsi.com> References: <314081fe$4b51d1c$875b4a5$@flhsi.com> Message-ID: Use a standard protocol and redistribute between the two. OSPF is likely the easiest way to go for this. I like EIGRP, but I don't think I like it enough to try a non-Cisco implementation of it. At least with OSPF you know that most of the bugs have been worked out (hopefully). On Wed, Jan 8, 2014 at 12:30 PM, Nick Olsen wrote: > Looking for EIGRP support in a platform other than Cisco. Since it was > opened up last year. We have a situation where we need to integrate into a > network running EIGRP and would like to avoid cisco if at all possible. > > Any thoughts? > > Nick Olsen > Network Operations > (855) FLSPEED x106 > > > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From rps at maine.edu Wed Jan 8 18:56:36 2014 From: rps at maine.edu (Ray Soucy) Date: Wed, 8 Jan 2014 13:56:36 -0500 Subject: Open source hardware In-Reply-To: References: <52CC07DC.4080903@ramapo.edu> Message-ID: Just to toss in a few more vendors so not to look biased: Champion One: http://www.championone.net/ Have used them with no complaints. And a new company I heard about off-list: Luma Optics: http://www.lumaoptics.net/ I haven't dealt with them before, but their solution seems to be pretty slick in that they give you the tools to recode optics yourself. When all is said and done, my experience with third-party optics has been that they're identical to brand-name optics except for the sticker. In fact, it's pretty clear most of the time that they're often made by the same place. I haven't counted them all up, but I believe we have over 1,000 third-party optics in use, so a fair enough sample size. Most of the optics that I've replaced in the last year have had a "Cisco" label on them. ;-) On Tue, Jan 7, 2014 at 9:58 AM, Ray Soucy wrote: > http://approvedoptics.com/ is a good starting point if you want correct > vendor codes > > > On Tue, Jan 7, 2014 at 8:57 AM, Vlade Ristevski wrote: > >> Sorry to get off topic, but is there a company that you can recommend? >> The price of the Cisco single mode GLC-LH-SMD= is killing me. I see a bunch >> of third party ones on Amazon and CDW but I'd to love to get my hands one >> that has the correct vendor code without going and trying them all. >> >> >> On 1/3/2014 7:48 AM, Ray Soucy wrote: >> >>> You actually buy brand-name SFP's? That's like buying the gold-plated >>> HDMI >>> Monster Cable at Best Buy at markup ... >>> >>> I just find the the companies that the vendors contract to make their OEM >>> SFP's and buy direct. Same SFP from the same factory except one has a >>> Cisco sticker. ;-) >>> >>> You can even get them with the correct vendor code, been doing this for >>> years and there is no difference in failure rate or quality and we go >>> through hundreds of SFPs. >>> >>> >>> >>> >>> Vlad >> Network Manager >> > > > > -- > Ray Patrick Soucy > Network Engineer > University of Maine System > > T: 207-561-3526 > F: 207-561-3531 > > MaineREN, Maine's Research and Education Network > www.maineren.net > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From excelsio at gmx.com Wed Jan 8 19:45:50 2014 From: excelsio at gmx.com (excelsio at gmx.com) Date: Wed, 08 Jan 2014 20:45:50 +0100 Subject: 10gbps peering subscriber switch recommendation In-Reply-To: References: Message-ID: <52CDAAEE.4060305@gmx.com> That?s actually a topic, I was thinking ago some time ago. Why not take a current TOR switch with 1. BGP support and 2. high buffer. Like mentioned above we have Trident 2 bases switches. HP (no recommendation) has its HP 5930 series but tells "Routing table size 16000 entries (IPv4), 8000 entries (IPv6)", but this one has 4GB RAM, so plenty of space for full tables. I haven?t tried it out myself, perhaps someone tried on any other device: What will happen, if I give the switch a full table? Is there a software limit by the vendor, which will simply cut everything above? Or would it simply work? Michael From saku at ytti.fi Wed Jan 8 19:50:52 2014 From: saku at ytti.fi (Saku Ytti) Date: Wed, 8 Jan 2014 21:50:52 +0200 Subject: Open source hardware In-Reply-To: References: <52CC07DC.4080903@ramapo.edu> Message-ID: <20140108195052.GA9200@pob.ytti.fi> On (2014-01-08 13:56 -0500), Ray Soucy wrote: > Just to toss in a few more vendors so not to look biased: Instead of suggesting names, I'm giving some suggestions want to ask for vendor when looking for new partner - DDM/DOM, should be included in each (<1USD price premium), min/max TX/RX in eeprom should match that of PDF specsheet - accountability - supplier knows what they've sold to you, and where they've sourced them, so if there is problem, they can easily state you which of your optics are affected - replacement - advance replacement for non-critical replacement - eeprommer - usable by field-tech without training. If they are 'x compatible' it only means that someone programmed the eeprom with 'x' data. That someone might as well be your field tech, as it reduces your spare cost and ensures you always have correct part. Verify software has codes for kit you need it for. - if you need part (like for example dwdm) when 1st party only support something like SR, make sure you get the eeprom saying something that still allows you to inventory it correctly for easing operations when it needs to be replaced - part numbers - product ordered with given partnumber should be same part, single source laser, microcontroller, casing etc. If some source/supplier is changed, part number is changed. (So you can rely on getting something you know to work, to avoid testing everything) - product change notification - if something is changed with 'compatible' part without part number change, you should be informed of what was changed and why - prices decrease rapidly, it's chore to keep renegotiating constantly, try to negotiate contract where your price changes in reflection to vendors supplies becoming cheaper And of course make sure they sell all the stuff you need, so you don't need to have many sources, fewer sources, larger volume, better prices and also less parts to track/test. Chances are if you're just using 1st party, there may be lot of interesting optics available which will allow you to engineer some problems lot cheaper than you've used to. > When all is said and done, my experience with third-party optics has been > that they're identical to brand-name optics except for the sticker. In > fact, it's pretty clear most of the time that they're often made by the > same place. -- ++ytti From mark.tinka at seacom.mu Wed Jan 8 20:15:37 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 8 Jan 2014 22:15:37 +0200 Subject: 10gbps peering subscriber switch recommendation In-Reply-To: <52CDAAEE.4060305@gmx.com> References: <52CDAAEE.4060305@gmx.com> Message-ID: <201401082215.41618.mark.tinka@seacom.mu> On Wednesday, January 08, 2014 09:45:50 PM excelsio at gmx.com wrote: > That?s actually a topic, I was thinking ago some time > ago. Why not take a current TOR switch with 1. BGP > support and 2. high buffer. Like mentioned above we have > Trident 2 bases switches. HP (no recommendation) has its > HP 5930 series but tells "Routing table size 16000 > entries (IPv4), 8000 entries (IPv6)", but this one has > 4GB RAM, so plenty of space for full tables. I haven?t > tried it out myself, perhaps someone tried on any other > device: What will happen, if I give the switch a full > table? Is there a software limit by the vendor, which > will simply cut everything above? Or would it simply > work? The 4GB RAM is control plane memory. The problem is FIB memory, since switches generally forward Layer 2 and Layer 3 traffic in hardware, and this relies on forwarding entries being recorded into the FIB. The 16,000 IPv4 entries or 8,000 IPv6 entries is because of limited FIB memory. It's, typically, a switch limitation. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From joelja at bogus.com Wed Jan 8 20:33:55 2014 From: joelja at bogus.com (joel jaeggli) Date: Wed, 08 Jan 2014 12:33:55 -0800 Subject: 10gbps peering subscriber switch recommendation In-Reply-To: <52CDAAEE.4060305@gmx.com> References: <52CDAAEE.4060305@gmx.com> Message-ID: <52CDB633.1090008@bogus.com> On 1/8/14, 11:45 AM, excelsio at gmx.com wrote: > That?s actually a topic, I was thinking ago some time ago. Why not take > a current TOR switch with 1. BGP support and 2. high buffer. Like > mentioned above we have Trident 2 bases switches. HP (no recommendation) > has its HP 5930 series but tells "Routing table size 16000 entries > (IPv4), 8000 entries (IPv6)", but this one has 4GB RAM, so plenty of > space for full tables. I haven?t tried it out myself, perhaps someone > tried on any other device: What will happen, if I give the switch a full > table? Is there a software limit by the vendor, which will simply cut > everything above? Or would it simply work? There are various reasons why one might take a full table on a switch with not not enough FIB, the important part of course being the part where you don't install them all. I have taken a full bgp feed on an broadcom based Arista. with respect to what happens if you don't filter them. Either you get continuous fib churn and you only get to forward to the routes you currently have installed at that time (this is if you're lucky) or it explodes and you get to keep the pieces. > Michael > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From henson at acm.org Thu Jan 9 00:09:41 2014 From: henson at acm.org (Paul B. Henson) Date: Wed, 8 Jan 2014 16:09:41 -0800 Subject: Verizon FIOS IPv6? In-Reply-To: References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> Message-ID: <023201cf0ccf$1a341c20$4e9c5460$@acm.org> > From: Justin M. Streiner [mailto:streiner at cluebyfour.org] > Sent: Tuesday, January 07, 2014 6:02 PM > > If you find the answer, you win the prize. Can the prize be the Verizon employees that should have been keeping us in the loop on this in a dunk tank ;)? > I've tried shaking numerous trees (front-line customer service, my VZB > sales person for $dayjob, other people I know who work at Verizon, etc...) > to get an answer on this and each time I got different responses. Same story, I've tried many different avenues over the past couple of years with no luck. You'd think somebody on the list would be friends with a Verizon employee in the know they could take out and get drunk and wheedle something out of :). Or have sufficient business with Verizon to have enough clout to demand an answer . From henson at acm.org Thu Jan 9 00:14:56 2014 From: henson at acm.org (Paul B. Henson) Date: Wed, 8 Jan 2014 16:14:56 -0800 Subject: Verizon FIOS IPv6? In-Reply-To: References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> Message-ID: <023401cf0ccf$d5ccdc10$81669430$@acm.org> > From: Adam Rothschild [mailto:asr at latency.net] > Sent: Tuesday, January 07, 2014 8:10 PM > > Sorry, yes, that is correct: one way to get IPv6 FIOS at the home is > to escalate through your (701/VZB) account team. Hmm, I actually have business FIOS at home (static IP highway robbery ), and have had no luck escalating requests for details on IPv6 through business support. Could you possibly provide more details on the process or appropriate contacts? > but what self-respecting network geek uses those in the first > place? :-) Damn straight. It's annoying they make us waste money on buying them in the first place 8-/. Although my brother-in-law did appreciate the donation of my actiontec paperweight to extend his consumer fios network to the other side of his house over coax and have better wireless coverage. Thanks. From iggdawg at gmail.com Wed Jan 8 13:30:56 2014 From: iggdawg at gmail.com (Ian Bowers) Date: Wed, 8 Jan 2014 08:30:56 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: <52CCEE54.9060503@gmail.com> References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> <20140108042850.GA2686@tamriel.snowman.net> <52CCEE54.9060503@gmail.com> Message-ID: I've been barking at them for a couple years now, I never get much. They're good about staffing their front line support with flowchart monkeys. My internet facing device is constantly listening for any sort of indication that native IPv6 is starting up, but never hears anything. So I rock HE like many of you. It works pretty well, and I'm, guessing I get a lot more address space via HE than VZ would give me. On Wed, Jan 8, 2014 at 1:21 AM, Andrew Fried wrote: > You fared better than I did. I also am a Verizon Business customer, > and when I called and inquired about ipv6 I was told that they didn't > carry that channel. :) > > > Andrew Fried > andrew.fried at gmail.com > > On 1/7/14, 11:28 PM, Stephen Frost wrote: > > * Christopher Morrow (morrowc.lists at gmail.com) wrote: > >> On Tue, Jan 7, 2014 at 10:56 PM, Adam Rothschild > >> wrote: > >>> I've heard of folk in and around the NYC metro getting set up > >>> for v6 by escalating through their commercial account teams, or > >>> the field > >> > >> 'commercial account teams' == business customers? > > > > As a FIOS business customer, I can say that I've had no progress on > > that front, though I've bugged them about it often enough... > > Perhaps I shall try again though. I would truely love to hear from > > one of these folks in NYC who managed to get it... > > > >>> implementation is shameful, and should be called out wherever > >>> possible. > >> > >> yes :( it's nice that the Networx contract didn't require any > >> ipv6 readiness... > > > > There's a US government mandate for government public websites to > > support IPv6 and quite a few of those do- in some cases through > > Networx. I don't recall agencies complaining about the inability to > > get IPv6 for public websites via Networx either. Additionally, > > most of the services under the Networx contract are more > > traditional telecom services which don't particularly care what you > > run over them. > > > > As for having Networx require IPv6 support for all services- some > > of us tried, and while a nice idea, I doubt it would have lasted > > terribly long post-award even if it had been included for the few > > IP-based services which were part of the original contract. Sadly, > > having been involved in government contracting, it's amazing what > > happens when the vendor says "we want to provide $awesome, but we > > need you to waive this *one* little thing" and there isn't a > > mandate (afair...) for agencies to run IPv6 internally (tho they're > > supposed to be buying devices which *support* it). > > > > I will say that the more the agencies complain to GSA the highest > > the chance of something being done about it. > > > > Thanks, > > > > Stephen > > > > From Zachary.Hanna at gmail.com Thu Jan 9 00:29:54 2014 From: Zachary.Hanna at gmail.com (Zach Hanna) Date: Wed, 8 Jan 2014 16:29:54 -0800 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: <52A57D55.9000202@inblock.ru> References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <529D9492.8020205@inblock.ru> <20131204001456.9ABEEB13118@rock.dv.isc.org> <529F7557.3020607@inblock.ru> <8C49C994-0B29-4436-ACD4-8FAC331681E0@delong.com> <52A57D55.9000202@inblock.ru> Message-ID: OK. So who other than Andrew was able to get this working (and keep it working) ? I'm about to place an order for slow-verse for my residence... -Z- On Mon, Dec 9, 2013 at 12:20 AM, Nikolay Shopik wrote: > On 04/12/13 23:48, Owen DeLong wrote: > > Please tell me what provider is selling 100Mbit for $20-30 in the > 408-532-xxxx > > area of San Jose, California. > > > > Currently, the only provider capable of delivering more than 768k wired > > here is charging me $100+/month for 30-50Mbps maximum. > > > > I could get 100Mbps from them, but they want $250+/month for that. > > > > If I can get 100Mbps for $20-30, I'd jump at it. > > I know this is nanog, but i was talking about Russia, sorry for > confusion. You can get 350Mbps for 70$ via GPON here. but plain ethernet > dominates mostly here > > > > > Not entirely sure what you are saying here. In this day and age, I don't > see > > any reason that wireless providers should get a free pass or be able to > sustain > > significantly worse policies than wireline providers. Wireless bandwidth > is > > rapidly approaching parity with wired bandwidth pricing at consumer > levels. > > Sure but most cases you hit tower limit or frequency to crowded, since > its shared medium and you can't do anything about that. In wired you can > just drop another cable to your new client. > > > > >> Some even come up with idea two separate /64 make things easier :-D, > >> instead just put at least round /60 > > > > Actually, providing a separate /64 for the provider link makes a lot of > sense. > > It really is best to pull that out of a separate provider aggregate > across all > > the subscribers in the same aggregation group than to carve individual > > link prefixes out of each subscribers internal-use prefix. > > > > For example, if you get a tunnel from HE, then, by default, you get a > /64 > > from our link block for the tunnel broker to which you connect and an > additional > > /64 for your internal use by default. If you click the "please give me a > /48" checkbox, > > then you'll also get an additional /48. > > I was talking about /64 + /64 to client LANs and not counting another > /64 for WAN interface. I find this hard to manage at least on Cisco, > actually didn't find way to separate them at all, unless its make them > static > > > > > We do this because it makes our provisioning easier and allows us to > support > > users that want prefixes as well as users whose equipment (or brains) > can't > > handle more than a single /64 for their LAN. > > > > There's really NOTHING to be gained from providing anything in between a > /64 > > and a /48, so we don't do it. > > > > Owen > > > > From streiner at cluebyfour.org Wed Jan 8 22:03:13 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 8 Jan 2014 17:03:13 -0500 (EST) Subject: Verizon FIOS IPv6? In-Reply-To: References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> <20140108042850.GA2686@tamriel.snowman.net> <52CCEE54.9060503@gmail.com> Message-ID: On Wed, 8 Jan 2014, Ian Bowers wrote: > So I rock HE like many of you. It works pretty well, and I'm, guessing > I get a lot more address space via HE than VZ would give me. I have a tunnel through HE and it is solid. Verizon states on their "What is IPv6?" page that they will provide a /56 to customers. At least they fixed the typo that up until recently said that a /56 was 56 LANs, so at least that's a step in the right direction. My guesses for the foot-dragging, re: v6 deployment on FiOS: 1. Can't get their set-top boxes working on it yet. One customer service rep told me this. I didn't feel up to starting the whole "what's wrong with dual-stack?" argument. 2. Still working out how to update back-end provisioning systems. 3. Dealing with different vintages of premise routers (older Actiontecs don't support it), ONTs, and possibly aggregation routers. 4. Still developing M&Ps and training materials for provisioners and front-line customer service reps. 5. They haven't hit a critical mass of non-static customers bitching about performance problems due to LSN. 6. Layer 8-10 issues. I do know Verizon is a very siloed organization. VZO doesn't communicate much with VZW or VZB, and vice versa, which is a shame. v6 on my VZW 4G LTE phone just plain works. jms > On Wed, Jan 8, 2014 at 1:21 AM, Andrew Fried wrote: > >> You fared better than I did. I also am a Verizon Business customer, >> and when I called and inquired about ipv6 I was told that they didn't >> carry that channel. :) >> >> >> Andrew Fried >> andrew.fried at gmail.com >> >> On 1/7/14, 11:28 PM, Stephen Frost wrote: >>> * Christopher Morrow (morrowc.lists at gmail.com) wrote: >>>> On Tue, Jan 7, 2014 at 10:56 PM, Adam Rothschild >>>> wrote: >>>>> I've heard of folk in and around the NYC metro getting set up >>>>> for v6 by escalating through their commercial account teams, or >>>>> the field >>>> >>>> 'commercial account teams' == business customers? >>> >>> As a FIOS business customer, I can say that I've had no progress on >>> that front, though I've bugged them about it often enough... >>> Perhaps I shall try again though. I would truely love to hear from >>> one of these folks in NYC who managed to get it... >>> >>>>> implementation is shameful, and should be called out wherever >>>>> possible. >>>> >>>> yes :( it's nice that the Networx contract didn't require any >>>> ipv6 readiness... >>> >>> There's a US government mandate for government public websites to >>> support IPv6 and quite a few of those do- in some cases through >>> Networx. I don't recall agencies complaining about the inability to >>> get IPv6 for public websites via Networx either. Additionally, >>> most of the services under the Networx contract are more >>> traditional telecom services which don't particularly care what you >>> run over them. >>> >>> As for having Networx require IPv6 support for all services- some >>> of us tried, and while a nice idea, I doubt it would have lasted >>> terribly long post-award even if it had been included for the few >>> IP-based services which were part of the original contract. Sadly, >>> having been involved in government contracting, it's amazing what >>> happens when the vendor says "we want to provide $awesome, but we >>> need you to waive this *one* little thing" and there isn't a >>> mandate (afair...) for agencies to run IPv6 internally (tho they're >>> supposed to be buying devices which *support* it). >>> >>> I will say that the more the agencies complain to GSA the highest >>> the chance of something being done about it. >>> >>> Thanks, >>> >>> Stephen >>> >> >> > From henson at acm.org Thu Jan 9 01:29:21 2014 From: henson at acm.org (Paul B. Henson) Date: Wed, 8 Jan 2014 17:29:21 -0800 Subject: Verizon FIOS IPv6? In-Reply-To: References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> <20140108042850.GA2686@tamriel.snowman.net> <52CCEE54.9060503@gmail.com> Message-ID: <024401cf0cda$3ac90490$b05b0db0$@acm.org> > From: Ian Bowers [mailto:iggdawg at gmail.com] > Sent: Wednesday, January 08, 2014 5:31 AM > > indication that native IPv6 is starting up, but never hears anything. So I > rock HE like many of you. It works pretty well, and I'm, guessing I get a > lot more address space via HE than VZ would give me. I don't remember where I saw it, I believe it was on an official Verizon page, but it said something about giving out /56's to their business static IP customers, guess they want to be sure not to run out ;). HE I believe gives out /64's? The cynic in me believes they are intentionally delaying it to prop up their ridiculously high margins on IPv4 static addresses. Right now I'm paying $20/month extra for an additional four for a total of five on my account. From dhubbard at dino.hostasaurus.com Thu Jan 9 02:27:50 2014 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 8 Jan 2014 21:27:50 -0500 Subject: Verizon FIOS IPv6? References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> <20140108042850.GA2686@tamriel.snowman.net> <52CCEE54.9060503@gmail.com> <024401cf0cda$3ac90490$b05b0db0$@acm.org> Message-ID: HE will give you five /64's and you can also get a /48 if you need more for one end point. The service works flawlessly; much more than can be said for VZW. I run it from DD-WRT-based router at home and have several office locations using it via Cisco gear. Would still greatly prefer native though to avoid the messier setup, throughput (although HE is very good on that front too), latency, etc. -----Original Message----- From: Paul B. Henson [mailto:henson at acm.org] Sent: Wednesday, January 08, 2014 8:29 PM To: 'Ian Bowers' Cc: nanog at nanog.org Subject: RE: Verizon FIOS IPv6? I don't remember where I saw it, I believe it was on an official Verizon page, but it said something about giving out /56's to their business static IP customers, guess they want to be sure not to run out ;). HE I believe gives out /64's? The cynic in me believes they are intentionally delaying it to prop up their ridiculously high margins on IPv4 static addresses. Right now I'm paying $20/month extra for an additional four for a total of five on my account. From owen at delong.com Thu Jan 9 02:42:00 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 8 Jan 2014 18:42:00 -0800 Subject: Verizon FIOS IPv6? In-Reply-To: References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> <20140108042850.GA2686@tamriel.snowman.net> <52CCEE54.9060503@gmail.com> <024401cf0cda$3ac90490$b05b0db0$@acm.org> Message-ID: <3BB4AE25-F9DE-4932-93C9-EC002A4B3F1A@delong.com> On Jan 8, 2014, at 18:27 , David Hubbard wrote: > HE will give you five /64's and you can also get a /48 if you need more > for one end point. The service works flawlessly; much more than can be > said for VZW. I run it from DD-WRT-based router at home and have > several office locations using it via Cisco gear. Would still greatly > prefer native though to avoid the messier setup, throughput (although HE > is very good on that front too), latency, etc. To clarify, you get 2 /64s per tunnel... One for the tunnel itself and one for your site. You can also get an additional /48 per tunnel just by requesting it. Owen > > -----Original Message----- > From: Paul B. Henson [mailto:henson at acm.org] > Sent: Wednesday, January 08, 2014 8:29 PM > To: 'Ian Bowers' > Cc: nanog at nanog.org > Subject: RE: Verizon FIOS IPv6? > > I don't remember where I saw it, I believe it was on an official Verizon > page, but it said something about giving out /56's to their business > static IP customers, guess they want to be sure not to run out ;). HE I > believe gives out /64's? > > The cynic in me believes they are intentionally delaying it to prop up > their ridiculously high margins on IPv4 static addresses. Right now I'm > paying $20/month extra for an additional four for a total of five on my > account. > > > > > From mark.tinka at seacom.mu Thu Jan 9 04:58:31 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 9 Jan 2014 06:58:31 +0200 Subject: 10gbps peering subscriber switch recommendation In-Reply-To: <52CDB633.1090008@bogus.com> References: <52CDAAEE.4060305@gmx.com> <52CDB633.1090008@bogus.com> Message-ID: <201401090658.31509.mark.tinka@seacom.mu> On Wednesday, January 08, 2014 10:33:55 PM joel jaeggli wrote: > There are various reasons why one might take a full table > on a switch with not not enough FIB, the important part > of course being the part where you don't install them > all. In Metro-E deployments, this is a good use-case when the box is providing both IP and Ethernet services to the same or different customers out of the same chassis. It avoids having to run 2x eBGP sessions for the IP services (the first being point-to-point eBGP between the switch and the customer to get their routes into the network, and the second being an eBGP Multi-Hop between the customer and a "bigger" box in your core to send them the full BGP table). If a switch allows you to keep the routes in control plane RAM without downloading them into the FIB, you can maintain a single point-to-point eBGP session to the customer, including sending them the full table, provided you have a default route in the switch's FIB to handle actual data plane traffic flow from the customer upstream. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From bosch at adacore.com Thu Jan 9 05:08:34 2014 From: bosch at adacore.com (Geert Bosch) Date: Thu, 9 Jan 2014 00:08:34 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> <20140108042850.GA2686@tamriel.snowman.net> <52CCEE54.9060503@gmail.com> Message-ID: <4B201062-4499-49DD-BA0B-86262D26B4F9@adacore.com> On Jan 8, 2014, at 17:03, Justin M. Streiner wrote: > I have a tunnel through HE and it is solid. I'm on Verizon FIOS (70/30 Mbit/s), and set up my ActionTec router to allow tunneling traffic through, but am using my Apple TimeCapsule base station (3 years old) for the actual IPv6 tunneling. I've been amazed how rock-solid the IPv6 has been. All traffic between my home and work workplace go over IPv6, and using X11 etc, I'm quite sensitive to latency or packet loss. To my surprise, generally the tunneled IPv6 performs (far) better than IPv4: --- XXXX.gnat.com ping6 statistics --- 20 packets transmitted, 20 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 15.204/16.911/18.721/0.941 ms This really is good latency, especially considering the tunnel. Note that my MacBook Pro is using a WiFi connection, adding a millisecond or two as well. --- XXXX ping statistics --- 20 packets transmitted, 20 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 26.280/28.259/31.289/1.254 ms This is fine, but not great. The Apple Base station does NAT-ing, but did the same for my previous DSL link to Bway, which had <16ms ping times, so I can rule out NAT-related delays. At this point in time I'm not holding my breath for VZ to do anything to accommodate IPv6 or provide good routing, and know that if, for my company or otherwise, I'll have an option to chose HE, I will. -Geert PS. Today I changed my FIOS autopay method with VZ (as somehow they ignored the info I gave at signup) and got notified it would take up to 60 days (!!!) for the changes to take effect. Clearly, VZ is (and always will be) a phone company. From bross at pobox.com Thu Jan 9 05:36:02 2014 From: bross at pobox.com (Brandon Ross) Date: Thu, 9 Jan 2014 00:36:02 -0500 (EST) Subject: Open source hardware In-Reply-To: <20140108195052.GA9200@pob.ytti.fi> References: <52CC07DC.4080903@ramapo.edu> <20140108195052.GA9200@pob.ytti.fi> Message-ID: On Wed, 8 Jan 2014, Saku Ytti wrote: > On (2014-01-08 13:56 -0500), Ray Soucy wrote: > >> Just to toss in a few more vendors so not to look biased: > > Instead of suggesting names, I'm giving some suggestions want to ask for > vendor when looking for new partner So, in other words, you should make higher demands of your 3rd party optics providers than any of the OEMs could meet? When was the last time your OEM lowered your pricing for you when their supplies got cheaper? And when was the last time they changed their part number when they changed the casing of an optic? -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross From andreas.larsen at ip-only.se Thu Jan 9 07:42:31 2014 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Thu, 9 Jan 2014 08:42:31 +0100 Subject: SV: 10gbps peering subscriber switch recommendation In-Reply-To: References: Message-ID: Xtreme x480 can do this and has upto 6 * 10G ports. It can actually hold a full bgp table also and is preatty cheap. // Andreas Med v?nlig h?lsning Andreas Larsen ? IP-Only Telecommunication AB| Postadress: 753 81 UPPSALA | Bes?ksadress: S:t Persgatan 6, Uppsala | Telefon: +46 (0)18 843 10 00 | Direkt: +46 (0)18 843 10 56 www.ip-only.se -----Ursprungligt meddelande----- Fr?n: randal k [mailto:nanog at data102.com] Skickat: den 6 januari 2014 18:57 Till: NANOG list ?mne: 10gbps peering subscriber switch recommendation Good morning, We're in the market to move our IX peering off of our core (too much BGP/CPU :-/ ) and onto a dedicated switch. Anybody have a recommendation on a switch that can do the following without costing a fortune? I have scoured Cisco, and bang for the buck is ... ASR9k (way over powered for handling zero-feature IX traffic), 3-8x 10gbps ports 64k routes minimum, preferably 128k Must be able to speak BGP Native/functional IPv6 would be sharp! Basic QoS to police our ports The prefix count seems to be the killer, as our exchange table is getting pretty big (42k+ currently). I'm really tempted to build a vyatta box or similar, but would rather do something off the shelf -- especially if it can be 1-2 gens old and cost effective. I'm certain that this same situation is scratching many other folks as exchanges become more important. Thanks for your input in advance -- stay warm! Randal From nanog at isp-services.nl Thu Jan 9 09:25:31 2014 From: nanog at isp-services.nl (ISP Services) Date: Thu, 09 Jan 2014 10:25:31 +0100 Subject: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds Message-ID: <52CE6B0B.5050306@isp-services.nl> Hi, I am wondering if anyone here has experiences with the Spamhaus DROP, EDROP and BGPCC BGP feeds, for null routing hijacked prefixes, and prefixes which contain (only) mallicious users. http://www.spamhaus.org/bgpf/ We currently already use a Team Cymru feed for null routing bogons. Would you reckon that the Spamhaus lists offer many valid additions to the Team Cymru feeds? Did you have any disputes about prefixes that are announced as malicious use by Spamhaus with customers or other ISP's? Any responses, on or off list are appreciated. Thanks, Dennis Hagens Network Engineer AS 24875 From mark.tinka at seacom.mu Thu Jan 9 10:32:36 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 9 Jan 2014 12:32:36 +0200 Subject: Verizon FIOS IPv6? In-Reply-To: References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> Message-ID: <201401091232.39409.mark.tinka@seacom.mu> On Thursday, January 09, 2014 12:03:13 AM Justin M. Streiner wrote: > My guesses for the foot-dragging, re: v6 deployment on > FiOS: 1. Can't get their set-top boxes working on it > yet. One customer service rep told me this. I didn't > feel up to starting the whole "what's wrong with > dual-stack?" argument. Well, typically, linear Tv services are ran in their own VLAN and on RFC 1918 space. So in essence, they can start deploying IPv6 for the Internet VLAN (I'm not claiming to know their network design, just speaking generally) while they figure out how to get their STB's supporting IPv6. The majority of STB's support neither IGMPv3 nor IPv6, for the same reason. The manufacturers don't see the point, and the operators who buy from them don't see the need to put them on the spot (which is all bad). I could see an issue where the STB also has some OTT content capability (like VoD or cloud-based DVR, e.t.c.), and if the servers pumping that content out are not part of the walled- garden, NAT44 would be needed to bring that content down to an STB that has an RFC 1918 address driving it. In such a case, supporting IPv6 on the STB sooner rather than later alleviates pressures associated with NAT44. So lack of IPv6 support in the STB is not a deal-breaking reason, IMHO, since users are generally using IPv6 on laptops, desktops, smart phones, tablets, gaming consoles, OTT services, Tv's, media streamers, e.t.c., which typically fall under the Internet VLAN, i.e., aren't in some walled- garden. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From saku at ytti.fi Thu Jan 9 12:45:02 2014 From: saku at ytti.fi (Saku Ytti) Date: Thu, 9 Jan 2014 14:45:02 +0200 Subject: Open source hardware In-Reply-To: References: <52CC07DC.4080903@ramapo.edu> <20140108195052.GA9200@pob.ytti.fi> Message-ID: <20140109124502.GA12807@pob.ytti.fi> On (2014-01-09 00:36 -0500), Brandon Ross wrote: > So, in other words, you should make higher demands of your 3rd party > optics providers than any of the OEMs could meet? When was the last > time your OEM lowered your pricing for you when their supplies got > cheaper? And when was the last time they changed their part number > when they changed the casing of an optic? We have some contracts were price decreases automatically each year for next 5-6 years. Cisco sometimes changes P#, sometimes not, change is documented and explained in either case, you can track these in Cisco PCN Tool. It's everything down to rack screws. Specialized shop, doing professionally just optics are able to do this for you, brokers buying where they can get cheapest, have no idea what they sell to you. -- ++ytti From sfrost at snowman.net Thu Jan 9 13:41:30 2014 From: sfrost at snowman.net (Stephen Frost) Date: Thu, 9 Jan 2014 08:41:30 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: <4B201062-4499-49DD-BA0B-86262D26B4F9@adacore.com> References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> <20140108042850.GA2686@tamriel.snowman.net> <52CCEE54.9060503@gmail.com> <4B201062-4499-49DD-BA0B-86262D26B4F9@adacore.com> Message-ID: <20140109134130.GL2686@tamriel.snowman.net> * Geert Bosch (bosch at adacore.com) wrote: > On Jan 8, 2014, at 17:03, Justin M. Streiner wrote: > > I have a tunnel through HE and it is solid. [...] > --- XXXX.gnat.com ping6 statistics --- > 20 packets transmitted, 20 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 15.204/16.911/18.721/0.941 ms > > This really is good latency, especially considering the tunnel. > Note that my MacBook Pro is using a WiFi connection, adding a > millisecond or two as well. > > --- XXXX ping statistics --- > 20 packets transmitted, 20 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 26.280/28.259/31.289/1.254 ms I'm really curious how *that* is working out. My IPv6 tunnel is only a ms or two slower than IPv4 (and it's all sub-15ms), but there is something very odd if the tunnel is *faster*. Have you tried working out where the difference is coming from (eg: mtr or similar)? > This is fine, but not great. The Apple Base station does NAT-ing, > but did the same for my previous DSL link to Bway, which had <16ms > ping times, so I can rule out NAT-related delays. At this point > in time I'm not holding my breath for VZ to do anything to accommodate > IPv6 or provide good routing, and know that if, for my company or > otherwise, I'll have an option to chose HE, I will. Spent another hour with the FIOS folks last night and, while the tech folks knew what IPv6 was, they weren't able to provide any info about timelines or, really, much of anything. > PS. Today I changed my FIOS autopay method with VZ (as somehow they > ignored the info I gave at signup) and got notified it would take > up to 60 days (!!!) for the changes to take effect. Clearly, VZ is > (and always will be) a phone company. Sadly, Verizon is *both* a phone company and an Internet company- it's just that FIOS is part of the phone company half. Verizon Enterprise has supported IPv6 for a number of years and we were able to turn it up at my last job w/o too much trouble, once I convinced the necessary folks that we should ask for it. Thanks, Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From bryan at serverstack.com Thu Jan 9 14:08:45 2014 From: bryan at serverstack.com (Bryan Socha) Date: Thu, 9 Jan 2014 09:08:45 -0500 Subject: Qwest Contact? Message-ID: Does anyone have a contact at qwest or can someone from qwest reach out to me? You are announcing an ipv4 block that is registered to us.. Thanks, Bryan Socha ServerStack From jeroen at massar.ch Thu Jan 9 17:28:11 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Thu, 09 Jan 2014 18:28:11 +0100 Subject: Deadline TOMORROW to Apply to Represent the "Technical Community" at the Brazil Meeting and in 1Net In-Reply-To: References: Message-ID: <52CEDC2B.6080302@massar.ch> For everybody who wants to dabble in politics that people on this list actually care about ;) Greets, Jeroen -------- Original Message -------- Subject: Deadline TOMORROW to Apply to Represent the "Technical Community" at the Brazil Meeting and in 1Net Date: Thu, 09 Jan 2014 16:04:01 -0000 From: CircleID: Dan York Deadline TOMORROW to Apply to Represent the "Technical Community" at the Brazil Meeting and in 1Net Are you interested in being a representative of the "technical community" to the "/Global Multistakeholder Meeting on the Future of Internet Governance/? happening in April 2014 in Brazil? Or would you like to represent the technical community on the "1net Steering Committee" that is guiding the future of the 1net initiative ? If so, *THE DEADLINE IS TOMORROW, Friday, January 10, 2014*, to submit your expression of interest in being considered for a role on those committees. More information about the process and how to apply can be found below. In the preparation for the Brazil meeting, the task of coordinating representatives of "the Internet technical community" was delegated to my employer, the Internet Society , and while I personally have had no involvement in this effort, my colleague Constance Bommelaer, Senior Director, Global Policy Partnerships, has been circulating this message below to relevant mailing lists and other forums. I'm posting it here as I think that readers in the CircleID community might also be excellent candidates to apply for these positions: * * * The Internet Society (ISOC) is coordinating the process leading to appointments to represent the Internet technical community in two of the "Brazil Planning Committees" and in the "1net Steering Committee". The "Brazil Planning Committees" will contribute to the preparation of a "/Global Multistakeholder Meeting on the Future of Internet Governance/? that will be held on 23 and 24 April 2014, in Sao Paolo, Brazil. The two major tasks of "1net Steering Committee" will be (1) to liaise with stakeholder communities and encourage participation and submission of productive ideas with respect to Internet governance issues; and (2) to steer, manage, and otherwise lead the activities of the 1net platform towards a productive understanding and possibly consensus with respect to these issues. Individuals interested in being suggested by the NomCom set up for this purpose are invited to read more about the process and the timeline here: http://www.internetsociety.org/sites/default/files/Call1netBR-ForPublication.pdf The deadline for submitting expressions of interest is *10 January 2014*. Any questions or requests for additional information can be sent to: information.itcg at gmail.com . Useful links: 1net: http://1net.org ISOC Internet governance activities: http://www.internetsociety.org/what-we-do/internet-issues/internet-governance * * * I do hope that many of you will consider applying so that the technical community can be well-represented at both the Brazil meeting and within the 1net Steering Committee! /Written by Dan York , Author and Speaker on Internet technologies/ *Follow CircleID on Twitter * *More under:* Internet Governance URL: http://www.circleid.com/posts/20140109_deadline_tomorrow_to_apply_to_represent_technical_community_1net/ From Valdis.Kletnieks at vt.edu Thu Jan 9 17:38:48 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 09 Jan 2014 12:38:48 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: Your message of "Thu, 09 Jan 2014 08:41:30 -0500." <20140109134130.GL2686@tamriel.snowman.net> References: <014d01cf0c1d$4c50c3a0$e4f24ae0$@acm.org> <20140108042850.GA2686@tamriel.snowman.net> <52CCEE54.9060503@gmail.com> <4B201062-4499-49DD-BA0B-86262D26B4F9@adacore.com> <20140109134130.GL2686@tamriel.snowman.net> Message-ID: <66025.1389289128@turing-police.cc.vt.edu> On Thu, 09 Jan 2014 08:41:30 -0500, Stephen Frost said: > I'm really curious how *that* is working out. My IPv6 tunnel is only a > ms or two slower than IPv4 (and it's all sub-15ms), but there is > something very odd if the tunnel is *faster*. Have you tried working > out where the difference is coming from (eg: mtr or similar)? May be different routing based on where the tunnel leads? I recently got Comcast residential native IPv6 working (sort of - bricked a Belkin reflashing dd-wrt, but plugging the laptop into the cablemodem directly does dhcpv6 just fine). IPv6 to work is about 30% faster than IPv4, because cogent routes v6 for us better: 4 pos-1-4-0-0-cr01.ashburn.va.ibone.comcast.net (2001:558:0:f7c5::1) [AS7922] 29.282 ms pos-1-2-0-0-cr01.ashburn.va.ibone.comcast.net (2001:558:0:f6cd::1) [AS7922] 28.307 ms pos-1-4-0-0-cr01.ashburn.va.ibone.comcast.net (2001:558:0:f7c5::1) [AS7922] 29.292 ms 5 * * be-12-pe04.ashburn.va.ibone.comcast.net (2001:558:0:f534::2) [AS7922] 26.520 ms 6 2001:559::16a (2001:559::16a) [AS7922] 61.890 ms 52.396 ms 2001:559::176 (2001:559::176) [AS7922] 60.563 ms 7 2001:550:2:2f::a (2001:550:2:2f::a) [AS174] 58.846 ms 54.715 ms 54.692 ms 8 isb-border.xe-5-0-0.155.cns.ipv6.vt.edu (2607:b400:f0:20::5) [AS1312] 46.999 ms 44.160 ms 43.343 ms .. 4 68.86.94.29 (68.86.94.29) [AS7922] 35.819 ms 68.86.91.149 (68.86.91.149) [AS7922] 34.560 ms * 5 * * * 6 te0-0-0-19.ccr21.atl02.atlas.cogentco.com (154.54.10.233) [AS174] 81.795 ms 77.678 ms 82.887 ms 7 be2053.mpd22.atl01.atlas.cogentco.com (154.54.3.145) [AS174] 83.760 ms be2051.ccr22.atl01.atlas.cogentco.com (154.54.0.161) [AS174] 88.056 ms 87.991 ms 8 be2169.ccr22.dca01.atlas.cogentco.com (154.54.31.98) [AS174] 89.785 ms 102.779 ms 106.434 ms 9 be2177.ccr41.iad02.atlas.cogentco.com (154.54.41.205) [AS174] 85.708 ms be2113.ccr41.iad02.atlas.cogentco.com (154.54.6.169) [AS174] 82.884 ms be2176.ccr41.iad02.atlas.cogentco.com (154.54.41.53) [AS174] 82.888 ms 10 38.127.193.146 (38.127.193.146) [AS174] 87.885 ms 91.767 ms 96.178 ms 11 isb-border.xe-5-0-0.155.cns.vt.edu (192.70.187.149) [AS1312] 98.993 ms 88.320 ms 89.401 ms Apparently, going Blacksburg-ashburn-blacksburg is a lot faster than blacksburg-ashburn-atlanta-DC-blacbksburg. Who'd thunk it? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From landonstewart at gmail.com Thu Jan 9 18:52:52 2014 From: landonstewart at gmail.com (Landon) Date: Thu, 9 Jan 2014 10:52:52 -0800 Subject: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds In-Reply-To: <52CE6B0B.5050306@isp-services.nl> References: <52CE6B0B.5050306@isp-services.nl> Message-ID: On 9 January 2014 01:25, ISP Services wrote: > Hi, > > I am wondering if anyone here has experiences with the Spamhaus DROP, > EDROP and BGPCC BGP feeds, for null routing hijacked prefixes, and prefixes > which contain (only) mallicious users. > > http://www.spamhaus.org/bgpf/ > > We currently already use a Team Cymru feed for null routing bogons. Would > you reckon that the Spamhaus lists offer many valid additions to the Team > Cymru feeds? Did you have any disputes about prefixes that are announced as > malicious use by Spamhaus with customers or other ISP's? > > Any responses, on or off list are appreciated. > At a previous employer we used both the Team Cymru feed and the Spamhaus DROP and EDROP lists to block badness and about twice a year at first we?d see our own customers listed on the Team Cymru lists then we?d see none in the year. I was at that place for over 10 years. The Team Cymru list was enabled 8 years ago now and Spamhaus DROP and DROP lists were enabled about 3-4 years ago. The Spamhaus DROP and EDROP lists never listed our own customers and just seemed to list serious badness with no false positive issues that I can recall. At first we used the /32?s on the DROP and EDROP lists only and then later we started allowing the larger prefixes into our routing without any disputes or false positives. -- Landon Stewart From sfrost at snowman.net Thu Jan 9 19:32:05 2014 From: sfrost at snowman.net (Stephen Frost) Date: Thu, 9 Jan 2014 14:32:05 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: <66025.1389289128@turing-police.cc.vt.edu> References: <20140108042850.GA2686@tamriel.snowman.net> <52CCEE54.9060503@gmail.com> <4B201062-4499-49DD-BA0B-86262D26B4F9@adacore.com> <20140109134130.GL2686@tamriel.snowman.net> <66025.1389289128@turing-police.cc.vt.edu> Message-ID: <20140109193205.GQ2686@tamriel.snowman.net> * Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) wrote: > On Thu, 09 Jan 2014 08:41:30 -0500, Stephen Frost said: > > I'm really curious how *that* is working out. My IPv6 tunnel is only a > > ms or two slower than IPv4 (and it's all sub-15ms), but there is > > something very odd if the tunnel is *faster*. Have you tried working > > out where the difference is coming from (eg: mtr or similar)? > > May be different routing based on where the tunnel leads? Sure, entirely possible, but I'd be investigating into why because clearly there's a better ipv4 route than that being used, if ipv6 tunneled over ipv4 is faster. A bit of difference is fine, but it sounded like more than 'a bit'. > I recently got Comcast residential native IPv6 working (sort of - bricked a > Belkin reflashing dd-wrt, but plugging the laptop into the cablemodem directly > does dhcpv6 just fine). IPv6 to work is about 30% faster than IPv4, because > cogent routes v6 for us better: Fun times. Neat to hear of folks getting native IPv6 tho. > 4 pos-1-4-0-0-cr01.ashburn.va.ibone.comcast.net (2001:558:0:f7c5::1) [AS7922] 29.282 ms pos-1-2-0-0-cr01.ashburn.va.ibone.comcast.net (2001:558:0:f6cd::1) [AS7922] 28.307 ms pos-1-4-0-0-cr01.ashburn.va.ibone.comcast.net (2001:558:0:f7c5::1) [AS7922] 29.292 ms > 5 * * be-12-pe04.ashburn.va.ibone.comcast.net (2001:558:0:f534::2) [AS7922] 26.520 ms > 6 2001:559::16a (2001:559::16a) [AS7922] 61.890 ms 52.396 ms 2001:559::176 (2001:559::176) [AS7922] 60.563 ms > 7 2001:550:2:2f::a (2001:550:2:2f::a) [AS174] 58.846 ms 54.715 ms 54.692 ms > 8 isb-border.xe-5-0-0.155.cns.ipv6.vt.edu (2607:b400:f0:20::5) [AS1312] 46.999 ms 44.160 ms 43.343 ms > .. > > 4 68.86.94.29 (68.86.94.29) [AS7922] 35.819 ms 68.86.91.149 (68.86.91.149) [AS7922] 34.560 ms * > 5 * * * > 6 te0-0-0-19.ccr21.atl02.atlas.cogentco.com (154.54.10.233) [AS174] 81.795 ms 77.678 ms 82.887 ms > 7 be2053.mpd22.atl01.atlas.cogentco.com (154.54.3.145) [AS174] 83.760 ms be2051.ccr22.atl01.atlas.cogentco.com (154.54.0.161) [AS174] 88.056 ms 87.991 ms > 8 be2169.ccr22.dca01.atlas.cogentco.com (154.54.31.98) [AS174] 89.785 ms 102.779 ms 106.434 ms > 9 be2177.ccr41.iad02.atlas.cogentco.com (154.54.41.205) [AS174] 85.708 ms be2113.ccr41.iad02.atlas.cogentco.com (154.54.6.169) [AS174] 82.884 ms be2176.ccr41.iad02.atlas.cogentco.com (154.54.41.53) [AS174] 82.888 ms > 10 38.127.193.146 (38.127.193.146) [AS174] 87.885 ms 91.767 ms 96.178 ms > 11 isb-border.xe-5-0-0.155.cns.vt.edu (192.70.187.149) [AS1312] 98.993 ms 88.320 ms 89.401 ms > > Apparently, going Blacksburg-ashburn-blacksburg is a lot faster than > blacksburg-ashburn-atlanta-DC-blacbksburg. Who'd thunk it? :) 68.86.94.29 appears to be Georgia, not Ashburn..?- so where is it going to Ashburn and, probably more importantly, why? That's more than a little bit out of your way to go from Blacksburg to Blacksburg... Does most of your IPv4 traffic flow through Georgia? Seems like that might be the real issue here, going Blacksburg-Atlanta-DC-Ashburn-Blacksburg Curiously, doing my own tests from here (not far outside Ashburn): IPv4 to VT: ~21ms IPv4 to Ashburn IPv6 gateway: ~7ms IPv6 to VT: ~18ms All going through DC to Ashburn, unsurprisingly. It's slightly faster, as it turns out, but I'm not going to quibble over 3ms. Have to admit, not sure I could stand 100ms latency between work & home. Thanks, Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From jra at baylink.com Thu Jan 9 19:38:05 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 9 Jan 2014 14:38:05 -0500 (EST) Subject: [VoiceOps] (cross post) VoIP heat charts... In-Reply-To: <20140109160922.GA18984@infiltrated.net> Message-ID: <24624102.3158.1389296285723.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "J. Oquendo" > Looking for something that I can plop in some CDRs and paint > a nice pretty heat chart picture of where calls are going. > Anyone ever undertaken a similar task, if so, would you have > a software you'd recommend. > > Looking to "heat chart" where fraudelent calls are going. So you want to be able to feed "NPANXX Count" to something that will map the call counts on a US map. You have anything that does NPANXX to H&V, or directly to Lat Lon, already? Cause that's the hard part. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Thu Jan 9 19:47:38 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 9 Jan 2014 14:47:38 -0500 (EST) Subject: [VoiceOps] (cross post) VoIP heat charts... In-Reply-To: <24624102.3158.1389296285723.JavaMail.root@benjamin.baylink.com> Message-ID: <31285088.3160.1389296858205.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jay Ashworth" > > From: "J. Oquendo" > > > Looking for something that I can plop in some CDRs and paint > > a nice pretty heat chart picture of where calls are going. > > Anyone ever undertaken a similar task, if so, would you have > > a software you'd recommend. > > > > Looking to "heat chart" where fraudelent calls are going. > > So you want to be able to feed "NPANXX Count" to something that will > map the call counts on a US map. > > You have anything that does NPANXX to H&V, or directly to Lat Lon, > already? > > Cause that's the hard part. Alas, openheatmap.org does not seem to have NPANXX as a location column that it can translate. I wonder if Paul Timmins could work something out with the gent. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mark at viviotech.net Thu Jan 9 19:57:51 2014 From: mark at viviotech.net (Mark Keymer) Date: Thu, 09 Jan 2014 11:57:51 -0800 Subject: [Off-Topic] Ubersmith Message-ID: <52CEFF3F.9010303@viviotech.net> Hi Everyone, I know this is a bit off topic. And I am completely open to someone giving me a link to a list that might be better to talk about Ubersmith. However I also know that Many of you might have some feedback about Ubersmith as well. ;) Basically, My company has been looking for some possible new software to run our company on vs custom build software along with several different software pages. We came across Ubersmith are and checking it out now. On the surface it looks like it could combine some of our current app into a nice single point application. But I would LOVE to get some feedback on what people think about it. And/or if there is something similar that I should be looking into. Looking for something Enterprise like. NOT WHMCS! Off-list replies are more then welcome. Thank you in advance. -- Mark Keymer CFO/COO Vivio Technologies From jra at baylink.com Thu Jan 9 20:26:44 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 9 Jan 2014 15:26:44 -0500 (EST) Subject: [Off-Topic] Ubersmith In-Reply-To: <52CEFF3F.9010303@viviotech.net> Message-ID: <14552511.3164.1389299204274.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mark Keymer" > I know this is a bit off topic. And I am completely open to someone > giving me a link to a list that might be better to talk about Ubersmith. > However I also know that Many of you might have some feedback about > Ubersmith as well. ;) I know that E-Solutions, at 400 N Tampa, was running Uber before they got bought out by Knology (now WOW); I don't know if they still are. They were pretty happy with it, I gather, though like everything it has some pinch points. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From trelane at trelane.net Thu Jan 9 20:30:52 2014 From: trelane at trelane.net (Andrew D Kirch) Date: Thu, 09 Jan 2014 15:30:52 -0500 Subject: AT&T UVERSE Native IPv6, a HOWTO In-Reply-To: References: <5290498A.6040405@trelane.net> <5648A8908CCB564EBF46E2BC904A75B19681060E62@EXVPMBX100-1.exc.icann.org> <20131128225638.74413AF290C@rock.dv.isc.org> <20131129010452.68AF0AF36E4@rock.dv.isc.org> <86haav72ds.fsf@valhalla.seastrom.com> <529D9492.8020205@inblock.ru> <20131204001456.9ABEEB13118@rock.dv.isc.org> <529F7557.3020607@inblock.ru> <8C49C994-0B29-4436-ACD4-8FAC331681E0@delong.com> <52A57D55.9000202@inblock.ru> Message-ID: <52CF06FC.3050004@trelane.net> Zach, I've had no issues here since launching ipv6 other than that the performance isn't amazing. Andrew On 1/8/2014 7:29 PM, Zach Hanna wrote: > OK. So who other than Andrew was able to get this working (and keep it > working) ? > I'm about to place an order for slow-verse for my residence... > > -Z- > > > On Mon, Dec 9, 2013 at 12:20 AM, Nikolay Shopik wrote: > >> On 04/12/13 23:48, Owen DeLong wrote: >>> Please tell me what provider is selling 100Mbit for $20-30 in the >> 408-532-xxxx >>> area of San Jose, California. >>> >>> Currently, the only provider capable of delivering more than 768k wired >>> here is charging me $100+/month for 30-50Mbps maximum. >>> >>> I could get 100Mbps from them, but they want $250+/month for that. >>> >>> If I can get 100Mbps for $20-30, I'd jump at it. >> I know this is nanog, but i was talking about Russia, sorry for >> confusion. You can get 350Mbps for 70$ via GPON here. but plain ethernet >> dominates mostly here >> >>> Not entirely sure what you are saying here. In this day and age, I don't >> see >>> any reason that wireless providers should get a free pass or be able to >> sustain >>> significantly worse policies than wireline providers. Wireless bandwidth >> is >>> rapidly approaching parity with wired bandwidth pricing at consumer >> levels. >> >> Sure but most cases you hit tower limit or frequency to crowded, since >> its shared medium and you can't do anything about that. In wired you can >> just drop another cable to your new client. >> >>>> Some even come up with idea two separate /64 make things easier :-D, >>>> instead just put at least round /60 >>> Actually, providing a separate /64 for the provider link makes a lot of >> sense. >>> It really is best to pull that out of a separate provider aggregate >> across all >>> the subscribers in the same aggregation group than to carve individual >>> link prefixes out of each subscribers internal-use prefix. >>> >>> For example, if you get a tunnel from HE, then, by default, you get a >> /64 >>> from our link block for the tunnel broker to which you connect and an >> additional >>> /64 for your internal use by default. If you click the "please give me a >> /48" checkbox, >>> then you'll also get an additional /48. >> I was talking about /64 + /64 to client LANs and not counting another >> /64 for WAN interface. I find this hard to manage at least on Cisco, >> actually didn't find way to separate them at all, unless its make them >> static >> >>> We do this because it makes our provisioning easier and allows us to >> support >>> users that want prefixes as well as users whose equipment (or brains) >> can't >>> handle more than a single /64 for their LAN. >>> >>> There's really NOTHING to be gained from providing anything in between a >> /64 >>> and a /48, so we don't do it. >>> >>> Owen >>> >> From richard.hesse at weebly.com Thu Jan 9 22:10:08 2014 From: richard.hesse at weebly.com (Richard Hesse) Date: Thu, 9 Jan 2014 22:10:08 +0000 Subject: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds In-Reply-To: <52CE6B0B.5050306@isp-services.nl> References: <52CE6B0B.5050306@isp-services.nl> Message-ID: We're also interested in using their BGP feeds, but their website ( spamhaustech.com) doesn't give much confidence about their technical prowess. Trying to get a simple quote for BGP feeds is...interesting. -richard On Thu, Jan 9, 2014 at 9:25 AM, ISP Services wrote: > Hi, > > I am wondering if anyone here has experiences with the Spamhaus DROP, > EDROP and BGPCC BGP feeds, for null routing hijacked prefixes, and prefixes > which contain (only) mallicious users. > > http://www.spamhaus.org/bgpf/ > > We currently already use a Team Cymru feed for null routing bogons. Would > you reckon that the Spamhaus lists offer many valid additions to the Team > Cymru feeds? Did you have any disputes about prefixes that are announced as > malicious use by Spamhaus with customers or other ISP's? > > Any responses, on or off list are appreciated. > > Thanks, > > Dennis Hagens > Network Engineer > AS 24875 > > > > From tshaw at oitc.com Thu Jan 9 22:36:46 2014 From: tshaw at oitc.com (TR Shaw) Date: Thu, 9 Jan 2014 17:36:46 -0500 Subject: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds In-Reply-To: References: <52CE6B0B.5050306@isp-services.nl> Message-ID: <7340D9F5-C40D-415E-9D6B-9DFEA0A0E47A@oitc.com> Richard I would be more than happy to get you intouch with someone who can help you Technically they are very good. Tom On Jan 9, 2014, at 5:10 PM, Richard Hesse wrote: > We're also interested in using their BGP feeds, but their website ( > spamhaustech.com) doesn't give much confidence about their technical > prowess. Trying to get a simple quote for BGP feeds is...interesting. > > -richard > > > On Thu, Jan 9, 2014 at 9:25 AM, ISP Services wrote: > >> Hi, >> >> I am wondering if anyone here has experiences with the Spamhaus DROP, >> EDROP and BGPCC BGP feeds, for null routing hijacked prefixes, and prefixes >> which contain (only) mallicious users. >> >> http://www.spamhaus.org/bgpf/ >> >> We currently already use a Team Cymru feed for null routing bogons. Would >> you reckon that the Spamhaus lists offer many valid additions to the Team >> Cymru feeds? Did you have any disputes about prefixes that are announced as >> malicious use by Spamhaus with customers or other ISP's? >> >> Any responses, on or off list are appreciated. >> >> Thanks, >> >> Dennis Hagens >> Network Engineer >> AS 24875 >> >> >> >> From bryan at serverstack.com Thu Jan 9 22:43:45 2014 From: bryan at serverstack.com (Bryan Socha) Date: Thu, 9 Jan 2014 17:43:45 -0500 Subject: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds In-Reply-To: <7340D9F5-C40D-415E-9D6B-9DFEA0A0E47A@oitc.com> References: <52CE6B0B.5050306@isp-services.nl> <7340D9F5-C40D-415E-9D6B-9DFEA0A0E47A@oitc.com> Message-ID: I would also like that contact, i've been trying to get the same quote for feed only for months. Thanks, Bryan From tshaw at oitc.com Thu Jan 9 22:48:53 2014 From: tshaw at oitc.com (TR Shaw) Date: Thu, 9 Jan 2014 17:48:53 -0500 Subject: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds In-Reply-To: References: <52CE6B0B.5050306@isp-services.nl> <7340D9F5-C40D-415E-9D6B-9DFEA0A0E47A@oitc.com> Message-ID: <299BE752-FAA8-43C2-BABE-03EB7AD579CC@oitc.com> Replied off list. On Jan 9, 2014, at 5:43 PM, Bryan Socha wrote: > I would also like that contact, i've been trying to get the same quote for feed only for months. > > Thanks, > Bryan > > From JMarcus at pulsepoint.com Thu Jan 9 21:04:29 2014 From: JMarcus at pulsepoint.com (James Marcus) Date: Thu, 9 Jan 2014 21:04:29 +0000 Subject: [Off-Topic] Ubersmith In-Reply-To: <14552511.3164.1389299204274.JavaMail.root@benjamin.baylink.com> References: <14552511.3164.1389299204274.JavaMail.root@benjamin.baylink.com> Message-ID: <493B2341-7509-4EFB-9811-CB4C75B6899E@pulsepoint.com> I used it, when I was hosting with Voxel and I thought it was pretty cool. I think Ubersmith was developed at Voxel and then spun off, is that correct? What do you want to do with it? James On Jan 9, 2014, at 3:26 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Mark Keymer" > >> I know this is a bit off topic. And I am completely open to someone >> giving me a link to a list that might be better to talk about Ubersmith. >> However I also know that Many of you might have some feedback about >> Ubersmith as well. ;) > > I know that E-Solutions, at 400 N Tampa, was running Uber before they > got bought out by Knology (now WOW); I don't know if they still are. > > They were pretty happy with it, I gather, though like everything it > has some pinch points. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 > From mark at viviotech.net Fri Jan 10 01:15:32 2014 From: mark at viviotech.net (Mark Keymer) Date: Thu, 09 Jan 2014 17:15:32 -0800 Subject: [Off-Topic] Ubersmith In-Reply-To: <493B2341-7509-4EFB-9811-CB4C75B6899E@pulsepoint.com> References: <14552511.3164.1389299204274.JavaMail.root@benjamin.baylink.com> <493B2341-7509-4EFB-9811-CB4C75B6899E@pulsepoint.com> Message-ID: <52CF49B4.3060103@viviotech.net> Hi James, Looking at the online billing / payment aspect, Along with some of its other feature. IP tracking Service tracking. Billing for cloudstack and integration with it along with Xenserver. The integrated ticketing system looks Cool too. Overall looking for a tool to manged customers and for customers to manage there servers / infrastructure along with billing of servers. Probably more as well but those are some highlights. Sincerely, Mark Keymer CFO/COO Vivio Technologies On 1/9/2014 1:04 PM, James Marcus wrote: > I used it, when I was hosting with Voxel and I thought it was pretty cool. I think Ubersmith was developed at Voxel and then spun off, is that correct? > What do you want to do with it? > James > On Jan 9, 2014, at 3:26 PM, Jay Ashworth wrote: > >> ----- Original Message ----- >>> From: "Mark Keymer" >>> I know this is a bit off topic. And I am completely open to someone >>> giving me a link to a list that might be better to talk about Ubersmith. >>> However I also know that Many of you might have some feedback about >>> Ubersmith as well. ;) >> I know that E-Solutions, at 400 N Tampa, was running Uber before they >> got bought out by Knology (now WOW); I don't know if they still are. >> >> They were pretty happy with it, I gather, though like everything it >> has some pinch points. >> >> Cheers, >> -- jra >> -- >> Jay R. Ashworth Baylink jra at baylink.com >> Designer The Things I Think RFC 2100 >> Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII >> St Petersburg FL USA #natog +1 727 647 1274 >> > From aaron at wholesaleinternet.net Fri Jan 10 01:20:22 2014 From: aaron at wholesaleinternet.net (Aaron) Date: Thu, 09 Jan 2014 19:20:22 -0600 Subject: [Off-Topic] Ubersmith In-Reply-To: <52CF49B4.3060103@viviotech.net> References: <14552511.3164.1389299204274.JavaMail.root@benjamin.baylink.com> <493B2341-7509-4EFB-9811-CB4C75B6899E@pulsepoint.com> <52CF49B4.3060103@viviotech.net> Message-ID: <52CF4AD6.6000602@wholesaleinternet.net> It depends on the size you plan on growing to. The software is good but their pricing doesn't scale well. We've been using it since 04 but are migrating away from it at this point. Aaron On 1/9/2014 7:15 PM, Mark Keymer wrote: > Hi James, > > Looking at the online billing / payment aspect, Along with some of its > other feature. IP tracking Service tracking. Billing for cloudstack > and integration with it along with Xenserver. The integrated > ticketing system looks Cool too. Overall looking for a tool to manged > customers and for customers to manage there servers / infrastructure > along with billing of servers. > > Probably more as well but those are some highlights. > > Sincerely, > > Mark Keymer > CFO/COO > Vivio Technologies > On 1/9/2014 1:04 PM, James Marcus wrote: > >> I used it, when I was hosting with Voxel and I thought it was pretty >> cool. I think Ubersmith was developed at Voxel and then spun off, is >> that correct? >> What do you want to do with it? >> James >> On Jan 9, 2014, at 3:26 PM, Jay Ashworth wrote: >> >>> ----- Original Message ----- >>>> From: "Mark Keymer" >>>> I know this is a bit off topic. And I am completely open to someone >>>> giving me a link to a list that might be better to talk about >>>> Ubersmith. >>>> However I also know that Many of you might have some feedback about >>>> Ubersmith as well. ;) >>> I know that E-Solutions, at 400 N Tampa, was running Uber before they >>> got bought out by Knology (now WOW); I don't know if they still are. >>> >>> They were pretty happy with it, I gather, though like everything it >>> has some pinch points. >>> >>> Cheers, >>> -- jra >>> -- >>> Jay R. Ashworth Baylink jra at baylink.com >>> Designer The Things I >>> Think RFC 2100 >>> Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII >>> St Petersburg FL USA #natog +1 727 647 1274 >>> >> > > From mjkelly at gmail.com Fri Jan 10 01:24:51 2014 From: mjkelly at gmail.com (matt kelly) Date: Thu, 9 Jan 2014 20:24:51 -0500 Subject: [Off-Topic] Ubersmith In-Reply-To: <52CF4AD6.6000602@wholesaleinternet.net> References: <14552511.3164.1389299204274.JavaMail.root@benjamin.baylink.com> <493B2341-7509-4EFB-9811-CB4C75B6899E@pulsepoint.com> <52CF49B4.3060103@viviotech.net> <52CF4AD6.6000602@wholesaleinternet.net> Message-ID: Aaron, Would you mind sharing what you are migrating to? Matt On Jan 9, 2014 8:23 PM, "Aaron" wrote: > It depends on the size you plan on growing to. The software is good but > their pricing doesn't scale well. > > We've been using it since 04 but are migrating away from it at this point. > > Aaron > > On 1/9/2014 7:15 PM, Mark Keymer wrote: > >> Hi James, >> >> Looking at the online billing / payment aspect, Along with some of its >> other feature. IP tracking Service tracking. Billing for cloudstack and >> integration with it along with Xenserver. The integrated ticketing system >> looks Cool too. Overall looking for a tool to manged customers and for >> customers to manage there servers / infrastructure along with billing of >> servers. >> >> Probably more as well but those are some highlights. >> >> Sincerely, >> >> Mark Keymer >> CFO/COO >> Vivio Technologies >> On 1/9/2014 1:04 PM, James Marcus wrote: >> >> I used it, when I was hosting with Voxel and I thought it was pretty >>> cool. I think Ubersmith was developed at Voxel and then spun off, is that >>> correct? >>> What do you want to do with it? >>> James >>> On Jan 9, 2014, at 3:26 PM, Jay Ashworth wrote: >>> >>> ----- Original Message ----- >>>> >>>>> From: "Mark Keymer" >>>>> I know this is a bit off topic. And I am completely open to someone >>>>> giving me a link to a list that might be better to talk about >>>>> Ubersmith. >>>>> However I also know that Many of you might have some feedback about >>>>> Ubersmith as well. ;) >>>>> >>>> I know that E-Solutions, at 400 N Tampa, was running Uber before they >>>> got bought out by Knology (now WOW); I don't know if they still are. >>>> >>>> They were pretty happy with it, I gather, though like everything it >>>> has some pinch points. >>>> >>>> Cheers, >>>> -- jra >>>> -- >>>> Jay R. Ashworth Baylink jra at baylink.com >>>> Designer The Things I Think >>>> RFC 2100 >>>> Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII >>>> St Petersburg FL USA #natog +1 727 647 1274 >>>> >>>> >>> >> >> > > From aaron at wholesaleinternet.net Fri Jan 10 01:30:04 2014 From: aaron at wholesaleinternet.net (Aaron) Date: Thu, 09 Jan 2014 19:30:04 -0600 Subject: [Off-Topic] Ubersmith In-Reply-To: References: <14552511.3164.1389299204274.JavaMail.root@benjamin.baylink.com> <493B2341-7509-4EFB-9811-CB4C75B6899E@pulsepoint.com> <52CF49B4.3060103@viviotech.net> <52CF4AD6.6000602@wholesaleinternet.net> Message-ID: <52CF4D1C.5080103@wholesaleinternet.net> We rolled our own. A friend is migrating to WHMCS from Ubersmith. Aaron On 1/9/2014 7:24 PM, matt kelly wrote: > > Aaron, > > Would you mind sharing what you are migrating to? > > Matt > > On Jan 9, 2014 8:23 PM, "Aaron" > wrote: > > It depends on the size you plan on growing to. The software is > good but their pricing doesn't scale well. > > We've been using it since 04 but are migrating away from it at > this point. > > Aaron > > On 1/9/2014 7:15 PM, Mark Keymer wrote: > > Hi James, > > Looking at the online billing / payment aspect, Along with > some of its other feature. IP tracking Service tracking. > Billing for cloudstack and integration with it along with > Xenserver. The integrated ticketing system looks Cool too. > Overall looking for a tool to manged customers and for > customers to manage there servers / infrastructure along with > billing of servers. > > Probably more as well but those are some highlights. > > Sincerely, > > Mark Keymer > CFO/COO > Vivio Technologies > On 1/9/2014 1:04 PM, James Marcus wrote: > > I used it, when I was hosting with Voxel and I thought it > was pretty cool. I think Ubersmith was developed at Voxel > and then spun off, is that correct? > What do you want to do with it? > James > On Jan 9, 2014, at 3:26 PM, Jay Ashworth > wrote: > > ----- Original Message ----- > > From: "Mark Keymer" > > I know this is a bit off topic. And I am > completely open to someone > giving me a link to a list that might be better to > talk about Ubersmith. > However I also know that Many of you might have > some feedback about > Ubersmith as well. ;) > > I know that E-Solutions, at 400 N Tampa, was running > Uber before they > got bought out by Knology (now WOW); I don't know if > they still are. > > They were pretty happy with it, I gather, though like > everything it > has some pinch points. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think > RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 > Land Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > > > > > From mysidia at gmail.com Fri Jan 10 02:08:19 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 9 Jan 2014 20:08:19 -0600 Subject: [Off-Topic] Ubersmith In-Reply-To: <52CF4D1C.5080103@wholesaleinternet.net> References: <14552511.3164.1389299204274.JavaMail.root@benjamin.baylink.com> <493B2341-7509-4EFB-9811-CB4C75B6899E@pulsepoint.com> <52CF49B4.3060103@viviotech.net> <52CF4AD6.6000602@wholesaleinternet.net> <52CF4D1C.5080103@wholesaleinternet.net> Message-ID: On Thu, Jan 9, 2014 at 7:30 PM, Aaron wrote: > We rolled our own. A friend is migrating to WHMCS from Ubersmith. > > Aaron I would be standoffish, due to Ubersmith alleged recent history of price increases. Admittedly... I am very skeptical about the concept of datacenter management or billing software providers charging a big monthly fee, plus extra per-client and extra per managed-device. That doesn't mean it's always a bad idea; it's just really annoying. If smart phones were sold like Enterprise software.... "Customer: How much for this smart phone?" "Sales clerk: How many people do you plan to call with it?" "Customer: Uh, 5 or 6 friends and family members." "Sales clerk: I see... well that will be $300 plus $25 per contact, so the total comes to $450. In 5 years the newer model will be $499 for you." "Customer: Wait... I also need to receive calls from 3 important business clients" "Sales clerk: In that case, the same smart phone costs $2500, plus an extra $100/month license fee for each business contact, and a 30% annual maintenance -- if you fail to renew before the end of the 12 months, it will deactivate and it will be full price to turn it back on." -- -JH From mjkelly at gmail.com Fri Jan 10 02:14:05 2014 From: mjkelly at gmail.com (matt kelly) Date: Thu, 9 Jan 2014 21:14:05 -0500 Subject: [Off-Topic] Ubersmith In-Reply-To: References: <14552511.3164.1389299204274.JavaMail.root@benjamin.baylink.com> <493B2341-7509-4EFB-9811-CB4C75B6899E@pulsepoint.com> <52CF49B4.3060103@viviotech.net> <52CF4AD6.6000602@wholesaleinternet.net> <52CF4D1C.5080103@wholesaleinternet.net> Message-ID: I'm also a bit leary of them now, considering they are owned by internap after the voxel acquisition. I like their software and used it for years. It just seems like they're trying to compete in the market of zuora and others when they are something completely different. I'm also surprised there have been no competitors to ubersmith in the data center space. Matt On Jan 9, 2014 9:08 PM, "Jimmy Hess" wrote: > On Thu, Jan 9, 2014 at 7:30 PM, Aaron wrote: > We rolled our own. A friend is migrating to WHMCS from Ubersmith. >> >> Aaron > > > I would be standoffish, due to Ubersmith alleged recent history of price > increases. Admittedly... I am very skeptical about the concept of > datacenter management or billing software providers charging a big > monthly fee, plus extra per-client and extra per managed-device. > > That doesn't mean it's always a bad idea; it's just really annoying. > > > If smart phones were sold like Enterprise software.... > > "Customer: How much for this smart phone?" > > "Sales clerk: How many people do you plan to call with it?" > > "Customer: Uh, 5 or 6 friends and family members." > > "Sales clerk: I see... well that will be $300 plus $25 per contact, so > the total comes to $450. In 5 years the newer model will be $499 for > you." > > "Customer: Wait... I also need to receive calls from 3 important business > clients" > > "Sales clerk: In that case, the same smart phone costs $2500, plus an > extra $100/month license fee for each business contact, and a 30% annual > maintenance -- if you fail to renew before the end of the 12 months, it > will deactivate and it will be full price to turn it back on." > > > -- > -JH > From bosch at adacore.com Fri Jan 10 05:17:53 2014 From: bosch at adacore.com (Geert Bosch) Date: Fri, 10 Jan 2014 00:17:53 -0500 Subject: Verizon FIOS IPv6? In-Reply-To: <20140109193205.GQ2686@tamriel.snowman.net> References: <20140108042850.GA2686@tamriel.snowman.net> <52CCEE54.9060503@gmail.com> <4B201062-4499-49DD-BA0B-86262D26B4F9@adacore.com> <20140109134130.GL2686@tamriel.snowman.net> <66025.1389289128@turing-police.cc.vt.edu> <20140109193205.GQ2686@tamriel.snowman.net> Message-ID: On Jan 9, 2014, at 14:32, Stephen Frost wrote: > Sure, entirely possible, but I'd be investigating into why because > clearly there's a better ipv4 route than that being used, if ipv6 > tunneled over ipv4 is faster. A bit of difference is fine, but it > sounded like more than 'a bit'. Of course it's a routing issue. At AdaCore (AS32019), we have very good connectivity with level3 (<2ms), but the Verizon/Level3 path seems variable and generally slow. Here are the relevant bits. Note that I've seen lots of different routings for IPv4 traffic, routing over Cogent, Alter.net, Above.net, but not so much when using the HE tunnel. Of course, I could just ascribe this to NSA traffic redirection/inspection, or some traffic engineering by a New Jersey governor, but I guess VZ might have their own reasons for subpar routing. It always seems as if VZ is avoiding L3. The Hurricane Electric tunnel server I'm using is 209.51.161.14. kwai:~%ping -i0.2 -c20 209.51.161.14 ... --- 209.51.161.14 ping statistics --- 20 packets transmitted, 20 received, 0% packet loss, time 3819ms rtt min/avg/max/mdev = 1.604/1.763/2.497/0.205 ms potomac:~%ping -i0.2 -c20 209.51.161.14 ... --- 209.51.161.14 ping statistics --- 20 packets transmitted, 20 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 6.832/8.040/9.152/0.720 ms The sum of these times is just 10ms. Now, look at the resulting time for my IPv4 tunnel endpoint: kwai:~%ping -i0.2 -c20 72.69.184.141 ... --- 72.69.184.141 ping statistics --- 20 packets transmitted, 20 received, 0% packet loss, time 3817ms rtt min/avg/max/mdev = 22.843/25.422/27.725/1.538 ms That's where the difference is. With trace routes: kwai:~%traceroute 209.51.161.14 traceroute to 209.51.161.14 (209.51.161.14), 30 hops max, 60 byte packets 1 jordan.gnat.com (205.232.38.200) 5.402 ms 5.483 ms 5.535 ms 2 towerstream-gw.gnat.com (69.38.252.177) 2.113 ms 2.119 ms 2.159 ms 3 g4-0.cr.nyc1.ny.towerstream.com (69.38.244.13) 2.253 ms 2.260 ms 2.296 ms 4 br.nyc0203.ny.towerstream.net (69.38.138.110) 3.181 ms 3.190 ms 3.209 ms 5 64.125.173.225 (64.125.173.225) 3.299 ms 3.308 ms 3.394 ms 6 xe-1-2-1.er2.lga5.us.above.net (64.125.31.166) 4.224 ms 2.113 ms 2.123 ms 7 core1.nyc4.he.net (198.32.118.57) 3.733 ms 10.968 ms 10.960 ms 8 tserv1.nyc4.he.net (209.51.161.14) 2.088 ms 1.694 ms 1.870 ms kwai:~%traceroute 72.69.184.141 traceroute to 72.69.184.141 (72.69.184.141), 30 hops max, 60 byte packets 1 jordan.gnat.com (205.232.38.200) 5.888 ms 6.295 ms 6.442 ms 2 towerstream-gw.gnat.com (69.38.252.177) 2.062 ms 2.066 ms 2.108 ms 3 g4-0.cr.nyc1.ny.towerstream.com (69.38.244.13) 2.201 ms 2.206 ms 2.319 ms 4 xe-4-0-1.edge4.NewYork1.Level3.net (4.28.130.57) 3.124 ms 3.129 ms 3.156 ms 5 vlan70.csw2.NewYork1.Level3.net (4.69.155.126) 3.248 ms vlan60.csw1.NewYork1.Level3.net (4.69.155.62) 3.299 ms vlan80.csw3.NewYork1.Level3.net (4.69.155.190) 3.304 ms 6 ae-81-81.ebr1.NewYork1.Level3.net (4.69.134.73) 4.702 ms ae-62-62.ebr2.NewYork1.Level3.net (4.69.148.33) 2.372 ms ae-81-81.ebr1.NewYork1.Level3.net (4.69.134.73) 2.392 ms 7 4.69.201.42 (4.69.201.42) 2.377 ms ae-45-45.ebr2.NewYork2.Level3.net (4.69.141.22) 2.366 ms ae-47-47.ebr2.NewYork2.Level3.net (4.69.201.34) 2.407 ms 8 ae-1-51.edge2.NewYork2.Level3.net (4.69.138.195) 2.369 ms 2.518 ms 2.529 ms 9 po6-20G.ar6.NYC1.gblx.net (208.51.134.113) 18.468 ms 18.474 ms 18.655 ms 10 0.ae11.BR3.NYC4.ALTER.NET (204.255.168.193) 20.372 ms 19.718 ms 17.999 ms 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * *C^Cpotomac:%traceroute 209.51.161.14 traceroute to 209.51.161.14 (209.51.161.14), 64 hops max, 52 byte packets 1 wireless_broadband_router (192.168.1.1) 1.238 ms 0.852 ms 0.805 ms 2 l100.nycmny-vfttp-102.verizon-gni.net (71.190.186.1) 5.275 ms 5.189 ms 5.732 ms 3 g1-15-4-1.nycmny-lcr-22.verizon-gni.net (130.81.218.160) 9.572 ms 7.315 ms 8.120 ms 4 so-3-1-0-0.ny5030-bb-rtr2.verizon-gni.net (130.81.199.12) 7.135 ms ae2-0.ny5030-bb-rtr1.verizon-gni.net (130.81.199.178) 7.228 ms so-5-0-0-0.ny5030-bb-rtr1.verizon-gni.net (130.81.22.18) 7.047 ms 5 0.xe-10-0-0.br3.nyc4.alter.net (152.63.24.109) 7.925 ms 0.xe-11-3-0.br2.nyc4.alter.net (152.63.23.137) 7.892 ms 0.xe-10-0-0.br3.nyc4.alter.net (152.63.24.109) 7.114 ms 6 204.255.168.190 (204.255.168.190) 7.497 ms 10.291 ms 8.601 ms 7 hurricane-electric-llc-new-york.tengigabitethernet1-3.ar5.nyc1.gblx.net (64.209.92.98) 8.228 ms 7.101 ms 17.883 ms 8 tserv1.nyc4.he.net (209.51.161.14) 8.962 ms 8.231 ms 6.681 ms potomac:%traceroute kwai.gnat.com traceroute to kwai.gnat.com (205.232.38.4), 64 hops max, 52 byte packets 1 wireless_broadband_router (192.168.1.1) 4.037 ms 2.140 ms 2.572 ms 2 l100.nycmny-vfttp-102.verizon-gni.net (71.190.186.1) 6.554 ms 7.270 ms 7.757 ms 3 g0-14-3-3.nycmny-lcr-22.verizon-gni.net (130.81.104.44) 11.689 ms 9.961 ms 9.519 ms 4 so-6-1-0-0.ny5030-bb-rtr2.verizon-gni.net (130.81.151.224) 6.582 ms ae0-0.ny5030-bb-rtr2.verizon-gni.net (130.81.209.126) 7.804 ms ae4-0.ny5030-bb-rtr1.verizon-gni.net (130.81.163.224) 7.244 ms 5 0.xe-10-1-0.br1.nyc1.alter.net (152.63.18.225) 8.677 ms 8.347 ms 8.810 ms 6 te-7-3-0.edge2.newyork2.level3.net (4.68.111.137) 27.316 ms ae11.edge2.newyork.level3.net (4.68.62.41) 29.472 ms 28.588 ms 7 vlan51.ebr1.newyork2.level3.net (4.69.138.222) 25.019 ms vlan52.ebr2.newyork2.level3.net (4.69.138.254) 23.100 ms vlan51.ebr1.newyork2.level3.net (4.69.138.222) 23.718 ms 8 ae-48-48.ebr2.newyork1.level3.net (4.69.201.49) 23.335 ms ae-46-46.ebr1.newyork1.level3.net (4.69.201.41) 24.846 ms 4.69.201.37 (4.69.201.37) 25.430 ms 9 ae-62-62.csw1.newyork1.level3.net (4.69.148.34) 24.207 ms ae-92-92.csw4.newyork1.level3.net (4.69.148.46) 24.709 ms ae-82-82.csw3.newyork1.level3.net (4.69.148.42) 27.682 ms 10 ae-2-70.edge4.newyork1.level3.net (4.69.155.84) 23.184 ms 22.921 ms ae-4-90.edge4.newyork1.level3.net (4.69.155.210) 25.784 ms 11 bandcon.edge4.newyork1.level3.net (4.28.130.58) 8.355 ms 8.672 ms 8.877 ms 12 e1-1.cr.nyc0007.c.ny.towerstream.net (69.38.231.173) 27.119 ms 25.984 ms 26.617 ms 13 jordan-towerstream.gnat.com (69.38.252.178) 28.139 ms 29.953 ms 29.601 ms 14 kwai.gnat.com (205.232.38.4) 28.848 ms 26.241 ms 28.212 ms From maillist at webjogger.net Fri Jan 10 14:11:22 2014 From: maillist at webjogger.net (Adam Greene) Date: Fri, 10 Jan 2014 09:11:22 -0500 Subject: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds In-Reply-To: <299BE752-FAA8-43C2-BABE-03EB7AD579CC@oitc.com> References: <52CE6B0B.5050306@isp-services.nl> <7340D9F5-C40D-415E-9D6B-9DFEA0A0E47A@oitc.com> <299BE752-FAA8-43C2-BABE-03EB7AD579CC@oitc.com> Message-ID: <00d501cf0e0d$d76e0870$864a1950$@webjogger.net> Hi TR, This looks like a very promising service to me as well. Could you hit me off list with the pricing contact? The pricing on http://www.spamhaustech.com/datafeed/pricecalculator.lasso is a little high ($9,223,372,036,854,780,000.00/yr). :) Thanks, Adam -----Original Message----- From: TR Shaw [mailto:tshaw at oitc.com] Sent: Thursday, January 09, 2014 5:49 PM To: Bryan Socha Cc: NANOG Mailing List Subject: Re: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds Replied off list. On Jan 9, 2014, at 5:43 PM, Bryan Socha wrote: > I would also like that contact, i've been trying to get the same quote for feed only for months. > > Thanks, > Bryan > > From eric-list at truenet.com Fri Jan 10 14:15:40 2014 From: eric-list at truenet.com (Eric Tykwinski) Date: Fri, 10 Jan 2014 09:15:40 -0500 Subject: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds In-Reply-To: <00d501cf0e0d$d76e0870$864a1950$@webjogger.net> References: <52CE6B0B.5050306@isp-services.nl> <7340D9F5-C40D-415E-9D6B-9DFEA0A0E47A@oitc.com> <299BE752-FAA8-43C2-BABE-03EB7AD579CC@oitc.com> <00d501cf0e0d$d76e0870$864a1950$@webjogger.net> Message-ID: <030101cf0e0e$71088af0$5319a0d0$@truenet.com> Looks like a bug, if you stick a 1 in total email users: Per Year: $504.00 -----Original Message----- From: Adam Greene [mailto:maillist at webjogger.net] Sent: Friday, January 10, 2014 9:11 AM To: 'NANOG Mailing List' Subject: RE: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds Hi TR, This looks like a very promising service to me as well. Could you hit me off list with the pricing contact? The pricing on http://www.spamhaustech.com/datafeed/pricecalculator.lasso is a little high ($9,223,372,036,854,780,000.00/yr). :) Thanks, Adam -----Original Message----- From: TR Shaw [mailto:tshaw at oitc.com] Sent: Thursday, January 09, 2014 5:49 PM To: Bryan Socha Cc: NANOG Mailing List Subject: Re: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds Replied off list. On Jan 9, 2014, at 5:43 PM, Bryan Socha wrote: > I would also like that contact, i've been trying to get the same quote > for feed only for months. > > Thanks, > Bryan > > From maillist at webjogger.net Fri Jan 10 15:53:50 2014 From: maillist at webjogger.net (Adam Greene) Date: Fri, 10 Jan 2014 10:53:50 -0500 Subject: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds In-Reply-To: <030101cf0e0e$71088af0$5319a0d0$@truenet.com> References: <52CE6B0B.5050306@isp-services.nl> <7340D9F5-C40D-415E-9D6B-9DFEA0A0E47A@oitc.com> <299BE752-FAA8-43C2-BABE-03EB7AD579CC@oitc.com> <00d501cf0e0d$d76e0870$864a1950$@webjogger.net> <030101cf0e0e$71088af0$5319a0d0$@truenet.com> Message-ID: <00cc01cf0e1c$27a79140$76f6b3c0$@webjogger.net> Ah yes, indeed. Makes much more sense. Interesting that they price per email accounts serviced. I guess that's how they determine your relative size. Interesting the idea of using this service in conjunction with Team Cymru's BOGON lists. -----Original Message----- From: Eric Tykwinski [mailto:eric-list at truenet.com] Sent: Friday, January 10, 2014 9:16 AM To: 'NANOG Mailing List' Subject: RE: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds Looks like a bug, if you stick a 1 in total email users: Per Year: $504.00 -----Original Message----- From: Adam Greene [mailto:maillist at webjogger.net] Sent: Friday, January 10, 2014 9:11 AM To: 'NANOG Mailing List' Subject: RE: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds Hi TR, This looks like a very promising service to me as well. Could you hit me off list with the pricing contact? The pricing on http://www.spamhaustech.com/datafeed/pricecalculator.lasso is a little high ($9,223,372,036,854,780,000.00/yr). :) Thanks, Adam -----Original Message----- From: TR Shaw [mailto:tshaw at oitc.com] Sent: Thursday, January 09, 2014 5:49 PM To: Bryan Socha Cc: NANOG Mailing List Subject: Re: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds Replied off list. On Jan 9, 2014, at 5:43 PM, Bryan Socha wrote: > I would also like that contact, i've been trying to get the same quote > for feed only for months. > > Thanks, > Bryan > > From nick at foobar.org Fri Jan 10 15:54:43 2014 From: nick at foobar.org (Nick Hilliard) Date: Fri, 10 Jan 2014 15:54:43 +0000 Subject: EIGRP support !Cisco In-Reply-To: References: <6434672$51e7277a$2af2e41c$@flhsi.com> Message-ID: <52D017C3.40805@foobar.org> On 08/01/2014 18:14, Christopher Morrow wrote: > you could employ one of the several methods to migrate from 'less > desirable igp' to 'more desirable igp' on all of the things in > question... there's people that have done this before even :) https://www.nanog.org/meetings/nanog29/presentations/gill.pdf Nick From morrowc.lists at gmail.com Fri Jan 10 15:57:12 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 10 Jan 2014 10:57:12 -0500 Subject: EIGRP support !Cisco In-Reply-To: <52D017C3.40805@foobar.org> References: <6434672$51e7277a$2af2e41c$@flhsi.com> <52D017C3.40805@foobar.org> Message-ID: On Fri, Jan 10, 2014 at 10:54 AM, Nick Hilliard wrote: > On 08/01/2014 18:14, Christopher Morrow wrote: >> you could employ one of the several methods to migrate from 'less >> desirable igp' to 'more desirable igp' on all of the things in >> question... there's people that have done this before even :) > > https://www.nanog.org/meetings/nanog29/presentations/gill.pdf oh yea! that guy! I hear he's done this sort of thing a few times now... probably has practice and tools and stuff :) From cscora at apnic.net Fri Jan 10 18:12:18 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 11 Jan 2014 04:12:18 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201401101812.s0AICI7E012499@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 11 Jan, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 477720 Prefixes after maximum aggregation: 190383 Deaggregation factor: 2.51 Unique aggregates announced to Internet: 236793 Total ASes present in the Internet Routing Table: 45866 Prefixes per ASN: 10.42 Origin-only ASes present in the Internet Routing Table: 35494 Origin ASes announcing only one prefix: 16270 Transit ASes present in the Internet Routing Table: 5988 Transit-only ASes present in the Internet Routing Table: 171 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 2673 Unregistered ASNs in the Routing Table: 630 Number of 32-bit ASNs allocated by the RIRs: 5665 Number of 32-bit ASNs visible in the Routing Table: 4384 Prefixes from 32-bit ASNs in the Routing Table: 13852 Number of bogon 32-bit ASNs visible in the Routing Table: 1 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 1824 Number of addresses announced to Internet: 2659446780 Equivalent to 158 /8s, 131 /16s and 239 /24s Percentage of available address space announced: 71.8 Percentage of allocated address space announced: 71.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 95.4 Total number of prefixes smaller than registry allocations: 166265 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 113470 Total APNIC prefixes after maximum aggregation: 34200 APNIC Deaggregation factor: 3.32 Prefixes being announced from the APNIC address blocks: 115868 Unique aggregates announced from the APNIC address blocks: 48493 APNIC Region origin ASes present in the Internet Routing Table: 4867 APNIC Prefixes per ASN: 23.81 APNIC Region origin ASes announcing only one prefix: 1209 APNIC Region transit ASes present in the Internet Routing Table: 834 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 28 Number of APNIC region 32-bit ASNs visible in the Routing Table: 803 Number of APNIC addresses announced to Internet: 730083008 Equivalent to 43 /8s, 132 /16s and 46 /24s Percentage of available APNIC address space announced: 85.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 163624 Total ARIN prefixes after maximum aggregation: 81887 ARIN Deaggregation factor: 2.00 Prefixes being announced from the ARIN address blocks: 164214 Unique aggregates announced from the ARIN address blocks: 75962 ARIN Region origin ASes present in the Internet Routing Table: 15931 ARIN Prefixes per ASN: 10.31 ARIN Region origin ASes announcing only one prefix: 5980 ARIN Region transit ASes present in the Internet Routing Table: 1677 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 56 Number of ARIN addresses announced to Internet: 1071167872 Equivalent to 63 /8s, 216 /16s and 185 /24s Percentage of available ARIN address space announced: 56.7 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 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, 23/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, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 120279 Total RIPE prefixes after maximum aggregation: 61358 RIPE Deaggregation factor: 1.96 Prefixes being announced from the RIPE address blocks: 123956 Unique aggregates announced from the RIPE address blocks: 79328 RIPE Region origin ASes present in the Internet Routing Table: 17592 RIPE Prefixes per ASN: 7.05 RIPE Region origin ASes announcing only one prefix: 8322 RIPE Region transit ASes present in the Internet Routing Table: 2845 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2558 Number of RIPE addresses announced to Internet: 655274884 Equivalent to 39 /8s, 14 /16s and 179 /24s Percentage of available RIPE address space announced: 95.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, 56320-58367 59392-61439, 61952-62463, 196608-200191 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 53827 Total LACNIC prefixes after maximum aggregation: 10064 LACNIC Deaggregation factor: 5.35 Prefixes being announced from the LACNIC address blocks: 59264 Unique aggregates announced from the LACNIC address blocks: 27483 LACNIC Region origin ASes present in the Internet Routing Table: 2063 LACNIC Prefixes per ASN: 28.73 LACNIC Region origin ASes announcing only one prefix: 558 LACNIC Region transit ASes present in the Internet Routing Table: 400 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 35 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 959 Number of LACNIC addresses announced to Internet: 147743032 Equivalent to 8 /8s, 206 /16s and 97 /24s Percentage of available LACNIC address space announced: 88.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 11853 Total AfriNIC prefixes after maximum aggregation: 2595 AfriNIC Deaggregation factor: 4.57 Prefixes being announced from the AfriNIC address blocks: 12594 Unique aggregates announced from the AfriNIC address blocks: 4132 AfriNIC Region origin ASes present in the Internet Routing Table: 697 AfriNIC Prefixes per ASN: 18.07 AfriNIC Region origin ASes announcing only one prefix: 201 AfriNIC Region transit ASes present in the Internet Routing Table: 148 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 8 Number of AfriNIC addresses announced to Internet: 49624832 Equivalent to 2 /8s, 245 /16s and 55 /24s Percentage of available AfriNIC address space announced: 49.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2944 11558 953 Korea Telecom 17974 2736 902 88 PT Telekomunikasi Indonesia 7545 2127 319 111 TPG Telecom Limited 4755 1811 392 193 TATA Communications formerly 9829 1563 1255 41 National Internet Backbone 9583 1294 100 535 Sify Limited 9498 1236 309 71 BHARTI Airtel Ltd. 7552 1234 1080 13 Viettel Corporation 4808 1146 2121 345 CNCGROUP IP network China169 24560 1097 382 167 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3029 3688 53 BellSouth.net Inc. 22773 2322 2940 139 Cox Communications Inc. 1785 2147 687 131 PaeTec Communications, Inc. 18566 2049 379 178 MegaPath Corporation 20115 1681 1665 588 Charter Communications 4323 1628 1081 410 tw telecom holdings, inc. 701 1508 11143 779 MCI Communications Services, 30036 1375 296 569 Mediacom Communications Corp 7018 1302 17747 845 AT&T Services, Inc. 6983 1295 756 581 ITC^Deltacom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1921 544 16 OJSC "Vimpelcom" 34984 1365 244 227 TELLCOM ILETISIM HIZMETLERI A 20940 1217 460 917 Akamai International B.V. 31148 1013 45 20 Freenet Ltd. 13188 922 100 26 TOV "Bank-Inform" 8551 850 370 38 Bezeq International-Ltd 6849 845 362 37 JSC "Ukrtelecom" 6830 770 2327 423 Liberty Global Operations B.V 12479 690 798 53 France Telecom Espana SA 35228 552 246 16 Telefonica UK Limited Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3439 1843 92 NET Servi?os de Comunica??o S 10620 2696 436 203 Telmex Colombia S.A. 18881 1795 908 20 Global Village Telecom 7303 1743 1163 230 Telecom Argentina S.A. 8151 1376 2865 423 Uninet S.A. de C.V. 11830 869 364 15 Instituto Costarricense de El 27947 859 93 89 Telconet S.A 7738 813 1562 37 Telemar Norte Leste S.A. 6503 795 434 61 Axtel, S.A.B. de C.V. 6147 780 373 27 Telefonica del Peru S.A.A. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1805 112 5 Sudanese Mobile Telephone (ZA 24863 897 338 26 Link Egypt (Link.NET) 6713 600 653 27 Office National des Postes et 8452 462 956 9 TE-AS 24835 298 144 9 Vodafone Data 3741 247 921 209 Internet Solutions 29571 240 21 14 Cote d'Ivoire Telecom 36992 229 783 24 ETISALAT MISR 15706 219 32 6 Sudatel (Sudan Telecom Co. Lt 29975 192 668 21 Vodacom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3439 1843 92 NET Servi?os de Comunica??o S 6389 3029 3688 53 BellSouth.net Inc. 4766 2944 11558 953 Korea Telecom 17974 2736 902 88 PT Telekomunikasi Indonesia 10620 2696 436 203 Telmex Colombia S.A. 22773 2322 2940 139 Cox Communications Inc. 1785 2147 687 131 PaeTec Communications, Inc. 7545 2127 319 111 TPG Telecom Limited 18566 2049 379 178 MegaPath Corporation 8402 1921 544 16 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3029 2976 BellSouth.net Inc. 17974 2736 2648 PT Telekomunikasi Indonesia 10620 2696 2493 Telmex Colombia S.A. 22773 2322 2183 Cox Communications Inc. 1785 2147 2016 PaeTec Communications, Inc. 7545 2127 2016 TPG Telecom Limited 4766 2944 1991 Korea Telecom 8402 1921 1905 OJSC "Vimpelcom" 18566 2049 1871 MegaPath Corporation 36998 1805 1800 Sudanese Mobile Telephone (ZA Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.192.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.196.0/22 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.200.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.202.0/23 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 62828 UNALLOCATED 8.21.130.0/24 4323 tw telecom holdings, 62850 UNALLOCATED 8.25.147.0/24 46887 Lightower Fiber Netw 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.90.128.0/18 27418 OUTOFWALL INC. 23.91.0.0/19 40676 Psychz Networks 23.91.14.0/24 40676 Psychz Networks 23.91.32.0/19 36315 Servpac Inc. 23.91.80.0/20 21560 Netstream Communications, LLC 23.91.96.0/20 37958 Beijing Blue I.T Technologies 23.91.112.0/21 32475 SingleHop 23.91.120.0/21 36351 SoftLayer Technologies Inc. 23.91.128.0/19 5645 TekSavvy Solutions, Inc. 23.91.160.0/19 36493 FIBERNETICS CORPORATION Complete listing at http://thyme.rand.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:16 /9:11 /10:30 /11:92 /12:254 /13:475 /14:943 /15:1638 /16:12852 /17:6809 /18:11447 /19:23340 /20:33224 /21:35848 /22:50874 /23:44219 /24:253304 /25:793 /26:952 /27:433 /28:48 /29:72 /30:32 /31:0 /32:14 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2004 2049 MegaPath Corporation 36998 1771 1805 Sudanese Mobile Telephone (ZA 6389 1699 3029 BellSouth.net Inc. 8402 1609 1921 OJSC "Vimpelcom" 22773 1565 2322 Cox Communications Inc. 30036 1215 1375 Mediacom Communications Corp 1785 1163 2147 PaeTec Communications, Inc. 11492 1157 1194 CABLE ONE, INC. 6983 1036 1295 ITC^Deltacom 22561 979 1257 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:936 2:876 3:3 4:15 5:875 6:21 8:635 12:1872 13:3 14:908 15:9 16:3 17:22 18:19 20:36 23:656 24:1751 27:1705 31:1517 32:44 33:2 34:5 36:109 37:1874 38:921 39:3 40:184 41:3299 42:243 44:14 46:2126 47:12 49:702 50:854 52:12 54:44 55:5 56:4 57:26 58:1144 59:596 60:369 61:1500 62:1210 63:1964 64:4380 65:2315 66:4130 67:2088 68:1082 69:3305 70:904 71:501 72:2024 74:2586 75:313 76:304 77:1153 78:1008 79:686 80:1299 81:1086 82:660 83:737 84:651 85:1217 86:401 87:1023 88:523 89:1596 90:152 91:5719 92:638 93:1619 94:2105 95:1516 96:534 97:348 98:1070 99:40 100:32 101:706 103:3942 105:534 106:142 107:370 108:548 109:2000 110:978 111:1155 112:609 113:819 114:772 115:1062 116:1017 117:836 118:1230 119:1283 120:326 121:786 122:1920 123:1261 124:1387 125:1456 128:659 129:236 130:356 131:666 132:353 133:159 134:312 135:73 136:277 137:315 138:354 139:174 140:201 141:352 142:551 143:414 144:503 145:91 146:567 147:434 148:792 149:363 150:153 151:479 152:410 153:208 154:53 155:529 156:317 157:420 158:287 159:808 160:360 161:468 162:996 163:233 164:670 165:586 166:272 167:637 168:1043 169:123 170:1167 171:186 172:12 173:1674 174:672 175:561 176:1361 177:2575 178:1937 179:384 180:1606 181:937 182:1422 183:485 184:633 185:1181 186:2777 187:1441 188:1955 189:1275 190:7326 191:9 192:7041 193:5437 194:4021 195:3405 196:1350 197:1090 198:4837 199:5528 200:6066 201:2558 202:9033 203:8883 204:4537 205:2630 206:2889 207:2830 208:3943 209:3716 210:3085 211:1629 212:2171 213:1971 214:860 215:83 216:5442 217:1729 218:612 219:325 220:1268 221:589 222:334 223:570 End of report From nanog at data102.com Fri Jan 10 18:41:36 2014 From: nanog at data102.com (randal k) Date: Fri, 10 Jan 2014 11:41:36 -0700 Subject: [Off-Topic] Ubersmith In-Reply-To: References: <14552511.3164.1389299204274.JavaMail.root@benjamin.baylink.com> <493B2341-7509-4EFB-9811-CB4C75B6899E@pulsepoint.com> <52CF49B4.3060103@viviotech.net> <52CF4AD6.6000602@wholesaleinternet.net> <52CF4D1C.5080103@wholesaleinternet.net> Message-ID: We have used Ubersmith here ata Data102 for several years (since august 2009? I think?) and have been very pleased with it. As a datacenter operator, it provides a truckload of tools and (perhaps the most important thing about it) integrates it all together pretty seamlessly. For a simple example - it can do all the general snmp graphing of a switchport, turn it on/off based on billing paramters, attach a device to a switchport, and come billing time, calculate and bill the 95th%. Very, very easily. It also handles monitoring metered power strips, can deal with switched PDUs, and allows all of that to be managed by the customer as well (yay for remote reboots through a decent UI!). Lots of other handy integrations (xen, vmware, cloudstack, onapp, pmacct, puppet, cdp, more!). And it all integrates pretty well with ticketing & customer accout management. It's new pricing structure is very off-putting. It used to be flat-rate, per-device, which was agreeable - somebody wants a managed server, add $1. No problem. Now, it is very much FUPayMe -- separate pricing for this feature, for this feature, "normal" devices and "advanced" devices. It's a ~50% hike from our current rate. As a small shop (~10k sqft, 15 employees), it's pretty brutal. I can't imagine what they're charging larger, more integrated places. Since the acquisition by Internap we have seen everything go downhill: quarterly updates turned into year-long waits; features & requests pretty much ignored; support seems more management-y; documentation has not been updated; they don't update their website pretty much at all; the order & sales manager appear to be completely disregarded and perma-beta; no updates at all to the 2.5.x codetrain; and 3.0 is now hidden behind the pay-more wall, after an 18 month wait. Maybe all of these are unlocked once we pay? We have been looking for alternatives since October or so, and the WHMCS Datacenter add-on looks OK, and Hostbill might be an option. We are loathe to go down the never-ending roll-our-own path, as it would take a lot of time to recreate what we have already enjoyed. We would *LOVE* to try out NocWorx, but they are not accepting new customers (and haven't for a year+). Tough spot for us. Any input would be awesome. Randal On Thu, Jan 9, 2014 at 7:14 PM, matt kelly wrote: > I'm also a bit leary of them now, considering they are owned by internap > after the voxel acquisition. I like their software and used it for years. > It just seems like they're trying to compete in the market of zuora and > others when they are something completely different. > > I'm also surprised there have been no competitors to ubersmith in the data > center space. > > Matt > On Jan 9, 2014 9:08 PM, "Jimmy Hess" wrote: > >> On Thu, Jan 9, 2014 at 7:30 PM, Aaron wrote: > We rolled our own. A friend is migrating to WHMCS from Ubersmith. >>> >>> Aaron >> >> >> I would be standoffish, due to Ubersmith alleged recent history of price >> increases. Admittedly... I am very skeptical about the concept of >> datacenter management or billing software providers charging a big >> monthly fee, plus extra per-client and extra per managed-device. >> >> That doesn't mean it's always a bad idea; it's just really annoying. >> >> >> If smart phones were sold like Enterprise software.... >> >> "Customer: How much for this smart phone?" >> >> "Sales clerk: How many people do you plan to call with it?" >> >> "Customer: Uh, 5 or 6 friends and family members." >> >> "Sales clerk: I see... well that will be $300 plus $25 per contact, so >> the total comes to $450. In 5 years the newer model will be $499 for >> you." >> >> "Customer: Wait... I also need to receive calls from 3 important business >> clients" >> >> "Sales clerk: In that case, the same smart phone costs $2500, plus an >> extra $100/month license fee for each business contact, and a 30% annual >> maintenance -- if you fail to renew before the end of the 12 months, it >> will deactivate and it will be full price to turn it back on." >> >> >> -- >> -JH >> From cidr-report at potaroo.net Fri Jan 10 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 10 Jan 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201401102200.s0AM007U010216@wattle.apnic.net> This report has been generated at Fri Jan 10 21:13:34 2014 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/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 03-01-14 488006 276420 04-01-14 487980 276353 05-01-14 487866 276635 06-01-14 488108 276237 07-01-14 488074 276227 08-01-14 488015 276657 09-01-14 488520 276469 10-01-14 488669 276406 AS Summary 46024 Number of ASes in routing system 18877 Number of ASes announcing only one prefix 4427 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 118834176 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 10Jan14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 489078 276301 212777 43.5% All ASes AS28573 3439 95 3344 97.2% NET Servi?os de Comunica??o S.A. AS6389 3029 56 2973 98.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS7029 4427 1657 2770 62.6% WINDSTREAM - Windstream Communications Inc AS17974 2735 184 2551 93.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4766 2944 962 1982 67.3% KIXS-AS-KR Korea Telecom AS18881 1795 31 1764 98.3% Global Village Telecom AS36998 1805 47 1758 97.4% SDN-MOBITEL AS1785 2146 389 1757 81.9% AS-PAETEC-NET - PaeTec Communications, Inc. AS10620 2696 1078 1618 60.0% Telmex Colombia S.A. AS22773 2325 826 1499 64.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2048 565 1483 72.4% MEGAPATH5-US - MegaPath Corporation AS4323 2932 1506 1426 48.6% TWTC - tw telecom holdings, inc. AS7303 1743 457 1286 73.8% Telecom Argentina S.A. AS4755 1811 594 1217 67.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1259 199 1060 84.2% VIETEL-AS-AP Viettel Corporation AS22561 1257 226 1031 82.0% AS22561 - CenturyTel Internet Holdings, Inc. AS9829 1532 640 892 58.2% BSNL-NIB National Internet Backbone AS7545 2124 1304 820 38.6% TPG-INTERNET-AP TPG Telecom Limited AS18101 988 185 803 81.3% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS35908 901 101 800 88.8% VPLSNET - Krypt Technologies AS4808 1146 383 763 66.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS701 1507 776 731 48.5% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS8151 1386 663 723 52.2% Uninet S.A. de C.V. AS24560 1089 368 721 66.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS6983 1295 581 714 55.1% ITCDELTA - ITC^Deltacom AS13977 848 143 705 83.1% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS4788 916 216 700 76.4% TMNET-AS-AP TM Net, Internet Service Provider AS855 748 58 690 92.2% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS6147 780 113 667 85.5% Telefonica del Peru S.A.A. AS7738 813 148 665 81.8% Telemar Norte Leste S.A. Total 54464 14551 39913 73.3% Top 30 total Possible Bogus Routes 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 41.73.2.0/24 AS37004 41.73.10.0/24 AS37004 41.73.11.0/24 AS37004 41.73.12.0/24 AS37004 41.73.13.0/24 AS37004 41.73.15.0/24 AS37004 41.73.16.0/24 AS37004 41.73.18.0/24 AS37004 41.73.20.0/24 AS37004 41.73.21.0/24 AS37004 41.76.48.0/21 AS36969 MTL-AS 41.78.120.0/23 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.87.32.0/19 AS37242 41.190.72.0/23 AS37451 CongoTelecom 41.190.74.0/23 AS37451 CongoTelecom 41.191.92.0/22 AS37245 41.191.108.0/22 AS37004 41.191.108.0/24 AS37004 41.191.109.0/24 AS37004 41.191.110.0/24 AS37004 41.191.111.0/24 AS37004 41.217.208.0/22 AS37158 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.122.216.0/22 AS48727 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos 63.247.0.0/24 AS27609 63.247.1.0/24 AS27609 63.247.2.0/24 AS27609 63.247.3.0/24 AS27609 63.247.4.0/24 AS27609 63.247.5.0/24 AS27609 63.247.6.0/24 AS27609 63.247.7.0/24 AS27609 63.247.8.0/24 AS27609 63.247.9.0/24 AS27609 63.247.10.0/24 AS27609 63.247.11.0/24 AS27609 63.247.13.0/24 AS27609 63.247.14.0/24 AS27609 63.247.15.0/24 AS27609 63.247.16.0/24 AS27609 63.247.17.0/24 AS27609 63.247.18.0/24 AS27609 63.247.19.0/24 AS27609 63.247.20.0/24 AS27609 63.247.21.0/24 AS27609 63.247.22.0/24 AS27609 63.247.23.0/24 AS27609 63.247.24.0/24 AS27609 63.247.25.0/24 AS27609 63.247.26.0/24 AS27609 63.247.27.0/24 AS27609 63.247.28.0/24 AS27609 63.247.29.0/24 AS27609 64.25.16.0/23 AS19535 64.25.20.0/24 AS19535 64.25.21.0/24 AS19535 64.25.22.0/24 AS19535 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 64.111.0.0/20 AS8039 CCC-ASN-1 - Cinergy Communications 64.111.160.0/20 AS40551 64.111.160.0/24 AS40551 64.111.161.0/24 AS40551 64.111.162.0/24 AS40551 64.111.167.0/24 AS40551 64.111.169.0/24 AS40551 64.111.170.0/24 AS40551 64.111.171.0/24 AS40551 64.111.172.0/24 AS40551 64.111.173.0/24 AS40551 64.111.174.0/24 AS40551 64.111.175.0/24 AS40551 64.119.240.0/22 AS26072 64.119.240.0/23 AS26072 64.119.242.0/23 AS26072 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.202.48.0/22 AS23380 64.202.52.0/23 AS23380 64.202.54.0/24 AS23380 64.202.55.0/24 AS23380 64.202.56.0/22 AS23380 64.202.60.0/24 AS23380 64.202.61.0/24 AS23380 64.202.62.0/24 AS23380 64.202.63.0/24 AS23380 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.11.112.0/20 AS14572 66.55.96.0/23 AS17203 66.55.98.0/24 AS17203 66.55.99.0/24 AS17203 66.55.100.0/22 AS17203 66.55.102.0/23 AS17203 66.55.104.0/21 AS17203 66.159.98.0/24 AS17206 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc. 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 66.206.208.0/22 AS23380 66.206.211.0/24 AS14288 MPINET - MPInet 66.206.212.0/24 AS23380 66.206.213.0/24 AS14288 MPINET - MPInet 66.206.214.0/24 AS23380 66.206.215.0/24 AS23380 66.206.216.0/23 AS14288 MPINET - MPInet 66.206.218.0/23 AS23380 66.206.220.0/22 AS23380 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.254.160.0/20 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.176.0/21 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.184.0/22 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 67.21.144.0/22 AS174 COGENT Cogent/PSI 67.21.148.0/22 AS174 COGENT Cogent/PSI 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.232.0/21 AS6246 AVALONTEL - AvalonTel 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.112.100.0/22 AS16764 74.113.200.0/23 AS46939 74.114.52.0/22 AS40818 74.114.52.0/23 AS40818 74.114.52.0/24 AS40818 74.114.53.0/24 AS40818 74.114.54.0/23 AS40818 74.114.54.0/24 AS40818 74.114.55.0/24 AS40818 74.114.140.0/22 AS32757 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 74.118.132.0/22 AS5117 77.243.80.0/24 AS42597 77.243.81.0/24 AS42597 77.243.88.0/24 AS42597 77.243.91.0/24 AS42597 77.243.94.0/24 AS42597 77.243.95.0/24 AS42597 80.248.64.0/20 AS30982 CAFETG AS de CAFE Informatique 80.248.64.0/21 AS8513 SKYVISION SkyVision Global Networks Ltd 80.248.64.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.65.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.66.0/23 AS30982 CAFETG AS de CAFE Informatique 80.248.66.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.67.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.68.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.69.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.70.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.71.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.77.0/24 AS30982 CAFETG AS de CAFE Informatique 80.250.32.0/22 AS37106 ODUA-AS 85.202.160.0/20 AS44404 91.193.60.0/22 AS3356 LEVEL3 Level 3 Communications 91.195.66.0/23 AS3356 LEVEL3 Level 3 Communications 91.197.36.0/22 AS43359 91.199.90.0/24 AS44330 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD 91.207.1.0/24 AS174 COGENT Cogent/PSI 91.207.152.0/24 AS64100 91.207.153.0/24 AS64100 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG 91.220.176.0/24 AS16265 LEASEWEB LeaseWeb B.V. 93.190.8.0/24 AS47254 93.190.9.0/24 AS47254 93.190.10.0/24 AS47254 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.11.1.0/24 AS9822 AMNET-AU-AP Amnet IT Services Pty Ltd 103.11.216.0/24 AS13208 103.11.217.0/24 AS13208 103.11.218.0/23 AS13117 KINGCORP-AS-IX Opennet Internet Exchange 103.11.219.0/24 AS13208 103.13.184.0/23 AS58674 103.15.228.0/22 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.228.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.230.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 103.25.52.0/24 AS14179 Interactive Gaming and Wagering N.V. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 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 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange 151.216.128.0/17 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM" 151.216.128.0/18 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM" 151.216.192.0/18 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM" 164.40.184.0/24 AS19821 172.85.0.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 174.136.192.0/18 AS14572 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL 178.218.240.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.241.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.242.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.243.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.244.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.245.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.246.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.247.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.248.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.249.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.250.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.251.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.252.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.253.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.254.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.255.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS 190.15.72.0/21 AS15146 CABLEBAHAMAS - Cable Bahamas 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A. 190.124.252.0/22 AS7303 Telecom Argentina S.A. 192.166.32.0/20 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.9.59.0/24 AS1257 TELE2 193.16.106.0/24 AS31539 193.16.145.0/24 AS31392 193.22.3.0/24 AS3209 VODANET Vodafone GmbH 193.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF 193.33.6.0/23 AS3356 LEVEL3 Level 3 Communications 193.109.15.0/24 AS12690 MKSNET-AS MKS Autonomous System 193.111.66.0/23 AS8220 COLT COLT Technology Services Group Limited 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 193.178.217.0/24 AS20737 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc. 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH 193.254.218.0/23 AS25229 VOLIA-AS Kyivski Telekomunikatsiyni Merezhi LLC 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH 194.50.82.0/24 AS16276 OVH OVH Systems 194.63.152.0/22 AS3356 LEVEL3 Level 3 Communications 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service 194.126.219.0/24 AS34545 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd 195.28.168.0/23 AS8655 195.114.4.0/23 AS41158 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB 195.130.208.0/24 AS16265 LEASEWEB LeaseWeb B.V. 195.137.188.0/24 AS35657 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA 195.234.156.0/24 AS25028 195.242.182.0/24 AS3356 LEVEL3 Level 3 Communications 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.18.112.0/20 AS1916 Associa??o Rede Nacional de Ensino e Pesquisa 200.23.189.0/24 AS57792 PROVITEX-AS PE Glazunov Yuriy Anatol'yevich 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 203.142.219.0/24 AS45149 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc. 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.115.110.0/23 AS53709 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc. 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp. 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 205.236.71.0/24 AS852 ASN852 - TELUS Communications Inc. 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.66.120.0/22 AS32757 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc. 208.69.192.0/23 AS6461 MFNX MFN - Metromedia Fiber Network 208.69.194.0/24 AS20161 TRGO - TeraGo Networks Inc. 208.69.195.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 208.74.224.0/22 AS174 COGENT Cogent/PSI 208.75.152.0/21 AS32146 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.84.232.0/24 AS33131 208.84.234.0/24 AS33131 208.84.237.0/24 AS33131 208.84.238.0/24 AS33131 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.164.0/22 AS46099 208.92.224.0/22 AS32757 208.92.226.0/24 AS32757 209.161.96.0/20 AS8039 CCC-ASN-1 - Cinergy Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.193.112.0/20 AS209 ASN-QWEST-US NOVARTIS-DMZ-US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 212.119.32.0/19 AS12550 213.184.64.0/24 AS13071 213.184.65.0/24 AS13071 213.184.66.0/24 AS13071 213.184.67.0/24 AS13071 213.184.68.0/24 AS13071 213.184.69.0/24 AS13071 213.184.70.0/24 AS13071 213.184.71.0/24 AS13071 213.184.72.0/24 AS13071 213.184.73.0/24 AS13071 213.184.74.0/24 AS13071 213.184.75.0/24 AS13071 213.184.76.0/24 AS13071 213.184.77.0/24 AS13071 213.184.78.0/24 AS13071 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.14.64.0/20 AS14728 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Jan 10 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 10 Jan 2014 22:00:01 GMT Subject: BGP Update Report Message-ID: <201401102200.s0AM015k010230@wattle.apnic.net> BGP Update Report Interval: 02-Jan-14 -to- 09-Jan-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4766 51860 2.9% 24.6 -- KIXS-AS-KR Korea Telecom 2 - AS9829 51069 2.9% 55.9 -- BSNL-NIB National Internet Backbone 3 - AS8402 41832 2.4% 67.1 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS3816 37975 2.1% 107.3 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 5 - AS14287 36480 2.0% 6080.0 -- TRIAD-TELECOM - Triad Telecom, Inc. 6 - AS4323 30618 1.7% 23.1 -- TWTC - tw telecom holdings, inc. 7 - AS701 29311 1.6% 4.1 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 8 - AS7029 23523 1.3% 14.9 -- WINDSTREAM - Windstream Communications Inc 9 - AS13118 21013 1.2% 5253.2 -- ASN-YARTELECOM OJSC Rostelecom 10 - AS4775 18564 1.0% 580.1 -- GLOBE-TELECOM-AS Globe Telecoms 11 - AS7552 18272 1.0% 12.0 -- VIETEL-AS-AP Viettel Corporation 12 - AS41691 17207 1.0% 614.5 -- SUMTEL-AS-RIPE Summa Telecom LLC 13 - AS4538 13563 0.8% 30.1 -- ERX-CERNET-BKB China Education and Research Network Center 14 - AS59217 13474 0.8% 13474.0 -- AZONNELIMITED-AS-AP Azonne Limited 15 - AS18403 12392 0.7% 21.7 -- FPT-AS-AP The Corporation for Financing & Promoting Technology 16 - AS17557 11877 0.7% 232.9 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 17 - AS11976 11648 0.7% 135.4 -- FIDN - Fidelity Communication International Inc. 18 - AS6629 11116 0.6% 171.0 -- NOAA-AS - NOAA 19 - AS45899 11014 0.6% 32.0 -- VNPT-AS-VN VNPT Corp 20 - AS5668 10685 0.6% 93.7 -- AS-5668 - CenturyTel Internet Holdings, Inc. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS59217 13474 0.8% 13474.0 -- AZONNELIMITED-AS-AP Azonne Limited 2 - AS54465 7200 0.4% 7200.0 -- QPM-AS-1 - QuickPlay Media Inc. 3 - AS14287 36480 2.0% 6080.0 -- TRIAD-TELECOM - Triad Telecom, Inc. 4 - AS13118 21013 1.2% 5253.2 -- ASN-YARTELECOM OJSC Rostelecom 5 - AS12922 4947 0.3% 4947.0 -- MULTITRADE-AS Bank Outsourcer 6 - AS19406 3895 0.2% 3895.0 -- TWRS-MA - Towerstream I, Inc. 7 - AS11685 3669 0.2% 3669.0 -- HNBCOL-AS - Huntington National Bank 8 - AS28477 3563 0.2% 3563.0 -- UNIVERSIDAD AUTONOMA DEL ESTADO DE MORELOS 9 - AS2 2306 0.1% 2054.0 -- CCHVC-AS-AP Beijing Network Video Communications Technology Co,. Ltd. 10 - AS62431 2106 0.1% 2106.0 -- NCSC-IE-AS National Cyber Security Centre 11 - AS56097 3230 0.2% 1615.0 -- JOISTER-AS Joister Group of Companies. 12 - AS51861 1614 0.1% 1614.0 -- SHARED-AS Eric Dorr 13 - AS22747 3110 0.2% 1555.0 -- TCIS - TulsaConnect, LLC 14 - AS30437 4436 0.2% 1478.7 -- GE-MS003 - General Electric Company 15 - AS45808 1106 0.1% 1106.0 -- UTP-MY Bandar Seri Iskandar 16 - AS7202 8568 0.5% 856.8 -- FAMU - Florida A & M University 17 - AS34238 808 0.1% 808.0 -- 18 - AS39250 807 0.1% 807.0 -- ASN-HYPERGRID HyperGrid s.r.l. 19 - AS11054 9300 0.5% 775.0 -- LIVEPERSON LivePerson, Inc 20 - AS23295 768 0.0% 768.0 -- EA-01 - Extend America TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/20 21008 1.1% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 103.243.164.0/22 13474 0.7% AS59217 -- AZONNELIMITED-AS-AP Azonne Limited 3 - 89.221.206.0/24 10668 0.6% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 4 - 192.58.232.0/24 10289 0.5% AS6629 -- NOAA-AS - NOAA 5 - 120.28.62.0/24 9328 0.5% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 6 - 222.127.0.0/24 9080 0.5% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 7 - 208.70.20.0/22 7332 0.4% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 8 - 208.73.244.0/22 7286 0.4% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 9 - 208.88.232.0/22 7280 0.4% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 10 - 208.78.116.0/22 7280 0.4% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 11 - 216.162.0.0/20 7274 0.4% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 12 - 206.152.15.0/24 7200 0.4% AS54465 -- QPM-AS-1 - QuickPlay Media Inc. 13 - 148.218.0.0/16 6840 0.3% AS11172 -- Alestra, S. de R.L. de C.V. AS28477 -- UNIVERSIDAD AUTONOMA DEL ESTADO DE MORELOS 14 - 85.249.160.0/20 6387 0.3% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 15 - 67.210.190.0/23 6214 0.3% AS11976 -- FIDN - Fidelity Communication International Inc. 16 - 103.2.238.0/24 5139 0.3% AS45194 -- SIPL-AS Syscon Infoway Pvt. Ltd., Internet Service Provider, India. AS56097 -- JOISTER-AS Joister Group of Companies. 17 - 183.87.110.0/24 5139 0.3% AS45194 -- SIPL-AS Syscon Infoway Pvt. Ltd., Internet Service Provider, India. AS56097 -- JOISTER-AS Joister Group of Companies. 18 - 194.105.61.0/24 4947 0.3% AS12922 -- MULTITRADE-AS Bank Outsourcer 19 - 199.187.118.0/24 4922 0.2% AS11054 -- LIVEPERSON LivePerson, Inc 20 - 67.210.188.0/23 4628 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From achatz at forthnet.gr Mon Jan 13 10:26:02 2014 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Mon, 13 Jan 2014 12:26:02 +0200 Subject: verify currently running software on ram Message-ID: <52D3BF3A.1040905@forthnet.gr> I'm looking for ways to verify that the currently running software on our Cisco/Juniper boxes is the one that is also in the flash/hd/storage/etc. Something that will somehow compare the running software in ram with the software on flash/hd/storage/etc, so that i can verify that nobody has actually messed with the running software (by whatever means that's possible). Besides the "install verify" command on IOS-XR (which i'm not 100% sure if it suits my needs), i haven't managed to find anything else. And the vendors say that indeed there is nothing more. All other options are about verifying the software file integrity before it gets loaded into ram. Have you ever done such an exercise? Are there maybe any external tools (or services) that offer this capability? -- Tassos From saku at ytti.fi Mon Jan 13 10:46:51 2014 From: saku at ytti.fi (Saku Ytti) Date: Mon, 13 Jan 2014 12:46:51 +0200 Subject: verify currently running software on ram In-Reply-To: <52D3BF3A.1040905@forthnet.gr> References: <52D3BF3A.1040905@forthnet.gr> Message-ID: <20140113104651.GA25317@pob.ytti.fi> On (2014-01-13 12:26 +0200), Tassos Chatzithomaoglou wrote: > I'm looking for ways to verify that the currently running software on our Cisco/Juniper boxes is the one that is also in the flash/hd/storage/etc. IOS: verify /md5 flash:file JunOS: filechecksum md5|sha-256|sha1 file But if your system is owned, maybe the verification reads filename and outputs expected hash instead of correct hash. -- ++ytti From saku at ytti.fi Mon Jan 13 10:51:03 2014 From: saku at ytti.fi (Saku Ytti) Date: Mon, 13 Jan 2014 12:51:03 +0200 Subject: verify currently running software on ram In-Reply-To: <20140113104651.GA25317@pob.ytti.fi> References: <52D3BF3A.1040905@forthnet.gr> <20140113104651.GA25317@pob.ytti.fi> Message-ID: <20140113105103.GB25317@pob.ytti.fi> On (2014-01-13 12:46 +0200), Saku Ytti wrote: > On (2014-01-13 12:26 +0200), Tassos Chatzithomaoglou wrote: > > > I'm looking for ways to verify that the currently running software on our Cisco/Juniper boxes is the one that is also in the flash/hd/storage/etc. > > IOS: verify /md5 flash:file > JunOS: filechecksum md5|sha-256|sha1 file > > But if your system is owned, maybe the verification reads filename and outputs > expected hash instead of correct hash. mea culpa, you were looking to check running to image, I don't think this is practical. In IOS its compressed and decompressed upon boot, so no practical way to map the two together. Same is true in JunOS, even without compression it wouldn't be possible to reasonably map the *.tgz to RAM. I think vendors could take page from XBOX360 etc, and embed public keys inside their NPU in modern lithography then sign images, it would be impractical attack vector. But changing memory runtime is probably going to very complicated to verify, easier to create infrastructure/HW where program memory cannot be changed runtime. -- ++ytti From achatz at forthnet.gr Mon Jan 13 12:09:19 2014 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Mon, 13 Jan 2014 14:09:19 +0200 Subject: verify currently running software on ram In-Reply-To: <20140113104651.GA25317@pob.ytti.fi> References: <52D3BF3A.1040905@forthnet.gr> <20140113104651.GA25317@pob.ytti.fi> Message-ID: <52D3D76F.3040805@forthnet.gr> That verifies the software that is stored somewhere, not the currently running one. Someone "insider" could load a "hacked" software into flash, boot the router with that file (supposing that he has found a way to do so) and then replace the file on the flash with the real one. How can you verify that the running software is actually the original one? -- Tassos Saku Ytti wrote on 13/1/2014 12:46: > On (2014-01-13 12:26 +0200), Tassos Chatzithomaoglou wrote: > >> I'm looking for ways to verify that the currently running software on our Cisco/Juniper boxes is the one that is also in the flash/hd/storage/etc. > IOS: verify /md5 flash:file > JunOS: filechecksum md5|sha-256|sha1 file > > But if your system is owned, maybe the verification reads filename and outputs > expected hash instead of correct hash. > From achatz at forthnet.gr Mon Jan 13 12:19:08 2014 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Mon, 13 Jan 2014 14:19:08 +0200 Subject: verify currently running software on ram In-Reply-To: <20140113105103.GB25317@pob.ytti.fi> References: <52D3BF3A.1040905@forthnet.gr> <20140113104651.GA25317@pob.ytti.fi> <20140113105103.GB25317@pob.ytti.fi> Message-ID: <52D3D9BC.6000102@forthnet.gr> Saku Ytti wrote on 13/1/2014 12:51: > On (2014-01-13 12:46 +0200), Saku Ytti wrote: >> On (2014-01-13 12:26 +0200), Tassos Chatzithomaoglou wrote: >> >>> I'm looking for ways to verify that the currently running software on our Cisco/Juniper boxes is the one that is also in the flash/hd/storage/etc. >> IOS: verify /md5 flash:file >> JunOS: filechecksum md5|sha-256|sha1 file >> >> But if your system is owned, maybe the verification reads filename and outputs >> expected hash instead of correct hash. > mea culpa, you were looking to check running to image, I don't think this is > practical. > In IOS its compressed and decompressed upon boot, so no practical way to map > the two together. > Same is true in JunOS, even without compression it wouldn't be possible to > reasonably map the *.tgz to RAM. > > I think vendors could take page from XBOX360 etc, and embed public keys inside > their NPU in modern lithography then sign images, it would be impractical > attack vector. I was assuming the vendors could take a snapshot of the memory and somehow "compare" it to a snapshot of the original software. Or (i don't know how easy it is) do an auditing of the memory snapshot on specific pointers...well, i don't know...just thinking loudly... > But changing memory runtime is probably going to very complicated to verify, > easier to create infrastructure/HW where program memory cannot be changed > runtime. > I agree, and we already do that, but a regulatory authority has brought into surface something trickier. -- Tassos From ag4ve.us at gmail.com Mon Jan 13 12:29:46 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 13 Jan 2014 07:29:46 -0500 Subject: verify currently running software on ram In-Reply-To: <52D3D9BC.6000102@forthnet.gr> References: <52D3BF3A.1040905@forthnet.gr> <20140113104651.GA25317@pob.ytti.fi> <20140113105103.GB25317@pob.ytti.fi> <52D3D9BC.6000102@forthnet.gr> Message-ID: dd kmem and see if it's what you'd expect (size of ram+swap). If so you should be able to look at it Also see Volatility On Jan 13, 2014 7:21 AM, "Tassos Chatzithomaoglou" wrote: > Saku Ytti wrote on 13/1/2014 12:51: > > On (2014-01-13 12:46 +0200), Saku Ytti wrote: > >> On (2014-01-13 12:26 +0200), Tassos Chatzithomaoglou wrote: > >> > >>> I'm looking for ways to verify that the currently running software on > our Cisco/Juniper boxes is the one that is also in the flash/hd/storage/etc. > >> IOS: verify /md5 flash:file > >> JunOS: filechecksum md5|sha-256|sha1 file > >> > >> But if your system is owned, maybe the verification reads filename and > outputs > >> expected hash instead of correct hash. > > mea culpa, you were looking to check running to image, I don't think > this is > > practical. > > In IOS its compressed and decompressed upon boot, so no practical way to > map > > the two together. > > Same is true in JunOS, even without compression it wouldn't be possible > to > > reasonably map the *.tgz to RAM. > > > > I think vendors could take page from XBOX360 etc, and embed public keys > inside > > their NPU in modern lithography then sign images, it would be impractical > > attack vector. > > I was assuming the vendors could take a snapshot of the memory and somehow > "compare" it to a snapshot of the original software. > Or (i don't know how easy it is) do an auditing of the memory snapshot on > specific pointers...well, i don't know...just thinking loudly... > > But changing memory runtime is probably going to very complicated to > verify, > > easier to create infrastructure/HW where program memory cannot be changed > > runtime. > > > I agree, and we already do that, but a regulatory authority has brought > into surface something trickier. > > -- > Tassos > > > From ag4ve.us at gmail.com Mon Jan 13 12:32:47 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 13 Jan 2014 07:32:47 -0500 Subject: verify currently running software on ram In-Reply-To: References: <52D3BF3A.1040905@forthnet.gr> <20140113104651.GA25317@pob.ytti.fi> <20140113105103.GB25317@pob.ytti.fi> <52D3D9BC.6000102@forthnet.gr> Message-ID: Doh, tired and not reading - the util should help after you get a dump though. On Jan 13, 2014 7:29 AM, "shawn wilson" wrote: > dd kmem and see if it's what you'd expect (size of ram+swap). If so you > should be able to look at it > > Also see Volatility > On Jan 13, 2014 7:21 AM, "Tassos Chatzithomaoglou" > wrote: > >> Saku Ytti wrote on 13/1/2014 12:51: >> > On (2014-01-13 12:46 +0200), Saku Ytti wrote: >> >> On (2014-01-13 12:26 +0200), Tassos Chatzithomaoglou wrote: >> >> >> >>> I'm looking for ways to verify that the currently running software on >> our Cisco/Juniper boxes is the one that is also in the flash/hd/storage/etc. >> >> IOS: verify /md5 flash:file >> >> JunOS: filechecksum md5|sha-256|sha1 file >> >> >> >> But if your system is owned, maybe the verification reads filename and >> outputs >> >> expected hash instead of correct hash. >> > mea culpa, you were looking to check running to image, I don't think >> this is >> > practical. >> > In IOS its compressed and decompressed upon boot, so no practical way >> to map >> > the two together. >> > Same is true in JunOS, even without compression it wouldn't be possible >> to >> > reasonably map the *.tgz to RAM. >> > >> > I think vendors could take page from XBOX360 etc, and embed public keys >> inside >> > their NPU in modern lithography then sign images, it would be >> impractical >> > attack vector. >> >> I was assuming the vendors could take a snapshot of the memory and >> somehow "compare" it to a snapshot of the original software. >> Or (i don't know how easy it is) do an auditing of the memory snapshot on >> specific pointers...well, i don't know...just thinking loudly... >> > But changing memory runtime is probably going to very complicated to >> verify, >> > easier to create infrastructure/HW where program memory cannot be >> changed >> > runtime. >> > >> I agree, and we already do that, but a regulatory authority has brought >> into surface something trickier. >> >> -- >> Tassos >> >> >> From Valdis.Kletnieks at vt.edu Mon Jan 13 12:44:49 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 13 Jan 2014 07:44:49 -0500 Subject: verify currently running software on ram In-Reply-To: Your message of "Mon, 13 Jan 2014 12:26:02 +0200." <52D3BF3A.1040905@forthnet.gr> References: <52D3BF3A.1040905@forthnet.gr> Message-ID: <210021.1389617089@turing-police.cc.vt.edu> On Mon, 13 Jan 2014 12:26:02 +0200, Tassos Chatzithomaoglou said: > I'm looking for ways to verify that the currently running software on our > Cisco/Juniper boxes is the one that is also in the flash/hd/storage/etc. In general, asking the operating system if it's pwned is an insoluble problem, because the pwner will of course arrange that the answer to such a query be "No, I'm not pwned". You really need assistance from one layer further down - if you're in a VM, you need to ask the hypervisor. If you're on bare metal, you need to ask the SMM or equivalent. If you're in the SMM, you need to ask the hardware. And of course, at each level, you have to ask yourself how you know that *that* level isn't lying to you.... (Yes, this is the corner of system security where, if you're not already a paranoid schizophrenic, you will be soon.. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jra at baylink.com Mon Jan 13 15:59:08 2014 From: jra at baylink.com (Jay Ashworth) Date: Mon, 13 Jan 2014 10:59:08 -0500 (EST) Subject: verify currently running software on ram In-Reply-To: <210021.1389617089@turing-police.cc.vt.edu> Message-ID: <3153715.3518.1389628748684.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "Valdis Kletnieks" > You really need assistance from one layer further down - if you're in > a VM, you need to ask the hypervisor. If you're on bare metal, you need > to ask the SMM or equivalent. If you're in the SMM, you need to ask the > hardware. And of course, at each level, you have to ask yourself how > you know that *that* level isn't lying to you.... > > (Yes, this is the corner of system security where, if you're not > already a paranoid schizophrenic, you will be soon.. :) If you have not already read the Ken Thompson paper: http://cm.bell-labs.com/who/ken/trust.html And for a bit more on whether it was ever actually implemented, from Ken himself: https://groups.google.com/d/msg/comp.security.unix/ivjYjNSduFc/0Er2cynPKjsJ Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mikeal.clark at gmail.com Mon Jan 13 18:14:37 2014 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Mon, 13 Jan 2014 12:14:37 -0600 Subject: VistaPrint? Message-ID: Anyone have a worthwhile contact? Have a friend with domain/dns/email running on my equipment and web service on theirs. Web server isn't configured correctly for the domain. From starthir at gmail.com Mon Jan 13 18:19:14 2014 From: starthir at gmail.com (Alvaro Pereira) Date: Mon, 13 Jan 2014 11:19:14 -0700 Subject: Amazon help Message-ID: Hi, Can someone from AWS/Amazon contact me off-list to help us with an issue? Thank you, Alvaro Pereira From jared at puck.nether.net Mon Jan 13 21:07:28 2014 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 13 Jan 2014 16:07:28 -0500 Subject: OpenNTPProject.org Message-ID: Greetings, With the recent increase in NTP attacks, I wanted to advise the community of a few things: There are about 1.2-1.5 million of these servers out there. 1) You can search your IP space to find NTP servers that respond to the ?MONLIST? queries. 2) I?ve found some vendors have old embedded versions of NTP including ILO/Service Processors and other parts of the ?internet of things?. 3) You want to upgrade NTP, or adjust your ntp.conf to include ?limited? or ?restrict? lines or both. (I defer to someone else to be an expert in this area, but am willing to learn :) ) 4) Please prevent packet spoofing where possible on your network. This will limit the impact of spoofed NTP or DNS (amongst others) packets from impacting the broader community. 5) Some vendors don?t have an easy way to alter the ntp configuration, or have not or won?t be updating NTP, you may need to use ACLs, firewall filters, or other methods to block this traffic. I?ve heard of many routers being used in attacks impacting the CPU usage. Take a moment and see if your devices respond to the following query/queries: ntpdc -n -c monlist 10.0.0.1 ntpdc -n -c loopinfo 10.0.0.1 ntpdc -n -c iostats 10.0.0.1 6) If you do VMs/Servers and have a template, please make sure that they do not respond to NTP requests. Thanks! - Jared From Derek.Andrew at usask.ca Mon Jan 13 21:13:18 2014 From: Derek.Andrew at usask.ca (Derek Andrew) Date: Mon, 13 Jan 2014 15:13:18 -0600 Subject: OpenNTPProject.org In-Reply-To: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> Message-ID: nmap -sU -pU:123 -Pn -n --script=ntp-monlist serverIP On Mon, Jan 13, 2014 at 3:07 PM, Jared Mauch wrote: > Greetings, > > With the recent increase in NTP attacks, I wanted to advise the community > of a few things: > > There are about 1.2-1.5 million of these servers out there. > > 1) You can search your IP space to find NTP servers that respond to the > ?MONLIST? queries. > > 2) I?ve found some vendors have old embedded versions of NTP including > ILO/Service Processors and other parts of the ?internet of things?. > > 3) You want to upgrade NTP, or adjust your ntp.conf to include ?limited? > or ?restrict? lines or both. (I defer to someone else to be an expert in > this area, but am willing to learn :) ) > > 4) Please prevent packet spoofing where possible on your network. This > will limit the impact of spoofed NTP or DNS (amongst others) packets from > impacting the broader community. > > 5) Some vendors don?t have an easy way to alter the ntp configuration, or > have not or won?t be updating NTP, you may need to use ACLs, firewall > filters, or other methods to block this traffic. I?ve heard of many > routers being used in attacks impacting the CPU usage. > > Take a moment and see if your devices respond to the following > query/queries: > > ntpdc -n -c monlist 10.0.0.1 > ntpdc -n -c loopinfo 10.0.0.1 > ntpdc -n -c iostats 10.0.0.1 > > 6) If you do VMs/Servers and have a template, please make sure that they > do not respond to NTP requests. > > Thanks! > > - Jared > -- Copyright 2014 Derek Andrew (excluding quotations) +1 306 966 4808 Information and Communications Technology University of Saskatchewan Peterson 120; 54 Innovation Boulevard Saskatoon,Saskatchewan,Canada. S7N 2V3 Timezone GMT-6 Typed but not read. From bzeeb-lists at lists.zabbadoz.net Mon Jan 13 21:33:14 2014 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon, 13 Jan 2014 21:33:14 +0000 Subject: OpenNTPProject.org In-Reply-To: References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> Message-ID: <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> On 13 Jan 2014, at 21:13 , Derek Andrew wrote: > nmap -sU -pU:123 -Pn -n --script=ntp-monlist serverIP Make that ?all server IPs? if on different subnets, address families, ... > On Mon, Jan 13, 2014 at 3:07 PM, Jared Mauch wrote: > >> 4) Please prevent packet spoofing where possible on your network. This >> will limit the impact of spoofed NTP or DNS (amongst others) packets from >> impacting the broader community. BCP38! I am always surprised when people need crypto if they fail the simple things. >> 5) Some vendors don?t have an easy way to alter the ntp configuration, or >> have not or won?t be updating NTP, you may need to use ACLs, firewall >> filters, or other methods to block this traffic. I?ve heard of many >> routers being used in attacks impacting the CPU usage. >> >> Take a moment and see if your devices respond to the following >> query/queries: >> >> ntpdc -n -c monlist 10.0.0.1 >> ntpdc -n -c loopinfo 10.0.0.1 >> ntpdc -n -c iostats 10.0.0.1 And no matter if you use the above nmap or these instructions to check, also check your IPv6 addresses! You need 'restrict -6 default ignore' lines or similar as well, not just a restrict default ignore. ? Bjoern A. Zeeb ????????? ??? ??????? ??????: '??? ??? ???? ?????? ??????? ?? ?? ??????? ??????? ??? ????? ????? ???? ?????? ?? ????? ????', ????????? ?????????, "??? ????? ?? ?????", ?.??? From dmburgess at linktechs.net Mon Jan 13 22:30:19 2014 From: dmburgess at linktechs.net (Dennis Burgess) Date: Mon, 13 Jan 2014 16:30:19 -0600 Subject: Winstream engineer? Message-ID: <50710E9A7E64454C974049FC998EB655018DE1DB@03-exchange.lti.local> Looking for a windstream engineer that can help with BGP issue (not advertising from your network to the net).. hit me offlist. not getting anywhere with tech :( Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition " Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs -- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace From m at expertknobtwiddlers.com Mon Jan 13 19:36:24 2014 From: m at expertknobtwiddlers.com (Michael Costello) Date: Mon, 13 Jan 2014 14:36:24 -0500 Subject: verify currently running software on ram In-Reply-To: <52D3BF3A.1040905@forthnet.gr> References: <52D3BF3A.1040905@forthnet.gr> Message-ID: <52D44038.70205@expertknobtwiddlers.com> On 1/13/14 5:26 AM, Tassos Chatzithomaoglou wrote: > I'm looking for ways to verify that the currently running software on > our Cisco/Juniper boxes is the one that is also in the > flash/hd/storage/etc. Something that will somehow compare the running > software in ram with the software on flash/hd/storage/etc, so that i > can verify that nobody has actually messed with the running software > (by whatever means that's possible). > > Besides the "install verify" command on IOS-XR (which i'm not 100% > sure if it suits my needs), i haven't managed to find anything else. > And the vendors say that indeed there is nothing more. All other > options are about verifying the software file integrity before it > gets loaded into ram. > > Have you ever done such an exercise? Are there maybe any external > tools (or services) that offer this capability? > As Tassos said, there are no solutions from vendors. There are, however, some examples by third parties such as Defending Embedded Systems with Software Symbiotes http://ids.cs.columbia.edu/sites/default/files/paper_2.pdf and Protecting Software Codes By Guards http://www.seas.gwu.edu/~simhaweb/security/summer2005/Atallah1.pdf There are other efforts inside academia as well as companies attempting to develop dynamic firmware attestation (full disclosure: I work for one such company). As Valdis and others have said, it's an insoluble problem with solutions of varying degrees of efficacy and practicality. -mc From paul at telcodata.us Tue Jan 14 01:33:46 2014 From: paul at telcodata.us (Paul Timmins) Date: Mon, 13 Jan 2014 20:33:46 -0500 Subject: [VoiceOps] (cross post) VoIP heat charts... In-Reply-To: <24624102.3158.1389296285723.JavaMail.root@benjamin.baylink.com> References: <24624102.3158.1389296285723.JavaMail.root@benjamin.baylink.com> Message-ID: On Jan 9, 2014, at 2:38 PM, Jay Ashworth wrote: > ----- Original Message ----- >> >> >> Looking to "heat chart" where fraudelent calls are going. > > So you want to be able to feed "NPANXX Count" to something that will map > the call counts on a US map. > > You have anything that does NPANXX to H&V, or directly to Lat Lon, already? > > Cause that's the hard part. Telcodata has this available. city-county-zip-byratecenter TelcoData - Advanced Membership Area code, exchange, State, City, County, Zip - By Ratecenter (Requires Advanced Subscription) From blair.trosper at gmail.com Tue Jan 14 06:42:20 2014 From: blair.trosper at gmail.com (Blair Trosper) Date: Tue, 14 Jan 2014 00:42:20 -0600 Subject: Google GCE Message-ID: Can someone from GCE contact me off list? Your service is a big pile of 503s from multiple locations and from multiple servers. The console is inoperable and instances are unreachable. I'm getting sent across the country to a VIP in LAX. A friend in California is getting a VIP in Hong Kong. You're having issues but it doesn't seem to have been detected. From saku at ytti.fi Tue Jan 14 07:18:30 2014 From: saku at ytti.fi (Saku Ytti) Date: Tue, 14 Jan 2014 09:18:30 +0200 Subject: OpenNTPProject.org In-Reply-To: <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> Message-ID: <20140114071830.GA18152@pob.ytti.fi> On (2014-01-13 21:33 +0000), Bjoern A. Zeeb wrote: > BCP38! I am always surprised when people need crypto if they fail the simple things. Saying that BCP38 is solution to the reflection attacks is not unlike 5 year old wishing nothing but world peace for christmas, endearing, but it's not going to change anything. BCP38 is completely unrealistic, many access networks are on autopilot, many don't have HW support for BCP38, one port configured has low-benefit, only that machine can stop attacking (but whole world). near term, reducing attack surface is practical to reduce impact (not a solution, just damage control) near term, transit providers who do BGP prefix-list, could use same prefix-list for ACL, segmenting spoofing domains. It's very high pay-off, couple ports configured, whole downstream branch isolated into its own spoofing domain, able to just attack targets inside same domain. mid term, transport area in IETF. DNS, NTP, SNMP, chargen et.al. could trivially change to QUIC/MinimaLT or compared, getting same 0 RTT penalty as UDP without reflection potential. -- ++ytti From dot at dotat.at Tue Jan 14 10:39:16 2014 From: dot at dotat.at (Tony Finch) Date: Tue, 14 Jan 2014 10:39:16 +0000 Subject: OpenNTPProject.org In-Reply-To: References: Message-ID: Jared Mauch wrote: > > 3) You want to upgrade NTP, or adjust your ntp.conf to include ?limited? > or ?restrict? lines or both. (I defer to someone else to be an expert > in this area, but am willing to learn :) ) There is useful guidance for Cisco, Juniper, and Unix here: https://www.team-cymru.org/ReadingRoom/Templates/secure-ntp-template.html Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From Derek.Andrew at usask.ca Tue Jan 14 15:31:23 2014 From: Derek.Andrew at usask.ca (Derek Andrew) Date: Tue, 14 Jan 2014 09:31:23 -0600 Subject: [VoiceOps] (cross post) VoIP heat charts... In-Reply-To: <59743c6ab1c94cc285bce351221a5fc1@CAMPUSCAS3.usask.ca> References: <24624102.3158.1389296285723.JavaMail.root@benjamin.baylink.com> <59743c6ab1c94cc285bce351221a5fc1@CAMPUSCAS3.usask.ca> Message-ID: http://www.nanpa.com/nanp1/allutlzd.zip lists NPANXX and Ratecentre. derek On Mon, Jan 13, 2014 at 7:33 PM, Paul Timmins wrote: > > On Jan 9, 2014, at 2:38 PM, Jay Ashworth wrote: > > > ----- Original Message ----- > >> > >> > >> Looking to "heat chart" where fraudelent calls are going. > > > > So you want to be able to feed "NPANXX Count" to something that will map > > the call counts on a US map. > > > > You have anything that does NPANXX to H&V, or directly to Lat Lon, > already? > > > > Cause that's the hard part. > > Telcodata has this available. > > city-county-zip-byratecenter TelcoData - Advanced Membership Area code, > exchange, State, City, County, Zip - By Ratecenter (Requires Advanced > Subscription) > > -- Copyright 2014 Derek Andrew (excluding quotations) +1 306 966 4808 Information and Communications Technology University of Saskatchewan Peterson 120; 54 Innovation Boulevard Saskatoon,Saskatchewan,Canada. S7N 2V3 Timezone GMT-6 Typed but not read. From fergdawgster at mykolab.com Tue Jan 14 15:36:26 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Tue, 14 Jan 2014 07:36:26 -0800 Subject: OpenNTPProject.org In-Reply-To: <20140114071830.GA18152@pob.ytti.fi> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> Message-ID: <52D5597A.1090601@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 1/13/2014 11:18 PM, Saku Ytti wrote: > On (2014-01-13 21:33 +0000), Bjoern A. Zeeb wrote: > >>> BCP38! I am always surprised when people need crypto if they >>> fail the simple things. > Saying that BCP38 is solution to the reflection attacks is not > unlike 5 year old wishing nothing but world peace for christmas, > endearing, but it's not going to change anything. BCP38 is > completely unrealistic, many access networks are on autopilot, > many don't have HW support for BCP38, one port configured has > low-benefit, only that machine can stop attacking (but whole > world). That does *not* make it an unworthy goal, nor should it stop people from encouraging it's implementation. - - ferg (co-author of BCP38) - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLVWXoACgkQKJasdVTchbIrtAD/T2bNNAgZOnnlniBPd6sEquxJ v01mmrhJxFTIDFq7EIkA/3vQbiwtEwBeVyCtc3coEkz50zSDh3j9QQjT+TQWCNVs =Al3Y -----END PGP SIGNATURE----- From damian at google.com Tue Jan 14 16:35:49 2014 From: damian at google.com (Damian Menscher) Date: Tue, 14 Jan 2014 08:35:49 -0800 Subject: OpenNTPProject.org In-Reply-To: <20140114071830.GA18152@pob.ytti.fi> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> Message-ID: On Mon, Jan 13, 2014 at 11:18 PM, Saku Ytti wrote: > On (2014-01-13 21:33 +0000), Bjoern A. Zeeb wrote: > > > BCP38! I am always surprised when people need crypto if they fail the > simple things. > > Saying that BCP38 is solution to the reflection attacks is not unlike 5 > year > old wishing nothing but world peace for christmas, endearing, but it's not > going to change anything. > BCP38 is completely unrealistic, many access networks are on autopilot, > many > don't have HW support for BCP38, one port configured has low-benefit, only > that machine can stop attacking (but whole world). > > near term, reducing attack surface is practical to reduce impact (not a > solution, just damage control) > BCP38 (even if not fully deployed) is the only viable form of reducing the attack surface. Other ideas can never reach enough adoption to have any impact (they need to be ~100% deployed before any improvement is seen). As an example, let's imagine you successfully close 99% of the open DNS recursive resolvers, dropping the number of available reflectors from 28M down to 280k. Has that achieved anything? No, the attacks will be just as large. Or even if you do get to 100%, you haven't done anything about the authoritative servers. Or the other protocols, like NTP, Chargen, etc. near term, transit providers who do BGP prefix-list, could use same > prefix-list for ACL, segmenting spoofing domains. It's very high pay-off, > couple ports configured, whole downstream branch isolated into its own > spoofing domain, able to just attack targets inside same domain. > I see this as a form of BCP38, but imposed on networks by their transit providers, rather than done voluntarily. It would be great if it could work, but I have doubts due to asymmetric routing announcements intended for traffic shaping. mid term, transport area in IETF. DNS, NTP, SNMP, chargen et.al. could > trivially change to QUIC/MinimaLT or compared, getting same 0 RTT penalty > as > UDP without reflection potential. > I'd expect that to take 20 years or more. Even if new standards are defined, the old servers will only be removed when they physically fail. My crazy proposal: get international agreement that sending spoofed packets is illegal, then trace their sources. Tracing the sources just requires transit providers (or other large networks) to collect and analyze netflow, but that may end up being as infeasible as changing the global legal system. ;) Damian From saku at ytti.fi Tue Jan 14 17:05:13 2014 From: saku at ytti.fi (Saku Ytti) Date: Tue, 14 Jan 2014 19:05:13 +0200 Subject: OpenNTPProject.org In-Reply-To: References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> Message-ID: <20140114170513.GA26030@pob.ytti.fi> On (2014-01-14 08:35 -0800), Damian Menscher wrote: > I see this as a form of BCP38, but imposed on networks by their transit > providers, rather than done voluntarily. It would be great if it could > work, but I have doubts due to asymmetric routing announcements intended > for traffic shaping. Yes, I should have specified 'BCP38 in access networks' as being completely unrealistic. (We do BCP38 on all ports and verify programmatically, but I know it's not at all practical solution globally for access). ACL in transit port is completely harmless, no announcements are needed for traffic to be accepted. There are very modest amount of transit ports globally and each port will create segmentation to the spoofing domains having immediate, significant effect on benefits of spoofed attacks. RPF obviously is non-starter for reasons you stated. > I'd expect that to take 20 years or more. Even if new standards are > defined, the old servers will only be removed when they physically fail. It would have to be carried over UDP initially and that support probably would have to live for 20 years. But new-l4-over-udp version could be deployable rapidly. I'm very optimistic that if we'd have useful L4 for DNS, significant portion of relevant DNS servers could be upgraded rapidly to support it. We may be able to use existing data for this, how many servers went from DNS source port to random source port to add entropy to reduce poisoning attack chance? Good portion of end users are running w7, w8, osx updating itself automatically, so end-user support could come automatically and not require action from users. phones, tablets etc have short upgrade cycles anyhow. Native-udp port could then be policed heavily, making reflected attacks pay-off poor and motivates rest of the users to take actions needed for new l4. > My crazy proposal: get international agreement that sending spoofed packets Agreed, crazy. -- ++ytti From brandon at burn.net Wed Jan 15 00:06:01 2014 From: brandon at burn.net (Brandon Applegate) Date: Tue, 14 Jan 2014 19:06:01 -0500 (EST) Subject: gmail.com - 550 error for ipv6/PTR ? Message-ID: Just saw this in a message tonight. No idea if this is a transient error or not. --- host gmail-smtp-in.l.google.com [gmail-smtp-in.l.google.com][2607:f8b0:4002:c01::1a] ???said: 550-5.7.1 [2607:ff70:11::11] Our system has detected that this ???message does not 550-5.7.1 meet IPv6 sending guidelines regarding PTR ???records and authentication 550-5.7.1 . Please review 550-5.7.1 ???https://support.google.com/mail/?p=ipv6_authentication_error [support.google.com] for more 550 ???5.7.1 information. t26si2290895yhl.255 - gsmtp (in reply to end of DATA ???command) --- That URL's relevant section says: Additional guidelines for IPv6 The sending IP must have a PTR record (i.e., a reverse DNS of the sending IP) and it should match the IP obtained via the forward DNS resolution of the hostname specified in the PTR record. Otherwise, mail will be marked as spam or possibly rejected. The sending domain should pass either SPF check or DKIM check. Otherwise, mail might be marked as spam. --- I have both of these (PTR's RR has matching AAAA, and I have SPF (but not DKIM)). I'm guessing that something on google's side is misinterpreting some data or other busted logic. I meet all the requirements laid out, and have been sending mail to gmail addresses (via ipv6) since $forever. Off-list replies are fine to minimize noise, and if there is an answer or any meaningful correlation I will reply on-list. Thanks in advance for any info/feedback. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 830B 4802 1DD4 F4F9 63FE B966 C0A7 189E 9EC0 3A74 "SH1-0151. This is the serial number, of our orbital gun." From johnl at iecc.com Wed Jan 15 01:38:18 2014 From: johnl at iecc.com (John Levine) Date: 15 Jan 2014 01:38:18 -0000 Subject: gmail.com - 550 error for ipv6/PTR ? In-Reply-To: Message-ID: <20140115013818.46352.qmail@joyce.lan> In article you write: >Just saw this in a message tonight. No idea if this is a transient error >or not. I saw the same thing, on an IP that has forward and reverse DNS and mail that passes SPF. Burp, I guess. From ml-nanog090304q at elcsplace.com Wed Jan 15 01:51:07 2014 From: ml-nanog090304q at elcsplace.com (Ted Cooper) Date: Wed, 15 Jan 2014 11:51:07 +1000 Subject: gmail.com - 550 error for ipv6/PTR ? In-Reply-To: References: Message-ID: <52D5E98B.1080607@elcsplace.com> On 15/01/14 10:06, Brandon Applegate wrote: > Off-list replies are fine to minimize noise, and if there is an answer > or any meaningful correlation I will reply on-list. Thanks in advance > for any info/feedback. I have been running into these a lot also and have so far concluded that it is an error within Google. The PTR/AAAA, SPF and DKIM are all matched up and tested as working. It also occurring on domains using google apps to handle their email so it is platform wide. All of the emails are personal emails, but coming from multiple domains/senders. The exact same email will be rejected when sent to any google IPv6 server for minutes/hours, but 3-4 hours later it will be accepted without error. The fact that it is being hard rejected is really quite annoying and generating a lot more support work. Unfortunately, my only fix at present is to turn off IPv6 delivery for all google hosted domains as I encounter them. It would be really nice if it was fixed. My theory is that they are failing PTR lookups. From elouie at yahoo.com Wed Jan 15 01:55:38 2014 From: elouie at yahoo.com (Eric A Louie) Date: Tue, 14 Jan 2014 17:55:38 -0800 (PST) Subject: best practice for advertising peering fabric routes Message-ID: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> I have a connection to a peering fabric and I'm not distributing the peering fabric routes into my network. I see three options 1. redistribute into my igp (OSPF) 2. configure ibgp and route them within that infrastructure.? All the default routes go out through the POPs so iBGP would see packets destined for the peering fabric and route it that-a-way 3. leave it "as is", and let the outbound traffic go out my upstreams and the inbound traffic come back through the peering fabric Advantages and disadvantages, pros and cons?? Recommendations?? Experiences, good and bad? I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the POPs yet.? That's another issue completely from a planning perspective. thanks Eric From elouie at yahoo.com Wed Jan 15 01:55:38 2014 From: elouie at yahoo.com (Eric A Louie) Date: Tue, 14 Jan 2014 17:55:38 -0800 (PST) Subject: best practice for advertising peering fabric routes Message-ID: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> I have a connection to a peering fabric and I'm not distributing the peering fabric routes into my network. I see three options 1. redistribute into my igp (OSPF) 2. configure ibgp and route them within that infrastructure.? All the default routes go out through the POPs so iBGP would see packets destined for the peering fabric and route it that-a-way 3. leave it "as is", and let the outbound traffic go out my upstreams and the inbound traffic come back through the peering fabric Advantages and disadvantages, pros and cons?? Recommendations?? Experiences, good and bad? I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the POPs yet.? That's another issue completely from a planning perspective. thanks Eric From cb.list6 at gmail.com Wed Jan 15 02:09:27 2014 From: cb.list6 at gmail.com (Cb B) Date: Tue, 14 Jan 2014 18:09:27 -0800 Subject: best practice for advertising peering fabric routes In-Reply-To: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> Message-ID: On Jan 14, 2014 6:01 PM, "Eric A Louie" wrote: > > I have a connection to a peering fabric and I'm not distributing the peering fabric routes into my network. > > I see three options > 1. redistribute into my igp (OSPF) > > 2. configure ibgp and route them within that infrastructure. All the default routes go out through the POPs so iBGP would see packets destined for the peering fabric and route it that-a-way > > 3. leave it "as is", and let the outbound traffic go out my upstreams and the inbound traffic come back through the peering fabric > > > Advantages and disadvantages, pros and cons? Recommendations? Experiences, good and bad? > > > I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the POPs yet. That's another issue completely from a planning perspective. > > thanks > Eric > http://tools.ietf.org/html/rfc5963 I like no-export From morrowc.lists at gmail.com Wed Jan 15 02:10:21 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 14 Jan 2014 21:10:21 -0500 Subject: gmail.com - 550 error for ipv6/PTR ? In-Reply-To: <52D5E98B.1080607@elcsplace.com> References: <52D5E98B.1080607@elcsplace.com> Message-ID: On Tue, Jan 14, 2014 at 8:51 PM, Ted Cooper wrote: > On 15/01/14 10:06, Brandon Applegate wrote: >> Off-list replies are fine to minimize noise, and if there is an answer >> or any meaningful correlation I will reply on-list. Thanks in advance >> for any info/feedback. > brandon, I didn't get your original... but could you ping me off-list and maybe I can get some data about what it is you're seeing? :) > I have been running into these a lot also and have so far concluded that > it is an error within Google. The PTR/AAAA, SPF and DKIM are all matched > up and tested as working. It also occurring on domains using google apps > to handle their email so it is platform wide. All of the emails are > personal emails, but coming from multiple domains/senders. > > The exact same email will be rejected when sent to any google IPv6 > server for minutes/hours, but 3-4 hours later it will be accepted > without error. > > The fact that it is being hard rejected is really quite annoying and > generating a lot more support work. > > Unfortunately, my only fix at present is to turn off IPv6 delivery for > all google hosted domains as I encounter them. It would be really nice > if it was fixed. > > My theory is that they are failing PTR lookups. > > > From morrowc.lists at gmail.com Wed Jan 15 02:22:24 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 14 Jan 2014 21:22:24 -0500 Subject: best practice for advertising peering fabric routes In-Reply-To: References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> Message-ID: On Tue, Jan 14, 2014 at 9:09 PM, Cb B wrote: > On Jan 14, 2014 6:01 PM, "Eric A Louie" wrote: >> >> I have a connection to a peering fabric and I'm not distributing the > peering fabric routes into my network. >> good plan. >> I see three options >> 1. redistribute into my igp (OSPF) >> >> 2. configure ibgp and route them within that infrastructure. All the > default routes go out through the POPs so iBGP would see packets destined > for the peering fabric and route it that-a-way >> >> 3. leave it "as is", and let the outbound traffic go out my upstreams and > the inbound traffic come back through the peering fabric >> >> 4. all peering-fabric routes get next-hop-self on your peering router before going into ibgp... all the rest of your network sees your local loopback as nexthop and things just work. >> Advantages and disadvantages, pros and cons? Recommendations? > Experiences, good and bad? >> >> >> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the > POPs yet. That's another issue completely from a planning perspective. >> >> thanks >> Eric >> > > http://tools.ietf.org/html/rfc5963 > > I like no-export From patrick at ianai.net Wed Jan 15 03:11:06 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 14 Jan 2014 22:11:06 -0500 Subject: best practice for advertising peering fabric routes In-Reply-To: References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> Message-ID: Pardon the top post, but I really don't have anything to comment below other than to agree with Chris and say rfc5963 is broken. NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP LAN should not be reachable from any device not directly attached to that LAN. Period. Doing so endangers your peers & the IX itself. It is on the order of not implementing BCP38, except no one has the (lame, ridiculous, idiotic, and pure cost-shifting BS) excuse that they "can't" do this. -- TTFN, patrick On Jan 14, 2014, at 21:22 , Christopher Morrow wrote: > On Tue, Jan 14, 2014 at 9:09 PM, Cb B wrote: >> On Jan 14, 2014 6:01 PM, "Eric A Louie" wrote: >>> >>> I have a connection to a peering fabric and I'm not distributing the >> peering fabric routes into my network. >>> > > good plan. > >>> I see three options >>> 1. redistribute into my igp (OSPF) >>> >>> 2. configure ibgp and route them within that infrastructure. All the >> default routes go out through the POPs so iBGP would see packets destined >> for the peering fabric and route it that-a-way >>> >>> 3. leave it "as is", and let the outbound traffic go out my upstreams and >> the inbound traffic come back through the peering fabric >>> >>> > > 4. all peering-fabric routes get next-hop-self on your peering router > before going into ibgp... > all the rest of your network sees your local loopback as nexthop and > things just work. > >>> Advantages and disadvantages, pros and cons? Recommendations? >> Experiences, good and bad? >>> >>> >>> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the >> POPs yet. That's another issue completely from a planning perspective. >>> >>> thanks >>> Eric >>> >> >> http://tools.ietf.org/html/rfc5963 >> >> I like no-export > From cb.list6 at gmail.com Wed Jan 15 03:19:24 2014 From: cb.list6 at gmail.com (Cb B) Date: Tue, 14 Jan 2014 19:19:24 -0800 Subject: best practice for advertising peering fabric routes In-Reply-To: References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> Message-ID: On Jan 14, 2014 7:13 PM, "Patrick W. Gilmore" wrote: > > Pardon the top post, but I really don't have anything to comment below other than to agree with Chris and say rfc5963 is broken. > > NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP LAN should not be reachable from any device not directly attached to that LAN. Period. > > Doing so endangers your peers & the IX itself. It is on the order of not implementing BCP38, except no one has the (lame, ridiculous, idiotic, and pure cost-shifting BS) excuse that they "can't" do this. > +1. Rfc5963 needs to update that guidance. Set next hop self loopback0 and done CB > -- > TTFN, > patrick > > > On Jan 14, 2014, at 21:22 , Christopher Morrow wrote: > > > On Tue, Jan 14, 2014 at 9:09 PM, Cb B wrote: > >> On Jan 14, 2014 6:01 PM, "Eric A Louie" wrote: > >>> > >>> I have a connection to a peering fabric and I'm not distributing the > >> peering fabric routes into my network. > >>> > > > > good plan. > > > >>> I see three options > >>> 1. redistribute into my igp (OSPF) > >>> > >>> 2. configure ibgp and route them within that infrastructure. All the > >> default routes go out through the POPs so iBGP would see packets destined > >> for the peering fabric and route it that-a-way > >>> > >>> 3. leave it "as is", and let the outbound traffic go out my upstreams and > >> the inbound traffic come back through the peering fabric > >>> > >>> > > > > 4. all peering-fabric routes get next-hop-self on your peering router > > before going into ibgp... > > all the rest of your network sees your local loopback as nexthop and > > things just work. > > > >>> Advantages and disadvantages, pros and cons? Recommendations? > >> Experiences, good and bad? > >>> > >>> > >>> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the > >> POPs yet. That's another issue completely from a planning perspective. > >>> > >>> thanks > >>> Eric > >>> > >> > >> http://tools.ietf.org/html/rfc5963 > >> > >> I like no-export > > > > From bicknell at ufp.org Wed Jan 15 03:20:33 2014 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 14 Jan 2014 21:20:33 -0600 Subject: best practice for advertising peering fabric routes In-Reply-To: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> Message-ID: <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> On Jan 14, 2014, at 7:55 PM, Eric A Louie wrote: > I have a connection to a peering fabric and I'm not distributing the peering fabric routes into my network. There's a two part problem lurking. Problem #1 is how you handle your internal routing. Most of the "big boys" will next-hop-self in iBGP all external routes. However depending on the size and configuration of your network there may be advantages to not using next-hop-self, or just putting it in your IGP. Basically, you should be doing the same thing you do for a /30 from a peer or transit provider in your network. There is one thing special about an exchange point though, for security reasons you probably want to add it to your "never accept" routing filter from peers/customers/transit providers. You don't need someone injecting a couple of more specifics to mess with your routing. Problem #2 is your customers. If you have customers that may operate default free, and they use one of the traceroute tools that not only finds the route, but then continues to probe it (like MTR, or Visual Traceroute) there can be an issue. The initial traceroute probe may return an IP on the exchange of your peer's router, but then when they subsequently source ICMP Ping to that IP there will be no route in their network, and it will simply never respond. Some call this a feature, some call this a problem. There is also an extremely rare problem where the far end of the peering exchange steps down MTU, and thus PMTU discovery is invoked, but your customers use Unicast RPF. Since the exchange LAN isn't in their table, Unicast RPF may drop the PMTU packet-too-big message, causing a timeout. If your customers have a default to you, all is well. However if they have a default to someone else, and take a table from you to selectively override the same problem can occur for any routes they select through you that also traverse the exchange. IMHO the best fix for #2 is that the exchange have an ASN, and announce the exchange LAN from that ASN, typically via the route server. You should then peer with the route server to pick up that network. That makes the announcement consistent, and makes it clear who operates that network, and your customers can then access it. Many exchanges do not do this, and then the next best solution might be to originate it from your ASN and announce it to your customers only, with no-export set on the way out. Various people will no doubt chime in and tell you the last two suggestions are either excellent wonderful and the worst idea ever. Safe to say I know of networks doing both and the world has not ended. YMMV, some assembly required, batteries not included, actual conditions may affect product performance, do not taunt the happy fun ball, and consult a doctor if your network is up for more than four hours. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From patrick at ianai.net Wed Jan 15 03:35:31 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 14 Jan 2014 22:35:31 -0500 Subject: best practice for advertising peering fabric routes In-Reply-To: <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> Message-ID: <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> On Jan 14, 2014, at 22:20 , Leo Bicknell wrote: > On Jan 14, 2014, at 7:55 PM, Eric A Louie wrote: > >> I have a connection to a peering fabric and I'm not distributing the peering fabric routes into my network. > > There's a two part problem lurking. > > Problem #1 is how you handle your internal routing. Most of the "big boys" will next-hop-self in iBGP all external routes. However depending on the size and configuration of your network there may be advantages to not using next-hop-self, or just putting it in your IGP. Basically, you should be doing the same thing you do for a /30 from a peer or transit provider in your network. There is one thing special about an exchange point though, for security reasons you probably want to add it to your "never accept" routing filter from peers/customers/transit providers. You don't need someone injecting a couple of more specifics to mess with your routing. > > Problem #2 is your customers. If you have customers that may operate default free, and they use one of the traceroute tools that not only finds the route, but then continues to probe it (like MTR, or Visual Traceroute) there can be an issue. The initial traceroute probe may return an IP on the exchange of your peer's router, but then when they subsequently source ICMP Ping to that IP there will be no route in their network, and it will simply never respond. Some call this a feature, some call this a problem. There is also an extremely rare problem where the far end of the peering exchange steps down MTU, and thus PMTU discovery is invoked, but your customers use Unicast RPF. Since the exchange LAN isn't in their table, Unicast RPF may drop the PMTU packet-too-big message, causing a timeout. > > If your customers have a default to you, all is well. However if they have a default to someone else, and take a table from you to selectively override the same problem can occur for any routes they select through you that also traverse the exchange. > > IMHO the best fix for #2 is that the exchange have an ASN, and announce the exchange LAN from that ASN, typically via the route server. You should then peer with the route server to pick up that network. That makes the announcement consistent, and makes it clear who operates that network, and your customers can then access it. Many exchanges do not do this, and then the next best solution might be to originate it from your ASN and announce it to your customers only, with no-export set on the way out. > > Various people will no doubt chime in and tell you the last two suggestions are either excellent wonderful and the worst idea ever. Safe to say I know of networks doing both and the world has not ended. YMMV, some assembly required, batteries not included, actual conditions may affect product performance, do not taunt the happy fun ball, and consult a doctor if your network is up for more than four hours. I've known Leo for .. well, let's just say a long time. And I have great respect for his networking abilities. But I fall into the second camp. As someone who owns & operates an IXP, and is on the board of a couple more, and helped start even more, I'm going to stick to my guns here. As for knowing networks that do both, blah, blah, blah. I know lots of networks that allow spam, don't configure BCP38, have abusable name or NTP servers, etc. and the world has not come to an end. Doesn't mean you should. Lame excuse, Leo, and beneath you to even go there. NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP LAN should not be reachable from any device not directly attached to that LAN. Period. If for no better reason, how about because it is not your prefix, and chances are the IXP does not want you to use the prefix. In fact, I challenge you to find a major IXP route server which is announcing the IXP block. But because this is a teaching list, let's go through the problems Leo mentions. Anyone who steps down MTU on an IXP is far too broken to worry about your customer having RFP and not getting PMTU. Again, I challenge you to find someone doing this today, their network would be close to unusable. As for traceroute .... Seriously? You want to increase breakage on the Internet because it might cause 3 stars in a traceroute? Puh-LEEEZE. Sorry, neither of those pass the sniff test, IMHO. So Just Don't Do It. Setting next-hop-self is not just for "big guys", the crappiest, tiniest router that can do peering at an IXP has the same ability. Use it. Stop putting me and every one of your peers in danger because you are lazy. -- TTFN, patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 535 bytes Desc: Message signed with OpenPGP using GPGMail URL: From blair.trosper at gmail.com Wed Jan 15 03:36:53 2014 From: blair.trosper at gmail.com (Blair Trosper) Date: Tue, 14 Jan 2014 21:36:53 -0600 Subject: gmail.com - 550 error for ipv6/PTR ? In-Reply-To: <52D5E98B.1080607@elcsplace.com> References: <52D5E98B.1080607@elcsplace.com> Message-ID: FWIW I do know there was a MASSIVE failure last night around 0800 UTC with Google's DNS system, and it caused their routing to not only go bat shit insane, but also for the edge nodes that serve their content to return largely 503 errors (service unavailable) for several hours. It wasn't until a few hours ago that the BGP table stabilized. It was a horrific mess last night...not sure if perhaps there's still problems unresolved from that same incident. On Tue, Jan 14, 2014 at 7:51 PM, Ted Cooper wrote: > On 15/01/14 10:06, Brandon Applegate wrote: > > Off-list replies are fine to minimize noise, and if there is an answer > > or any meaningful correlation I will reply on-list. Thanks in advance > > for any info/feedback. > > I have been running into these a lot also and have so far concluded that > it is an error within Google. The PTR/AAAA, SPF and DKIM are all matched > up and tested as working. It also occurring on domains using google apps > to handle their email so it is platform wide. All of the emails are > personal emails, but coming from multiple domains/senders. > > The exact same email will be rejected when sent to any google IPv6 > server for minutes/hours, but 3-4 hours later it will be accepted > without error. > > The fact that it is being hard rejected is really quite annoying and > generating a lot more support work. > > Unfortunately, my only fix at present is to turn off IPv6 delivery for > all google hosted domains as I encounter them. It would be really nice > if it was fixed. > > My theory is that they are failing PTR lookups. > > > > From blair.trosper at gmail.com Wed Jan 15 03:42:39 2014 From: blair.trosper at gmail.com (Blair Trosper) Date: Tue, 14 Jan 2014 21:42:39 -0600 Subject: gmail.com - 550 error for ipv6/PTR ? In-Reply-To: References: <52D5E98B.1080607@elcsplace.com> Message-ID: Possibly related, a lot of 503 errors are starting to show up in the javascript served by Google inside Gmail...reminds me of the issue in the early morning hours (US time)...very similar to what I'm starting to see on the front end. I've not had any IPv6 emails bounce, but I do have some that are MIA from Google Apps. They were sent from one GApps domain to another, but they haven't materialized on the other end...but they also haven't bounced back to me. As a matter of curiosity, I also sent my personal Gmail account email over v6, and it's doing the same thing...either it's delayed or it's going to bounce. The front-end of Gmail is starting to behave weirdly, as well, spitting out bizarre errors like "technical code: undefined", and saying it wasn't able to send a message, but the message going through. There's a fair amount of chatter about this on Twitter, so I know it's not just me. It also thinks it's offline in one tab, when an account in another is perfectly fine. Maybe a DC somewhere is having trouble again? On Tue, Jan 14, 2014 at 8:10 PM, Christopher Morrow wrote: > On Tue, Jan 14, 2014 at 8:51 PM, Ted Cooper > wrote: > > On 15/01/14 10:06, Brandon Applegate wrote: > >> Off-list replies are fine to minimize noise, and if there is an answer > >> or any meaningful correlation I will reply on-list. Thanks in advance > >> for any info/feedback. > > > > brandon, I didn't get your original... but could you ping me off-list > and maybe I can get some data about what it is you're seeing? :) > > > I have been running into these a lot also and have so far concluded that > > it is an error within Google. The PTR/AAAA, SPF and DKIM are all matched > > up and tested as working. It also occurring on domains using google apps > > to handle their email so it is platform wide. All of the emails are > > personal emails, but coming from multiple domains/senders. > > > > The exact same email will be rejected when sent to any google IPv6 > > server for minutes/hours, but 3-4 hours later it will be accepted > > without error. > > > > The fact that it is being hard rejected is really quite annoying and > > generating a lot more support work. > > > > Unfortunately, my only fix at present is to turn off IPv6 delivery for > > all google hosted domains as I encounter them. It would be really nice > > if it was fixed. > > > > My theory is that they are failing PTR lookups. > > > > > > > > From bicknell at ufp.org Wed Jan 15 04:03:07 2014 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 14 Jan 2014 22:03:07 -0600 Subject: best practice for advertising peering fabric routes In-Reply-To: <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> Message-ID: <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> On Jan 14, 2014, at 9:35 PM, Patrick W. Gilmore wrote: > So Just Don't Do It. Setting next-hop-self is not just for "big guys", the crappiest, tiniest router that can do peering at an IXP has the same ability. Use it. Stop putting me and every one of your peers in danger because you are lazy. I'm going to have to disagree here with Patrick, because this is security through obscurity, and that doesn't work well. For some history about why people like Patrick take the position he did, read: http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet Exchange points got attacked, so people yanked them from the routing table hoping to prevent attacks. If you're on this list it should take you all of about 3 seconds to realize the attackers could do a traceroute, and attack the IP one hop on the far side of the exchange for a few dozen providers and still cause all sorts of havoc, or do any of another half dozen things I won't mention to cause problems. The effect would be nearly, if not perfectly identical, since that traffic still has to cross the exchange. I'll point out the MTU step-down issue is real, and it's part of why we can't have 9K MTU exchanges be the default on the Internet, which would really make things better for a significant number of users. I think Patrick is a bit quick to dismiss some of the potential issues. Every link on every router is subject to attack. Exchange point LAN's really aren't special in that regard. If anything the only thing that makes them slightly special is that they may in fact be more oversubscribed than most links. Where a backbone might have a router with 20x10GE, so attackers could try and drive 190GE out a 10GE in theory; an exchange point may have 100 people with 20x10GE coming in. An alternate view that mega-exchange points are massively oversubscribed potential single points of failure, and perhaps network operators should consider that. While a DDOS taking an exchange down for half a day is bad, imagine if there was a more sinister attack, taking out the physical infrastructure of an exchange. That can't be "fixed" with a routing advertisement. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From patrick at ianai.net Wed Jan 15 04:41:42 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 14 Jan 2014 23:41:42 -0500 Subject: best practice for advertising peering fabric routes In-Reply-To: <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> Message-ID: On Jan 14, 2014, at 23:03 , Leo Bicknell wrote: > On Jan 14, 2014, at 9:35 PM, Patrick W. Gilmore wrote: > >> So Just Don't Do It. Setting next-hop-self is not just for "big guys", the crappiest, tiniest router that can do peering at an IXP has the same ability. Use it. Stop putting me and every one of your peers in danger because you are lazy. > > I'm going to have to disagree here with Patrick, because this is security through obscurity, and that doesn't work well. Leo, each of your points below is incorrect. I'm happy to discuss off-list if you'd like. > For some history about why people like Patrick take the position he did, read: http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet > > Exchange points got attacked, so people yanked them from the routing table hoping to prevent attacks. If you're on this list it should take you all of about 3 seconds to realize the attackers could do a traceroute, and attack the IP one hop on the far side of the exchange for a few dozen providers and still cause all sorts of havoc, or do any of another half dozen things I won't mention to cause problems. The effect would be nearly, if not perfectly identical, since that traffic still has to cross the exchange. Let's take just the incident mentioned in the blog post above (which is pretty broken itself, but hey, who said the CEO of CDN had to know anything about networking... ? :). To where would the attacker traceroute -to-? Somewhere inside Cloudflare? Other LINX members? Remember, most of the attack was sourced from networks which were not attached to the LINX. If the source network or the source network's upstreams are not LINX members, there is probably _no_ path that goes through LINX. Even if they are members, lots of networks have alternative paths (other IXPs, private interconnections, etc.). For instance, sources in Germany may well flow over DE-CIX even if there is a peering session at LINX. Etc. There is no single or set of IP addresses that will guarantee even a majority of packets traverse a specific IXP except the IXP LAN. Also, the attack was reflected DNS, so the attacker couldn't actually perform the traceroutes you suggest from each source as he did not control the sources. He _might_ be able to find _some_ of the paths with a lot of sleuthing through route & traceroute servers, but that would make things massively more difficult, as well as massively cut the number of servers he can abuse to the same effect. Both of which are huge wins for the good guys. Pulling the IXP prefix has a enormous benefits and essentially no downside. I know literally hundreds of ISPs large & small who do not carry the IXP prefix, and none have seen any significant issues (most have seen zero, a few get asked about 3 stars, but as I said before, puh-leeeeze). I'm a bit surprised you even tried to bring this up. I know you well enough to know you would have realized all of the above if you had though about it for a while (or just asked). > I'll point out the MTU step-down issue is real, and it's part of why we can't have 9K MTU exchanges be the default on the Internet, which would really make things better for a significant number of users. I think Patrick is a bit quick to dismiss some of the potential issues. MTU step-down is a real issue, and it's real enough whether IXP LANs are in the DFZ or not. Let's solve the overarching problem before doing something which has real, proven harm and leaves the root cause in place. Besides, the two VLAN method already exists in multiple places and it hasn't helped adoption of 9K packets. Unless you are talking about letting some people attach with 1500 MTU and others with 9000 MTU? 'Cause if that's what you meant, then I'm just going to call you loony and ask what you're smoking. > Every link on every router is subject to attack. Exchange point LAN's really aren't special in that regard. If anything the only thing that makes them slightly special is that they may in fact be more oversubscribed than most links. Where a backbone might have a router with 20x10GE, so attackers could try and drive 190GE out a 10GE in theory; an exchange point may have 100 people with 20x10GE coming in. An alternate view that mega-exchange points are massively oversubscribed potential single points of failure, and perhaps network operators should consider that. While a DDOS taking an exchange down for half a day is bad, imagine if there was a more sinister attack, taking out the physical infrastructure of an exchange. That can't be "fixed" with a routing advertisement. IXPs are more special because they are shared. Other links are between you & one other network not hundreds of other networks, some of whom have no relationship with you. If you don't like the rules of IXPs, don't join one. But hooking up to one and deciding "I'm going to carry this prefix" even when told not to is .. well, let's call it bad manners. As for the rest, nothing is a silver bullet. Claiming "this doesn't solve every possible problem so we shouldn't do it" is even more lame than your first excuse that the world hasn't ended. This solves lots of real, provable problems. It is trivial to implement. There is no network which peers at an IXP and cannot implement it. It _has_ been implemented 1000s of times without the harm you mention. In short, it should be done. I repeat: NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP LAN should not be reachable from any device except those directly attached to that LAN. Period. If you join one of my IXPs and I find you are carrying a prefix I own, did not advertise to you, and specifically told you not to carry, I'm going to ask you to stop immediately or face possible disconnection. The other members of my IXP should not be endangered because you don't like to follow the rules. What's more, I get a lot more people thanking me for doing that than complaining about it. -- TTFN, patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 535 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rdobbins at arbor.net Wed Jan 15 06:02:41 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 15 Jan 2014 06:02:41 +0000 Subject: best practice for advertising peering fabric routes In-Reply-To: References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> Message-ID: <166C4D5B-DA53-4D3A-BA9D-633D03E1FD35@arbor.net> On Jan 15, 2014, at 11:41 AM, Patrick W. Gilmore wrote: > I repeat: NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP LAN should not be reachable from any device except those directly attached to that LAN. Period. +1 Again, folks, this isn't theoretical. When the particular attacks cited in this thread were taking place, I was astonished that the IXP infrastructure routes were even being advertised outside of the IXP network, because of these very issues. IXPs are not the problem when it comes to breaking PMTU-D. The problem is largely with enterprise networks, and with 'security' vendors who've propagated the myth that simply blocking all ICMP somehow increases 'security'. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From elouie at yahoo.com Wed Jan 15 06:22:56 2014 From: elouie at yahoo.com (Eric A Louie) Date: Tue, 14 Jan 2014 22:22:56 -0800 (PST) Subject: best practice for advertising peering fabric routes In-Reply-To: References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> Message-ID: <1389766976.17890.YahooMailNeo@web181605.mail.ne1.yahoo.com> Thank you - I will heed the warning.? I want to be a good community member and make sure we're maintaining the agreed-upon practices (I'll re-read/review my agreement with the IXP) So if that is the case, I have to rely on the peering fabric to just return traffic, since the rest of my network (save the directly connected router) will not know about those routes outbound?? And what about my customers who are counting on me routing their office traffic through my network into the peering fabric to their properties?? (I have one specifically who is eventually looking for that capability)? Do I have to provide them some sort of VPN to make that happen across my network to the peering fabric router? >________________________________ > From: Patrick W. Gilmore >To: NANOG list >Sent: Tuesday, January 14, 2014 7:11 PM >Subject: Re: best practice for advertising peering fabric routes > > >Pardon the top post, but I really don't have anything to comment below other than to agree with Chris and say rfc5963 is broken. > >NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP LAN should not be reachable from any device not directly attached to that LAN. Period. > >Doing so endangers your peers & the IX itself. It is on the order of not implementing BCP38, except no one has the (lame, ridiculous, idiotic, and pure cost-shifting BS) excuse that they "can't" do this. > >-- >TTFN, >patrick > > >On Jan 14, 2014, at 21:22 , Christopher Morrow wrote: > >> On Tue, Jan 14, 2014 at 9:09 PM, Cb B wrote: >>> On Jan 14, 2014 6:01 PM, "Eric A Louie" wrote: >>>> >>>> I have a connection to a peering fabric and I'm not distributing the >>> peering fabric routes into my network. >>>> >> >> good plan. >> >>>> I see three options >>>> 1. redistribute into my igp (OSPF) >>>> >>>> 2. configure ibgp and route them within that infrastructure.? All the >>> default routes go out through the POPs so iBGP would see packets destined >>> for the peering fabric and route it that-a-way >>>> >>>> 3. leave it "as is", and let the outbound traffic go out my upstreams and >>> the inbound traffic come back through the peering fabric >>>> >>>> >> >> 4. all peering-fabric routes get next-hop-self on your peering router >> before going into ibgp... >> all the rest of your network sees your local loopback as nexthop and >> things just work. >> >>>> Advantages and disadvantages, pros and cons?? Recommendations? >>> Experiences, good and bad? >>>> >>>> >>>> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the >>> POPs yet.? That's another issue completely from a planning perspective. >>>> >>>> thanks >>>> Eric >>>> >>> >>> http://tools.ietf.org/html/rfc5963 >>> >>> I like no-export >> > > > > > From elouie at yahoo.com Wed Jan 15 06:36:40 2014 From: elouie at yahoo.com (Eric A Louie) Date: Tue, 14 Jan 2014 22:36:40 -0800 (PST) Subject: best practice for advertising peering fabric routes In-Reply-To: <1389766976.17890.YahooMailNeo@web181605.mail.ne1.yahoo.com> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1389766976.17890.YahooMailNeo@web181605.mail.ne1.yahoo.com> Message-ID: <1389767800.94499.YahooMailNeo@web181603.mail.ne1.yahoo.com> Never mind, I just carefully re-read the point.? Right, I'll filter the prefix(es) of the IXP LAN(s) that I'm connected to and not let THAT get out, no reason to advertise it since no traffic ever goes to it.? That still has me asking to how best to advertise the rest of the public prefixes coming from the other fabric members. >________________________________ > From: Eric A Louie >To: Patrick W. Gilmore ; NANOG list >Sent: Tuesday, January 14, 2014 10:22 PM >Subject: Re: best practice for advertising peering fabric routes > > >Thank you - I will heed the warning.? I want to be a good community member and make sure we're maintaining the agreed-upon practices (I'll re-read/review my agreement with the IXP) > > >So if that is the case, I have to rely on the peering fabric to just return traffic, since the rest of my network (save the directly connected router) will not know about those routes outbound?? And what about my customers who are counting on me routing their office traffic through my network into the peering fabric to their properties?? (I have one specifically who is eventually looking for that capability)? Do I have to provide them some sort of VPN to make that happen across my network to the peering fabric router? > > > > >>________________________________ >> From: Patrick W. Gilmore >>To: NANOG list >>Sent: Tuesday, January 14, 2014 7:11 PM >>Subject: Re: best practice for advertising peering fabric routes >> >> >>Pardon the top post, but I really don't have anything to comment below other than to agree with Chris and say rfc5963 is broken. >> >>NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP LAN should not be reachable from any device not directly attached to that LAN. Period. >> >>Doing so endangers your peers & the IX itself. It is on the order of not implementing BCP38, except no one has the (lame, ridiculous, idiotic, and pure cost-shifting BS) excuse that they "can't" do this. >> >>-- >>TTFN, >>patrick >> >> >>On Jan 14, 2014, at 21:22 , Christopher Morrow wrote: >> >>> On Tue, Jan 14, 2014 at 9:09 PM, Cb B wrote: >>>> On Jan 14, 2014 6:01 PM, "Eric A Louie" wrote: >>>>> >>>>> I have a connection to a peering fabric and I'm not distributing the >>>> peering fabric routes into my network. >>>>> >>> >>> good plan. >>> >>>>> I see three options >>>>> 1. redistribute into my igp (OSPF) >>>>> >>>>> 2. configure ibgp and route them within that infrastructure.? All the >>>> default routes go out through the POPs so iBGP would see packets destined >>>> for the peering fabric and route it that-a-way >>>>> >>>>> 3. leave it "as is", and let the outbound traffic go out my upstreams and >>>> the inbound traffic come back through the peering fabric >>>>> >>>>> >>> >>> 4. all peering-fabric routes get next-hop-self on your peering router >>> before going into ibgp... >>> all the rest of your network sees your local loopback as nexthop and >>> things just work. >>> >>>>> Advantages and disadvantages, pros and cons?? Recommendations? >>>> Experiences, good and bad? >>>>> >>>>> >>>>> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the >>>> POPs yet.? That's another issue completely from a planning perspective. >>>>> >>>>> thanks >>>>> Eric >>>>> >>>> >>>> http://tools.ietf.org/html/rfc5963 >>>> >>>> I like no-export >>> >> >> >> >> >> > > > From morrowc.lists at gmail.com Wed Jan 15 06:37:29 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 15 Jan 2014 01:37:29 -0500 Subject: best practice for advertising peering fabric routes In-Reply-To: <1389766976.17890.YahooMailNeo@web181605.mail.ne1.yahoo.com> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1389766976.17890.YahooMailNeo@web181605.mail.ne1.yahoo.com> Message-ID: On Wed, Jan 15, 2014 at 1:22 AM, Eric A Louie wrote: > Thank you - I will heed the warning. I want to be a good community member and make sure we're maintaining the agreed-upon practices (I'll re-read/review my agreement with the IXP) > > > So if that is the case, I have to rely on the peering fabric to just return traffic, since the rest of my network (save the directly connected router) will not know about those routes outbound? And what about my customers who are counting on me routing their office traffic through my network into the peering fabric to their properties? (I have one specifically who is eventually looking for that capability) Do I have to provide them some sort of VPN to make that happen across my network to the peering fabric router? > perhaps I'm confused, but you have sort of this situation: ixp-participants -> ixp -> your-router -> your-network -> your-customer you get routes for ixp-participants from 'ixp' you send to the 'ixp' (and on to 'ixp-participants') routes for 'your-customer' and 'your-network' right? then so long as you send 'your-customer' the routes you learn from 'ixp' (which you set 'next-hop-self' on in ibgp from 'your-router' to 'your-network' (in the ibgp-mesh that you will setup) ... everything just works. All routers behind 'your-router' in 'your-netowrk' see 'ixp-participants' with a next-hop of 'your-router' who still knows 'send to ixp!' for the route(s) in question. > > > >>________________________________ >> From: Patrick W. Gilmore >>To: NANOG list >>Sent: Tuesday, January 14, 2014 7:11 PM >>Subject: Re: best practice for advertising peering fabric routes >> >> >>Pardon the top post, but I really don't have anything to comment below other than to agree with Chris and say rfc5963 is broken. >> >>NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP LAN should not be reachable from any device not directly attached to that LAN. Period. >> >>Doing so endangers your peers & the IX itself. It is on the order of not implementing BCP38, except no one has the (lame, ridiculous, idiotic, and pure cost-shifting BS) excuse that they "can't" do this. >> >>-- >>TTFN, >>patrick >> >> >>On Jan 14, 2014, at 21:22 , Christopher Morrow wrote: >> >>> On Tue, Jan 14, 2014 at 9:09 PM, Cb B wrote: >>>> On Jan 14, 2014 6:01 PM, "Eric A Louie" wrote: >>>>> >>>>> I have a connection to a peering fabric and I'm not distributing the >>>> peering fabric routes into my network. >>>>> >>> >>> good plan. >>> >>>>> I see three options >>>>> 1. redistribute into my igp (OSPF) >>>>> >>>>> 2. configure ibgp and route them within that infrastructure. All the >>>> default routes go out through the POPs so iBGP would see packets destined >>>> for the peering fabric and route it that-a-way >>>>> >>>>> 3. leave it "as is", and let the outbound traffic go out my upstreams and >>>> the inbound traffic come back through the peering fabric >>>>> >>>>> >>> >>> 4. all peering-fabric routes get next-hop-self on your peering router >>> before going into ibgp... >>> all the rest of your network sees your local loopback as nexthop and >>> things just work. >>> >>>>> Advantages and disadvantages, pros and cons? Recommendations? >>>> Experiences, good and bad? >>>>> >>>>> >>>>> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the >>>> POPs yet. That's another issue completely from a planning perspective. >>>>> >>>>> thanks >>>>> Eric >>>>> >>>> >>>> http://tools.ietf.org/html/rfc5963 >>>> >>>> I like no-export >>> >> >> >> >> >> From morrowc.lists at gmail.com Wed Jan 15 06:41:15 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 15 Jan 2014 01:41:15 -0500 Subject: best practice for advertising peering fabric routes In-Reply-To: <1389767800.94499.YahooMailNeo@web181603.mail.ne1.yahoo.com> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1389766976.17890.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1389767800.94499.YahooMailNeo@web181603.mail.ne1.yahoo.com> Message-ID: On Wed, Jan 15, 2014 at 1:36 AM, Eric A Louie wrote: > Never mind, I just carefully re-read the point. Right, I'll filter the prefix(es) of the IXP LAN(s) that I'm connected to and not let THAT get out, no reason to advertise it since no traffic ever goes to it. That still has me asking to how best to advertise the rest of the public prefixes coming from the other fabric members. > on your ibgp peers on 'your-router' you'd have something like: match community set next-hop-self for one vendors view of the situation... and there is a link to: that's worth a read. http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml > > > > >>________________________________ >> From: Eric A Louie >>To: Patrick W. Gilmore ; NANOG list >>Sent: Tuesday, January 14, 2014 10:22 PM >>Subject: Re: best practice for advertising peering fabric routes >> >> >>Thank you - I will heed the warning. I want to be a good community member and make sure we're maintaining the agreed-upon practices (I'll re-read/review my agreement with the IXP) >> >> >>So if that is the case, I have to rely on the peering fabric to just return traffic, since the rest of my network (save the directly connected router) will not know about those routes outbound? And what about my customers who are counting on me routing their office traffic through my network into the peering fabric to their properties? (I have one specifically who is eventually looking for that capability) Do I have to provide them some sort of VPN to make that happen across my network to the peering fabric router? >> >> >> >> >>>________________________________ >>> From: Patrick W. Gilmore >>>To: NANOG list >>>Sent: Tuesday, January 14, 2014 7:11 PM >>>Subject: Re: best practice for advertising peering fabric routes >>> >>> >>>Pardon the top post, but I really don't have anything to comment below other than to agree with Chris and say rfc5963 is broken. >>> >>>NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP LAN should not be reachable from any device not directly attached to that LAN. Period. >>> >>>Doing so endangers your peers & the IX itself. It is on the order of not implementing BCP38, except no one has the (lame, ridiculous, idiotic, and pure cost-shifting BS) excuse that they "can't" do this. >>> >>>-- >>>TTFN, >>>patrick >>> >>> >>>On Jan 14, 2014, at 21:22 , Christopher Morrow wrote: >>> >>>> On Tue, Jan 14, 2014 at 9:09 PM, Cb B wrote: >>>>> On Jan 14, 2014 6:01 PM, "Eric A Louie" wrote: >>>>>> >>>>>> I have a connection to a peering fabric and I'm not distributing the >>>>> peering fabric routes into my network. >>>>>> >>>> >>>> good plan. >>>> >>>>>> I see three options >>>>>> 1. redistribute into my igp (OSPF) >>>>>> >>>>>> 2. configure ibgp and route them within that infrastructure. All the >>>>> default routes go out through the POPs so iBGP would see packets destined >>>>> for the peering fabric and route it that-a-way >>>>>> >>>>>> 3. leave it "as is", and let the outbound traffic go out my upstreams and >>>>> the inbound traffic come back through the peering fabric >>>>>> >>>>>> >>>> >>>> 4. all peering-fabric routes get next-hop-self on your peering router >>>> before going into ibgp... >>>> all the rest of your network sees your local loopback as nexthop and >>>> things just work. >>>> >>>>>> Advantages and disadvantages, pros and cons? Recommendations? >>>>> Experiences, good and bad? >>>>>> >>>>>> >>>>>> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the >>>>> POPs yet. That's another issue completely from a planning perspective. >>>>>> >>>>>> thanks >>>>>> Eric >>>>>> >>>>> >>>>> http://tools.ietf.org/html/rfc5963 >>>>> >>>>> I like no-export >>>> >>> >>> >>> >>> >>> >> >> >> From elouie at yahoo.com Wed Jan 15 06:59:54 2014 From: elouie at yahoo.com (Eric A Louie) Date: Tue, 14 Jan 2014 22:59:54 -0800 (PST) Subject: best practice for advertising peering fabric routes In-Reply-To: References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1389766976.17890.YahooMailNeo@web181605.mail.ne1.yahoo.com> Message-ID: <1389769194.41348.YahooMailNeo@web181601.mail.ne1.yahoo.com> Ok, so the right way to do it is in iBGP.? That pretty much answers the question - don't redistribute those ixp-participant prefixes into my IGP. I have a lot of iBGP homework to do, to make it work with the 5 POPs that are all taking full route feeds.? I tried once and couldn't get the BGP tables working correctly with a full mesh of the 5 routers, so it looks like time to try it again, this time with a route reflector.? >________________________________ > From: Christopher Morrow >To: Eric A Louie >Cc: Patrick W. Gilmore ; NANOG list >Sent: Tuesday, January 14, 2014 10:37 PM >Subject: Re: best practice for advertising peering fabric routes > > >On Wed, Jan 15, 2014 at 1:22 AM, Eric A Louie wrote: >> Thank you - I will heed the warning.? I want to be a good community member and make sure we're maintaining the agreed-upon practices (I'll re-read/review my agreement with the IXP) >> >> >> So if that is the case, I have to rely on the peering fabric to just return traffic, since the rest of my network (save the directly connected router) will not know about those routes outbound?? And what about my customers who are counting on me routing their office traffic through my network into the peering fabric to their properties?? (I have one specifically who is eventually looking for that capability)? Do I have to provide them some sort of VPN to make that happen across my network to the peering fabric router? >> > >perhaps I'm confused, but you have sort of this situation: >? ixp-participants -> ixp -> your-router -> your-network -> your-customer > >you get routes for ixp-participants from 'ixp' >you send to the 'ixp' (and on to 'ixp-participants') routes for >'your-customer' and 'your-network' > >right? > >then so long as you send 'your-customer' the routes you learn from >'ixp' (which you set 'next-hop-self' on in ibgp from 'your-router' to >'your-network' (in the ibgp-mesh that you will setup) ... everything >just works. > >All routers behind 'your-router' in 'your-netowrk' see >'ixp-participants' with a next-hop of 'your-router' who still knows >'send to ixp!' for the route(s) in question. > >> >> >> >>>________________________________ >>> From: Patrick W. Gilmore >>>To: NANOG list >>>Sent: Tuesday, January 14, 2014 7:11 PM >>>Subject: Re: best practice for advertising peering fabric routes >>> >>> >>>Pardon the top post, but I really don't have anything to comment below other than to agree with Chris and say rfc5963 is broken. >>> >>>NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP LAN should not be reachable from any device not directly attached to that LAN. Period. >>> >>>Doing so endangers your peers & the IX itself. It is on the order of not implementing BCP38, except no one has the (lame, ridiculous, idiotic, and pure cost-shifting BS) excuse that they "can't" do this. >>> >>>-- >>>TTFN, >>>patrick >>> >>> >>>On Jan 14, 2014, at 21:22 , Christopher Morrow wrote: >>> >>>> On Tue, Jan 14, 2014 at 9:09 PM, Cb B wrote: >>>>> On Jan 14, 2014 6:01 PM, "Eric A Louie" wrote: >>>>>> >>>>>> I have a connection to a peering fabric and I'm not distributing the >>>>> peering fabric routes into my network. >>>>>> >>>> >>>> good plan. >>>> >>>>>> I see three options >>>>>> 1. redistribute into my igp (OSPF) >>>>>> >>>>>> 2. configure ibgp and route them within that infrastructure.? All the >>>>> default routes go out through the POPs so iBGP would see packets destined >>>>> for the peering fabric and route it that-a-way >>>>>> >>>>>> 3. leave it "as is", and let the outbound traffic go out my upstreams and >>>>> the inbound traffic come back through the peering fabric >>>>>> >>>>>> >>>> >>>> 4. all peering-fabric routes get next-hop-self on your peering router >>>> before going into ibgp... >>>> all the rest of your network sees your local loopback as nexthop and >>>> things just work. >>>> >>>>>> Advantages and disadvantages, pros and cons?? Recommendations? >>>>> Experiences, good and bad? >>>>>> >>>>>> >>>>>> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the >>>>> POPs yet.? That's another issue completely from a planning perspective. >>>>>> >>>>>> thanks >>>>>> Eric >>>>>> >>>>> >>>>> http://tools.ietf.org/html/rfc5963 >>>>> >>>>> I like no-export >>>> >>> >>> >>> >>> >>> > > > From laurent at guerby.net Wed Jan 15 07:09:01 2014 From: laurent at guerby.net (Laurent GUERBY) Date: Wed, 15 Jan 2014 08:09:01 +0100 Subject: gmail.com - 550 error for ipv6/PTR ? In-Reply-To: References: Message-ID: <1389769741.1427.8.camel@pc2> On Tue, 2014-01-14 at 19:06 -0500, Brandon Applegate wrote: > Just saw this in a message tonight. No idea if this is a transient error > or not. Got one too for AS197422 at "Tue, 14 Jan 2014 23:59:01 +0100", resent the mail at "Wed, 15 Jan 2014 00:03:12 +0100" and it worked so probably transient. Laurent host gmail-smtp-in.l.google.com[2a00:1450:400c:c05::1a] said: 550-5.7.1 [2a01:6600:80xxx] Our system has detected that this message 550-5.7.1 does not meet IPv6 sending guidelines regarding PTR records and 550-5.7.1 authentication. Please review 550-5.7.1 https://support.google.com/mail/?p=ipv6_authentication_error for more 550 5.7.1 information. hg12si1854476wib.39 - gsmtp (in reply to end of DATA command) Arrival-Date: Tue, 14 Jan 2014 22:59:01 +0000 (UTC) Date: Tue, 14 Jan 2014 23:59:01 +0100 > --- > host gmail-smtp-in.l.google.com > [gmail-smtp-in.l.google.com][2607:f8b0:4002:c01::1a] > said: 550-5.7.1 [2607:ff70:11::11] Our system has detected that this > message does not 550-5.7.1 meet IPv6 sending guidelines regarding PTR > records and authentication 550-5.7.1 . Please review 550-5.7.1 > https://support.google.com/mail/?p=ipv6_authentication_error > [support.google.com] for more 550 > 5.7.1 information. t26si2290895yhl.255 - gsmtp (in reply to end of DATA > command) > --- > That URL's relevant section says: > > Additional guidelines for IPv6 > > The sending IP must have a PTR record (i.e., a reverse DNS of the sending > IP) and it should match the IP obtained via the forward DNS resolution of > the hostname specified in the PTR record. Otherwise, mail will be marked > as spam or possibly rejected. > > The sending domain should pass either SPF check or DKIM check. Otherwise, > mail might be marked as spam. > --- > > I have both of these (PTR's RR has matching AAAA, and I have SPF (but not > DKIM)). > > I'm guessing that something on google's side is misinterpreting some data > or other busted logic. I meet all the requirements laid out, and have > been sending mail to gmail addresses (via ipv6) since $forever. > > Off-list replies are fine to minimize noise, and if there is an answer or > any meaningful correlation I will reply on-list. Thanks in advance for > any info/feedback. > > -- > Brandon Applegate - CCIE 10273 > PGP Key fingerprint: > 830B 4802 1DD4 F4F9 63FE B966 C0A7 189E 9EC0 3A74 > "SH1-0151. This is the serial number, of our orbital gun." From m.hallgren at free.fr Wed Jan 15 07:57:32 2014 From: m.hallgren at free.fr (Michael Hallgren) Date: Wed, 15 Jan 2014 08:57:32 +0100 Subject: best practice for advertising peering fabric routes In-Reply-To: <1389769194.41348.YahooMailNeo@web181601.mail.ne1.yahoo.com> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1389766976.17890.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1389769194.41348.YahooMailNeo@web181601.mail.ne1.yahoo.com> Message-ID: <52D63F6C.7010907@free.fr> Le 15/01/2014 07:59, Eric A Louie a ?crit : > Ok, so the right way to do it is in iBGP. That pretty much answers the question - don't redistribute those ixp-participant prefixes into my IGP. Yes, using next-hop self (rather than importing IXP routes) as pointed out earlier in this thread. > > I have a lot of iBGP homework to do, to make it work with the 5 POPs that are all taking full route feeds. I tried once and couldn't get the BGP tables working correctly with a full mesh of the 5 routers, so it looks like time to try it again, this time with a route reflector. > I don't think you need route-reflection in a 5 node iBGP. What do you mean by "couldn't get the BGP tables working correctly"? Cheers, mh > > > >> ________________________________ >> From: Christopher Morrow >> To: Eric A Louie >> Cc: Patrick W. Gilmore ; NANOG list >> Sent: Tuesday, January 14, 2014 10:37 PM >> Subject: Re: best practice for advertising peering fabric routes >> >> >> On Wed, Jan 15, 2014 at 1:22 AM, Eric A Louie wrote: >>> Thank you - I will heed the warning. I want to be a good community member and make sure we're maintaining the agreed-upon practices (I'll re-read/review my agreement with the IXP) >>> >>> >>> So if that is the case, I have to rely on the peering fabric to just return traffic, since the rest of my network (save the directly connected router) will not know about those routes outbound? And what about my customers who are counting on me routing their office traffic through my network into the peering fabric to their properties? (I have one specifically who is eventually looking for that capability) Do I have to provide them some sort of VPN to make that happen across my network to the peering fabric router? >>> >> perhaps I'm confused, but you have sort of this situation: >> ixp-participants -> ixp -> your-router -> your-network -> your-customer >> >> you get routes for ixp-participants from 'ixp' >> you send to the 'ixp' (and on to 'ixp-participants') routes for >> 'your-customer' and 'your-network' >> >> right? >> >> then so long as you send 'your-customer' the routes you learn from >> 'ixp' (which you set 'next-hop-self' on in ibgp from 'your-router' to >> 'your-network' (in the ibgp-mesh that you will setup) ... everything >> just works. >> >> All routers behind 'your-router' in 'your-netowrk' see >> 'ixp-participants' with a next-hop of 'your-router' who still knows >> 'send to ixp!' for the route(s) in question. >> >>> >>> >>>> ________________________________ >>>> From: Patrick W. Gilmore >>>> To: NANOG list >>>> Sent: Tuesday, January 14, 2014 7:11 PM >>>> Subject: Re: best practice for advertising peering fabric routes >>>> >>>> >>>> Pardon the top post, but I really don't have anything to comment below other than to agree with Chris and say rfc5963 is broken. >>>> >>>> NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP LAN should not be reachable from any device not directly attached to that LAN. Period. >>>> >>>> Doing so endangers your peers & the IX itself. It is on the order of not implementing BCP38, except no one has the (lame, ridiculous, idiotic, and pure cost-shifting BS) excuse that they "can't" do this. >>>> >>>> -- >>>> TTFN, >>>> patrick >>>> >>>> >>>> On Jan 14, 2014, at 21:22 , Christopher Morrow wrote: >>>> >>>>> On Tue, Jan 14, 2014 at 9:09 PM, Cb B wrote: >>>>>> On Jan 14, 2014 6:01 PM, "Eric A Louie" wrote: >>>>>>> I have a connection to a peering fabric and I'm not distributing the >>>>>> peering fabric routes into my network. >>>>> good plan. >>>>> >>>>>>> I see three options >>>>>>> 1. redistribute into my igp (OSPF) >>>>>>> >>>>>>> 2. configure ibgp and route them within that infrastructure. All the >>>>>> default routes go out through the POPs so iBGP would see packets destined >>>>>> for the peering fabric and route it that-a-way >>>>>>> 3. leave it "as is", and let the outbound traffic go out my upstreams and >>>>>> the inbound traffic come back through the peering fabric >>>>>>> >>>>> 4. all peering-fabric routes get next-hop-self on your peering router >>>>> before going into ibgp... >>>>> all the rest of your network sees your local loopback as nexthop and >>>>> things just work. >>>>> >>>>>>> Advantages and disadvantages, pros and cons? Recommendations? >>>>>> Experiences, good and bad? >>>>>>> >>>>>>> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the >>>>>> POPs yet. That's another issue completely from a planning perspective. >>>>>>> thanks >>>>>>> Eric >>>>>>> >>>>>> http://tools.ietf.org/html/rfc5963 >>>>>> >>>>>> I like no-export >>>> >>>> >>>> >>>> >> >> From hmurray at megapathdsl.net Wed Jan 15 08:37:19 2014 From: hmurray at megapathdsl.net (Hal Murray) Date: Wed, 15 Jan 2014 00:37:19 -0800 Subject: [VoiceOps] (cross post) VoIP heat charts... Message-ID: <20140115083719.4571D406061@ip-64-139-1-69.sjc.megapath.net> > http://www.nanpa.com/nanp1/allutlzd.zip lists NPANXX and Ratecentre. How does number portability interact with this? What fraction of numbers have been ported? (Where should I look/google to find the answer?) -- These are my opinions. I hate spam. From mark.tinka at seacom.mu Wed Jan 15 12:55:15 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 15 Jan 2014 14:55:15 +0200 Subject: best practice for advertising peering fabric routes In-Reply-To: <52D63F6C.7010907@free.fr> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1389769194.41348.YahooMailNeo@web181601.mail.ne1.yahoo.com> <52D63F6C.7010907@free.fr> Message-ID: <201401151455.21256.mark.tinka@seacom.mu> On Wednesday, January 15, 2014 09:57:32 AM Michael Hallgren wrote: > I don't think you need route-reflection in a 5 node iBGP. I'm for doing it now and not worrying about it later. Also, don't originate your routes from your peering router Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From bicknell at ufp.org Wed Jan 15 14:18:13 2014 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 15 Jan 2014 08:18:13 -0600 Subject: best practice for advertising peering fabric routes In-Reply-To: <166C4D5B-DA53-4D3A-BA9D-633D03E1FD35@arbor.net> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <166C4D5B-DA53-4D3A-BA9D-633D03E1FD35@arbor.net> Message-ID: <818A55E6-40E6-4106-B012-8F70CB16676E@ufp.org> On Jan 15, 2014, at 12:02 AM, "Dobbins, Roland" wrote: > Again, folks, this isn't theoretical. When the particular attacks cited in this thread were taking place, I was astonished that the IXP infrastructure routes were even being advertised outside of the IXP network, because of these very issues. I know a lot of people push next-hop-self, and if you're a large ISP with thousands of BGP customers is pretty much required to scale. However, a good engineer would know there are drawbacks to next-hop-self, in particular it slows convergence in a number of situations. There are networks where fast convergence is more important than route scaling, and thus the traditional design of BGP next-hops being edge interfaces, and edge interfaces in the IGP performs better. By attempting to force IX participants to not put the route in IGP, those IX participants are collectively deciding on a slower converging network for everyone. I don't like a world where connecting to an exchange point forces a particular network design on participants. > IXPs are not the problem when it comes to breaking PMTU-D. The problem is largely with enterprise networks, and with 'security' vendors who've propagated the myth that simply blocking all ICMP somehow increases 'security'. That's some circular reasoning. Networks won't 9K peer at exchange points for a number of reasons, including PMTU-D discovery issues. Since there are virtual no 9K peering at exchange points, PMTU-D is a non-issue. Maybe if IXP design didn't break PMTU-D it would help attract more 9K peers, or there might even be a future where 9K peering was required? This whole problem smacks to me of exchange points that are "too big to fail". Since some of these exchanges are so big, everyone else must bend to their needs. I think the world would be a better place if some of these were broken up into smaller exchanges and they imposed less restrictions on their participants. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rdobbins at arbor.net Wed Jan 15 14:49:10 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 15 Jan 2014 14:49:10 +0000 Subject: best practice for advertising peering fabric routes In-Reply-To: <818A55E6-40E6-4106-B012-8F70CB16676E@ufp.org> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <166C4D5B-DA53-4D3A-BA9D-633D03E1FD35@arbor.net> <818A55E6-40E6-4106-B012-8F70CB16676E@ufp.org> Message-ID: <74DBED92-F940-494F-8321-7CA7F4DB265D@arbor.net> On Jan 15, 2014, at 9:18 PM, Leo Bicknell wrote: > However, a good engineer would know there are drawbacks to next-hop-self, in particular it slows convergence in a number of situations. There are networks where fast convergence is more important than route scaling, and thus the traditional design of BGP next-hops being edge interfaces, and edge interfaces in the IGP performs better. A good engineer also knows that there are huge drawbacks to having a peer's network infrastructure DDoSed, routes flapping, core bandwidth consumed by tens and hundreds of gb/sec of attack traffic, et. al., too. ;> > By attempting to force IX participants to not put the route in IGP, those IX participants are collectively deciding on a slower converging network for everyone. I don't like a world where connecting to an exchange point forces a particular network design on participants. Concur. But that's the world we live in, unfortunately. It's just another example of the huge, concentric nature of the collateral damage arising from DDoS attacks, both from the attacks themselves, and from the compromises folks have to make in order to increase resilience against such attacks. > That's some circular reasoning. Not really. What I'm saying is that since PMTU-D is already broken on so many endpoint networks - i.e., where traffic originates and where it terminates - that any issues arising from PMTU-D irregularities in IXP networks are trivial by comparison. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From saku at ytti.fi Wed Jan 15 14:57:26 2014 From: saku at ytti.fi (Saku Ytti) Date: Wed, 15 Jan 2014 16:57:26 +0200 Subject: best practice for advertising peering fabric routes In-Reply-To: <818A55E6-40E6-4106-B012-8F70CB16676E@ufp.org> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <166C4D5B-DA53-4D3A-BA9D-633D03E1FD35@arbor.net> <818A55E6-40E6-4106-B012-8F70CB16676E@ufp.org> Message-ID: <20140115145726.GA1299@pob.ytti.fi> On (2014-01-15 08:18 -0600), Leo Bicknell wrote: > I know a lot of people push next-hop-self, and if you're a large ISP with thousands of BGP customers is pretty much required to scale. It's actually the polar opposite. If you are small, there are no compelling reasons to put IXP in IGP. If you are large, you may wish to have different IGP metric to two egress points in same peering router. In which case you should at very least have IP ACL in IXP interface which only allows LAN2LAN. -- ++ytti From bicknell at ufp.org Wed Jan 15 15:31:07 2014 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 15 Jan 2014 09:31:07 -0600 Subject: best practice for advertising peering fabric routes In-Reply-To: <74DBED92-F940-494F-8321-7CA7F4DB265D@arbor.net> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <166C4D5B-DA53-4D3A-BA9D-633D03E1FD35@arbor.net> <818A55E6-40E6-4106-B012-8F70CB16676E@ufp.org> <74DBED92-F940-494F-8321-7CA7F4DB265D@arbor.net> Message-ID: <3F0CA014-2607-403A-B05C-DD39D08A0683@ufp.org> On Jan 15, 2014, at 8:49 AM, "Dobbins, Roland" wrote: > Not really. What I'm saying is that since PMTU-D is already broken on so many endpoint networks - i.e., where traffic originates and where it terminates - that any issues arising from PMTU-D irregularities in IXP networks are trivial by comparison. I think we're looking at two different aspects of the same issue. I believe you're coming at it from a 'for all users of the Internet, what's the chance they have connectivity that does not break PMTU-D.' That's an important group to study, particularly for those DSL users still left with < 1500 byte MTU's. And you're right, for those users IXP's are the least of their worries, mostly it's content-side poor networking, like load balancers and firewalls that don't work correctly. I am approaching it from a different perspective, 'where is PMTU-D broken for people who want to use 1500-9K frames end to end?' I'm the network guy who wants to buy transit in the US, and transit in Germany and run a tunnel of 1500 byte packets end to end, necessitating a ~1540 byte packet. Finding transit providers who will configure jumbo frames is trivial these days, and most backbones are jumbo frame clean (at least to 4470, but many to 9K). There's probably about a 25% chance private peelings are also jumbo clean. Pretty much the only thing broken for this use case is IXP's. Only a few have a second VLAN for 9K peerings, and most participants don't use it for a host of reasons, including PMTU-D problems. I'm an oddball. I think MPLS VPN's are a terrible idea for the consumer, locking them into a single provider in the vast majority of cases. Consumers would be better served by having a tunnel box (IPSec maybe?) at their edge and running there own tunnel over IP provider-independently, if they could get > 1500B MTU at the edge, and move those packets end to end. While I've always thought that, in the post-Snowden world I think I seem a little less crazy, rather than relying on your provider to keep your "VPN" traffic secret, customers should be encrypting it in a device they own. But hey, I get why ISP's don't want to offer 9K MTU clean paths end to end. Customers could then buy a VPN appliance and manage their own VPN's with no vendor lock-in. MPLS VPN revenues would tumble, and customers would move more fluidly between providers. That's terrible if you're an ISP. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rdobbins at arbor.net Wed Jan 15 15:37:43 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 15 Jan 2014 15:37:43 +0000 Subject: best practice for advertising peering fabric routes In-Reply-To: <3F0CA014-2607-403A-B05C-DD39D08A0683@ufp.org> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <166C4D5B-DA53-4D3A-BA9D-633D03E1FD35@arbor.net> <818A55E6-40E6-4106-B012-8F70CB16676E@ufp.org> <74DBED92-F940-494F-8321-7CA7F4DB265D@arbor.net> <3F0CA014-2607-403A-B05C-DD39D08A0683@ufp.org> Message-ID: <38C51356-6825-4D57-B29F-E03F177B687F@arbor.net> On Jan 15, 2014, at 10:31 PM, Leo Bicknell wrote: > I am approaching it from a different perspective, 'where is PMTU-D broken for people who want to use 1500-9K frames end to end?' I understand that perspective, absolutely. But what I'm saying is that that whether or not they want to use jumbo frames for Internet traffic, it doesn't matter, because PMTU-D is likely to be broken either at the place where the traffic is initiated, the place where the traffic is received, or both - so any nonsense in the middle, especially on IXP networks in particular, isn't really a significant issue in and of itself. If we could get things optimized and remediated to the point where potential PMTU-D breakage in IXP networks were a significant issue of iteself, the Internet would be much improved. But I don't see any likelihood of that happening anytime soon. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bill at herrin.us Wed Jan 15 15:44:54 2014 From: bill at herrin.us (William Herrin) Date: Wed, 15 Jan 2014 10:44:54 -0500 Subject: best practice for advertising peering fabric routes In-Reply-To: References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> Message-ID: On Tue, Jan 14, 2014 at 10:11 PM, Patrick W. Gilmore wrote: > NEVER EVER EVER put an IX prefix into BGP, IGP, or even > static route. An IXP LAN should not be reachable from any > device not directly attached to that LAN. Period. > > Doing so endangers your peers & the IX itself. It is on the order > of not implementing BCP38, except no one has the (lame, > ridiculous, idiotic, and pure cost-shifting BS) excuse that they > "can't" do this. Hi Patrick, I have to disagree with you. If it appears in a traceroute to somewhere else, I'd like to be able to ping and traceroute directly to it. When I can't, that impairs my ability to troubleshoot the all too common can't-get-there-from-here problems. The more you hide the infrastructure, the more intractable problems become for your customers. The IXP LAN should be reachable from every device on the ASes which connect to it, not just the immediate router. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bicknell at ufp.org Wed Jan 15 15:52:43 2014 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 15 Jan 2014 09:52:43 -0600 Subject: best practice for advertising peering fabric routes In-Reply-To: <38C51356-6825-4D57-B29F-E03F177B687F@arbor.net> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <166C4D5B-DA53-4D3A-BA9D-633D03E1FD35@arbor.net> <818A55E6-40E6-4106-B012-8F70CB16676E@ufp.org> <74DBED92-F940-494F-8321-7CA7F4DB265D@arbor.net> <3F0CA014-2607-403A-B05C-DD39D08A0683@ufp.org> <38C51356-6825-4D57-B29F-E03F177B687F@arbor.net> Message-ID: <90C97AD3-6638-44A4-A647-196F7E044283@ufp.org> On Jan 15, 2014, at 9:37 AM, "Dobbins, Roland" wrote: > But what I'm saying is that that whether or not they want to use jumbo frames for Internet traffic, it doesn't matter, because PMTU-D is likely to be broken either at the place where the traffic is initiated, the place where the traffic is received, or both - so any nonsense in the middle, especially on IXP networks in particular, isn't really a significant issue in and of itself. Your assertion does not match my deployment experience. When I have deployed endpoints that have working PMTU-D, I have 99.999% success with the ISP's in the middle having working PMTU-D. It even works fine for 9K providers connected to 1500B exchange points, because the packet-too-big typically originates from the input side of the router (the backbone link to the IXP router). Indeed, the only place I've seen it broken is where the ISP 9K peers at an exchange, and the "far end" ISP runs a < 9K backbone (like 4470), so the far end IXP-router does the packet-to-big, and originates it from the exchange LAN, which because it's no longer in the table fails to past uRPF. (Business class) ISP's don't break PMTU-D, end users break it with the equipment they connect. So a smart user connecting equipment that is properly configured should be able to expect it to work properly. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From patrick at ianai.net Wed Jan 15 15:57:02 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 15 Jan 2014 10:57:02 -0500 Subject: best practice for advertising peering fabric routes In-Reply-To: References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> Message-ID: On Jan 15, 2014, at 10:44 , William Herrin wrote: > On Tue, Jan 14, 2014 at 10:11 PM, Patrick W. Gilmore wrote: >> NEVER EVER EVER put an IX prefix into BGP, IGP, or even >> static route. An IXP LAN should not be reachable from any >> device not directly attached to that LAN. Period. >> >> Doing so endangers your peers & the IX itself. It is on the order >> of not implementing BCP38, except no one has the (lame, >> ridiculous, idiotic, and pure cost-shifting BS) excuse that they >> "can't" do this. > > Hi Patrick, > > I have to disagree with you. If it appears in a traceroute to > somewhere else, I'd like to be able to ping and traceroute directly to > it. When I can't, that impairs my ability to troubleshoot the all too > common can't-get-there-from-here problems. The more you hide the > infrastructure, the more intractable problems become for your > customers. > > The IXP LAN should be reachable from every device on the ASes which > connect to it, not just the immediate router. We disagree. Plus, you really can't type "ping" on the router connected to the IXP? _If_ you can guarantee your network has zero bots, abusable [DNS|NTP|etc.] servers, all your downstreams are perfectly clean, etc., etc., then maybe I could see you carrying it in your IGP. As I know 100% of ISPs (to at least one decimal place) cannot make such a guarantee, then doing so puts the IXP and all other members - whether peers of yours or not - at risk. Putting others at risk because you are lazy or because it makes your life easier is .. I believe I called it bad manners before. But let's take the philosophical out of this. The prefix in question is owned by the IXP. I said in an earlier post that if you carry a prefix I own, did not announce to you, and make it very clear I specifically do not want you to carry, I will ask you to stop or face possible disconnection. You may claim convergence (a bit of BS), troubleshooting (non-issue, IMO), or even "but I waaaaaaaaaaaant to!!1!1!" (whatever). Doesn't matter. That's not your prefix, you were not given it and told not to carry it, so Do Not Carry It. Ask your IXP if they mind whether you carry the prefix. See what they say. -- TTFN, patrick From rdobbins at arbor.net Wed Jan 15 15:58:12 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 15 Jan 2014 15:58:12 +0000 Subject: best practice for advertising peering fabric routes In-Reply-To: <90C97AD3-6638-44A4-A647-196F7E044283@ufp.org> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <166C4D5B-DA53-4D3A-BA9D-633D03E1FD35@arbor.net> <818A55E6-40E6-4106-B012-8F70CB16676E@ufp.org> <74DBED92-F940-494F-8321-7CA7F4DB265D@arbor.net> <3F0CA014-2607-403A-B05C-DD39D08A0683@ufp.org> <38C51356-6825-4D57-B29F-E03F177B687F@arbor.net> <90C97AD3-6638-44A4-A647-196F7E044283@ufp.org> Message-ID: On Jan 15, 2014, at 10:52 PM, Leo Bicknell wrote: > (Business class) ISP's don't break PMTU-D, end users break it with the equipment they connect. Concur 100%. That's my point. > So a smart user connecting equipment that is properly configured should be able to expect it to work properly. In my deployment experience, many (most?) end-user organization break PMTU-D to/through their LANs outside of their IDCs, much less to the Internet, for themselves, and for everyone who wishes to communicate with them across the Internet. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From David.Siegel at Level3.com Wed Jan 15 16:03:53 2014 From: David.Siegel at Level3.com (Siegel, David) Date: Wed, 15 Jan 2014 16:03:53 +0000 Subject: best practice for advertising peering fabric routes In-Reply-To: References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> Message-ID: <970945E55BFD8C4EA4CAD74B647A9DC05C0C7B7C@USIDCWVEMBX10.corp.global.level3.com> UUnet once advertised the /24 for MAE-East to me (well, Net99), and because I also had it in my IGP, my network was using UUnet's backbone for west-to-east coast traffic for a couple of days until I noticed and fixed it (with next-hop-self). I agree 100% with Patrick and others on this point. No good can come from propagating IXP address space any further than is absolutely necessary. Best not to propagate it at all. Dave -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: Wednesday, January 15, 2014 8:57 AM To: NANOG list Subject: Re: best practice for advertising peering fabric routes On Jan 15, 2014, at 10:44 , William Herrin wrote: > On Tue, Jan 14, 2014 at 10:11 PM, Patrick W. Gilmore wrote: >> NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. >> An IXP LAN should not be reachable from any device not directly >> attached to that LAN. Period. >> >> Doing so endangers your peers & the IX itself. It is on the order of >> not implementing BCP38, except no one has the (lame, ridiculous, >> idiotic, and pure cost-shifting BS) excuse that they "can't" do this. > > Hi Patrick, > > I have to disagree with you. If it appears in a traceroute to > somewhere else, I'd like to be able to ping and traceroute directly to > it. When I can't, that impairs my ability to troubleshoot the all too > common can't-get-there-from-here problems. The more you hide the > infrastructure, the more intractable problems become for your > customers. > > The IXP LAN should be reachable from every device on the ASes which > connect to it, not just the immediate router. We disagree. Plus, you really can't type "ping" on the router connected to the IXP? _If_ you can guarantee your network has zero bots, abusable [DNS|NTP|etc.] servers, all your downstreams are perfectly clean, etc., etc., then maybe I could see you carrying it in your IGP. As I know 100% of ISPs (to at least one decimal place) cannot make such a guarantee, then doing so puts the IXP and all other members - whether peers of yours or not - at risk. Putting others at risk because you are lazy or because it makes your life easier is .. I believe I called it bad manners before. But let's take the philosophical out of this. The prefix in question is owned by the IXP. I said in an earlier post that if you carry a prefix I own, did not announce to you, and make it very clear I specifically do not want you to carry, I will ask you to stop or face possible disconnection. You may claim convergence (a bit of BS), troubleshooting (non-issue, IMO), or even "but I waaaaaaaaaaaant to!!1!1!" (whatever). Doesn't matter. That's not your prefix, you were not given it and told not to carry it, so Do Not Carry It. Ask your IXP if they mind whether you carry the prefix. See what they say. -- TTFN, patrick From bill at herrin.us Wed Jan 15 16:43:11 2014 From: bill at herrin.us (William Herrin) Date: Wed, 15 Jan 2014 11:43:11 -0500 Subject: best practice for advertising peering fabric routes In-Reply-To: References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> Message-ID: On Wed, Jan 15, 2014 at 10:57 AM, Patrick W. Gilmore wrote: > On Jan 15, 2014, at 10:44 , William Herrin wrote: >> I have to disagree with you. If it appears in a traceroute to >> somewhere else, I'd like to be able to ping and traceroute directly to >> it. When I can't, that impairs my ability to troubleshoot the all too >> common can't-get-there-from-here problems. The more you hide the >> infrastructure, the more intractable problems become for your >> customers. >> >> The IXP LAN should be reachable from every device on the ASes which >> connect to it, not just the immediate router. > > We disagree. > > Plus, you really can't type "ping" on the router connected to the IXP? Not when I'm the downstream customer, no. It's jolly good that *you* can test, but before the rest of us can get through the layers of support which insulate you, we have to be able to convincingly test too. > As I know 100% of ISPs (to at least one decimal place) cannot > make such a guarantee, then doing so puts the IXP and all other > members - whether peers of yours or not - at risk. Putting others > at risk because you are lazy or because it makes your life easier > is .. I believe I called it bad manners before. That makes no sense. The IXP is at no more or less risk from your customers than any other connection you have for Internet carriage. Risk which you are responsible for managing either way. > I said in an earlier post that if you carry a prefix I own, > did not announce to you, and make it very clear I > specifically do not want you to carry, I will ask you to > stop or face possible disconnection. [...] That's not your prefix, > you were not given it and told not to carry it, so Do Not Carry It. Well yes, of course. If you participate in an IXP you follow the rules of the IXP. I respectfully question the wisdom of such a rule and the IXPs I deal with only ask that you not announce the IXP prefix externally. But it's not OK to unilaterally break the IXP's rules, however poorly conceived. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nanog at shankland.org Wed Jan 15 17:04:18 2014 From: nanog at shankland.org (Jim Shankland) Date: Wed, 15 Jan 2014 09:04:18 -0800 Subject: best practice for advertising peering fabric routes In-Reply-To: References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> Message-ID: <52D6BF92.7070400@shankland.org> On 1/14/14, 8:41 PM, Patrick W. Gilmore wrote: > I repeat: NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP LAN should not be reachable from any device except those directly attached to that LAN. Period. > > So ... RFC1918 addresses for the IXP fabric, then? (Half kidding, but still ....) Jim Shankland From jabley at hopcount.ca Wed Jan 15 17:35:51 2014 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 15 Jan 2014 12:35:51 -0500 Subject: best practice for advertising peering fabric routes In-Reply-To: <52D6BF92.7070400@shankland.org> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <52D6BF92.7070400@shankland.org> Message-ID: <21B4A54F-452A-4C97-B3B3-61181132760D@hopcount.ca> On 2014-01-15, at 12:04, Jim Shankland wrote: > On 1/14/14, 8:41 PM, Patrick W. Gilmore wrote: >> I repeat: NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP LAN should not be reachable from any device except those directly attached to that LAN. Period. > > So ... RFC1918 addresses for the IXP fabric, then? I've heard apparently non-drunk people suggest IPv6 link-local addresses as BGP endpoints across exchanges, too. > (Half kidding, but still ....) RFC 6752. One observation on this thread: some networks have customers who react badly to unusual things seen in traceroute. Sometimes the margin on an individual customer is low enough that one support call displaces any profit you were going to make off them this month. It's understandable to me that such network operators would choose to carry IXP routes internally in order to avoid that potential support burden. I don't pretend to have any universal good/bad answer to the original question, though. I don't think the world is that simple. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From hardenrm at uchicago.edu Wed Jan 15 17:42:47 2014 From: hardenrm at uchicago.edu (Ryan Harden) Date: Wed, 15 Jan 2014 17:42:47 +0000 Subject: Amazon AWS Engineer Message-ID: <00792A5A-6986-4828-ADD7-CBF8B7CDE50F@uchicago.edu> Could an Amazon AWS Engineer contact me off list. We're seeing what is perceived to be performance issues and I'd like to discuss what the expected performance should be. The Amazon AWS support channels don't appear to be meant for network type question. Thanks /Ryan Ryan Harden Senior Network Engineer University of Chicago - AS160 P: 773-834-5441 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From niels=nanog at bakker.net Wed Jan 15 17:54:02 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 15 Jan 2014 18:54:02 +0100 Subject: best practice for advertising peering fabric routes In-Reply-To: <52D6BF92.7070400@shankland.org> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <52D6BF92.7070400@shankland.org> Message-ID: <20140115175402.GB67472@burnout.tpb.net> * nanog at shankland.org (Jim Shankland) [Wed 15 Jan 2014, 18:04 CET]: >So ... RFC1918 addresses for the IXP fabric, then? > >(Half kidding, but still ....) They need to be globally unique. -- Niels. -- "It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account." -- roy edroso, alicublog.blogspot.com From niels=nanog at bakker.net Wed Jan 15 17:56:27 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 15 Jan 2014 18:56:27 +0100 Subject: best practice for advertising peering fabric routes In-Reply-To: <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> Message-ID: <20140115175627.GC67472@burnout.tpb.net> * patrick at ianai.net (Patrick W. Gilmore) [Wed 15 Jan 2014, 04:36 CET]: [..] >NEVER EVER EVER put an IX prefix into BGP, IGP, or even static >route. An IXP LAN should not be reachable from any device not >directly attached to that LAN. Period. This is correct, and protects both your (ISP) infrastructure and the IXP's. All major European IXPs revisited their policy after the giant DDoS attack on CloudFlare, and the above was pretty much the outcome. -- Niels. -- "It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account." -- roy edroso, alicublog.blogspot.com From nanog at bitfreak.org Wed Jan 15 18:05:50 2014 From: nanog at bitfreak.org (Darren Pilgrim) Date: Wed, 15 Jan 2014 10:05:50 -0800 Subject: gmail.com - 550 error for ipv6/PTR ? In-Reply-To: References: Message-ID: <52D6CDFE.3090401@bitfreak.org> On 1/14/2014 4:06 PM, Brandon Applegate wrote: > Just saw this in a message tonight. No idea if this is a transient error > or not. > > --- > host gmail-smtp-in.l.google.com > [gmail-smtp-in.l.google.com][2607:f8b0:4002:c01::1a] > said: 550-5.7.1 [2607:ff70:11::11] Our system has detected that this > message does not 550-5.7.1 meet IPv6 sending guidelines regarding PTR > records and authentication 550-5.7.1 . Please review 550-5.7.1 > https://support.google.com/mail/?p=ipv6_authentication_error > [support.google.com] for more 550 > 5.7.1 information. t26si2290895yhl.255 - gsmtp (in reply to end of DATA > command) I saw a number of these as well but in my case the bracketed IP addresses were malformed. For example: host gmail-smtp-in.l.google.com[2607:f8b0:4002:c01::1a] said: 550-5.7.1 [2607:fc50:1000:1f00::2 16] Our system has detected that this 550-5.7.1 message does not meet IPv6 sending guidelines... From fmartin at linkedin.com Wed Jan 15 18:14:16 2014 From: fmartin at linkedin.com (Franck Martin) Date: Wed, 15 Jan 2014 18:14:16 +0000 Subject: gmail.com - 550 error for ipv6/PTR ? In-Reply-To: <52D6CDFE.3090401@bitfreak.org> References: <52D6CDFE.3090401@bitfreak.org> Message-ID: <77426B543150464AA3F30DF1A91365DE6AF92A4F@ESV4-MBX01.linkedin.biz> On Jan 15, 2014, at 10:05 AM, Darren Pilgrim wrote: > On 1/14/2014 4:06 PM, Brandon Applegate wrote: >> Just saw this in a message tonight. No idea if this is a transient error >> or not. >> >> --- >> host gmail-smtp-in.l.google.com >> [gmail-smtp-in.l.google.com][2607:f8b0:4002:c01::1a] >> said: 550-5.7.1 [2607:ff70:11::11] Our system has detected that this >> message does not 550-5.7.1 meet IPv6 sending guidelines regarding PTR >> records and authentication 550-5.7.1 . Please review 550-5.7.1 >> https://support.google.com/mail/?p=ipv6_authentication_error >> [support.google.com] for more 550 >> 5.7.1 information. t26si2290895yhl.255 - gsmtp (in reply to end of DATA >> command) > > I saw a number of these as well but in my case the bracketed IP addresses were malformed. For example: > > host gmail-smtp-in.l.google.com[2607:f8b0:4002:c01::1a] said: 550-5.7.1 [2607:fc50:1000:1f00::2 16] Our system has detected that this 550-5.7.1 message does not meet IPv6 sending guidelines... > https://support.google.com/mail/answer/81126?hl=en#authentication Additional guidelines for IPv6 The sending IP must have a PTR record (i.e., a reverse DNS of the sending IP) and it should match the IP obtained via the forward DNS resolution of the hostname specified in the PTR record. Otherwise, mail will be marked as spam or possibly rejected. The sending domain should pass either SPF check or DKIM check. Otherwise, mail might be marked as spam. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From morrowc.lists at gmail.com Wed Jan 15 18:22:20 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 15 Jan 2014 13:22:20 -0500 Subject: best practice for advertising peering fabric routes In-Reply-To: <20140115175402.GB67472@burnout.tpb.net> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <52D6BF92.7070400@shankland.org> <20140115175402.GB67472@burnout.tpb.net> Message-ID: On Wed, Jan 15, 2014 at 12:54 PM, Niels Bakker wrote: > * nanog at shankland.org (Jim Shankland) [Wed 15 Jan 2014, 18:04 CET]: > >> So ... RFC1918 addresses for the IXP fabric, then? >> >> (Half kidding, but still ....) > > > They need to be globally unique. do they? :) also... there is/was an exchange in south america (columbia maybe? it's been a while since I saw this in configs) that used 192.168.0.0/16 space for their exchange. From bill at herrin.us Wed Jan 15 18:26:57 2014 From: bill at herrin.us (William Herrin) Date: Wed, 15 Jan 2014 13:26:57 -0500 Subject: best practice for advertising peering fabric routes In-Reply-To: <20140115175402.GB67472@burnout.tpb.net> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <52D6BF92.7070400@shankland.org> <20140115175402.GB67472@burnout.tpb.net> Message-ID: On Wed, Jan 15, 2014 at 12:54 PM, Niels Bakker wrote: > * nanog at shankland.org (Jim Shankland) [Wed 15 Jan 2014, 18:04 CET]: > >> So ... RFC1918 addresses for the IXP fabric, then? >> >> (Half kidding, but still ....) > > They need to be globally unique. Hi Niels, Actually, they don't. To meet the basic definition of working, they just have to be able to originate ICMP destination unreachable packets with a reasonable expectation that the recipient will receive those packets. Global uniqueness is not required for that. However, RFC1918 addresses don't meet the requirement for a different reason: they're routinely dropped at AS borders, thus don't have an expectation of reaching the external destination. Of course working, monitorable and testable are three different things. If my NMS can't reach the IXP's addresses, my view of the IXP is impaired. And "the Internet is broken" is not a trouble report that leads to a successful outcome with customer support... it helps to be able to pin things down with some specificity. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nanog at bitfreak.org Wed Jan 15 18:56:37 2014 From: nanog at bitfreak.org (Darren Pilgrim) Date: Wed, 15 Jan 2014 10:56:37 -0800 Subject: gmail.com - 550 error for ipv6/PTR ? In-Reply-To: <77426B543150464AA3F30DF1A91365DE6AF92A4F@ESV4-MBX01.linkedin.biz> References: <52D6CDFE.3090401@bitfreak.org> <77426B543150464AA3F30DF1A91365DE6AF92A4F@ESV4-MBX01.linkedin.biz> Message-ID: <52D6D9E5.8090402@bitfreak.org> On 1/15/2014 10:14 AM, Franck Martin wrote: > > On Jan 15, 2014, at 10:05 AM, Darren Pilgrim > > wrote: > >> On 1/14/2014 4:06 PM, Brandon Applegate wrote: >>> Just saw this in a message tonight. No idea if this is a transient error >>> or not. >>> >>> --- >>> host gmail-smtp-in.l.google.com >>> [gmail-smtp-in.l.google.com >>> ][2607:f8b0:4002:c01::1a] >>> said: 550-5.7.1 [2607:ff70:11::11] Our system has detected that this >>> message does not 550-5.7.1 meet IPv6 sending guidelines regarding PTR >>> records and authentication 550-5.7.1 . Please review 550-5.7.1 >>> https://support.google.com/mail/?p=ipv6_authentication_error >>> [support.google.com ] for more 550 >>> 5.7.1 information. t26si2290895yhl.255 - gsmtp (in reply to end of >>> DATA >>> command) >> >> I saw a number of these as well but in my case the bracketed IP >> addresses were malformed. For example: >> >> host gmail-smtp-in.l.google.com >> [2607:f8b0:4002:c01::1a] said: >> 550-5.7.1 [2607:fc50:1000:1f00::2 16] Our system has detected >> that this 550-5.7.1 message does not meet IPv6 sending guidelines... >> > > https://support.google.com/mail/answer/81126?hl=en#authentication My point was that Google told me it rejected "2607:fc50:1000:1f00::2 16". In this case, 2607:fc50:1000:1f00::2 is the correct address, but it appeared (to me) that Google's data was somehow corrupt. I'm pretty sure the IPv6 address format doesn't allow spaces. ;) From stillwaxin at gmail.com Wed Jan 15 19:04:52 2014 From: stillwaxin at gmail.com (Michael Still) Date: Wed, 15 Jan 2014 14:04:52 -0500 Subject: best practice for advertising peering fabric routes In-Reply-To: References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <52D6BF92.7070400@shankland.org> <20140115175402.GB67472@burnout.tpb.net> Message-ID: On Wed, Jan 15, 2014 at 1:26 PM, William Herrin wrote: > On Wed, Jan 15, 2014 at 12:54 PM, Niels Bakker wrote: >> * nanog at shankland.org (Jim Shankland) [Wed 15 Jan 2014, 18:04 CET]: >> >>> So ... RFC1918 addresses for the IXP fabric, then? >>> >>> (Half kidding, but still ....) >> >> They need to be globally unique. > > Hi Niels, > > Actually, they don't. To meet the basic definition of working, they > just have to be able to originate ICMP destination unreachable packets > with a reasonable expectation that the recipient will receive those > packets. Global uniqueness is not required for that. However, RFC1918 > addresses don't meet the requirement for a different reason: they're > routinely dropped at AS borders, thus don't have an expectation of > reaching the external destination. > > Of course working, monitorable and testable are three different > things. If my NMS can't reach the IXP's addresses, my view of the IXP > is impaired. And "the Internet is broken" is not a trouble report that > leads to a successful outcome with customer support... it helps to be > able to pin things down with some specificity. > > Regards, > Bill Herrin Using RFC1918 would incur the assumption that one will need to use a unique router or routing instance for every exchange connected to since exchanges are likely to have overlapping space at that point (RFC1918 IXP registry anyone?). I don't think it'd be a good idea to go down that path.. Also mentioned in a past nanog was the idea of potentially getting someone like team cymru to setup all exchange prefixes in a special bogon list and you could null route on your edge all those prefixes.. I inquired to team cymru about this back when originally discussed but never got anywhere with them. > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -- [stillwaxin at gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin at gmail.com ~]$ From clay at bloomcounty.org Wed Jan 15 19:33:57 2014 From: clay at bloomcounty.org (Clay Fiske) Date: Wed, 15 Jan 2014 11:33:57 -0800 Subject: best practice for advertising peering fabric routes In-Reply-To: References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <52D6BF92.7070400@shankland.org> <20140115175402.GB67472@burnout.tpb.net> Message-ID: <30B98ADB-1CED-4022-9E80-576EEBF40697@bloomcounty.org> On Jan 15, 2014, at 10:26 AM, William Herrin wrote: > > Of course working, monitorable and testable are three different > things. If my NMS can't reach the IXP's addresses, my view of the IXP > is impaired. And "the Internet is broken" is not a trouble report that > leads to a successful outcome with customer support... it helps to be > able to pin things down with some specificity. This approach concerns me for a number of reasons. First, having your NMS ping your upstream?s IXP peers probably doesn?t scale. If I?m a peer of a reasonably large provider, I?m pretty sure I don?t want all their customers hammering my management plane. Even if you?re the only one doing it, you also don?t know if I?m rate-limiting pings for that or any other reason. Second, what information do you get that you didn?t already have? If you saw the IP in a traceroute then you know it exists, is alive, is in the path, and a rough estimation of the latency. Pinging it may even give you negative information. Platforms vary and all, but in my experience pinging a router, especially a potentially busy one peering at an IXP, shows notably worse performance than ?real? traffic experiences (admittedly somewhat true of TTL Expired responses, but less so in my experience). Now you?re potentially seeing high latency and packet loss which in reality might not even be there at all. Third, you don?t know that your ping to the peering IP is even taking the same path as the packets addressed to the real destination. MTR for example looks nice, but it would probably be more accurate if it simply ran the traceroute over and over instead of pinging each hop directly. You would also detect path changes for the real destination that pinging intermediate hops wouldn?t show you. While I appreciate the desire to be able to do as much of your own detective work as possible, I can also see where you?re now shifting workload onto someone else?s support organization when they?re not necessarily the problem either (?Hey, my NMS says your peering router is causing latency and packet loss, fix it!?). I?m also not saying there isn?t a troubleshooting gap caused by this. I?m just not sure being able to ping the IXP hop solves that problem either. Semi-related tangent: Working in an IXP setting I have seen weird corner cases cause issues in conjunction with the IXP subnet existing in BGP. Say someone?s got proxy ARP enabled on their router (sadly, more common than it should be, and not just from noobs at startups). Now say your IXP is growing and you expand the subnet. No matter how much you harp on the customers to make the change, they don?t all do it at once. Someone announces the new, larger subnet in BGP. Now when anyone ARPs for IPs in the new part of the range, proxy ARP guy (still on the smaller subnet) says ?hey I have a route for that, send it here?. That was fun to troubleshoot. :) -c From niels=nanog at bakker.net Wed Jan 15 20:46:25 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 15 Jan 2014 21:46:25 +0100 Subject: best practice for advertising peering fabric routes In-Reply-To: <30B98ADB-1CED-4022-9E80-576EEBF40697@bloomcounty.org> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <52D6BF92.7070400@shankland.org> <20140115175402.GB67472@burnout.tpb.net> <30B98ADB-1CED-4022-9E80-576EEBF40697@bloomcounty.org> Message-ID: <20140115204625.GD67472@burnout.tpb.net> * clay at bloomcounty.org (Clay Fiske) [Wed 15 Jan 2014, 20:34 CET]: >Semi-related tangent: Working in an IXP setting I have seen weird >corner cases cause issues in conjunction with the IXP subnet >existing in BGP. Say someone?s got proxy ARP enabled on their router >(sadly, more common than it should be, and not just from noobs at >startups). Now say your IXP is growing and you expand the subnet. No >matter how much you harp on the customers to make the change, they >don?t all do it at once. Someone announces the new, larger subnet in >BGP. Now when anyone ARPs for IPs in the new part of the range, >proxy ARP guy (still on the smaller subnet) says ?hey I have a route >for that, send it here?. That was fun to troubleshoot. :) Proper run IXPs pay engineers to hunt down people with Proxy ARP enabled on their peering interfaces. -- Niels. -- "It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account." -- roy edroso, alicublog.blogspot.com From niels=nanog at bakker.net Wed Jan 15 20:50:14 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 15 Jan 2014 21:50:14 +0100 Subject: best practice for advertising peering fabric routes In-Reply-To: References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <52D6BF92.7070400@shankland.org> <20140115175402.GB67472@burnout.tpb.net> Message-ID: <20140115205014.GE67472@burnout.tpb.net> * bill at herrin.us (William Herrin) [Wed 15 Jan 2014, 19:27 CET]: >On Wed, Jan 15, 2014 at 12:54 PM, Niels Bakker wrote: >>* nanog at shankland.org (Jim Shankland) [Wed 15 Jan 2014, 18:04 CET]: >> >>>So ... RFC1918 addresses for the IXP fabric, then? >>>(Half kidding, but still ....) >> >>They need to be globally unique. > >Actually, they don't. To meet the basic definition of working, they >just have to be able to originate ICMP destination unreachable >packets with a reasonable expectation that the recipient will >receive those packets. Global uniqueness is not required for that. >However, RFC1918 addresses don't meet the requirement for a >different reason: they're routinely dropped at AS borders, thus >don't have an expectation of reaching the external destination. They need to be globally unique because otherwise a connected network might be using them already internally, thus keeping them from connecting - or as another followup mail stated, force everything into their own VRFs, and that may still collide. This was rehashed a few years ago on the RIPE AP-WG mailing list, IIRC. -- Niels. -- "It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account." -- roy edroso, alicublog.blogspot.com From fmartin at linkedin.com Wed Jan 15 20:57:05 2014 From: fmartin at linkedin.com (Franck Martin) Date: Wed, 15 Jan 2014 20:57:05 +0000 Subject: gmail.com - 550 error for ipv6/PTR ? In-Reply-To: <52D6D9E5.8090402@bitfreak.org> References: <52D6CDFE.3090401@bitfreak.org> <77426B543150464AA3F30DF1A91365DE6AF92A4F@ESV4-MBX01.linkedin.biz> <52D6D9E5.8090402@bitfreak.org> Message-ID: <77426B543150464AA3F30DF1A91365DE6AF9BFAF@ESV4-MBX01.linkedin.biz> On Jan 15, 2014, at 10:56 AM, Darren Pilgrim wrote: > On 1/15/2014 10:14 AM, Franck Martin wrote: >> >> On Jan 15, 2014, at 10:05 AM, Darren Pilgrim > > >> wrote: >> >>> On 1/14/2014 4:06 PM, Brandon Applegate wrote: >>>> Just saw this in a message tonight. No idea if this is a transient error >>>> or not. >>>> >>>> --- >>>> host gmail-smtp-in.l.google.com >>>> [gmail-smtp-in.l.google.com >>>> ][2607:f8b0:4002:c01::1a] >>>> said: 550-5.7.1 [2607:ff70:11::11] Our system has detected that this >>>> message does not 550-5.7.1 meet IPv6 sending guidelines regarding PTR >>>> records and authentication 550-5.7.1 . Please review 550-5.7.1 >>>> https://support.google.com/mail/?p=ipv6_authentication_error >>>> [support.google.com ] for more 550 >>>> 5.7.1 information. t26si2290895yhl.255 - gsmtp (in reply to end of >>>> DATA >>>> command) >>> >>> I saw a number of these as well but in my case the bracketed IP >>> addresses were malformed. For example: >>> >>> host gmail-smtp-in.l.google.com >>> [2607:f8b0:4002:c01::1a] said: >>> 550-5.7.1 [2607:fc50:1000:1f00::2 16] Our system has detected >>> that this 550-5.7.1 message does not meet IPv6 sending guidelines... >>> >> >> https://support.google.com/mail/answer/81126?hl=en#authentication > > My point was that Google told me it rejected "2607:fc50:1000:1f00::2 16". In this case, 2607:fc50:1000:1f00::2 is the correct address, but it appeared (to me) that Google's data was somehow corrupt. > > I'm pretty sure the IPv6 address format doesn't allow spaces. ;) > Ah yes, the confusion with the separator between IP and ports. IPv4:port IPv6.port That gets a lot of regex confused... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From blake at ispn.net Wed Jan 15 21:22:10 2014 From: blake at ispn.net (Blake Hudson) Date: Wed, 15 Jan 2014 15:22:10 -0600 Subject: Internet Routing Registries - RADb, etc Message-ID: <52D6FC02.4080504@ispn.net> Can someone provide a little guidance on RADb (and other IRRs)? Our organization is not a customer of any IRRs, but our ARIN IP allocation is registered in RADb and Level3's IRR. The majority of these entries are incorrect and list other AS#'s (AS's that have never been authorized to announce this IP space) as the originating AS for our ARIN IP allocation. I have emailed Level3 about the incorrect entries in their IRR with no response. I have also emailed Cogent about their incorrect entry in RADb, also with no response. Should I be concerned about these entries? Do these entries give someone the ability to announce our IP space? How is the information in these databases checked for accuracy and why did RADb and Level3 put these entries in their database when the posting party was not authorized to announce this space? And finally, what can be done to correct or remove these entries (as a non-customer of either RADb or Level3)? Thanks in advance, --Blake From nick at foobar.org Wed Jan 15 21:30:58 2014 From: nick at foobar.org (Nick Hilliard) Date: Wed, 15 Jan 2014 21:30:58 +0000 Subject: Internet Routing Registries - RADb, etc In-Reply-To: <52D6FC02.4080504@ispn.net> References: <52D6FC02.4080504@ispn.net> Message-ID: <52D6FE12.8000504@foobar.org> On 15/01/2014 21:22, Blake Hudson wrote: > I have emailed Level3 about the incorrect entries in their IRR with no > response. I have also emailed Cogent about their incorrect entry in RADb, > also with no response. > > Should I be concerned about these entries? Do these entries give someone > the ability to announce our IP space? How is the information in these > databases checked for accuracy and why did RADb and Level3 put these > entries in their database when the posting party was not authorized to > announce this space? And finally, what can be done to correct or remove > these entries (as a non-customer of either RADb or Level3)? It depends. Most organisations do not use IRRDBs for compiling prefix lists, but some do. If you happen to get service from one of these organisations, it's better to ensure that the prefixes are correctly registered. Lots of European IXPs use IRRDBs for route-server prefix filter lists, but this may not be relevant to you. Level3 fills their IRRDB up with piles of crap. Good luck getting them to remove anything. RADB is well run, and if Cogent can't get their act together enough to remove the entries from there, you can email Merit directly (radb-support at merit.edu) and they can delete stuff, assuming that source: is RADB and you can prove that you legitimately hold the address space. Nick From fergdawgster at mykolab.com Wed Jan 15 21:31:53 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 15 Jan 2014 13:31:53 -0800 Subject: Internet Routing Registries - RADb, etc In-Reply-To: <52D6FC02.4080504@ispn.net> References: <52D6FC02.4080504@ispn.net> Message-ID: <52D6FE49.2050603@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Or perhaps this indicates that no one pays attention to what is in the RAdb, and therefore makes a statement about the RAdb itself? No idea myself... - - ferg On 1/15/2014 1:22 PM, Blake Hudson wrote: > Can someone provide a little guidance on RADb (and other IRRs)? > > Our organization is not a customer of any IRRs, but our ARIN IP > allocation is registered in RADb and Level3's IRR. The majority of > these entries are incorrect and list other AS#'s (AS's that have > never been authorized to announce this IP space) as the originating > AS for our ARIN IP allocation. > > I have emailed Level3 about the incorrect entries in their IRR with > no response. I have also emailed Cogent about their incorrect entry > in RADb, also with no response. > > Should I be concerned about these entries? Do these entries give > someone the ability to announce our IP space? How is the > information in these databases checked for accuracy and why did > RADb and Level3 put these entries in their database when the > posting party was not authorized to announce this space? And > finally, what can be done to correct or remove these entries (as a > non-customer of either RADb or Level3)? > > Thanks in advance, --Blake > > > > - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLW/kkACgkQKJasdVTchbJL0AD/eU+UD9adD33gOw3YHyD8TjaE l2ISHTI628wbF+jZSmUA/0rj0WrWrba6HqCrNsnhgIp2DClJqCYLAD8m0a1xbtG7 =coKB -----END PGP SIGNATURE----- From mysidia at gmail.com Wed Jan 15 22:18:25 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 15 Jan 2014 16:18:25 -0600 Subject: gmail.com - 550 error for ipv6/PTR ? In-Reply-To: <52D6CDFE.3090401@bitfreak.org> References: <52D6CDFE.3090401@bitfreak.org> Message-ID: On Wed, Jan 15, 2014 at 12:05 PM, Darren Pilgrim wrote: > host gmail-smtp-in.l.google.com[2607:f8b0:4002:c01::1a] said: 550-5.7.1 > [2607:fc50:1000:1f00::2 16] Our system has detected that this > 550-5.7.1 message does not meet IPv6 sending guidelines... > I could not reproduce the error during a telnet test. However, I see a substantial number of outgoing 550 5.7.1 rejects that look just like that, mixed in with accepted mail to gmail.com. So it would appear to be transient, but ongoing. And more than a bit troublesome, since it is shown as a 550 reject, and delivery therefore will not be deferred and retried appropriately. Jan 15 15:41:29 [...] Failed "Site gmail.com (2607:f8b0:4002:c01::1a) said after data sent: 550 5.7.1 more information. q48si1281225yhb.127 - gsmtp 550-5.7.1 [2607:f360:0:1f0::40:2f00 12] Our system has detected that this" -- -JH From owen at delong.com Wed Jan 15 23:20:54 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 15 Jan 2014 15:20:54 -0800 Subject: gmail.com - 550 error for ipv6/PTR ? In-Reply-To: <77426B543150464AA3F30DF1A91365DE6AF9BFAF@ESV4-MBX01.linkedin.biz> References: <52D6CDFE.3090401@bitfreak.org> <77426B543150464AA3F30DF1A91365DE6AF92A4F@ESV4-MBX01.linkedin.biz> <52D6D9E5.8090402@bitfreak.org> <77426B543150464AA3F30DF1A91365DE6AF9BFAF@ESV4-MBX01.linkedin.biz> Message-ID: <6FD561F4-23ED-4E7C-A68E-D13919C1E004@delong.com> > > > Ah yes, the confusion with the separator between IP and ports. > > IPv4:port > IPv6.port > > That gets a lot of regex confused... Especially since IPv4:port works, while IPv6:port usually does not and you usually need [ipv6]:port. Owen From eric at telic.us Wed Jan 15 23:30:11 2014 From: eric at telic.us (Eric Krichbaum) Date: Wed, 15 Jan 2014 17:30:11 -0600 Subject: Internet Routing Registries - RADb, etc In-Reply-To: <52D6FE12.8000504@foobar.org> References: <52D6FC02.4080504@ispn.net> <52D6FE12.8000504@foobar.org> Message-ID: <091c01cf1249$bce26560$36a73020$@telic.us> I 100% agree with Nick. But, in dealing with Level3, you need Level3 Members Remarks in your objects to deal with multiple registries etc. They have an ok system that is a nightmare to pull from different datasources with them and they've churned the ultimately responsible individual a few times which makes it tough to get someone knowledgeable. Larry and team however at RADB will respond to remove your entries from someone else's stale records without much hassle. Cogent will use your IRR data to generate a list the first time but they don't have a clue when it comes to keeping up to date. The underlying problem is that there is incentive to enter objects (or have them entered for you) but none to remove old/stale/incorrect objects. Eric -----Original Message----- From: Nick Hilliard [mailto:nick at foobar.org] Sent: Wednesday, January 15, 2014 3:31 PM To: Blake Hudson; nanog at nanog.org Subject: Re: Internet Routing Registries - RADb, etc On 15/01/2014 21:22, Blake Hudson wrote: > I have emailed Level3 about the incorrect entries in their IRR with no > response. I have also emailed Cogent about their incorrect entry in > RADb, also with no response. > > Should I be concerned about these entries? Do these entries give > someone the ability to announce our IP space? How is the information > in these databases checked for accuracy and why did RADb and Level3 > put these entries in their database when the posting party was not > authorized to announce this space? And finally, what can be done to > correct or remove these entries (as a non-customer of either RADb or Level3)? It depends. Most organisations do not use IRRDBs for compiling prefix lists, but some do. If you happen to get service from one of these organisations, it's better to ensure that the prefixes are correctly registered. Lots of European IXPs use IRRDBs for route-server prefix filter lists, but this may not be relevant to you. Level3 fills their IRRDB up with piles of crap. Good luck getting them to remove anything. RADB is well run, and if Cogent can't get their act together enough to remove the entries from there, you can email Merit directly (radb-support at merit.edu) and they can delete stuff, assuming that source: is RADB and you can prove that you legitimately hold the address space. Nick From clay at bloomcounty.org Wed Jan 15 23:31:28 2014 From: clay at bloomcounty.org (Clay Fiske) Date: Wed, 15 Jan 2014 15:31:28 -0800 Subject: Proxy ARP detection (was re: best practice for advertising peering fabric routes) In-Reply-To: <20140115204625.GD67472@burnout.tpb.net> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <52D6BF92.7070400@shankland.org> <20140115175402.GB67472@burnout.tpb.net> <30B98ADB-1CED-4022-9E80-576EEBF40697@bloomcounty.org> <20140115204625.GD67472@burnout.tpb.net> Message-ID: On Jan 15, 2014, at 12:46 PM, Niels Bakker wrote: > * clay at bloomcounty.org (Clay Fiske) [Wed 15 Jan 2014, 20:34 CET]: >> Semi-related tangent: Working in an IXP setting I have seen weird corner cases cause issues in conjunction with the IXP subnet existing in BGP. Say someone?s got proxy ARP enabled on their router (sadly, more common than it should be, and not just from noobs at startups). Now say your IXP is growing and you expand the subnet. No matter how much you harp on the customers to make the change, they don?t all do it at once. Someone announces the new, larger subnet in BGP. Now when anyone ARPs for IPs in the new part of the range, proxy ARP guy (still on the smaller subnet) says ?hey I have a route for that, send it here?. That was fun to troubleshoot. :) > > Proper run IXPs pay engineers to hunt down people with Proxy ARP enabled on their peering interfaces. Yes, yes, I expected a smug reply like this. I just didn?t expect it to take so long. But how can I detect proxy ARP when detecting proxy ARP was patented in 1996? http://www.google.com/patents/US5708654 Seriously though, it?s not so simple. You only get replies if the IP you ARP for is in the offender?s route table (or they have a default route). I?ve seen different routers respond depending on which non-local IP was ARPed for. And while using something like 8.8.8.8 might be an obvious choice, I don?t care to hose up everyone?s connectivity to it just to find local proxy ARP offenders on my network. -c From nicolai-nanog at chocolatine.org Wed Jan 15 23:31:06 2014 From: nicolai-nanog at chocolatine.org (Nicolai) Date: Wed, 15 Jan 2014 17:31:06 -0600 Subject: OpenNTPProject.org In-Reply-To: <20140114071830.GA18152@pob.ytti.fi> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> Message-ID: <20140115233106.GA22360@vectra.student.iastate.edu> On Tue, Jan 14, 2014 at 09:18:30AM +0200, Saku Ytti wrote: > DNS, NTP, SNMP, chargen et.al. could trivially change to QUIC/MinimaLT > or compared, getting same 0 RTT penalty as UDP without reflection > potential. I wouldn't say trivial, but QUIC and MinimaLT are hopefully the future. The near future, I hope! For now I'd just like to mention that OpenNTPD, from the OpenBSD project, is immune to the kind of large NTP amplification attacks now being discussed. It's certainly a good fit for some organizations/setups. http://www.openntpd.org Nicolai From niels=nanog at bakker.net Wed Jan 15 23:47:02 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 16 Jan 2014 00:47:02 +0100 Subject: Proxy ARP detection In-Reply-To: References: <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <52D6BF92.7070400@shankland.org> <20140115175402.GB67472@burnout.tpb.net> <30B98ADB-1CED-4022-9E80-576EEBF40697@bloomcounty.org> <20140115204625.GD67472@burnout.tpb.net> Message-ID: <20140115234702.GF67472@burnout.tpb.net> * clay at bloomcounty.org (Clay Fiske) [Thu 16 Jan 2014, 00:35 CET]: [...] >Seriously though, it?s not so simple. You only get replies if the IP >you ARP for is in the offender?s route table (or they have a default >route). I?ve seen different routers respond depending on which >non-local IP was ARPed for. And while using something like 8.8.8.8 >might be an obvious choice, I don?t care to hose up everyone?s >connectivity to it just to find local proxy ARP offenders on my >network. You'll never be entirely sure but obviously you're not limited to sending only one ARP request - this isn't The Hunt For The Red October movie. We're talking a common misconfiguration here in this thread - or at least you were, two mails upthread. How will checking for Proxy ARP possibly hose up anybody's connectivity? You realise that ARP replies are unicast, right? And that IXPs generally have dedicated servers for monitoring from which they can source packets? -- Niels. -- "It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account." -- roy edroso, alicublog.blogspot.com From clay at bloomcounty.org Wed Jan 15 23:58:39 2014 From: clay at bloomcounty.org (Clay Fiske) Date: Wed, 15 Jan 2014 15:58:39 -0800 Subject: Proxy ARP detection In-Reply-To: <20140115234702.GF67472@burnout.tpb.net> References: <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <52D6BF92.7070400@shankland.org> <20140115175402.GB67472@burnout.tpb.net> <30B98ADB-1CED-4022-9E80-576EEBF40697@bloomcounty.org> <20140115204625.GD67472@burnout.tpb.net> <20140115234702.GF67472@burnout.tpb.net> Message-ID: <4C209FFB-6573-4282-9142-561E79BF1FA9@bloomcounty.org> On Jan 15, 2014, at 3:47 PM, Niels Bakker wrote: > * clay at bloomcounty.org (Clay Fiske) [Thu 16 Jan 2014, 00:35 CET]: > [...] >> Seriously though, it?s not so simple. You only get replies if the IP you ARP for is in the offender?s route table (or they have a default route). I?ve seen different routers respond depending on which non-local IP was ARPed for. And while using something like 8.8.8.8 might be an obvious choice, I don?t care to hose up everyone?s connectivity to it just to find local proxy ARP offenders on my network. > > You'll never be entirely sure but obviously you're not limited to sending only one ARP request - this isn't The Hunt For The Red October movie. We're talking a common misconfiguration here in this thread - or at least you were, two mails upthread. > > How will checking for Proxy ARP possibly hose up anybody's connectivity? You realise that ARP replies are unicast, right? And that IXPs generally have dedicated servers for monitoring from which they can source packets? This is where theory diverges nicely from practice. In some cases the offender broadcast his reply, and guess what else? A lot of routers listen to unsolicited ARP replies. So no, even though I consider it someone else?s bad behavior to broadcast an ARP reply, I?m not willing to take the chance with an IP that doesn?t belong to me. -c From niels=nanog at bakker.net Thu Jan 16 00:03:31 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 16 Jan 2014 01:03:31 +0100 Subject: Proxy ARP detection In-Reply-To: <4C209FFB-6573-4282-9142-561E79BF1FA9@bloomcounty.org> References: <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <52D6BF92.7070400@shankland.org> <20140115175402.GB67472@burnout.tpb.net> <30B98ADB-1CED-4022-9E80-576EEBF40697@bloomcounty.org> <20140115204625.GD67472@burnout.tpb.net> <20140115234702.GF67472@burnout.tpb.net> <4C209FFB-6573-4282-9142-561E79BF1FA9@bloomcounty.org> Message-ID: <20140116000331.GG67472@burnout.tpb.net> * clay at bloomcounty.org (Clay Fiske) [Thu 16 Jan 2014, 00:59 CET]: >This is where theory diverges nicely from practice. In some cases >the offender broadcast his reply, and guess what else? A lot of >routers listen to unsolicited ARP replies. I've never seen this. Please name vendor and product, if only so other subscribers to this list can avoid doing business with them. >So no, even though I consider it someone else?s bad behavior to >broadcast an ARP reply, I?m not willing to take the chance with an >IP that doesn?t belong to me. So do an ARP request for www.equinix.com, or (and!) for an unused address on your Peering LAN. Standard tools like arpwatch should alert you to fishy things going on, loudly. -- Niels. -- "It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account." -- roy edroso, alicublog.blogspot.com From clay at bloomcounty.org Thu Jan 16 00:24:19 2014 From: clay at bloomcounty.org (Clay Fiske) Date: Wed, 15 Jan 2014 16:24:19 -0800 Subject: Proxy ARP detection In-Reply-To: <20140116000331.GG67472@burnout.tpb.net> References: <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <52D6BF92.7070400@shankland.org> <20140115175402.GB67472@burnout.tpb.net> <30B98ADB-1CED-4022-9E80-576EEBF40697@bloomcounty.org> <20140115204625.GD67472@burnout.tpb.net> <20140115234702.GF67472@burnout.tpb.net> <4C209FFB-6573-4282-9142-561E79BF1FA9@bloomcounty.org> <20140116000331.GG67472@burnout.tpb.net> Message-ID: <52710A09-568A-4463-A0B4-871DAC7B5572@bloomcounty.org> On Jan 15, 2014, at 4:03 PM, Niels Bakker wrote: > * clay at bloomcounty.org (Clay Fiske) [Thu 16 Jan 2014, 00:59 CET]: >> This is where theory diverges nicely from practice. In some cases the offender broadcast his reply, and guess what else? A lot of routers listen to unsolicited ARP replies. > > I've never seen this. Please name vendor and product, if only so other subscribers to this list can avoid doing business with them. This was some time ago, but the two I was able to dig up from that case were both Junipers. Perhaps it?s something that only happens when proxy ARP is enabled? -c From ilissa at imillerpr.com Thu Jan 16 01:09:27 2014 From: ilissa at imillerpr.com (Ilissa Miller) Date: Wed, 15 Jan 2014 20:09:27 -0500 Subject: Question re: WordPress Message-ID: Wondering if anyone in the community could kindly advise. How can someone get a deceased person's blog removed/taken down from WordPress? Please contact me directly offline if you can assist. Thank you Ilissa eMail: ilissa at imillerpr.com From erosen at redhat.com Thu Jan 16 00:54:14 2014 From: erosen at redhat.com (Eric Rosen) Date: Wed, 15 Jan 2014 19:54:14 -0500 (EST) Subject: Proxy ARP detection In-Reply-To: <52710A09-568A-4463-A0B4-871DAC7B5572@bloomcounty.org> References: <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <30B98ADB-1CED-4022-9E80-576EEBF40697@bloomcounty.org> <20140115204625.GD67472@burnout.tpb.net> <20140115234702.GF67472@burnout.tpb.net> <4C209FFB-6573-4282-9142-561E79BF1FA9@bloomcounty.org> <20140116000331.GG67472@burnout.tpb.net> <52710A09-568A-4463-A0B4-871DAC7B5572@bloomcounty.org> Message-ID: <1755866067.1304337.1389833654129.JavaMail.root@redhat.com> Cisco PIX's used to do this if the firewall had a route and saw a ARP request in that IP range it would proxy arp. ----- Original Message ----- > > On Jan 15, 2014, at 4:03 PM, Niels Bakker wrote: > > > * clay at bloomcounty.org (Clay Fiske) [Thu 16 Jan 2014, 00:59 CET]: > >> This is where theory diverges nicely from practice. In some cases the > >> offender broadcast his reply, and guess what else? A lot of routers > >> listen to unsolicited ARP replies. > > > > I've never seen this. Please name vendor and product, if only so other > > subscribers to this list can avoid doing business with them. > > This was some time ago, but the two I was able to dig up from that case were > both Junipers. Perhaps it?s something that only happens when proxy ARP is > enabled? > > > -c > > > -- Eric Rosen CCIE Security #17821 Information Security Analyst Red Hat, Inc erosen at redhat.com 919.890.8555 x48555 IRC erosen From fmartin at linkedin.com Thu Jan 16 01:35:02 2014 From: fmartin at linkedin.com (Franck Martin) Date: Thu, 16 Jan 2014 01:35:02 +0000 Subject: gmail.com - 550 error for ipv6/PTR ? In-Reply-To: References: Message-ID: <77426B543150464AA3F30DF1A91365DE6AFA0E9B@ESV4-MBX01.linkedin.biz> On Jan 14, 2014, at 4:06 PM, Brandon Applegate wrote: > Just saw this in a message tonight. No idea if this is a transient error or not. > > --- > host gmail-smtp-in.l.google.com [gmail-smtp-in.l.google.com][2607:f8b0:4002:c01::1a] > said: 550-5.7.1 [2607:ff70:11::11] Our system has detected that this > message does not 550-5.7.1 meet IPv6 sending guidelines regarding PTR > records and authentication 550-5.7.1 . Please review 550-5.7.1 > https://support.google.com/mail/?p=ipv6_authentication_error [support.google.com] for more 550 > 5.7.1 information. t26si2290895yhl.255 - gsmtp (in reply to end of DATA > command) --- > That URL's relevant section says: > > Additional guidelines for IPv6 > > The sending IP must have a PTR record (i.e., a reverse DNS of the sending IP) and it should match the IP obtained via the forward DNS resolution of the hostname specified in the PTR record. Otherwise, mail will be marked as spam or possibly rejected. > > The sending domain should pass either SPF check or DKIM check. Otherwise, mail might be marked as spam. > --- > > I have both of these (PTR's RR has matching AAAA, and I have SPF (but not DKIM)). > It occurs to me, you may have sent a bounce, where the envelope from is empty, therefore SPF would work on the domain in the helo/ehlo. People often forget to put a SPF record there... So there may be no SPF in fact... https://dmarcian.com/spf-survey/orbital.burn.net http://trac.tools.ietf.org/html/draft-ietf-spfbis-4408bis-21#section-10.1.3 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From joly at punkcast.com Thu Jan 16 01:42:02 2014 From: joly at punkcast.com (Joly MacFie) Date: Wed, 15 Jan 2014 20:42:02 -0500 Subject: Question re: WordPress In-Reply-To: References: Message-ID: wordpress.com ? On Wed, Jan 15, 2014 at 8:09 PM, Ilissa Miller wrote: > Wondering if anyone in the community could kindly advise. How can someone > get a deceased person's blog removed/taken down from WordPress? > > Please contact me directly offline if you can assist. > > Thank you > Ilissa > > eMail: ilissa at imillerpr.com > > > > > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From ilissa at imillerpr.com Thu Jan 16 02:01:37 2014 From: ilissa at imillerpr.com (Ilissa Miller) Date: Wed, 15 Jan 2014 21:01:37 -0500 Subject: Question re: WordPress In-Reply-To: <95B8DAFA-E2B9-4369-A78A-449963A455C9@addrex.net> References: <95B8DAFA-E2B9-4369-A78A-449963A455C9@addrex.net> Message-ID: <269FED42-B6C2-4165-9FA8-68FDFEC13A09@imillerpr.com> THANK YOU! On Jan 15, 2014, at 8:50 PM, Peter Thimmesch wrote: > http://en.support.wordpress.com/deceased-user/ > > > > On Jan 15, 2014, at 8:09 PM, Ilissa Miller wrote: > >> Wondering if anyone in the community could kindly advise. How can someone get a deceased person's blog removed/taken down from WordPress? >> >> Please contact me directly offline if you can assist. >> >> Thank you >> Ilissa >> >> eMail: ilissa at imillerpr.com >> >> >> >> >> Ilissa Miller CEO, iMiller Public Relations President, Northeast DAS + Small Cell Association Tel: 914.315.6424 Cel: 917.743.0931 eMail: ilissa at imillerpr.com www.imillerpr.com www.northeastdas.com From patrick at ianai.net Thu Jan 16 04:21:00 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 15 Jan 2014 23:21:00 -0500 Subject: Proxy ARP detection In-Reply-To: <1755866067.1304337.1389833654129.JavaMail.root@redhat.com> References: <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <30B98ADB-1CED-4022-9E80-576EEBF40697@bloomcounty.org> <20140115204625.GD67472@burnout.tpb.net> <20140115234702.GF67472@burnout.tpb.net> <4C209FFB-6573-4282-9142-561E79BF1FA9@bloomcounty.org> <20140116000331.GG67472@burnout.tpb.net> <52710A09-568A-4463-A0B4-871DAC7B5572@bloomcounty.org> <1755866067.1304337.1389833654129.JavaMail.root@redhat.com> Message-ID: Excellent. So all everyone has to do is not buy cisco _or_ juniper. Wait a minute.... -- TTFN, patrick On Jan 15, 2014, at 19:54 , Eric Rosen wrote: > Cisco PIX's used to do this if the firewall had a route and saw a ARP request in that IP range it would proxy arp. > > ----- Original Message ----- >> >> On Jan 15, 2014, at 4:03 PM, Niels Bakker wrote: >> >>> * clay at bloomcounty.org (Clay Fiske) [Thu 16 Jan 2014, 00:59 CET]: >>>> This is where theory diverges nicely from practice. In some cases the >>>> offender broadcast his reply, and guess what else? A lot of routers >>>> listen to unsolicited ARP replies. >>> >>> I've never seen this. Please name vendor and product, if only so other >>> subscribers to this list can avoid doing business with them. >> >> This was some time ago, but the two I was able to dig up from that case were >> both Junipers. Perhaps it?s something that only happens when proxy ARP is >> enabled? >> >> >> -c >> >> >> > > -- > Eric Rosen > CCIE Security #17821 > Information Security Analyst > Red Hat, Inc > erosen at redhat.com > 919.890.8555 x48555 > IRC erosen > > > From ljb at merit.edu Thu Jan 16 04:30:05 2014 From: ljb at merit.edu (Larry J. Blunk) Date: Wed, 15 Jan 2014 23:30:05 -0500 (EST) Subject: Internet Routing Registries - RADb, etc In-Reply-To: <52D6FC02.4080504@ispn.net> References: Message-ID: <1162483215.426628.1389846605814.JavaMail.zimbra@merit.edu> Blake, If you find that an RADb maintainer is unresponsive about removing stale/incorrect objects in the RADb, we will review your request and can remove the objects in question. Regards, Larry Blunk Merit ----- Original Message ----- > Can someone provide a little guidance on RADb (and other IRRs)? > > Our organization is not a customer of any IRRs, but our ARIN IP > allocation is registered in RADb and Level3's IRR. The majority of these > entries are incorrect and list other AS#'s (AS's that have never been > authorized to announce this IP space) as the originating AS for our ARIN > IP allocation. > > I have emailed Level3 about the incorrect entries in their IRR with no > response. I have also emailed Cogent about their incorrect entry in > RADb, also with no response. > > Should I be concerned about these entries? Do these entries give someone > the ability to announce our IP space? How is the information in these > databases checked for accuracy and why did RADb and Level3 put these > entries in their database when the posting party was not authorized to > announce this space? And finally, what can be done to correct or remove > these entries (as a non-customer of either RADb or Level3)? > > Thanks in advance, > --Blake > > > > From mysidia at gmail.com Thu Jan 16 04:39:21 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 15 Jan 2014 22:39:21 -0600 Subject: Proxy ARP detection In-Reply-To: References: <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <30B98ADB-1CED-4022-9E80-576EEBF40697@bloomcounty.org> <20140115204625.GD67472@burnout.tpb.net> <20140115234702.GF67472@burnout.tpb.net> <4C209FFB-6573-4282-9142-561E79BF1FA9@bloomcounty.org> <20140116000331.GG67472@burnout.tpb.net> <52710A09-568A-4463-A0B4-871DAC7B5572@bloomcounty.org> <1755866067.1304337.1389833654129.JavaMail.root@redhat.com> Message-ID: On Wed, Jan 15, 2014 at 10:21 PM, Patrick W. Gilmore wrote: > Excellent. So all everyone has to do is not buy cisco _or_ juniper. > Or make the LANs IPv6-only adressed, since ARP is not used. And it is probably unlikely that someone will turn on a ND Proxy by "accident". > Wait a minute.... > > -- > TTFN, > patrick > -- -JH From ml at kenweb.org Thu Jan 16 04:49:15 2014 From: ml at kenweb.org (ML) Date: Wed, 15 Jan 2014 23:49:15 -0500 Subject: Proxy ARP detection (was re: best practice for advertising peering fabric routes) In-Reply-To: References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <52D6BF92.7070400@shankland.org> <20140115175402.GB67472@burnout.tpb.net> <30B98ADB-1CED-4022-9E80-576EEBF40697@bloomcounty.org> <20140115204625.GD67472@burnout.tpb.net> Message-ID: <52D764CB.3030509@kenweb.org> On 1/15/2014 6:31 PM, Clay Fiske wrote: > Yes, yes, I expected a smug reply like this. I just didn?t expect it to take so long. > > But how can I detect proxy ARP when detecting proxy ARP was patented in 1996? > > http://www.google.com/patents/US5708654 > > > Seriously though, it?s not so simple. You only get replies if the IP you ARP for is in the offender?s route table (or they have a default route). I?ve seen different routers respond depending on which non-local IP was ARPed for. And while using something like 8.8.8.8 might be an obvious choice, I don?t care to hose up everyone?s connectivity to it just to find local proxy ARP offenders on my network. > > -c > Shouldn't ARP inspection be a common feature? From mysidia at gmail.com Thu Jan 16 05:17:29 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 15 Jan 2014 23:17:29 -0600 Subject: Proxy ARP detection (was re: best practice for advertising peering fabric routes) In-Reply-To: <52D764CB.3030509@kenweb.org> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <52D6BF92.7070400@shankland.org> <20140115175402.GB67472@burnout.tpb.net> <30B98ADB-1CED-4022-9E80-576EEBF40697@bloomcounty.org> <20140115204625.GD67472@burnout.tpb.net> <52D764CB.3030509@kenweb.org> Message-ID: On Wed, Jan 15, 2014 at 10:49 PM, ML wrote: > > Shouldn't ARP inspection be a common feature? > Dynamic ARP inspection is mostly useful only when the trusted ports receive their MAC to IP address mapping from a trusted DHCP server, and the trusted mapping is established using DHCP snooping. Or else, you have a manually entered entries in the secure ARP database of MAC to IP mappings. Which most operators would be resistant to dealing with, because of all the extra work. -It's not as if the switches know what the valid subnets are and suppress ARP requests for outside networks. Therefore, in most cases; ARP inspection won't be used, except for DHCP clients. Arp inspection goes hand-in-hand with increasing resistance against a Man in the Middle attack from a compromised workstation on a LAN, using ARP hijacking to capture traffic or distribute malware to a neighboring workstation. In most cases, DHCP-based configuration will not be used for routers (the very devices that might inadvertently have proxy-arp).... -- -JH From johnl at iecc.com Thu Jan 16 05:34:17 2014 From: johnl at iecc.com (John Levine) Date: 16 Jan 2014 05:34:17 -0000 Subject: gmail.com - 550 error for ipv6/PTR ? In-Reply-To: <77426B543150464AA3F30DF1A91365DE6AFA0E9B@ESV4-MBX01.linkedin.biz> Message-ID: <20140116053417.64252.qmail@joyce.lan> >It occurs to me, you may have sent a bounce, where the envelope from is empty, therefore SPF would work on the domain in the helo/ehlo. People often >forget to put a SPF record there... So there may be no SPF in fact... Nope. In this case, Google was just messed up. R's, John From pierre at userid.org Thu Jan 16 14:15:39 2014 From: pierre at userid.org (Pierre Lamy) Date: Thu, 16 Jan 2014 09:15:39 -0500 Subject: OpenNTPProject.org In-Reply-To: <52D5597A.1090601@mykolab.com> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <52D5597A.1090601@mykolab.com> Message-ID: <52D7E98B.4040801@userid.org> BCP38 will only ever get implemented if governments and ruling 'net bodies force deployment. There's otherwise very little benefit seen by the access network providers, since the targets are other orgs and the attacks are happening in a different backyard. On 14/01/2014 10:36 AM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 1/13/2014 11:18 PM, Saku Ytti wrote: > >> On (2014-01-13 21:33 +0000), Bjoern A. Zeeb wrote: >> >>>> BCP38! I am always surprised when people need crypto if they >>>> fail the simple things. >> Saying that BCP38 is solution to the reflection attacks is not >> unlike 5 year old wishing nothing but world peace for christmas, >> endearing, but it's not going to change anything. BCP38 is >> completely unrealistic, many access networks are on autopilot, >> many don't have HW support for BCP38, one port configured has >> low-benefit, only that machine can stop attacking (but whole >> world). > That does *not* make it an unworthy goal, nor should it stop people > from encouraging it's implementation. > > - - ferg (co-author of BCP38) > > > - -- > Paul Ferguson > PGP Public Key ID: 0x54DC85B2 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlLVWXoACgkQKJasdVTchbIrtAD/T2bNNAgZOnnlniBPd6sEquxJ > v01mmrhJxFTIDFq7EIkA/3vQbiwtEwBeVyCtc3coEkz50zSDh3j9QQjT+TQWCNVs > =Al3Y > -----END PGP SIGNATURE----- From rdobbins at arbor.net Thu Jan 16 14:30:35 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 16 Jan 2014 14:30:35 +0000 Subject: OpenNTPProject.org In-Reply-To: <20140114170513.GA26030@pob.ytti.fi> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140114170513.GA26030@pob.ytti.fi> Message-ID: <83122121-54D1-44F9-9618-CCD98043118A@arbor.net> On Jan 15, 2014, at 12:05 AM, Saku Ytti wrote: > (We do BCP38 on all ports and verify programmatically, but I know it's not at all practical solution globally for access). Anti-spoofing is eminently practical for most types of access network topologies using even slightly modern equipment; uRPF, ACLs, cable IP source verify, DHCP Snooping (which works just fine with fixed-address hosts), PACLs/VACLs, et. al. are some of the more prevalent mechanisms available. In point of fact, anti-spoofing is most useful and most practical at the access-network edge, or as close to it as possible. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From blake at ispn.net Thu Jan 16 14:32:02 2014 From: blake at ispn.net (Blake Hudson) Date: Thu, 16 Jan 2014 08:32:02 -0600 Subject: Internet Routing Registries - RADb, etc In-Reply-To: <091c01cf1249$bce26560$36a73020$@telic.us> References: <52D6FC02.4080504@ispn.net> <52D6FE12.8000504@foobar.org> <091c01cf1249$bce26560$36a73020$@telic.us> Message-ID: <52D7ED62.1060908@ispn.net> Eric Krichbaum wrote the following on 1/15/2014 5:30 PM: > I 100% agree with Nick. But, in dealing with Level3, you need Level3 Members Remarks in your objects to deal with multiple registries etc. They have an ok system that is a nightmare to pull from different datasources with them and they've churned the ultimately responsible individual a few times which makes it tough to get someone knowledgeable. Larry and team however at RADB will respond to remove your entries from someone else's stale records without much hassle. > > Cogent will use your IRR data to generate a list the first time but they don't have a clue when it comes to keeping up to date. > > The underlying problem is that there is incentive to enter objects (or have them entered for you) but none to remove old/stale/incorrect objects. > > Eric > > > -----Original Message----- > From: Nick Hilliard [mailto:nick at foobar.org] > Sent: Wednesday, January 15, 2014 3:31 PM > To: Blake Hudson; nanog at nanog.org > Subject: Re: Internet Routing Registries - RADb, etc > > On 15/01/2014 21:22, Blake Hudson wrote: >> I have emailed Level3 about the incorrect entries in their IRR with no >> response. I have also emailed Cogent about their incorrect entry in >> RADb, also with no response. >> >> Should I be concerned about these entries? Do these entries give >> someone the ability to announce our IP space? How is the information >> in these databases checked for accuracy and why did RADb and Level3 >> put these entries in their database when the posting party was not >> authorized to announce this space? And finally, what can be done to >> correct or remove these entries (as a non-customer of either RADb or Level3)? > It depends. Most organisations do not use IRRDBs for compiling prefix lists, but some do. If you happen to get service from one of these organisations, it's better to ensure that the prefixes are correctly registered. Lots of European IXPs use IRRDBs for route-server prefix filter lists, but this may not be relevant to you. > > Level3 fills their IRRDB up with piles of crap. Good luck getting them to remove anything. > > RADB is well run, and if Cogent can't get their act together enough to remove the entries from there, you can email Merit directly > (radb-support at merit.edu) and they can delete stuff, assuming that source: > is RADB and you can prove that you legitimately hold the address space. > > Nick > Thanks for the responses, these objects are all older. However, none of them are stale or from previous owners, allocations, etc. Each of these objects were posted to their respective IRR's after the IP space was allocated to us. This leads me to believe that the individual IRR's really do very little checking for accuracy and their usefulness is then questionable. I have contacted Merit and found them to be responsive. I will look at "securing" a spot in ARIN's and RIPE's databases, if possible. Hopefully this will make it unnecessary for someone to post an entry in a 3rd party IRR and possibly more difficult as well. --Blake From saku at ytti.fi Thu Jan 16 14:56:33 2014 From: saku at ytti.fi (Saku Ytti) Date: Thu, 16 Jan 2014 16:56:33 +0200 Subject: OpenNTPProject.org In-Reply-To: <83122121-54D1-44F9-9618-CCD98043118A@arbor.net> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140114170513.GA26030@pob.ytti.fi> <83122121-54D1-44F9-9618-CCD98043118A@arbor.net> Message-ID: <20140116145633.GA3758@pob.ytti.fi> On (2014-01-16 14:30 +0000), Dobbins, Roland wrote: > In point of fact, anti-spoofing is most useful and most practical at the access-network edge, or as close to it as possible. We must disagree on definition of practical. Maybe if I'd reword it realistic we might be closer. It is not going to happen, the most suspect places are places where it's going to be most difficult to get, either fully on autopilot with no technical personnel capable or having the power to make the change or ghetto gear with no capability for it. The longer we endorse fantasy the longer it'll take to promote practical solutions. There is nothing near consensus that IP transit should or even can be ACLd, but it's really simple and I'm happy to volunteer my time with any network wishing to implement it. Very modest amount of ports will produce significant reduction in spoofing pay-off. -- ++ytti From rdobbins at arbor.net Thu Jan 16 15:13:43 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 16 Jan 2014 15:13:43 +0000 Subject: OpenNTPProject.org In-Reply-To: <20140116145633.GA3758@pob.ytti.fi> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140114170513.GA26030@pob.ytti.fi> <83122121-54D1-44F9-9618-CCD98043118A@arbor.net> <20140116145633.GA3758@pob.ytti.fi> Message-ID: <8880C09E-5A29-4A1B-9D6C-698A75951D6D@arbor.net> On Jan 16, 2014, at 9:56 PM, Saku Ytti wrote: > It is not going to happen, the most suspect places are places where it's going to be most difficult to get, either fully on autopilot with no technical > personnel capable or having the power to make the change or ghetto gear with no capability for it. That may well be the case, unfortunately; my point was that at or near the access edge is the most *technically* and *topologically* feasible place to implement antispoofing mechanisms, as you indicated in your reply. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From asullivan at dyn.com Thu Jan 16 16:27:28 2014 From: asullivan at dyn.com (Andrew Sullivan) Date: Thu, 16 Jan 2014 11:27:28 -0500 Subject: "trivial" changes to DNS (was: OpenNTPProject.org) In-Reply-To: <20140114071830.GA18152@pob.ytti.fi> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> Message-ID: <20140116162727.GQ22344@dyn.com> On Tue, Jan 14, 2014 at 09:18:30AM +0200, Saku Ytti wrote: > > mid term, transport area in IETF. DNS, NTP, SNMP, chargen et.al. could > trivially change to QUIC/MinimaLT Oh, yes, it'd obviously be trivial to change DNS to use a different transport. This is shown by the massive success of getting EDNS0 universally deployed in under 10 years. Right? A -- Andrew Sullivan Dyn, Inc. asullivan at dyn.com v: +1 603 663 0448 From niels=nanog at bakker.net Thu Jan 16 16:28:34 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 16 Jan 2014 17:28:34 +0100 Subject: Proxy ARP detection In-Reply-To: <52710A09-568A-4463-A0B4-871DAC7B5572@bloomcounty.org> References: <52D6BF92.7070400@shankland.org> <20140115175402.GB67472@burnout.tpb.net> <30B98ADB-1CED-4022-9E80-576EEBF40697@bloomcounty.org> <20140115204625.GD67472@burnout.tpb.net> <20140115234702.GF67472@burnout.tpb.net> <4C209FFB-6573-4282-9142-561E79BF1FA9@bloomcounty.org> <20140116000331.GG67472@burnout.tpb.net> <52710A09-568A-4463-A0B4-871DAC7B5572@bloomcounty.org> Message-ID: <20140116162834.GH67472@burnout.tpb.net> * clay at bloomcounty.org (Clay Fiske) [Thu 16 Jan 2014, 01:25 CET]: >On Jan 15, 2014, at 4:03 PM, Niels Bakker wrote: >>* clay at bloomcounty.org (Clay Fiske) [Thu 16 Jan 2014, 00:59 CET]: >>>This is where theory diverges nicely from practice. In some >>>cases the offender broadcast his reply, and guess what else? A >>>lot of routers listen to unsolicited ARP replies. >> >>I've never seen this. Please name vendor and product, if only so >>other subscribers to this list can avoid doing business with them. > >This was some time ago, but the two I was able to dig up from that >case were both Junipers. Perhaps it?s something that only happens >when proxy ARP is enabled? Maybe. I don't think I've ever dealt with a situation in which Proxy ARP was enabled on a Juniper router. I've certainly not seen them reply to a request with a broadcast, and frankly that sounds like such a weird implementation decision that I'm going to need to see pcaps before I believe it. Even if this were a regular occurrence - which it evidently is not - it's still better to trigger this when you know you're doing something rather than have to step in later when another misconfiguration triggers routing problems like described in an earlier mail, renumbering into a larger subnet. -- Niels. -- "It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account." -- roy edroso, alicublog.blogspot.com From morrowc.lists at gmail.com Thu Jan 16 16:32:05 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 16 Jan 2014 11:32:05 -0500 Subject: "trivial" changes to DNS (was: OpenNTPProject.org) In-Reply-To: <20140116162727.GQ22344@dyn.com> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140116162727.GQ22344@dyn.com> Message-ID: On Thu, Jan 16, 2014 at 11:27 AM, Andrew Sullivan wrote: > On Tue, Jan 14, 2014 at 09:18:30AM +0200, Saku Ytti wrote: >> >> mid term, transport area in IETF. DNS, NTP, SNMP, chargen et.al. could >> trivially change to QUIC/MinimaLT > > Oh, yes, it'd obviously be trivial to change DNS to use a different > transport. This is shown by the massive success of getting EDNS0 > universally deployed in under 10 years. Right? pretty easy to believe that quic would be helpful right? especially if you were interested in: 1) keeping resource utilization down/same on dns servers 2) rtt and latency impacts of extra rtt on upper layer protocols 3) the Xmillions of embedded devices that end users rely upon for dns in their homes seems totally feasible. -chris From rubensk at gmail.com Thu Jan 16 16:33:45 2014 From: rubensk at gmail.com (Rubens Kuhl) Date: Thu, 16 Jan 2014 14:33:45 -0200 Subject: "trivial" changes to DNS (was: OpenNTPProject.org) In-Reply-To: <20140116162727.GQ22344@dyn.com> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140116162727.GQ22344@dyn.com> Message-ID: On Thu, Jan 16, 2014 at 2:27 PM, Andrew Sullivan wrote: > On Tue, Jan 14, 2014 at 09:18:30AM +0200, Saku Ytti wrote: > > > > mid term, transport area in IETF. DNS, NTP, SNMP, chargen et.al. could > > trivially change to QUIC/MinimaLT > > Oh, yes, it'd obviously be trivial to change DNS to use a different > transport. This is shown by the massive success of getting EDNS0 > universally deployed in under 10 years. Right? > Perhaps the problem with EDNS0 is exactly its backward compatibility. A parallel protocol adopted by the usual suspects of authoritative and recursive names servers that at some point becomes required for query volumes larger than x qps could account for most of name resolution on the planet in much less than 10 years. Rubens From asullivan at dyn.com Thu Jan 16 16:39:46 2014 From: asullivan at dyn.com (Andrew Sullivan) Date: Thu, 16 Jan 2014 11:39:46 -0500 Subject: "trivial" changes to DNS (was: OpenNTPProject.org) In-Reply-To: References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140116162727.GQ22344@dyn.com> Message-ID: <20140116163945.GU22344@dyn.com> On Thu, Jan 16, 2014 at 11:32:05AM -0500, Christopher Morrow wrote: > pretty easy to believe that quic would be helpful right? Yes. It's also pretty easy to believe that ditching DNS completely in favour of something without 8 billion warts would be helpful. > seems totally feasible. Certainly, it would be possible to standardize it. Whether it would be "trivial" to get it deployed is quite a different matter. The evidence to date is that there is a very, very long tail in any change having to do with the DNS. We are still, to this day, fighting with sysadmins who are convinced that firewall rules on TCP/53 are perfectly reasonable, even though DNS _always_ used TCP. People who believe there are going to be easy fixes to the issues coming from DNS are deluding themselves. A -- Andrew Sullivan Dyn, Inc. asullivan at dyn.com v: +1 603 663 0448 From vristevs at ramapo.edu Thu Jan 16 16:46:07 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Thu, 16 Jan 2014 11:46:07 -0500 Subject: Proxy ARP detection In-Reply-To: <1755866067.1304337.1389833654129.JavaMail.root@redhat.com> References: <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <30B98ADB-1CED-4022-9E80-576EEBF40697@bloomcounty.org> <20140115204625.GD67472@burnout.tpb.net> <20140115234702.GF67472@burnout.tpb.net> <4C209FFB-6573-4282-9142-561E79BF1FA9@bloomcounty.org> <20140116000331.GG67472@burnout.tpb.net> <52710A09-568A-4463-A0B4-871DAC7B5572@bloomcounty.org> <1755866067.1304337.1389833654129.JavaMail.root@redhat.com> Message-ID: <52D80CCF.4020306@ramapo.edu> Cisco ASA's still have proxy ARP enabled by default when certain NAT types are configured. http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/nat_objects.html "Default Settings (8.3(1), 8.3(2), and 8.4(1)) The default behavior for identity NAT has proxy ARP disabled. You cannot configure this setting. (8.4(2) and later) The default behavior for identity NAT has proxy ARP enabled, matching other static NAT rules. You can disable proxy ARP if desired. See the "Routing NAT Packets" section for more information." On 1/15/2014 7:54 PM, Eric Rosen wrote: > Cisco PIX's used to do this if the firewall had a route and saw a ARP request in that IP range it would proxy arp. > > ----- Original Message ----- >> On Jan 15, 2014, at 4:03 PM, Niels Bakker wrote: >> >>> * clay at bloomcounty.org (Clay Fiske) [Thu 16 Jan 2014, 00:59 CET]: >>>> This is where theory diverges nicely from practice. In some cases the >>>> offender broadcast his reply, and guess what else? A lot of routers >>>> listen to unsolicited ARP replies. >>> I've never seen this. Please name vendor and product, if only so other >>> subscribers to this list can avoid doing business with them. >> This was some time ago, but the two I was able to dig up from that case were >> both Junipers. Perhaps it?s something that only happens when proxy ARP is >> enabled? >> >> >> -c >> >> >> -- Vlade Ristevski Network Manager IT Services Ramapo College (201)-684-6854 From morrowc.lists at gmail.com Thu Jan 16 16:48:56 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 16 Jan 2014 11:48:56 -0500 Subject: "trivial" changes to DNS (was: OpenNTPProject.org) In-Reply-To: <20140116163945.GU22344@dyn.com> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140116162727.GQ22344@dyn.com> <20140116163945.GU22344@dyn.com> Message-ID: On Thu, Jan 16, 2014 at 11:39 AM, Andrew Sullivan wrote: > On Thu, Jan 16, 2014 at 11:32:05AM -0500, Christopher Morrow wrote: > >> pretty easy to believe that quic would be helpful right? > > Yes. It's also pretty easy to believe that ditching DNS completely in > favour of something without 8 billion warts would be helpful. > >> seems totally feasible. > > Certainly, it would be possible to standardize it. Whether it would > be "trivial" to get it deployed is quite a different matter. The > evidence to date is that there is a very, very long tail in any change > having to do with the DNS. We are still, to this day, fighting with > sysadmins who are convinced that firewall rules on TCP/53 are > perfectly reasonable, even though DNS _always_ used TCP. > > People who believe there are going to be easy fixes to the issues > coming from DNS are deluding themselves. I totally agree... I was actually joking in my last note :( sorry for not adding the ":)" as requisite in email. So... what other options are there to solve the larger problem of: "Some service is running on a public host, and it can be used to attack a third party" where in all of these cases the third party is someone who's address has been spoofed in the src-address of a packet. -chris From niels=nanog at bakker.net Thu Jan 16 16:51:07 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Thu, 16 Jan 2014 17:51:07 +0100 Subject: Proxy ARP detection In-Reply-To: <52D80CCF.4020306@ramapo.edu> References: <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <30B98ADB-1CED-4022-9E80-576EEBF40697@bloomcounty.org> <20140115204625.GD67472@burnout.tpb.net> <20140115234702.GF67472@burnout.tpb.net> <4C209FFB-6573-4282-9142-561E79BF1FA9@bloomcounty.org> <20140116000331.GG67472@burnout.tpb.net> <52710A09-568A-4463-A0B4-871DAC7B5572@bloomcounty.org> <1755866067.1304337.1389833654129.JavaMail.root@redhat.com> <52D80CCF.4020306@ramapo.edu> Message-ID: <20140116165107.GI67472@burnout.tpb.net> * vristevs at ramapo.edu (Vlade Ristevski) [Thu 16 Jan 2014, 17:46 CET]: >Cisco ASA's still have proxy ARP enabled by default when certain NAT >types are configured. That wasn't the question. The question was what equipment would send proxy ARP replies as broadcasts, possibly causing poisoning in other routers (which still sounds far-fetched to me). -- Niels. -- "It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account." -- roy edroso, alicublog.blogspot.com From asullivan at dyn.com Thu Jan 16 17:06:25 2014 From: asullivan at dyn.com (Andrew Sullivan) Date: Thu, 16 Jan 2014 12:06:25 -0500 Subject: "trivial" changes to DNS (was: OpenNTPProject.org) In-Reply-To: References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140116162727.GQ22344@dyn.com> <20140116163945.GU22344@dyn.com> Message-ID: <20140116170623.GY22344@dyn.com> On Thu, Jan 16, 2014 at 11:48:56AM -0500, Christopher Morrow wrote: > > I totally agree... I was actually joking in my last note :( sorry for > not adding the ":)" as requisite in email. I'm sorry my humour is now so impaired from reading 1net and other such things that I didn't figure it out! > So... what other options are there to solve the larger problem [?] If I knew, I'd run out an implement it rather than talk about it! A -- Andrew Sullivan Dyn, Inc. asullivan at dyn.com v: +1 603 663 0448 From wbailey at satelliteintelligencegroup.com Thu Jan 16 17:17:39 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 16 Jan 2014 17:17:39 +0000 Subject: Proxy ARP detection In-Reply-To: <20140116165107.GI67472@burnout.tpb.net> References: <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <30B98ADB-1CED-4022-9E80-576EEBF40697@bloomcounty.org> <20140115204625.GD67472@burnout.tpb.net> <20140115234702.GF67472@burnout.tpb.net> <4C209FFB-6573-4282-9142-561E79BF1FA9@bloomcounty.org> <20140116000331.GG67472@burnout.tpb.net> <52710A09-568A-4463-A0B4-871DAC7B5572@bloomcounty.org> <1755866067.1304337.1389833654129.JavaMail.root@redhat.com> <52D80CCF.4020306@ramapo.edu>,<20140116165107.GI67472@burnout.tpb.net> Message-ID: <9vujytl8wci0hk0lmtlq4rhx.1389892652116@email.android.com> I seem to recall some video encoders doing that, but I can't remember the vendor. Sent from my Mobile Device. -------- Original message -------- From: Niels Bakker Date: 01/16/2014 8:54 AM (GMT-08:00) To: nanog at nanog.org Subject: Re: Proxy ARP detection * vristevs at ramapo.edu (Vlade Ristevski) [Thu 16 Jan 2014, 17:46 CET]: >Cisco ASA's still have proxy ARP enabled by default when certain NAT >types are configured. That wasn't the question. The question was what equipment would send proxy ARP replies as broadcasts, possibly causing poisoning in other routers (which still sounds far-fetched to me). -- Niels. -- "It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account." -- roy edroso, alicublog.blogspot.com From cb.list6 at gmail.com Thu Jan 16 17:19:44 2014 From: cb.list6 at gmail.com (Cb B) Date: Thu, 16 Jan 2014 09:19:44 -0800 Subject: "trivial" changes to DNS (was: OpenNTPProject.org) In-Reply-To: <20140116170623.GY22344@dyn.com> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140116162727.GQ22344@dyn.com> <20140116163945.GU22344@dyn.com> <20140116170623.GY22344@dyn.com> Message-ID: On Jan 16, 2014 9:08 AM, "Andrew Sullivan" wrote: > > On Thu, Jan 16, 2014 at 11:48:56AM -0500, Christopher Morrow wrote: > > > > I totally agree... I was actually joking in my last note :( sorry for > > not adding the ":)" as requisite in email. > > I'm sorry my humour is now so impaired from reading 1net and other > such things that I didn't figure it out! > > > So... what other options are there to solve the larger problem [?] > > If I knew, I'd run out an implement it rather than talk about it! > > A > Well. These reflection attacks have something in common. The big ones (chargen, dns, ntp) are all IPv4 UDP. And these are all *very* big. I hate to throw the baby out with the bathwater, but in my network, IPv4 UDP is overstaying it's welcome. Just like IPv4 ICMP in 2001 - 2003, its fate is nearly certain. I hope QUIC does not stay on UDP, as it may find itself cut off at the legs. CB > -- > Andrew Sullivan > Dyn, Inc. > asullivan at dyn.com > v: +1 603 663 0448 > From nick at foobar.org Thu Jan 16 17:21:12 2014 From: nick at foobar.org (Nick Hilliard) Date: Thu, 16 Jan 2014 17:21:12 +0000 Subject: Internet Routing Registries - RADb, etc In-Reply-To: <52D7ED62.1060908@ispn.net> References: <52D6FC02.4080504@ispn.net> <52D6FE12.8000504@foobar.org> <091c01cf1249$bce26560$36a73020$@telic.us> <52D7ED62.1060908@ispn.net> Message-ID: <52D81508.3020608@foobar.org> On 16/01/2014 14:32, Blake Hudson wrote: > Thanks for the responses, these objects are all older. However, none of > them are stale or from previous owners, allocations, etc. Each of these > objects were posted to their respective IRR's after the IP space was > allocated to us. This leads me to believe that the individual IRR's really > do very little checking for accuracy and their usefulness is then > questionable. Oh yeah. I got hit by that sort of thing a week or two back. It wasn't origin: AS14179 / mnt-by: MAINT-AS28071, by any chance? AS14179 have been hijacking chunks of space from the various registries. Nick From asullivan at dyn.com Thu Jan 16 17:30:00 2014 From: asullivan at dyn.com (Andrew Sullivan) Date: Thu, 16 Jan 2014 12:30:00 -0500 Subject: "trivial" changes to DNS (was: OpenNTPProject.org) In-Reply-To: References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140116162727.GQ22344@dyn.com> <20140116163945.GU22344@dyn.com> <20140116170623.GY22344@dyn.com> Message-ID: <20140116172959.GA22344@dyn.com> On Thu, Jan 16, 2014 at 09:19:44AM -0800, Cb B wrote: > I hate to throw the baby out with the bathwater, but in my network, IPv4 > UDP is overstaying it's welcome. Just like IPv4 ICMP in 2001 - 2003, its > fate is nearly certain. I won't speak about the other protocols, but I encourage you to turn off DNS using UDP over IPv4 in your network and report back to us all on how that works out. You may not be able to do it by email, however. Best regards, A -- Andrew Sullivan Dyn, Inc. asullivan at dyn.com v: +1 603 663 0448 From cb.list6 at gmail.com Thu Jan 16 17:45:38 2014 From: cb.list6 at gmail.com (Cb B) Date: Thu, 16 Jan 2014 09:45:38 -0800 Subject: "trivial" changes to DNS (was: OpenNTPProject.org) In-Reply-To: <20140116172959.GA22344@dyn.com> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140116162727.GQ22344@dyn.com> <20140116163945.GU22344@dyn.com> <20140116170623.GY22344@dyn.com> <20140116172959.GA22344@dyn.com> Message-ID: On Jan 16, 2014 9:31 AM, "Andrew Sullivan" wrote: > > On Thu, Jan 16, 2014 at 09:19:44AM -0800, Cb B wrote: > > I hate to throw the baby out with the bathwater, but in my network, IPv4 > > UDP is overstaying it's welcome. Just like IPv4 ICMP in 2001 - 2003, its > > fate is nearly certain. > > I won't speak about the other protocols, but I encourage you to turn > off DNS using UDP over IPv4 in your network and report back to us all > on how that works out. You may not be able to do it by email, > however. > I white listed google and facebooks auth servers, so its cool. CB > Best regards, > > A > > -- > Andrew Sullivan > Dyn, Inc. > asullivan at dyn.com > v: +1 603 663 0448 > From jared at puck.Nether.net Thu Jan 16 17:55:18 2014 From: jared at puck.Nether.net (Jared Mauch) Date: Thu, 16 Jan 2014 12:55:18 -0500 Subject: "trivial" changes to DNS (was: OpenNTPProject.org) In-Reply-To: <20140116163945.GU22344@dyn.com> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140116162727.GQ22344@dyn.com> <20140116163945.GU22344@dyn.com> Message-ID: <20140116175518.GA27572@puck.nether.net> On Thu, Jan 16, 2014 at 11:39:46AM -0500, Andrew Sullivan wrote: > On Thu, Jan 16, 2014 at 11:32:05AM -0500, Christopher Morrow wrote: > > > pretty easy to believe that quic would be helpful right? > > Yes. It's also pretty easy to believe that ditching DNS completely in > favour of something without 8 billion warts would be helpful. > > > seems totally feasible. > > Certainly, it would be possible to standardize it. Whether it would > be "trivial" to get it deployed is quite a different matter. The > evidence to date is that there is a very, very long tail in any change > having to do with the DNS. We are still, to this day, fighting with > sysadmins who are convinced that firewall rules on TCP/53 are > perfectly reasonable, even though DNS _always_ used TCP. I can point anyone interested to the place in the bind source to force it to reply to all UDP queries with TC=1 to force TCP. should be safe on any authority servers, as a recursive server should be able to do outbound TCP. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From richard.hesse at weebly.com Thu Jan 16 17:58:09 2014 From: richard.hesse at weebly.com (Richard Hesse) Date: Thu, 16 Jan 2014 09:58:09 -0800 Subject: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds In-Reply-To: <030101cf0e0e$71088af0$5319a0d0$@truenet.com> References: <52CE6B0B.5050306@isp-services.nl> <7340D9F5-C40D-415E-9D6B-9DFEA0A0E47A@oitc.com> <299BE752-FAA8-43C2-BABE-03EB7AD579CC@oitc.com> <00d501cf0e0d$d76e0870$864a1950$@webjogger.net> <030101cf0e0e$71088af0$5319a0d0$@truenet.com> Message-ID: Probably not a bug, but par for their technical prowess. The SpamTeq website includes your account number and password in every URI. I'm not sure I'd trust a company that does something as terrible as that to practice good coding elsewhere and not cause major damage with their data feeds. -richard On Fri, Jan 10, 2014 at 6:15 AM, Eric Tykwinski wrote: > Looks like a bug, if you stick a 1 in total email users: > Per Year: $504.00 > > -----Original Message----- > From: Adam Greene [mailto:maillist at webjogger.net] > Sent: Friday, January 10, 2014 9:11 AM > To: 'NANOG Mailing List' > Subject: RE: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds > > Hi TR, > > This looks like a very promising service to me as well. > > Could you hit me off list with the pricing contact? > > The pricing on http://www.spamhaustech.com/datafeed/pricecalculator.lassois > a little high ($9,223,372,036,854,780,000.00/yr). > > :) > > Thanks, > Adam > > -----Original Message----- > From: TR Shaw [mailto:tshaw at oitc.com] > Sent: Thursday, January 09, 2014 5:49 PM > To: Bryan Socha > Cc: NANOG Mailing List > Subject: Re: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds > > Replied off list. > > On Jan 9, 2014, at 5:43 PM, Bryan Socha wrote: > > > I would also like that contact, i've been trying to get the same quote > > for > feed only for months. > > > > Thanks, > > Bryan > > > > > > > > > > > > From bzeeb-lists at lists.zabbadoz.net Thu Jan 16 18:10:59 2014 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Thu, 16 Jan 2014 18:10:59 +0000 Subject: "trivial" changes to DNS (was: OpenNTPProject.org) In-Reply-To: <20140116172959.GA22344@dyn.com> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140116162727.GQ22344@dyn.com> <20140116163945.GU22344@dyn.com> <20140116170623.GY22344@dyn.com> <20140116172959.GA22344@dyn.com> Message-ID: <6BA1DB7D-9DB9-4BCD-950F-7675F60FF52B@lists.zabbadoz.net> On 16 Jan 2014, at 17:30 , Andrew Sullivan wrote: > On Thu, Jan 16, 2014 at 09:19:44AM -0800, Cb B wrote: >> I hate to throw the baby out with the bathwater, but in my network, IPv4 >> UDP is overstaying it's welcome. Just like IPv4 ICMP in 2001 - 2003, its >> fate is nearly certain. > > I won't speak about the other protocols, but I encourage you to turn > off DNS using UDP over IPv4 in your network and report back to us all > on how that works out. You may not be able to do it by email, > however. Why not? .org and nanog.org have IPv6-enabled DNS, mailman.nanog.org has an IPv6 address. What else do you need to reply to this list? ? Bjoern A. Zeeb ????????? ??? ??????? ??????: '??? ??? ???? ?????? ??????? ?? ?? ??????? ??????? ??? ????? ????? ???? ?????? ?? ????? ????', ????????? ?????????, "??? ????? ?? ?????", ?.??? From saku at ytti.fi Thu Jan 16 18:13:06 2014 From: saku at ytti.fi (Saku Ytti) Date: Thu, 16 Jan 2014 20:13:06 +0200 Subject: "trivial" changes to DNS (was: OpenNTPProject.org) In-Reply-To: References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140116162727.GQ22344@dyn.com> <20140116163945.GU22344@dyn.com> <20140116170623.GY22344@dyn.com> Message-ID: <20140116181306.GA27689@pob.ytti.fi> On (2014-01-16 09:19 -0800), Cb B wrote: > I hope QUIC does not stay on UDP, as it may find itself cut off at the > legs. Any new L4 would need to support both flavours, over UDP and native. Over UDP is needed to be deployable right now and be working to vast majority of the end users. Native-only would present chicken and egg problem, goog/fb/amzn/msft etc won't add support to it, because failure rate is too high, and stateful box vendors won't add support, because no customer demand. And what becomes to deployment pace, good technologies which give benefits to end users can and have been deployed very fast. IPv6 does not give benefit to end users, EDNS does not give benefit to end users. QUIC/MinimaLT/IETF-transport-standardized-version would give benefit to end users, all persistent connections like ssh would keep running when you jump between networks. You could in your homeserver specifically allow /you/ to connect to any service, regardless of your IP address, because key is your identity, not your IP address. (So sort of LISPy thing going on here, we'd make IP more low-level information which it should be, it wouldn't be identity anymore) Parity packets have potential to give much better performance in packet loss conditions. Packet pacing seems much better on fast to slow file transfers. -- ++ytti From betty at newnog.org Thu Jan 16 18:18:48 2014 From: betty at newnog.org (Betty Burke ) Date: Thu, 16 Jan 2014 13:18:48 -0500 Subject: [NANOG-announce] NANOG Reminders Message-ID: Colleagues: A few reminders regarding the Education Series, Routing Fundamentals, class Sunday, February 9, 2014 and NANOG 60, February 10-12, 2014 in Atlanta, GA. In addition to the exciting NANOG 60 activities, NANOG is offering an Educational Series class "Routing Fundamentals" on Sunday, February 9, 2014. This is a great opportunity for folks who would like to advance their Network Operations Career. Registration remains open, and does include a One (1) day NANOG 60 meeting registration. The Program Committee delivered another great NANOG meeting agenda. The NANOG 60 program includes a Keynote address Monday morning, presentations on Security, BGP, Performance Measurement, IPv6, and the ever popular Data Center and Peering tracks. Don't delay, register soon as early Registrationends on January 24, 2014, (non-member $450, member $425, student $100), If you, or someone you know, might benefit from a bit of help with travel to attend NANOG 60, please be sure to check out the NANOG Fellowship program. Don't delay, NANOG 60 selections will be awarded soon. The Education class and NANOG 60 will take place at the Westin Peachtree Plaza. Make your room reservations soon, the room rate of $169. expires, Friday, January 24, 2014. There are a few NANOG 60 Sponsorship Opportunities remaining. Be sure to contact the NANOG Development Committee via marketing at nanog.orgto reserve your opportunity. Should you have any questions regarding NANOG activities, feel free to send your message to NANOG-Support at nanog.org. We look forward to seeing you in Atlanta! Sincerely, Betty -- Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From cb.list6 at gmail.com Thu Jan 16 18:20:15 2014 From: cb.list6 at gmail.com (Cb B) Date: Thu, 16 Jan 2014 10:20:15 -0800 Subject: "trivial" changes to DNS (was: OpenNTPProject.org) In-Reply-To: <20140116181306.GA27689@pob.ytti.fi> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140116162727.GQ22344@dyn.com> <20140116163945.GU22344@dyn.com> <20140116170623.GY22344@dyn.com> <20140116181306.GA27689@pob.ytti.fi> Message-ID: On Jan 16, 2014 10:16 AM, "Saku Ytti" wrote: > > On (2014-01-16 09:19 -0800), Cb B wrote: > > > I hope QUIC does not stay on UDP, as it may find itself cut off at the > > legs. > > Any new L4 would need to support both flavours, over UDP and native. Over UDP > is needed to be deployable right now and be working to vast majority of the > end users. > Native-only would present chicken and egg problem, goog/fb/amzn/msft etc won't > add support to it, because failure rate is too high, and stateful box vendors > won't add support, because no customer demand. > > And what becomes to deployment pace, good technologies which give benefits to > end users can and have been deployed very fast. > IPv6 does not give benefit to end users, EDNS does not give benefit to end > users. > > QUIC/MinimaLT/IETF-transport-standardized-version would give benefit to end > users, all persistent connections like ssh would keep running when you jump > between networks. > You could in your homeserver specifically allow /you/ to connect to any > service, regardless of your IP address, because key is your identity, not your > IP address. (So sort of LISPy thing going on here, we'd make IP more low-level > information which it should be, it wouldn't be identity anymore) > Parity packets have potential to give much better performance in packet loss > conditions. Packet pacing seems much better on fast to slow file transfers. > > -- > ++ytti > Then let's go all the way with ILNP. I like that. CB From courtneysmith at comcast.net Thu Jan 16 18:26:11 2014 From: courtneysmith at comcast.net (courtneysmith at comcast.net) Date: Thu, 16 Jan 2014 18:26:11 +0000 (UTC) Subject: Internet Routing Registries - RADb, etc In-Reply-To: Message-ID: <2061246597.531557.1389896771856.JavaMail.root@sz0003a.westchester.pa.mail.comcast.net> On 16/01/2014 14:32, Blake Hudson wrote: > Thanks for the responses, these objects are all older. However, none of > them are stale or from previous owners, allocations, etc. Each of these > objects were posted to their respective IRR's after the IP space was > allocated to us. This leads me to believe that the individual IRR's really > do very little checking for accuracy and their usefulness is then > questionable. Oh yeah. I got hit by that sort of thing a week or two back. It wasn't origin: AS14179 / mnt-by: MAINT-AS28071, by any chance? AS14179 have been hijacking chunks of space from the various registries. Nick ------------------------------ Another possible scenario. a.b.c.d/24->small_isp->regional_isp->Level3 Imagine a regional ISP is a customer of Level3. Level3 filters the regional ISP based on Regional ISP's IRR objects. Small ISP buys access from Regional. Small ISP doesn't maintain their own objects. Regional ISP wants Small's business so doesn't force the issue. Regional manually maintains the filters. Regional adds objects under Regional's maintainer whenever Small request a filter change. If they don?t, Level3 wont accept the announcement from them. Customer with a.b.c.d/24 has no idea about any of this. Now we are years later. Customer has either moved to another small ISP or Small ISP found a different regional ISP. a.b.c.d/24->small_isp->new_regional_isp->Level3 or a.b.c.d/24->new_small_isp->new_regional_isp->Level3 The original Regional ISP didnt remember to delete all the objects related to Small ISP's customers. The objects just sit there until one day customer has interest in registring their own object. Customer sees entries for their /24 under Regional ISP's objects. Customer knows they have never done business with Regional. Also the objects are newer than the customer's allocation from their RIR. Customer comes to the conclusion that Regional ISP must have been hi-jacking their space or doing some other naughtiness. Proxy registering objects isn't a good idea. However, the number of networks with allocations from ARIN registering objects in any IRR appears to be extremely low. ARIN doesn?t charge you more to use rr.arin.net. Folks seem to not be aware of IRR or perceive it provides no benefit to them. Will RPKI adoption suffer the same fate? From johnl at iecc.com Thu Jan 16 19:04:59 2014 From: johnl at iecc.com (John Levine) Date: 16 Jan 2014 19:04:59 -0000 Subject: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds In-Reply-To: <030101cf0e0e$71088af0$5319a0d0$@truenet.com> Message-ID: <20140116190459.70093.qmail@joyce.lan> In article <030101cf0e0e$71088af0$5319a0d0$@truenet.com> you write: >Looks like a bug, if you stick a 1 in total email users: >Per Year: $504.00 No, that's right. If you're a tiny little network, you can use the public DNS servers for the BL lookups, and you can FTP the text version of DROP and turn in into firewall rules or whatever. That's what I do (hack perl scripts available on request.) The BGP feed is intended for networks large enough to need BGP. R's, John From asullivan at dyn.com Thu Jan 16 19:33:22 2014 From: asullivan at dyn.com (Andrew Sullivan) Date: Thu, 16 Jan 2014 14:33:22 -0500 Subject: "trivial" changes to DNS (was: OpenNTPProject.org) In-Reply-To: <20140116175518.GA27572@puck.nether.net> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140116162727.GQ22344@dyn.com> <20140116163945.GU22344@dyn.com> <20140116175518.GA27572@puck.nether.net> Message-ID: <20140116193321.GE22344@dyn.com> On Thu, Jan 16, 2014 at 12:55:18PM -0500, Jared Mauch wrote: > I can point anyone interested to the place in the > bind source to force it to reply to all UDP queries with TC=1 > to force TCP. should be safe on any authority servers, as a recursive > server should be able to do outbound TCP. You could also (and for most cases, I recommend you do) enable the Response Rate Limiting patches available on most of the open-source authoritative servers. Sorry I didn't think to mention it earlier. I thought everyone already knew that. But it does appear to help. A -- Andrew Sullivan Dyn, Inc. asullivan at dyn.com v: +1 603 663 0448 From mysidia at gmail.com Thu Jan 16 19:35:00 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 16 Jan 2014 13:35:00 -0600 Subject: "trivial" changes to DNS (was: OpenNTPProject.org) In-Reply-To: References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140116162727.GQ22344@dyn.com> <20140116163945.GU22344@dyn.com> Message-ID: On Thu, Jan 16, 2014 at 10:48 AM, Christopher Morrow < morrowc.lists at gmail.com> wrote: > On Thu, Jan 16, 2014 at 11:39 AM, Andrew Sullivan > wrote: > > On Thu, Jan 16, 2014 at 11:32:05AM -0500, Christopher Morrow wrote: > So... what other options are there to solve the larger problem of: > "Some service is running on a public host, and it can be used to > attack a third party" > > where in all of these cases the third party is someone who's address > has been spoofed in the src-address of a packet. > Standardizing some UDP service-neutral PRE-Authentication system comes to mind; operating at the host level, independent of the various services, requiring the client to perform at least as much work as the response packet. E.g. Fwknop Single-Packet Authentication/Port-Knocking Style "The application doesn't see any UDP packets from a source:port number pair, until a source address authenticity event occurs, for that source ip:port number pair." Say instead of "port knocking" though, the client is required to estimate the size of the response to its first round trip of UDP request messages. Then the client's UDP stack must construct and send a Hashcash proof of work, of sufficient difficulty based on the estimated query plus response size, up to the first full round trip; containing a message digest of the first UDP packet the client will send, before sending the packet, or it will be silently discarded. An out-of-band reply will come back to the claimed source, that the client souce IP:Port has to acknowledge within 5 packets. Once the out-of-band reply is acknowledged, the source is confirmed not to be spoofed. UDP response packets and new queries above the estimated initial reply size or after the 5th packet are delayed until definitive confirmation or silently dropped, instead of returned to the claimed source. -chris > -- -JH From Valdis.Kletnieks at vt.edu Thu Jan 16 20:49:43 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 16 Jan 2014 15:49:43 -0500 Subject: "trivial" changes to DNS (was: OpenNTPProject.org) In-Reply-To: Your message of "Thu, 16 Jan 2014 13:35:00 -0600." References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140116162727.GQ22344@dyn.com> <20140116163945.GU22344@dyn.com> Message-ID: <65078.1389905383@turing-police.cc.vt.edu> On Thu, 16 Jan 2014 13:35:00 -0600, Jimmy Hess said: > Then the client's UDP stack must construct and send a Hashcash proof > of work, of sufficient difficulty based on the estimated query plus > response size, > up to the first full round trip; > containing a message digest of the first UDP packet the client will > send, before sending the packet, or it will be silently discarded. > An out-of-band reply will come back to the claimed source, that the > client souce IP:Port has to acknowledge within 5 packets. > Once the out-of-band reply is acknowledged, the source is confirmed not > to be spoofed. How is this any better than a TCP 3-packet handshake with syncookies? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From blake at ispn.net Thu Jan 16 21:04:58 2014 From: blake at ispn.net (Blake Hudson) Date: Thu, 16 Jan 2014 15:04:58 -0600 Subject: Internet Routing Registries - RADb, etc In-Reply-To: <2061246597.531557.1389896771856.JavaMail.root@sz0003a.westchester.pa.mail.comcast.net> References: <2061246597.531557.1389896771856.JavaMail.root@sz0003a.westchester.pa.mail.comcast.net> Message-ID: <52D8497A.1020104@ispn.net> courtneysmith at comcast.net wrote the following on 1/16/2014 12:26 PM: > On 16/01/2014 14:32, Blake Hudson wrote: >> Thanks for the responses, these objects are all older. However, none of >> them are stale or from previous owners, allocations, etc. Each of these >> objects were posted to their respective IRR's after the IP space was >> allocated to us. This leads me to believe that the individual IRR's really >> do very little checking for accuracy and their usefulness is then >> questionable. > Oh yeah. I got hit by that sort of thing a week or two back. It wasn't > origin: AS14179 / mnt-by: MAINT-AS28071, by any chance? AS14179 have been > hijacking chunks of space from the various registries. > > Nick > > ------------------------------ > > > > Another possible scenario. > > > > a.b.c.d/24->small_isp->regional_isp->Level3 > > > > Imagine a regional ISP is a customer of Level3. Level3 filters the regional ISP based on Regional ISP's IRR objects. Small ISP buys access from Regional. Small ISP doesn't maintain their own objects. Regional ISP wants Small's business so doesn't force the issue. Regional manually maintains the filters. Regional adds objects under Regional's maintainer whenever Small request a filter change. If they don?t, Level3 wont accept the announcement from them. Customer with a.b.c.d/24 has no idea about any of this. > > > > Now we are years later. Customer has either moved to another small ISP or Small ISP found a different regional ISP. > > > > a.b.c.d/24->small_isp->new_regional_isp->Level3 > > > > or > > > > a.b.c.d/24->new_small_isp->new_regional_isp->Level3 > > > > > > The original Regional ISP didnt remember to delete all the objects related to Small ISP's customers. The objects just sit there until one day customer has interest in registring their own object. Customer sees entries for their /24 under Regional ISP's objects. Customer knows they have never done business with Regional. Also the objects are newer than the customer's allocation from their RIR. Customer comes to the conclusion that Regional ISP must have been hi-jacking their space or doing some other naughtiness. > > > > > > Proxy registering objects isn't a good idea. However, the number of networks with allocations from ARIN registering objects in any IRR appears to be extremely low. ARIN doesn?t charge you more to use rr.arin.net. Folks seem to not be aware of IRR or perceive it provides no benefit to them. Will RPKI adoption suffer the same fate? I can understand the scenarios you've described. In fact, the timing does seem to indicate that someone was thinking they were doing something helpful (the route objects were introduced around the time we started announcing the allocation). The part that doesn't make sense is that one of the route objects has valid information and the other three were entered for AS #'s that are not peers of ours and should not have ever been transit paths to L3. We do peer with folks that peer with L3, however the route objects in L3's databases are for different ASs. I'm glad that ARIN provides an IRR, and hope to use it. With an authority that actually has the information necessary to perform authorization checks, I'm not sure why there's a need for independent IRRs to exist. Perhaps they filled a gap at some point in the past? --Blake From marka at isc.org Thu Jan 16 21:05:41 2014 From: marka at isc.org (Mark Andrews) Date: Fri, 17 Jan 2014 08:05:41 +1100 Subject: "trivial" changes to DNS (was: OpenNTPProject.org) In-Reply-To: Your message of "Thu, 16 Jan 2014 13:35:00 -0600." References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140116162727.GQ22344@dyn.com> <20140116163945.GU22344@dyn.com> Message-ID: <20140116210541.C6292D228BB@rock.dv.isc.org> We don't need to change transport, we don't need to port knock. We just need to implementent a slightly modified dns cookies which reminds me that I need to review Donald Eastlake's new draft to be. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From Curtis at GreenKey.net Thu Jan 16 21:06:14 2014 From: Curtis at GreenKey.net (Curtis Doty) Date: Thu, 16 Jan 2014 13:06:14 -0800 Subject: Experiences with Spamhaus BGP DROP, EDROP and BGPCC BGP feeds In-Reply-To: <20140116190459.70093.qmail@joyce.lan> References: <030101cf0e0e$71088af0$5319a0d0$@truenet.com> <20140116190459.70093.qmail@joyce.lan> Message-ID: On Thu, Jan 16, 2014 at 11:04 AM, John Levine wrote: > If you're a tiny little network, you can > use the public DNS servers for the BL lookups, and you can > FTP the text version of DROP and turn in into firewall > rules or whatever. That's what I do (hack perl scripts > available on request.) > Here's working Bash script to sync the freely available DROP/EDROP lists into a quagga/linux route server. https://gist.github.com/dotysan/8463112 I ran that awhile back without issue. But not anymore. Last year I added the $250/yr BOTNETCC list which is BGP-only. And it was too convenient to move the DROP/EDROP lists into BGP for an additional $250. It works as advertized. The BOTNETCC list is only v4/32s and more dynamic than the other lists. It's up to you to set it up correctly so an accident doesn't blackhole your own prefixes...or favorite offshore gambling site. :-p ../C From jlewis at lewis.org Thu Jan 16 21:22:31 2014 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 16 Jan 2014 16:22:31 -0500 (EST) Subject: Internet Routing Registries - RADb, etc In-Reply-To: <091c01cf1249$bce26560$36a73020$@telic.us> References: <52D6FC02.4080504@ispn.net> <52D6FE12.8000504@foobar.org> <091c01cf1249$bce26560$36a73020$@telic.us> Message-ID: On Wed, 15 Jan 2014, Eric Krichbaum wrote: > I 100% agree with Nick. But, in dealing with Level3, you need Level3 > Members Remarks in your objects to deal with multiple registries etc. > They have an ok system that is a nightmare to pull from different > datasources with them and they've churned the ultimately responsible > individual a few times which makes it tough to get someone > knowledgeable. Larry and team however at RADB will respond to remove > your entries from someone else's stale records without much hassle. > > Cogent will use your IRR data to generate a list the first time but they > don't have a clue when it comes to keeping up to date. > > The underlying problem is that there is incentive to enter objects (or > have them entered for you) but none to remove old/stale/incorrect > objects. Also, at least of the ones I've dealt with, there is no verification of records as they're entered. If your ASN/IPs are not already there, anyone can put them in under their own maintainer object. Since some providers do use IRR data to build and maintain customer prefix filters, it's not unusual for service providers to put customer ASNs/IPs into an IRR on behalf of their customers...and when the customer leaves, there's really no incentive to clean up and remove the objects. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From nick at foobar.org Thu Jan 16 22:11:01 2014 From: nick at foobar.org (Nick Hilliard) Date: Thu, 16 Jan 2014 22:11:01 +0000 Subject: Internet Routing Registries - RADb, etc In-Reply-To: References: <52D6FC02.4080504@ispn.net> <52D6FE12.8000504@foobar.org> <091c01cf1249$bce26560$36a73020$@telic.us> Message-ID: <52D858F5.1060409@foobar.org> On 16/01/2014 21:22, Jon Lewis wrote: > Also, at least of the ones I've dealt with, there is no verification of > records as they're entered. on the RIPE IRRDB, there is validation, so you can't just go in and register route: objects for someone else's allocations or assignments. Not sure about the other RIRs, except for ARIN which doesn't support this on rr.arin.net. Nick From marka at isc.org Thu Jan 16 22:52:06 2014 From: marka at isc.org (Mark Andrews) Date: Fri, 17 Jan 2014 09:52:06 +1100 Subject: OpenNTPProject.org In-Reply-To: Your message of "Thu, 16 Jan 2014 09:15:39 -0500." <52D7E98B.4040801@userid.org> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <52D5597A.1090601@mykolab.com> <52D7E98B.4040801@userid.org> Message-ID: <20140116225206.53CB1D2332D@rock.dv.isc.org> In message <52D7E98B.4040801 at userid.org>, Pierre Lamy writes: > BCP38 will only ever get implemented if governments and ruling 'net > bodies force deployment. There's otherwise very little benefit seen by > the access network providers, since the targets are other orgs and the > attacks are happening in a different backyard. Except the targets are *everybody* including the access networks. This really is "if you are not part of the solution, you are part of the problem" and applies 100% to access networks. And it doesn't require governments, it just requires CEO's with the gumption to say we are not going to accept routes from you, via transit or direct, until you publically state that you are implementing BCP38 within your network and then follow through. If you implement BCP the publish the fact on you sites. This lets others know they are not alone in the fight to make the net a better place. e.g. "We implement BCP 38 on XX% of customer links" "We implement BCP 38 on all of our single homed customers" "We implement BCP 38 on all our data centers traffic" "We implement BCP 38 on all our NOC traffic" "We implement BCP 38 on all our outgoing traffic" "We implement BCP 38 on all our traffic" Machines get owned everywhere including data centers and NOCs. BCP 38 filters should be everywhere. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jeroen at massar.ch Thu Jan 16 23:21:42 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Fri, 17 Jan 2014 00:21:42 +0100 Subject: Internet Routing Registries - RADb, etc In-Reply-To: <52D858F5.1060409@foobar.org> References: <52D6FC02.4080504@ispn.net> <52D6FE12.8000504@foobar.org> <091c01cf1249$bce26560$36a73020$@telic.us> <52D858F5.1060409@foobar.org> Message-ID: <52D86986.3050700@massar.ch> On 2014-01-16 23:11, Nick Hilliard wrote: > On 16/01/2014 21:22, Jon Lewis wrote: >> Also, at least of the ones I've dealt with, there is no verification of >> records as they're entered. > > on the RIPE IRRDB, there is validation, so you can't just go in and > register route: objects for someone else's allocations or assignments. You mean auth for RIPE region prefixes, as one can also register ARIN/APNIC/etc prefixes in the RIPEdb and then, there is no auth (but a mail to dbm at ripe.net resolves any issues quite quickly if something fake is there) Greets, Jeroen From surfer at mauigateway.com Thu Jan 16 23:45:59 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 16 Jan 2014 15:45:59 -0800 Subject: OpenNTPProject.org Message-ID: <20140116154559.950562E5@resin05.mta.everyone.net> --- marka at isc.org wrote: In message <52D7E98B.4040801 at userid.org>, Pierre Lamy writes: > BCP38 will only ever get implemented if governments and ruling 'net > bodies force deployment. There's otherwise very little benefit seen by > the access network providers, since the targets are other orgs and the > attacks are happening in a different backyard. Except the targets are *everybody* including the access networks. This really is "if you are not part of the solution, you are part of the problem" and applies 100% to access networks. And it doesn't require governments, it just requires CEO's with the gumption to say we are not going to accept routes from you, via transit or direct, until you publically state that you are implementing BCP38 within your network and then follow through. -------------------------------------------------------- Many/most CEOs would not have an understanding of what a BCP is and their first response likely would be to ask, "What's the business case?" Government regulation is also not the answer. They can't all agree on basic crap, much less on some esoteric (in their opinion) netgeekery thingie... scott From mysidia at gmail.com Thu Jan 16 23:58:50 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 16 Jan 2014 17:58:50 -0600 Subject: "trivial" changes to DNS (was: OpenNTPProject.org) In-Reply-To: <20140116210541.C6292D228BB@rock.dv.isc.org> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140116162727.GQ22344@dyn.com> <20140116163945.GU22344@dyn.com> <20140116210541.C6292D228BB@rock.dv.isc.org> Message-ID: On Thu, Jan 16, 2014 at 3:05 PM, Mark Andrews wrote: > We don't need to change transport, we don't need to port knock. We > just need to implementent a slightly modified dns cookies which > reminds me that I need to review Donald Eastlake's new draft to be. > But a change to DNS doesn't solve the problem for the other thousand or so UDP-based protocols. What would your fix be for the Chargen and SNMP protocols? -- > Mark Andrews, ISC > -- -JH From dougb at dougbarton.us Fri Jan 17 00:39:54 2014 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 16 Jan 2014 16:39:54 -0800 Subject: OpenNTPProject.org In-Reply-To: <20140116154559.950562E5@resin05.mta.everyone.net> References: <20140116154559.950562E5@resin05.mta.everyone.net> Message-ID: <52D87BDA.2040804@dougbarton.us> On 01/16/2014 03:45 PM, Scott Weeks wrote: > Many/most CEOs would not have an understanding of what a BCP is and > their first response likely would be to ask, "What's the business > case?" What I've tried to explain to people is that not being used as a botnet will reduce their outbound traffic. It's not much, but it's something. > Government regulation is also not the answer. They can't all agree > on basic crap, much less on some esoteric (in their opinion) netgeekery > thingie... Just have the NSA paint it as a national security issue. :) Doug From surfer at mauigateway.com Fri Jan 17 01:03:24 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 16 Jan 2014 17:03:24 -0800 Subject: OpenNTPProject.org Message-ID: <20140116170324.9505541B@resin05.mta.everyone.net> --- dougb at dougbarton.us wrote: From: Doug Barton On 01/16/2014 03:45 PM, Scott Weeks wrote: > Many/most CEOs would not have an understanding of what a BCP is and > their first response likely would be to ask, "What's the business > case?" What I've tried to explain to people is that not being used as a botnet will reduce their outbound traffic. It's not much, but it's something. ---------------------------------------------- Maybe it's just Hawaii, but many managers I've had would not be able to understand the importance of that. CEOs? ferget it! Plus I've done only eyeball networks since the early 2000s, so outbound is orders of magnitude lower than inbound and that also means I'm probably biased. I do those things trying to be a good netizen, but I don't tell the managers. It's not even on their radars. Further, I have met a lot of enterprise-level network folks along the way that don't know and/or just don't care. > Government regulation is also not the answer. They can't all agree > on basic crap, much less on some esoteric (in their opinion) netgeekery > thingie... Just have the NSA paint it as a national security issue. :) -------------------------------------------------------------- Since they're p0wning the entire internet globally that's one way to get it implemented, I suppose... :) scott From marka at isc.org Fri Jan 17 01:03:28 2014 From: marka at isc.org (Mark Andrews) Date: Fri, 17 Jan 2014 12:03:28 +1100 Subject: "trivial" changes to DNS (was: OpenNTPProject.org) In-Reply-To: Your message of "Thu, 16 Jan 2014 17:58:50 -0600." References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140116162727.GQ22344@dyn.com> <20140116163945.GU22344@dyn.com> <20140116210541.C6292D228BB@rock.dv.isc.org> Message-ID: <20140117010328.6CD0ED2C0E5@rock.dv.isc.org> In message , Jimmy Hess writes: > On Thu, Jan 16, 2014 at 3:05 PM, Mark Andrews wrote: > > > We don't need to change transport, we don't need to port knock. We > > just need to implementent a slightly modified dns cookies which > > reminds me that I need to review Donald Eastlake's new draft to be. > > > > But a change to DNS doesn't solve the problem for the other thousand or so > UDP-based protocols. What thousand protocols? There really are very few protocols widely deployed on top of UDP. > What would your fix be for the Chargen and SNMP protocols? Chargen is turned off on many platforms by default. Turn it off on more. Chargen loops are detectable. SNMP doesn't need to be open to the entire world. It's not like authoritative DNS servers which are offering a service to everyone. New UDP based protocols need to think about how to handle spoof traffic. You look at providing extending routing protocols to provide information about the legitimate source addresses that may be emitted over a link. SIDR should help here with authentication of the data. This will enable better automatic filtering to be deployed. You continue to deploy BCP38. Every site that deploys BCD is one less site where owened machines can be used to launch attacks from. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mysidia at gmail.com Fri Jan 17 01:16:50 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 16 Jan 2014 19:16:50 -0600 Subject: Proxy ARP detection In-Reply-To: <20140116165107.GI67472@burnout.tpb.net> References: <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <30B98ADB-1CED-4022-9E80-576EEBF40697@bloomcounty.org> <20140115204625.GD67472@burnout.tpb.net> <20140115234702.GF67472@burnout.tpb.net> <4C209FFB-6573-4282-9142-561E79BF1FA9@bloomcounty.org> <20140116000331.GG67472@burnout.tpb.net> <52710A09-568A-4463-A0B4-871DAC7B5572@bloomcounty.org> <1755866067.1304337.1389833654129.JavaMail.root@redhat.com> <52D80CCF.4020306@ramapo.edu> <20140116165107.GI67472@burnout.tpb.net> Message-ID: On Thu, Jan 16, 2014 at 10:51 AM, Niels Bakker wrote: > That wasn't the question. The question was what equipment would send > proxy ARP replies as broadcasts, possibly causing poisoning in other > routers (which still sounds far-fetched to me). > Which current routers will actually _listen_ to a broadcast ARP response involving an IP address that is outside the subnet assigned to that IP interface, and override the routing table with that entry? -- -J From cb.list6 at gmail.com Fri Jan 17 01:20:01 2014 From: cb.list6 at gmail.com (Cb B) Date: Thu, 16 Jan 2014 17:20:01 -0800 Subject: "trivial" changes to DNS (was: OpenNTPProject.org) In-Reply-To: <20140117010328.6CD0ED2C0E5@rock.dv.isc.org> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140116162727.GQ22344@dyn.com> <20140116163945.GU22344@dyn.com> <20140116210541.C6292D228BB@rock.dv.isc.org> <20140117010328.6CD0ED2C0E5@rock.dv.isc.org> Message-ID: On Jan 16, 2014 5:10 PM, "Mark Andrews" wrote: > > > In message < CAAAwwbVJKEok-ydwEQd4cowJ9qAAtbC8mKqwNXrsud55+H9ZEw at mail.gmail.com> > , Jimmy Hess writes: > > On Thu, Jan 16, 2014 at 3:05 PM, Mark Andrews wrote: > > > > > We don't need to change transport, we don't need to port knock. We > > > just need to implementent a slightly modified dns cookies which > > > reminds me that I need to review Donald Eastlake's new draft to be. > > > > > > > But a change to DNS doesn't solve the problem for the other thousand or so > > UDP-based protocols. > > What thousand protocols? There really are very few protocols widely > deployed on top of UDP. > > > What would your fix be for the Chargen and SNMP protocols? > > Chargen is turned off on many platforms by default. Turn it off > on more. Chargen loops are detectable. > Somebody has it on. I can confirm multi gb/s size chargen attacks going on regularly. I agree. More chargen off, more bcp 38, but ...yeh.. chargen is a big problem here and now CB > SNMP doesn't need to be open to the entire world. It's not like > authoritative DNS servers which are offering a service to everyone. > > New UDP based protocols need to think about how to handle spoof > traffic. > > You look at providing extending routing protocols to provide > information about the legitimate source addresses that may be emitted > over a link. SIDR should help here with authentication of the data. > This will enable better automatic filtering to be deployed. > > You continue to deploy BCP38. Every site that deploys BCD is one > less site where owened machines can be used to launch attacks from. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From marka at isc.org Fri Jan 17 01:44:07 2014 From: marka at isc.org (Mark Andrews) Date: Fri, 17 Jan 2014 12:44:07 +1100 Subject: "trivial" changes to DNS (was: OpenNTPProject.org) In-Reply-To: Your message of "Thu, 16 Jan 2014 17:20:01 -0800." References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140116162727.GQ22344@dyn.com> <20140116163945.GU22344@dyn.com> <20140116210541.C6292D228BB@rock.dv.isc.org> <20140117010328.6CD0ED2C0E5@rock.dv.isc.org> Message-ID: <20140117014408.06461D2C783@rock.dv.isc.org> In message , Cb B writes: > > On Jan 16, 2014 5:10 PM, "Mark Andrews" wrote: > > > > > > In message < > CAAAwwbVJKEok-ydwEQd4cowJ9qAAtbC8mKqwNXrsud55+H9ZEw at mail.gmail.com> > > , Jimmy Hess writes: > > > On Thu, Jan 16, 2014 at 3:05 PM, Mark Andrews wrote: > > > > > > > We don't need to change transport, we don't need to port knock. We > > > > just need to implementent a slightly modified dns cookies which > > > > reminds me that I need to review Donald Eastlake's new draft to be. > > > > > > > > > > But a change to DNS doesn't solve the problem for the other thousand or > so > > > UDP-based protocols. > > > > What thousand protocols? There really are very few protocols widely > > deployed on top of UDP. > > > > > What would your fix be for the Chargen and SNMP protocols? > > > > Chargen is turned off on many platforms by default. Turn it off > > on more. Chargen loops are detectable. > > > > Somebody has it on. > > I can confirm multi gb/s size chargen attacks going on regularly. > > I agree. More chargen off, more bcp 38, but ...yeh.. chargen is a big > problem here and now So go and *report* the traffic streams so that chargen service can be turned off or if the box doesn't support that, the box is replaced / filter. I don't know anyone that *needs* chargen turned on all the time. Most *never* need it to be turned on. India was just declared polio free. Fixing chargen is easier than that. Step 1. make sure you do not have chargen sources. Step 2. report traffic. Step 3. stop accepting all traffic to/from the if step 2 does not help. Mark > CB > > > SNMP doesn't need to be open to the entire world. It's not like > > authoritative DNS servers which are offering a service to everyone. > > > > New UDP based protocols need to think about how to handle spoof > > traffic. > > > > You look at providing extending routing protocols to provide > > information about the legitimate source addresses that may be emitted > > over a link. SIDR should help here with authentication of the data. > > This will enable better automatic filtering to be deployed. > > > > You continue to deploy BCP38. Every site that deploys BCD is one > > less site where owened machines can be used to launch attacks from. > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > --047d7bfd030c59198804f02057ae > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > >


> On Jan 16, 2014 5:10 PM, "Mark Andrews" < ka at isc.org">marka at isc.org> wrote:
> >
> >
> > In message < NXrsud55%2BH9ZEw at mail.gmail.com">CAAAwwbVJKEok-ydwEQd4cowJ9qAAtbC8mKqwNXrsu= > d55+H9ZEw at mail.gmail.com>
> > , Jimmy Hess writes:
> > > On Thu, Jan 16, 2014 at 3:05 PM, Mark Andrews < to:marka at isc.org">marka at isc.org> wrote:
> > >
> > > > We don't need to change transport, we don't need to = > port knock. =A0We
> > > > just need to implementent a slightly modified dns cookies wh= > ich
> > > > reminds me that I need to review Donald Eastlake's new d= > raft to be.
> > > >
> > >
> > > But a change to DNS doesn't solve the problem for the other t= > housand or so
> > > UDP-based protocols.
> >
> > What thousand protocols? =A0There really are very few protocols widely= >
> > deployed on top of UDP.
> >
> > > What would your fix be for the Chargen and SNMP protocols?
> >
> > Chargen is turned off on many platforms by default. =A0Turn it off
> > on more. =A0Chargen loops are detectable.
> >

>

Somebody has it on.

>

I can confirm multi gb/s size chargen attacks going on regul= > arly.

>

I agree. More chargen off, more bcp 38, but ...yeh.. chargen= > is a big problem here and now

>

CB

>

> SNMP doesn't need to be open to the entire world. = > =A0It's not like
> > authoritative DNS servers which are offering a service to everyone. > > >
> > New UDP based protocols need to think about how to handle spoof
> > traffic.
> >
> > You look at providing extending routing protocols to provide
> > information about the legitimate source addresses that may be emitted<= > br> > > over a link. =A0SIDR should help here with authentication of the data.= >
> > This will enable better automatic filtering to be deployed.
> >
> > You continue to deploy BCP38. =A0Every site that deploys BCD is one > > > less site where owened machines can be used to launch attacks from. > > >
> > Mark
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: ef=3D"mailto:marka at isc.org">marka at isc.org
> >
>

> > --047d7bfd030c59198804f02057ae-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jra at baylink.com Fri Jan 17 03:02:48 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 16 Jan 2014 22:02:48 -0500 (EST) Subject: BCP38.info (was: Re: OpenNTPProject.org) In-Reply-To: <20140116154559.950562E5@resin05.mta.everyone.net> Message-ID: <16671126.3986.1389927768115.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Weeks" > And it doesn't require governments, it just requires CEO's with the > gumption to say we are not going to accept routes from you, via > transit or direct, until you publically state that you are > implementing > BCP38 within your network and then follow through. > -------------------------------------------------------- > > Many/most CEOs would not have an understanding of what a BCP is and > their first response likely would be to ask, "What's the business > case?" > > Government regulation is also not the answer. They can't all agree > on basic crap, much less on some esoteric (in their opinion) > netgeekery thingie... Then we aren't doing our educational job correctly. In part, that's my fault, because I dropped the ball on http://www.bcp38.info So let me pick the ball back up: would everyone who has asserted in this thread that BCP38 is the New Hawtness from 20 years ago, please take 30 minutes out of your weekend, and go find a place 'pon that wiki that you can usefully apply a Vulcan Nerve Pinch to make it more suitable for us to wave in front of the faces of the people about whom Scott is concerned here? I have just rewritten the front page a bit, in recognition of the fact that as it was, it did not really address that audience itself, but more detail work on the interior about who should enable BCP38 filtering, how they can do it, and why they don't -- and why those reasons are spurious -- would be very helpful. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From ag4ve.us at gmail.com Fri Jan 17 07:04:56 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Fri, 17 Jan 2014 02:04:56 -0500 Subject: Windows Update subnets Message-ID: Does anyone have a list of all of the ranges Microsoft uses for Windows Update? I've found domains but not a full list of subnets. From joelja at bogus.com Fri Jan 17 07:14:08 2014 From: joelja at bogus.com (joel jaeggli) Date: Thu, 16 Jan 2014 23:14:08 -0800 Subject: Windows Update subnets In-Reply-To: References: Message-ID: <52D8D840.60607@bogus.com> I think you'll find that windows update heavily leverages 3rd party CDN providers as well as their own... http://technet.microsoft.com/en-us/library/cc627316.aspx On 1/16/14, 11:04 PM, shawn wilson wrote: > Does anyone have a list of all of the ranges Microsoft uses for > Windows Update? I've found domains but not a full list of subnets. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From dot at dotat.at Fri Jan 17 11:44:50 2014 From: dot at dotat.at (Tony Finch) Date: Fri, 17 Jan 2014 11:44:50 +0000 Subject: "trivial" changes to DNS (was: OpenNTPProject.org) In-Reply-To: <20140116175518.GA27572@puck.nether.net> References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140116162727.GQ22344@dyn.com> <20140116163945.GU22344@dyn.com> <20140116175518.GA27572@puck.nether.net> Message-ID: Jared Mauch wrote: > > I can point anyone interested to the place in the > bind source to force it to reply to all UDP queries with TC=1 > to force TCP. should be safe on any authority servers, as a recursive > server should be able to do outbound TCP. However see http://www.potaroo.net/ispcol/2013-09/dnstcp.html Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From jabley at hopcount.ca Fri Jan 17 16:07:34 2014 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 17 Jan 2014 11:07:34 -0500 Subject: Internet Routing Registries - RADb, etc In-Reply-To: <52D86986.3050700@massar.ch> References: <52D6FC02.4080504@ispn.net> <52D6FE12.8000504@foobar.org> <091c01cf1249$bce26560$36a73020$@telic.us> <52D858F5.1060409@foobar.org> <52D86986.3050700@massar.ch> Message-ID: On 2014-01-16, at 18:21, Jeroen Massar wrote: > On 2014-01-16 23:11, Nick Hilliard wrote: >> On 16/01/2014 21:22, Jon Lewis wrote: >>> Also, at least of the ones I've dealt with, there is no verification of >>> records as they're entered. >> >> on the RIPE IRRDB, there is validation, so you can't just go in and >> register route: objects for someone else's allocations or assignments. > > You mean auth for RIPE region prefixes, as one can also register > ARIN/APNIC/etc prefixes in the RIPEdb and then, there is no auth (but a > mail to dbm at ripe.net resolves any issues quite quickly if something fake > is there) Yep. For someone with non-RIPE NCC numbers the only manual part of the process is getting a maintainer object created. Once you've done that it's likely that your new parent route object in the RIPE db will be something like this: inetnum: 199.91.32.0 - 199.255.255.255 netname: NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK descr: IPv4 address block not managed by the RIPE NCC remarks: ------------------------------------------------------ remarks: remarks: Networks in this range are not in use in remarks: the RIPE NCC service region. remarks: remarks: You can find the whois server to query, or the remarks: IANA registry to query on this web page: remarks: http://www.iana.org/assignments/ipv4-address-space remarks: remarks: You can access databases of other RIR's at: remarks: remarks: AFRINIC (Africa) remarks: http://www.afrinic.net/ whois.afrinic.net remarks: remarks: APNIC (Asia Pacific) remarks: http://www.apnic.net/ whois.apnic.net remarks: remarks: ARIN (Northern America) remarks: http://www.arin.net/ whois.arin.net remarks: remarks: LACNIC (Latin America and the Carribean) remarks: http://www.lacnic.net/ whois.lacnic.net remarks: remarks: ------------------------------------------------------ which includes mnt-routes: RIPE-NCC-RPSL-MNT corresponding to mntner: RIPE-NCC-RPSL-MNT descr: This maintainer may be used to create objects to represent descr: routing policy in the RIPE Database for number resources not descr: allocated or assigned from the RIPE NCC. admin-c: RD132-RIPE auth: MD5-PW # Filtered remarks: ******************************************************* remarks: * The password for this object is 'RPSL', without the * remarks: * quotes. Do NOT use this maintainer as 'mnt-by'. * remarks: ******************************************************* mnt-by: RIPE-DBM-MNT referral-by: RIPE-DBM-MNT source: RIPE # Filtered Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From cscora at apnic.net Fri Jan 17 18:13:24 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 18 Jan 2014 04:13:24 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201401171813.s0HIDOPp014700@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 18 Jan, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 477794 Prefixes after maximum aggregation: 190510 Deaggregation factor: 2.51 Unique aggregates announced to Internet: 236762 Total ASes present in the Internet Routing Table: 45894 Prefixes per ASN: 10.41 Origin-only ASes present in the Internet Routing Table: 35494 Origin ASes announcing only one prefix: 16273 Transit ASes present in the Internet Routing Table: 5985 Transit-only ASes present in the Internet Routing Table: 171 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 2683 Unregistered ASNs in the Routing Table: 638 Number of 32-bit ASNs allocated by the RIRs: 5697 Number of 32-bit ASNs visible in the Routing Table: 4415 Prefixes from 32-bit ASNs in the Routing Table: 13942 Number of bogon 32-bit ASNs visible in the Routing Table: 1 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 1907 Number of addresses announced to Internet: 2658908708 Equivalent to 158 /8s, 123 /16s and 186 /24s Percentage of available address space announced: 71.8 Percentage of allocated address space announced: 71.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 95.4 Total number of prefixes smaller than registry allocations: 166098 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 113736 Total APNIC prefixes after maximum aggregation: 34266 APNIC Deaggregation factor: 3.32 Prefixes being announced from the APNIC address blocks: 116142 Unique aggregates announced from the APNIC address blocks: 48679 APNIC Region origin ASes present in the Internet Routing Table: 4871 APNIC Prefixes per ASN: 23.84 APNIC Region origin ASes announcing only one prefix: 1215 APNIC Region transit ASes present in the Internet Routing Table: 835 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 28 Number of APNIC region 32-bit ASNs visible in the Routing Table: 805 Number of APNIC addresses announced to Internet: 729226752 Equivalent to 43 /8s, 119 /16s and 30 /24s Percentage of available APNIC address space announced: 85.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 163574 Total ARIN prefixes after maximum aggregation: 81969 ARIN Deaggregation factor: 2.00 Prefixes being announced from the ARIN address blocks: 164087 Unique aggregates announced from the ARIN address blocks: 75843 ARIN Region origin ASes present in the Internet Routing Table: 15929 ARIN Prefixes per ASN: 10.30 ARIN Region origin ASes announcing only one prefix: 5981 ARIN Region transit ASes present in the Internet Routing Table: 1672 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 57 Number of ARIN addresses announced to Internet: 1070986112 Equivalent to 63 /8s, 213 /16s and 243 /24s Percentage of available ARIN address space announced: 56.7 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 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, 23/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, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 120201 Total RIPE prefixes after maximum aggregation: 61464 RIPE Deaggregation factor: 1.96 Prefixes being announced from the RIPE address blocks: 123838 Unique aggregates announced from the RIPE address blocks: 79301 RIPE Region origin ASes present in the Internet Routing Table: 17579 RIPE Prefixes per ASN: 7.04 RIPE Region origin ASes announcing only one prefix: 8322 RIPE Region transit ASes present in the Internet Routing Table: 2841 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2572 Number of RIPE addresses announced to Internet: 655129732 Equivalent to 39 /8s, 12 /16s and 124 /24s Percentage of available RIPE address space announced: 95.2 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, 56320-58367 59392-61439, 61952-62463, 196608-200191 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 53681 Total LACNIC prefixes after maximum aggregation: 9906 LACNIC Deaggregation factor: 5.42 Prefixes being announced from the LACNIC address blocks: 59214 Unique aggregates announced from the LACNIC address blocks: 27413 LACNIC Region origin ASes present in the Internet Routing Table: 2058 LACNIC Prefixes per ASN: 28.77 LACNIC Region origin ASes announcing only one prefix: 553 LACNIC Region transit ASes present in the Internet Routing Table: 402 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 35 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 972 Number of LACNIC addresses announced to Internet: 148257824 Equivalent to 8 /8s, 214 /16s and 60 /24s Percentage of available LACNIC address space announced: 88.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 11827 Total AfriNIC prefixes after maximum aggregation: 2607 AfriNIC Deaggregation factor: 4.54 Prefixes being announced from the AfriNIC address blocks: 12606 Unique aggregates announced from the AfriNIC address blocks: 4071 AfriNIC Region origin ASes present in the Internet Routing Table: 699 AfriNIC Prefixes per ASN: 18.03 AfriNIC Region origin ASes announcing only one prefix: 202 AfriNIC Region transit ASes present in the Internet Routing Table: 147 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 9 Number of AfriNIC addresses announced to Internet: 49673728 Equivalent to 2 /8s, 245 /16s and 246 /24s Percentage of available AfriNIC address space announced: 49.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2941 11558 953 Korea Telecom 17974 2738 902 88 PT Telekomunikasi Indonesia 7545 2139 320 115 TPG Telecom Limited 4755 1812 392 193 TATA Communications formerly 9829 1574 1266 43 National Internet Backbone 9583 1297 101 533 Sify Limited 7552 1233 1080 13 Viettel Corporation 9498 1213 309 68 BHARTI Airtel Ltd. 4808 1158 2121 348 CNCGROUP IP network China169 24560 1093 382 167 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3028 3688 53 BellSouth.net Inc. 22773 2321 2940 139 Cox Communications Inc. 1785 2151 688 133 PaeTec Communications, Inc. 18566 2048 379 178 MegaPath Corporation 20115 1681 1665 587 Charter Communications 4323 1629 1082 412 tw telecom holdings, inc. 701 1503 11158 772 MCI Communications Services, 30036 1377 297 571 Mediacom Communications Corp 7018 1302 17747 846 AT&T Services, Inc. 6983 1295 756 581 ITC^Deltacom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1856 544 16 OJSC "Vimpelcom" 34984 1367 244 224 TELLCOM ILETISIM HIZMETLERI A 20940 1220 459 919 Akamai International B.V. 13188 1039 100 26 TOV "Bank-Inform" 31148 1013 45 21 Freenet Ltd. 6849 883 363 38 JSC "Ukrtelecom" 8551 849 370 38 Bezeq International-Ltd 6830 769 2327 424 Liberty Global Operations B.V 12479 692 797 55 France Telecom Espana SA 35228 552 246 16 Telefonica UK Limited Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3443 1861 77 NET Servi?os de Comunica??o S 10620 2701 436 205 Telmex Colombia S.A. 18881 1810 909 21 Global Village Telecom 7303 1741 1164 220 Telecom Argentina S.A. 8151 1387 2880 429 Uninet S.A. de C.V. 11830 869 364 15 Instituto Costarricense de El 7738 846 1626 38 Telemar Norte Leste S.A. 27947 837 93 94 Telconet S.A 6503 836 434 61 Axtel, S.A.B. de C.V. 6147 777 373 27 Telefonica del Peru S.A.A. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1805 112 5 Sudanese Mobile Telephone (ZA 24863 904 380 28 Link Egypt (Link.NET) 6713 600 653 27 Office National des Postes et 8452 468 956 9 TE-AS 24835 298 144 9 Vodafone Data 3741 247 921 209 Internet Solutions 29571 239 21 14 Cote d'Ivoire Telecom 36992 237 783 24 ETISALAT MISR 15706 219 32 6 Sudatel (Sudan Telecom Co. Lt 29975 192 668 21 Vodacom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3443 1861 77 NET Servi?os de Comunica??o S 6389 3028 3688 53 BellSouth.net Inc. 4766 2941 11558 953 Korea Telecom 17974 2738 902 88 PT Telekomunikasi Indonesia 10620 2701 436 205 Telmex Colombia S.A. 22773 2321 2940 139 Cox Communications Inc. 1785 2151 688 133 PaeTec Communications, Inc. 7545 2139 320 115 TPG Telecom Limited 18566 2048 379 178 MegaPath Corporation 8402 1856 544 16 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3028 2975 BellSouth.net Inc. 17974 2738 2650 PT Telekomunikasi Indonesia 10620 2701 2496 Telmex Colombia S.A. 22773 2321 2182 Cox Communications Inc. 7545 2139 2024 TPG Telecom Limited 1785 2151 2018 PaeTec Communications, Inc. 4766 2941 1988 Korea Telecom 18566 2048 1870 MegaPath Corporation 8402 1856 1840 OJSC "Vimpelcom" 36998 1805 1800 Sudanese Mobile Telephone (ZA Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.192.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.196.0/22 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.200.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.202.0/23 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 62828 UNALLOCATED 8.21.130.0/24 4323 tw telecom holdings, 62850 UNALLOCATED 8.25.147.0/24 46887 Lightower Fiber Netw 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.90.128.0/18 27418 OUTOFWALL INC. 23.91.0.0/19 40676 Psychz Networks 23.91.14.0/24 40676 Psychz Networks 23.91.32.0/19 36315 Servpac Inc. 23.91.80.0/20 21560 Netstream Communications, LLC 23.91.96.0/20 40676 Psychz Networks 23.91.112.0/21 32475 SingleHop 23.91.120.0/21 36351 SoftLayer Technologies Inc. 23.91.128.0/19 5645 TekSavvy Solutions, Inc. 23.91.160.0/19 36493 FIBERNETICS CORPORATION Complete listing at http://thyme.rand.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:16 /9:11 /10:30 /11:92 /12:253 /13:475 /14:947 /15:1644 /16:12849 /17:6802 /18:11458 /19:23434 /20:33165 /21:35851 /22:50929 /23:44223 /24:253415 /25:787 /26:945 /27:426 /28:12 /29:14 /30:7 /31:0 /32:9 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2003 2048 MegaPath Corporation 36998 1771 1805 Sudanese Mobile Telephone (ZA 6389 1698 3028 BellSouth.net Inc. 22773 1565 2321 Cox Communications Inc. 8402 1543 1856 OJSC "Vimpelcom" 30036 1217 1377 Mediacom Communications Corp 1785 1163 2151 PaeTec Communications, Inc. 11492 1157 1194 CABLE ONE, INC. 6983 1036 1295 ITC^Deltacom 31148 957 1013 Freenet Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:935 2:839 3:3 4:15 5:860 6:21 8:634 12:1872 13:3 14:910 15:9 16:3 17:23 18:19 20:36 23:659 24:1751 27:1729 31:1522 32:44 33:2 34:5 36:112 37:1907 38:917 39:3 40:184 41:3301 42:243 44:14 46:2124 47:12 49:670 50:842 52:12 54:44 55:5 56:4 57:26 58:1136 59:594 60:370 61:1500 62:1211 63:1947 64:4372 65:2315 66:4132 67:2057 68:1080 69:3286 70:913 71:501 72:2037 74:2596 75:314 76:308 77:1151 78:1014 79:688 80:1308 81:1078 82:681 83:740 84:649 85:1219 86:429 87:1020 88:510 89:1593 90:145 91:5699 92:646 93:1582 94:2102 95:1478 96:533 97:350 98:1068 99:41 100:29 101:711 103:3968 105:534 106:142 107:380 108:548 109:2039 110:978 111:1207 112:609 113:820 114:774 115:1076 116:1015 117:835 118:1239 119:1296 120:326 121:787 122:1916 123:1268 124:1393 125:1450 128:665 129:236 130:345 131:663 132:353 133:159 134:312 135:74 136:281 137:314 138:351 139:143 140:199 141:354 142:552 143:406 144:500 145:93 146:566 147:432 148:793 149:360 150:149 151:476 152:414 153:206 154:52 155:528 156:317 157:420 158:293 159:831 160:361 161:471 162:1032 163:232 164:668 165:590 166:271 167:639 168:1042 169:123 170:1169 171:187 172:12 173:1640 174:680 175:559 176:1360 177:2633 178:1946 179:392 180:1617 181:939 182:1418 183:499 184:636 185:1187 186:2795 187:1440 188:1965 189:1277 190:7326 191:9 192:7038 193:5417 194:4017 195:3384 196:1353 197:1084 198:4823 199:5539 200:6058 201:2536 202:9070 203:8904 204:4509 205:2639 206:2893 207:2846 208:3947 209:3716 210:3078 211:1624 212:2154 213:1972 214:883 215:83 216:5425 217:1726 218:610 219:324 220:1268 221:593 222:334 223:569 End of report From sil at infiltrated.net Fri Jan 17 19:25:42 2014 From: sil at infiltrated.net (J. Oquendo) Date: Fri, 17 Jan 2014 13:25:42 -0600 Subject: Oklahoma State Univ. Message-ID: <20140117192542.GA79498@infiltrated.net> Yes I know there is UNISOG, not on it anymore. Can someone on that list either forward, or put me in touch with one in the know there (AS5078) concerning things malware related appreciated. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF From jtk at cymru.com Fri Jan 17 19:50:19 2014 From: jtk at cymru.com (John Kristoff) Date: Fri, 17 Jan 2014 13:50:19 -0600 Subject: Oklahoma State Univ. In-Reply-To: <20140117192542.GA79498@infiltrated.net> References: <20140117192542.GA79498@infiltrated.net> Message-ID: <20140117135019.39b04ae3@localhost> On Fri, 17 Jan 2014 13:25:42 -0600 "J. Oquendo" wrote: > Yes I know there is UNISOG, not on it anymore. Can someone > on that list either forward, or put me in touch with one > in the know there (AS5078) concerning things malware related > appreciated. UNISOG no longer exists. The REN-ISAC community has, mostly, replaced it. Have you just tried contacting their security folks directly? Chances are usually high if an .edu has a dedicated security staff and web site, that is probably the best place to go: Alternatively, REN-ISAC is always helpful if you want to go through them for some reason. John From sil at infiltrated.net Fri Jan 17 19:36:19 2014 From: sil at infiltrated.net (J. Oquendo) Date: Fri, 17 Jan 2014 13:36:19 -0600 Subject: Oklahoma State Univ. In-Reply-To: <20140117135019.39b04ae3@localhost> References: <20140117192542.GA79498@infiltrated.net> <20140117135019.39b04ae3@localhost> Message-ID: <20140117193619.GD79498@infiltrated.net> On Fri, 17 Jan 2014, John Kristoff wrote: > > UNISOG no longer exists. The REN-ISAC community has, mostly, replaced > it. > > Have you just tried contacting their security folks directly? Chances > are usually high if an .edu has a dedicated security staff and web > site, that is probably the best place to go: > > > > Alternatively, REN-ISAC is always helpful if you want to go through > them for some reason. > > John > I'd forgotten about the great folks at REN-ISAC. Was slapped in the head before this, so I emailed them. Thanks for the responses, sorry for the noise. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF From cidr-report at potaroo.net Fri Jan 17 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 17 Jan 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201401172200.s0HM00Zn060845@wattle.apnic.net> This report has been generated at Fri Jan 17 21:13:37 2014 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/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 10-01-14 488669 276220 11-01-14 489052 275870 12-01-14 489033 274065 13-01-14 489232 273802 14-01-14 489156 273952 15-01-14 488772 274453 16-01-14 489430 274529 17-01-14 489707 274209 AS Summary 46064 Number of ASes in routing system 18902 Number of ASes announcing only one prefix 4424 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 118904064 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 17Jan14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 489486 274234 215252 44.0% All ASes AS28573 3446 81 3365 97.6% NET Servi?os de Comunica??o S.A. AS6389 3028 56 2972 98.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS7029 4424 1666 2758 62.3% WINDSTREAM - Windstream Communications Inc AS17974 2737 186 2551 93.2% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS22773 2326 171 2155 92.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4766 2941 962 1979 67.3% KIXS-AS-KR Korea Telecom AS18881 1810 34 1776 98.1% Global Village Telecom AS1785 2151 400 1751 81.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS36998 1805 144 1661 92.0% SDN-MOBITEL AS10620 2701 1104 1597 59.1% Telmex Colombia S.A. AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath Corporation AS4323 2935 1511 1424 48.5% TWTC - tw telecom holdings, inc. AS7303 1741 448 1293 74.3% Telecom Argentina S.A. AS4755 1812 595 1217 67.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7545 2143 1027 1116 52.1% TPG-INTERNET-AP TPG Telecom Limited AS7552 1258 156 1102 87.6% VIETEL-AS-AP Viettel Corporation AS22561 1229 223 1006 81.9% AS22561 - CenturyTel Internet Holdings, Inc. AS9829 1574 693 881 56.0% BSNL-NIB National Internet Backbone AS18101 988 185 803 81.3% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS35908 900 107 793 88.1% VPLSNET - Krypt Technologies AS4808 1158 387 771 66.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS701 1504 773 731 48.6% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS24560 1092 368 724 66.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS8151 1394 673 721 51.7% Uninet S.A. de C.V. AS6983 1295 585 710 54.8% ITCDELTA - ITC^Deltacom AS13977 849 145 704 82.9% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS7738 846 148 698 82.5% Telemar Norte Leste S.A. AS855 747 57 690 92.4% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS4788 921 237 684 74.3% TMNET-AS-AP TM Net, Internet Service Provider AS6147 778 113 665 85.5% Telefonica del Peru S.A.A. Total 54580 13800 40780 74.7% Top 30 total Possible Bogus Routes 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 41.73.2.0/24 AS37004 41.73.10.0/24 AS37004 41.73.11.0/24 AS37004 41.73.12.0/24 AS37004 41.73.13.0/24 AS37004 41.73.15.0/24 AS37004 41.73.16.0/24 AS37004 41.73.18.0/24 AS37004 41.73.20.0/24 AS37004 41.73.21.0/24 AS37004 41.76.48.0/21 AS36969 MTL-AS 41.78.120.0/23 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.87.32.0/19 AS37242 41.190.72.0/23 AS37451 CongoTelecom 41.190.74.0/23 AS37451 CongoTelecom 41.191.92.0/22 AS37245 41.191.108.0/22 AS37004 41.191.108.0/24 AS37004 41.191.109.0/24 AS37004 41.191.110.0/24 AS37004 41.191.111.0/24 AS37004 41.217.208.0/22 AS37158 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.122.216.0/22 AS48727 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos 63.247.0.0/24 AS27609 63.247.1.0/24 AS27609 63.247.2.0/24 AS27609 63.247.3.0/24 AS27609 63.247.4.0/24 AS27609 63.247.5.0/24 AS27609 63.247.6.0/24 AS27609 63.247.7.0/24 AS27609 63.247.8.0/24 AS27609 63.247.9.0/24 AS27609 63.247.10.0/24 AS27609 63.247.11.0/24 AS27609 63.247.13.0/24 AS27609 63.247.14.0/24 AS27609 63.247.15.0/24 AS27609 63.247.16.0/24 AS27609 63.247.17.0/24 AS27609 63.247.18.0/24 AS27609 63.247.19.0/24 AS27609 63.247.20.0/24 AS27609 63.247.21.0/24 AS27609 63.247.22.0/24 AS27609 63.247.23.0/24 AS27609 63.247.24.0/24 AS27609 63.247.25.0/24 AS27609 63.247.26.0/24 AS27609 63.247.27.0/24 AS27609 63.247.28.0/24 AS27609 63.247.29.0/24 AS27609 64.25.16.0/23 AS19535 64.25.20.0/24 AS19535 64.25.21.0/24 AS19535 64.25.22.0/24 AS19535 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 64.111.0.0/20 AS8039 CCC-ASN-1 - Cinergy Communications 64.111.160.0/20 AS40551 64.111.160.0/24 AS40551 64.111.161.0/24 AS40551 64.111.162.0/24 AS40551 64.111.167.0/24 AS40551 64.111.169.0/24 AS40551 64.111.170.0/24 AS40551 64.111.171.0/24 AS40551 64.111.172.0/24 AS40551 64.111.173.0/24 AS40551 64.111.174.0/24 AS40551 64.111.175.0/24 AS40551 64.119.240.0/22 AS26072 64.119.240.0/23 AS26072 64.119.242.0/23 AS26072 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.202.48.0/22 AS23380 64.202.52.0/23 AS23380 64.202.54.0/24 AS23380 64.202.55.0/24 AS23380 64.202.56.0/22 AS23380 64.202.60.0/24 AS23380 64.202.61.0/24 AS23380 64.202.62.0/24 AS23380 64.202.63.0/24 AS23380 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.11.112.0/20 AS14572 66.55.96.0/23 AS17203 66.55.98.0/24 AS17203 66.55.99.0/24 AS17203 66.55.100.0/22 AS17203 66.55.102.0/23 AS17203 66.55.104.0/21 AS17203 66.159.98.0/24 AS17206 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc. 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 66.206.208.0/22 AS23380 66.206.211.0/24 AS14288 MPINET - MPInet 66.206.212.0/24 AS23380 66.206.213.0/24 AS14288 MPINET - MPInet 66.206.214.0/24 AS23380 66.206.215.0/24 AS23380 66.206.216.0/23 AS14288 MPINET - MPInet 66.206.218.0/23 AS23380 66.206.220.0/22 AS23380 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.254.160.0/20 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.176.0/21 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.184.0/22 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 67.21.144.0/22 AS174 COGENT Cogent/PSI 67.21.148.0/22 AS174 COGENT Cogent/PSI 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.232.0/21 AS6246 AVALONTEL - AvalonTel 74.112.100.0/22 AS16764 74.113.200.0/23 AS46939 74.114.52.0/22 AS40818 74.114.52.0/23 AS40818 74.114.52.0/24 AS40818 74.114.53.0/24 AS40818 74.114.54.0/23 AS40818 74.114.54.0/24 AS40818 74.114.55.0/24 AS40818 74.114.140.0/22 AS32757 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 74.118.132.0/22 AS5117 77.243.80.0/24 AS42597 77.243.81.0/24 AS42597 77.243.88.0/24 AS42597 77.243.91.0/24 AS42597 77.243.94.0/24 AS42597 77.243.95.0/24 AS42597 80.248.64.0/20 AS30982 CAFETG AS de CAFE Informatique 80.248.64.0/21 AS8513 SKYVISION SkyVision Global Networks Ltd 80.248.64.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.65.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.66.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.67.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.68.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.69.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.70.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.71.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.72.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.73.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.74.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.75.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.76.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.77.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.78.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.79.0/24 AS30982 CAFETG AS de CAFE Informatique 80.250.32.0/22 AS37106 ODUA-AS 85.202.160.0/20 AS44404 91.193.60.0/22 AS3356 LEVEL3 Level 3 Communications 91.195.66.0/23 AS3356 LEVEL3 Level 3 Communications 91.197.36.0/22 AS43359 91.199.90.0/24 AS44330 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD 91.207.1.0/24 AS174 COGENT Cogent/PSI 91.207.152.0/24 AS64100 91.207.153.0/24 AS64100 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal 91.220.176.0/24 AS16265 LEASEWEB LeaseWeb B.V. 91.229.182.0/24 AS56960 91.229.186.0/24 AS56967 93.190.8.0/24 AS47254 93.190.9.0/24 AS47254 93.190.10.0/24 AS47254 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.11.1.0/24 AS9822 AMNET-AU-AP Amnet IT Services Pty Ltd 103.11.216.0/24 AS13208 103.11.217.0/24 AS13208 103.11.218.0/23 AS13117 KINGCORP-AS-IX Opennet Internet Exchange 103.11.219.0/24 AS13208 103.13.184.0/23 AS58674 103.15.228.0/22 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.228.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.230.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 107.161.112.0/20 AS46261 QUICKPACKET - QuickPacket, LLC 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 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 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange 151.216.128.0/17 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM" 151.216.128.0/18 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM" 151.216.192.0/18 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM" 164.40.184.0/24 AS19821 172.85.0.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 174.136.192.0/18 AS14572 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL 178.218.240.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.241.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.242.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.243.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.244.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.245.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.246.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.247.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.248.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.249.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.250.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.251.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.252.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.253.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.254.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.255.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS 190.93.176.0/20 AS26218 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A. 190.124.252.0/22 AS7303 Telecom Argentina S.A. 191.253.208.0/22 AS26280 Brasilnet Telecomunica??es Ltda ME 192.166.32.0/20 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.9.59.0/24 AS1257 TELE2 193.16.106.0/24 AS31539 193.16.145.0/24 AS31392 193.22.3.0/24 AS3209 VODANET Vodafone GmbH 193.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF 193.33.6.0/23 AS3356 LEVEL3 Level 3 Communications 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 193.178.217.0/24 AS20737 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc. 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH 193.254.218.0/23 AS25229 VOLIA-AS Kyivski Telekomunikatsiyni Merezhi LLC 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH 194.50.82.0/24 AS16276 OVH OVH Systems 194.63.152.0/22 AS3356 LEVEL3 Level 3 Communications 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service 194.126.219.0/24 AS34545 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd 195.28.168.0/23 AS8655 195.64.128.0/23 AS8751 MEDIASAT Media Sat SRL 195.85.194.0/24 AS3356 LEVEL3 Level 3 Communications 195.114.4.0/23 AS41158 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB 195.130.208.0/24 AS16265 LEASEWEB LeaseWeb B.V. 195.137.188.0/24 AS35657 195.149.119.0/24 AS3356 LEVEL3 Level 3 Communications 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA 195.234.156.0/24 AS25028 195.242.182.0/24 AS3356 LEVEL3 Level 3 Communications 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.18.112.0/20 AS1916 Associa??o Rede Nacional de Ensino e Pesquisa 200.23.189.0/24 AS57792 PROVITEX-AS PE Glazunov Yuriy Anatol'yevich 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 203.142.219.0/24 AS45149 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc. 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.115.110.0/23 AS53709 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc. 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp. 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 205.236.71.0/24 AS852 ASN852 - TELUS Communications Inc. 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.66.120.0/22 AS32757 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc. 208.69.192.0/23 AS6461 MFNX MFN - Metromedia Fiber Network 208.69.195.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 208.74.224.0/22 AS174 COGENT Cogent/PSI 208.75.152.0/21 AS32146 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc. 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.84.232.0/24 AS33131 208.84.234.0/24 AS33131 208.84.237.0/24 AS33131 208.84.238.0/24 AS33131 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.164.0/22 AS46099 208.92.224.0/22 AS32757 208.92.226.0/24 AS32757 209.161.96.0/20 AS8039 CCC-ASN-1 - Cinergy Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.193.112.0/20 AS209 ASN-QWEST-US NOVARTIS-DMZ-US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 212.119.32.0/19 AS12550 213.184.64.0/24 AS13071 213.184.65.0/24 AS13071 213.184.66.0/24 AS13071 213.184.67.0/24 AS13071 213.184.68.0/24 AS13071 213.184.69.0/24 AS13071 213.184.70.0/24 AS13071 213.184.71.0/24 AS13071 213.184.72.0/24 AS13071 213.184.73.0/24 AS13071 213.184.74.0/24 AS13071 213.184.75.0/24 AS13071 213.184.76.0/24 AS13071 213.184.77.0/24 AS13071 213.184.78.0/24 AS13071 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.14.64.0/20 AS14728 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Jan 17 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 17 Jan 2014 22:00:01 GMT Subject: BGP Update Report Message-ID: <201401172200.s0HM01Ok060862@wattle.apnic.net> BGP Update Report Interval: 09-Jan-14 -to- 16-Jan-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS14420 64462 2.7% 131.6 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 2 - AS36998 47173 2.0% 26.1 -- SDN-MOBITEL 3 - AS8402 42055 1.8% 20.9 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS4538 39647 1.7% 74.0 -- ERX-CERNET-BKB China Education and Research Network Center 5 - AS3816 34557 1.4% 45.3 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 6 - AS9829 32965 1.4% 25.9 -- BSNL-NIB National Internet Backbone 7 - AS4766 28582 1.2% 9.7 -- KIXS-AS-KR Korea Telecom 8 - AS14287 28224 1.2% 522.7 -- TRIAD-TELECOM - Triad Telecom, Inc. 9 - AS11492 25060 1.1% 21.0 -- CABLEONE - CABLE ONE, INC. 10 - AS13118 21089 0.9% 479.3 -- ASN-YARTELECOM OJSC Rostelecom 11 - AS4775 18816 0.8% 265.0 -- GLOBE-TELECOM-AS Globe Telecoms 12 - AS45271 18042 0.8% 60.1 -- ICLNET-AS-AP Idea Cellular Limited 13 - AS41691 17889 0.8% 777.8 -- SUMTEL-AS-RIPE Summa Telecom LLC 14 - AS7029 17500 0.7% 10.2 -- WINDSTREAM - Windstream Communications Inc 15 - AS27947 15966 0.7% 18.3 -- Telconet S.A 16 - AS28573 15547 0.7% 4.5 -- NET Servi?os de Comunica??o S.A. 17 - AS6713 14715 0.6% 25.3 -- IAM-AS 18 - AS45899 14430 0.6% 42.6 -- VNPT-AS-VN VNPT Corp 19 - AS59217 14028 0.6% 14028.0 -- AZONNELIMITED-AS-AP Azonne Limited 20 - AS27738 11726 0.5% 20.4 -- Ecuadortelecom S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS59217 14028 0.6% 14028.0 -- AZONNELIMITED-AS-AP Azonne Limited 2 - AS12922 6427 0.3% 6427.0 -- MULTITRADE-AS CEDACRI S.P.A. 3 - AS54465 7319 0.3% 2439.7 -- QPM-AS-1 - QuickPlay Media Inc. 4 - AS62431 2189 0.1% 2189.0 -- NCSC-IE-AS National Cyber Security Centre 5 - AS51861 1552 0.1% 1552.0 -- SHARED-AS Eric Dorr 6 - AS45808 1507 0.1% 1507.0 -- UTP-MY Bandar Seri Iskandar 7 - AS62751 1445 0.1% 1445.0 -- HSAUWC-AS - HSA-UWC 8 - AS28477 2466 0.1% 1233.0 -- UNIVERSIDAD AUTONOMA DEL ESTADO DE MORELOS 9 - AS56097 2311 0.1% 1155.5 -- JOISTER-AS Joister Group of Companies. 10 - AS30437 4470 0.2% 1117.5 -- GE-MS003 - General Electric Company 11 - AS33385 1097 0.1% 1097.0 -- QUOMATION - Quomation Insurance Services, Inc. 12 - AS44505 1024 0.0% 1024.0 -- FIBERNET FiberNet Communication LLC 13 - AS35181 10194 0.4% 1019.4 -- PWC Autonomous System Number for Public WareHouse Company 14 - AS57201 860 0.0% 860.0 -- EDF-AS Estonian Defence Forces 15 - AS7202 8401 0.3% 840.1 -- FAMU - Florida A & M University 16 - AS60345 1663 0.1% 831.5 -- NBITI-AS Nahjol Balagheh International Research Institution 17 - AS16561 1565 0.1% 782.5 -- ARIBANETWORK Ariba Inc. Autonomous System 18 - AS41691 17889 0.8% 777.8 -- SUMTEL-AS-RIPE Summa Telecom LLC 19 - AS6629 8933 0.4% 687.2 -- NOAA-AS - NOAA 20 - AS24185 1227 0.1% 613.5 -- I-FLEX-AS I-FLEX Solutions Limited, Software Development, Mumbai, India TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/20 21046 0.8% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 103.243.164.0/22 14028 0.6% AS59217 -- AZONNELIMITED-AS-AP Azonne Limited 3 - 89.221.206.0/24 10210 0.4% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 4 - 85.239.28.0/24 10157 0.4% AS35181 -- PWC Autonomous System Number for Public WareHouse Company 5 - 120.28.62.0/24 9299 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 6 - 222.127.0.0/24 9295 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 7 - 192.58.232.0/24 8898 0.3% AS6629 -- NOAA-AS - NOAA 8 - 85.249.160.0/20 7608 0.3% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 9 - 206.152.15.0/24 7307 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc. 10 - 194.105.61.0/24 6427 0.2% AS12922 -- MULTITRADE-AS CEDACRI S.P.A. 11 - 67.210.190.0/23 6323 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. 12 - 208.70.20.0/22 5651 0.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 13 - 208.88.232.0/22 5629 0.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 14 - 208.73.244.0/22 5629 0.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 15 - 208.78.116.0/22 5627 0.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 16 - 216.162.0.0/20 5627 0.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 17 - 199.187.118.0/24 4951 0.2% AS11054 -- LIVEPERSON LivePerson, Inc 18 - 67.210.188.0/23 4884 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. 20 - 148.218.0.0/16 4702 0.2% AS11172 -- Alestra, S. de R.L. de C.V. AS28477 -- UNIVERSIDAD AUTONOMA DEL ESTADO DE MORELOS Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From mukom.tamon at gmail.com Sat Jan 18 04:09:58 2014 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Sat, 18 Jan 2014 08:09:58 +0400 Subject: Experiences with IPv6 and Routing Efficiency Message-ID: Hello folks, Does anyone have any experiences or insights to share on how more (or less) efficient routing is with IPv6? Any specific thoughts with respect to how the following characteristics help or not with routing efficiency? - fixed header size - Extension header chain - flow labels in header - no intermediate fragmentation - no checksums Thanks in advance. -- Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ ?When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran ------------------------------------------------------------------------------------------------------------------------------------------- From fw at deneb.enyo.de Sat Jan 18 10:37:23 2014 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 18 Jan 2014 11:37:23 +0100 Subject: best practice for advertising peering fabric routes In-Reply-To: (Patrick W. Gilmore's message of "Tue, 14 Jan 2014 22:11:06 -0500") References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> Message-ID: <87iothshi4.fsf@mid.deneb.enyo.de> * Patrick W. Gilmore: > NEVER EVER EVER put an IX prefix into BGP, IGP, or even static > route. An IXP LAN should not be reachable from any device not > directly attached to that LAN. Period. > > Doing so endangers your peers & the IX itself. It is on the order of > not implementing BCP38, except no one has the (lame, ridiculous, > idiotic, and pure cost-shifting BS) excuse that they "can't" do > this. Any ideas why DE-CIX doesn't enforce this? One advantage is that IXP participants can perform emergency maintenance if they have isolated their IXP router from their own network. From nick at foobar.org Sat Jan 18 12:22:08 2014 From: nick at foobar.org (Nick Hilliard) Date: Sat, 18 Jan 2014 12:22:08 +0000 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: References: Message-ID: <52DA71F0.50306@foobar.org> On 18/01/2014 04:09, Mukom Akong T. wrote: > Does anyone have any experiences or insights to share on how more (or > less) efficient routing is with IPv6? Any specific thoughts with respect to > how the following characteristics help or not with routing efficiency? > - fixed header size > - Extension header chain > - flow labels in header > - no intermediate fragmentation > - no checksums extension headers are a poor idea because it's troublesome to process them on cheap hardware. Because of this, packets with any sort of extension headers are routinely dropped by a large percentage of organisations. Flow labels are generally unused (i.e. set to zero by many host stacks). Nick From saku at ytti.fi Sat Jan 18 13:00:18 2014 From: saku at ytti.fi (Saku Ytti) Date: Sat, 18 Jan 2014 15:00:18 +0200 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: <52DA71F0.50306@foobar.org> References: <52DA71F0.50306@foobar.org> Message-ID: <20140118130018.GA10740@pob.ytti.fi> On (2014-01-18 12:22 +0000), Nick Hilliard wrote: > On 18/01/2014 04:09, Mukom Akong T. wrote: > > Does anyone have any experiences or insights to share on how more (or > > less) efficient routing is with IPv6? Any specific thoughts with respect to > > how the following characteristics help or not with routing efficiency? > > - fixed header size > > - Extension header chain > > - flow labels in header > > - no intermediate fragmentation > > - no checksums > > extension headers are a poor idea because it's troublesome to process them > on cheap hardware. Because of this, packets with any sort of extension > headers are routinely dropped by a large percentage of organisations. Flow > labels are generally unused (i.e. set to zero by many host stacks). Fully agreed. Main issues in IPv6 in my POV 1. EH - allows by passing L4 ACL matches in practical devices - EH could be packet long, 64k, i.e. L4 might be in fragments - some HW simply silently drops packet with more EH than it can parse - some HW punt packets with EH they can't parse 2. lack of checksum - in some instances packet corruption maybe impossible to detect in network 3. solicited-node multicast in LAN - replaces broadcast 'problem' with vastly harder problem - likely most practical deployments will just use traditional flooding 4. large lans - no really ipv6's fault, but addressing policy's fault - due to vast scale, large lan adds hard to solve dos vectors I think IPv6 was probably designed in somewhat unfortunate time, when L2 was already all ASIC, but maybe not everyone/most saw that L3 would be too, perhaps it could have used more interdisciplinary cooperation. But none of those are really show-stoppers, and perfect is enemy of done. And hindsight is 20/20. Maybe instead of attempting to packet IPSEC as mandatory on it (now dropped), it should have done new mandatory PKI based L4, it could have been the selling point which pushes adoptation. -- ++ytti From mukom.tamon at gmail.com Sat Jan 18 16:07:59 2014 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Sat, 18 Jan 2014 20:07:59 +0400 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: <20140118054256.GA25595@vacation.karoshi.com> References: <20140118054256.GA25595@vacation.karoshi.com> Message-ID: On 18 Jan 2014 09:42, wrote: > > > please define "efficient" in this context. Would a routing device process (while forwarding for example) more IPv6 packets than IPv4? Not a dictionary definition > > /bill > > On Sat, Jan 18, 2014 at 08:09:58AM +0400, Mukom Akong T. wrote: > > Hello folks, > > > > Does anyone have any experiences or insights to share on how more (or > > less) efficient routing is with IPv6? Any specific thoughts with respect to > > how the following characteristics help or not with routing efficiency? > > - fixed header size > > - Extension header chain > > - flow labels in header > > - no intermediate fragmentation > > - no checksums > > > > Thanks in advance. > > > > -- > > > > Mukom Akong T. > > > > http://about.me/perfexcellence | twitter: @perfexcellent > > ------------------------------------------------------------------------------------------------------------------------------------------ > > ?When you work, you are the FLUTE through whose lungs the whispering of the > > hours turns to MUSIC" - Kahlil Gibran > > ------------------------------------------------------------------------------------------------------------------------------------------- From mark.tinka at seacom.mu Sat Jan 18 17:49:44 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 18 Jan 2014 19:49:44 +0200 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: References: Message-ID: <201401181949.47926.mark.tinka@seacom.mu> On Saturday, January 18, 2014 06:09:58 AM Mukom Akong T. wrote: > Does anyone have any experiences or insights to share on > how more (or less) efficient routing is with IPv6? Any > specific thoughts with respect to how the following > characteristics help or not with routing efficiency? - > fixed header size > - Extension header chain > - flow labels in header > - no intermediate fragmentation > - no checksums One thing to think about is routing efficiency. At this time, networks that employ MPLS-TE for IPv4, and run native IPv6, have challenges doing the same for IPv6, mostly because it's not possible to point IPv6 traffic into MPLS-TE tunnels built over an IPv4 control plane. If you are doing 6PE, this could be possible, but most vendors can't do the former. More native IPv6 control planes for MPLS (and by extension, MPLS-TE) will mean that IPv6 traffic will travel the same path as IPv4 traffic in MPLS-TE'd networks. When that will be remains to be seen. Until then, the most we can do for native IPv6 traffic is fiddle around with IGP metrics, to obtain some kind of reasonable TE. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Sat Jan 18 17:51:10 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 18 Jan 2014 19:51:10 +0200 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: References: <20140118054256.GA25595@vacation.karoshi.com> Message-ID: <201401181951.11494.mark.tinka@seacom.mu> On Saturday, January 18, 2014 06:07:59 PM Mukom Akong T. wrote: > Would a routing device process (while forwarding for > example) more IPv6 packets than IPv4? It could (as a function of raw traffic). What's the concern, unless we misunderstand? Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From jvanoppen at spectrumnet.us Sat Jan 18 18:30:24 2014 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Sat, 18 Jan 2014 18:30:24 +0000 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: <201401181949.47926.mark.tinka@seacom.mu> References: <201401181949.47926.mark.tinka@seacom.mu> Message-ID: This is exactly what pushed us into 6PE... it was the only way to make performance similar to v4 from a routing standpoint. John @ AS11404 From joelja at bogus.com Sat Jan 18 18:55:33 2014 From: joelja at bogus.com (joel jaeggli) Date: Sat, 18 Jan 2014 10:55:33 -0800 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: References: <201401181949.47926.mark.tinka@seacom.mu> Message-ID: <52DACE25.1060500@bogus.com> On 1/18/14, 10:30 AM, John van Oppen wrote: > This is exactly what pushed us into 6PE... it was the only way to make performance similar to v4 from a routing standpoint. This statement is a bit facile... What platform are you referring to? > John @ AS11404 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From martin.pels at ams-ix.net Sat Jan 18 19:23:52 2014 From: martin.pels at ams-ix.net (Martin Pels) Date: Sat, 18 Jan 2014 20:23:52 +0100 Subject: best practice for advertising peering fabric routes In-Reply-To: <818A55E6-40E6-4106-B012-8F70CB16676E@ufp.org> References: <1389750938.95176.YahooMailNeo@web181605.mail.ne1.yahoo.com> <1DE560B4-092A-4C10-B3B4-08386F5B400A@ufp.org> <5365528F-94F6-4782-99E8-E8C85810F4E6@ianai.net> <14EE0086-2C8F-4A0A-AC19-52848832BC15@ufp.org> <166C4D5B-DA53-4D3A-BA9D-633D03E1FD35@arbor.net> <818A55E6-40E6-4106-B012-8F70CB16676E@ufp.org> Message-ID: <20140118202352.0ec039d0@fizzix> Hello Leo, On Wed, 15 Jan 2014 08:18:13 -0600 Leo Bicknell wrote: > This whole problem smacks to me of exchange points that are "too big to fail". Since some of these exchanges are so big, everyone else must bend to their needs. I think the world would be a better place if some of these were broken up into smaller exchanges and they imposed less restrictions on their participants. You forgot to add "and would break down on a weekly basis". The restrictions that IXPs impose on their customers have nothing to do with the size of their peering LAN, but everything with offering a reliable service to these same customers. Kind regards, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mukom.tamon at gmail.com Sun Jan 19 03:55:04 2014 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Sun, 19 Jan 2014 07:55:04 +0400 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: <201401181951.11494.mark.tinka@seacom.mu> References: <20140118054256.GA25595@vacation.karoshi.com> <201401181951.11494.mark.tinka@seacom.mu> Message-ID: Thank you all for your insightful responses (please keep them coming). On Sat, Jan 18, 2014 at 9:51 PM, Mark Tinka wrote: > It could (as a function of raw traffic). > > What's the concern, unless we misunderstand? > Was just trying to get more info from large networks about whether how some of the things that make theoretical logical sense actually work out in practice that way e.g. whether fixed header size and the fewer headers required to decode to read an IPv6 packet (with respect to IPv4) really may provide some signifiant performance advantages. I do realise that question might be difficult to prove on a real network that runs dual stack. Since the existence of IPv4 on both control and data planes may have consequences that we don't immediately understand. -- Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ ?When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran ------------------------------------------------------------------------------------------------------------------------------------------- From mukom.tamon at gmail.com Sun Jan 19 04:00:44 2014 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Sun, 19 Jan 2014 08:00:44 +0400 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: <52DA71F0.50306@foobar.org> References: <52DA71F0.50306@foobar.org> Message-ID: On Sat, Jan 18, 2014 at 4:22 PM, Nick Hilliard wrote: > extension headers are a poor idea because it's troublesome to process them > on cheap hardware. > Have you found them to be more troublesome to process than IPv4 options are/were? > Because of this, packets with any sort of extension > headers are routinely dropped by a large percentage of organisations. Flow > labels are generally unused (i.e. set to zero by many host stacks). > -- Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ ?When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran ------------------------------------------------------------------------------------------------------------------------------------------- From mukom.tamon at gmail.com Sun Jan 19 04:08:26 2014 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Sun, 19 Jan 2014 08:08:26 +0400 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: <20140118130018.GA10740@pob.ytti.fi> References: <52DA71F0.50306@foobar.org> <20140118130018.GA10740@pob.ytti.fi> Message-ID: Thank you for your responses Saku, On Sat, Jan 18, 2014 at 5:00 PM, Saku Ytti wrote: > > > 2. lack of checksum > - in some instances packet corruption maybe impossible to detect in > network > How prevalent is this problem? There might be not point fixing a problem with a 0.2% probability of occurring, especially as it might be cheaper to detect and fix the errors at the application layer. > > 3. solicited-node multicast in LAN > - replaces broadcast 'problem' with vastly harder problem > - likely most practical deployments will just use traditional flooding > Could you please explain how broadcast is better than solicited node multicast. In any case we aren't getting round that for now and it is deeply imbedded in NDP. I am interested in your negative experiences with solicited node multicasts. > > 4. large lans > - no really ipv6's fault, but addressing policy's fault > - due to vast scale, large lan adds hard to solve dos vectors > Just because you can have 2^64 possible hosts on a LAN still doesn't mean we through principles of good LAN design out the door. :-) So I'd say it's rather the fault of shoddy network design rather than address policy. > > -- Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ ?When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran ------------------------------------------------------------------------------------------------------------------------------------------- From geier at geier.ne.tz Sun Jan 19 07:19:21 2014 From: geier at geier.ne.tz (Frank Habicht) Date: Sun, 19 Jan 2014 10:19:21 +0300 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: References: <52DA71F0.50306@foobar.org> Message-ID: <52DB7C79.1020808@geier.ne.tz> On 1/19/2014 7:00 AM, Mukom Akong T. wrote: > On Sat, Jan 18, 2014 at 4:22 PM, Nick Hilliard wrote: >> extension headers are a poor idea because it's troublesome to process them >> on cheap hardware. > > Have you found them to be more troublesome to process than IPv4 options > are/were? at what position in the packet is the tcp port? a) in v4 b) in v6 c) v6 with a few extension headers now program a chip to filter based on this port number... Frank From sthaug at nethelp.no Sun Jan 19 07:58:12 2014 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sun, 19 Jan 2014 08:58:12 +0100 (CET) Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: References: <201401181951.11494.mark.tinka@seacom.mu> Message-ID: <20140119.085812.74730056.sthaug@nethelp.no> > Was just trying to get more info from large networks about whether how some > of the things that make theoretical logical sense actually work out in > practice that way e.g. whether fixed header size and the fewer headers > required to decode to read an IPv6 packet (with respect to IPv4) really may > provide some signifiant performance advantages. So far, all indications are that the fixed header size means nothing, in terms of speed, but the *extension* headers are a significant complication and source of problems. Some of the other claims (e.g. more secure because IPsec is always available) are simply wrong - there is plenty of IPv6 equipment that doesn't offer IPsec. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From mysidia at gmail.com Sun Jan 19 08:57:58 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 19 Jan 2014 02:57:58 -0600 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: <20140119.085812.74730056.sthaug@nethelp.no> References: <201401181951.11494.mark.tinka@seacom.mu> <20140119.085812.74730056.sthaug@nethelp.no> Message-ID: On Sun, Jan 19, 2014 at 1:58 AM, wrote: >Some of the other claims (e.g. more secure because IPsec is always >available) are simply wrong - there is plenty of IPv6 equipment that >doesn't offer IPsec. The claim of more secure would really be wrong, even if all IPv6 equipment supported IPsec. Aside from: Encrypting the transport between all the LAN hosts does not assure security in general ----- not against common attacks. Aside from: Encrypting the transport between hosts on a LAN can mask malicious activity from Intrusion Detection Systems, that would otherwise capture packets between hosts, and check against a signature database; showing possible signs of compromise, or possible attempts to exploit a vulnerability. The problem is; most users don't have any understanding of IPsec, AND it requires manual configuration ---- IPv6 and IPsec standards don't provide any method of automatic configuration interoperable between various hosts, AND users are unlikely to take the steps to manually configure IPsec. > > So far, all indications are that the fixed header size means nothing, in terms of speed, but the *extension* headers are a significant > complication and source of problems. > > I believe this is correct; The important thing is that specific pre-defined bit positions in the header correspond to specific items, and therefore, as few bits as possible need to be inspected, before the decision is made -- which buffer to copy the packet into. And.... the removal of some headers to extensions are more like a minor reduction in bandwidth overhead, in exchange for a large amount of extra work, processing any packets that use the extension headers. On the other hand; Given Moore's law, and the much quicker rate that CPU power is expanding at cost $X than network bandwidth ----- it could actually make a great deal of sense though to take on the extra complexity and sacrifice router CPU efficiency, in exchange, for lower header overhead sizes. "Problems" are due to vendors with buggy implementations. The extension headers add complexity., but it could still be a lot better than the alternative -- larger total header size, resulting in fewer bytes of useful data payload per IP packet. Fewer bytes of payload per packet = Fewer user databits per second that can be sent over a link of a particular bitrate, before the link is congested. . > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > > -- -Mysid From jvanoppen at spectrumnet.us Sun Jan 19 09:10:02 2014 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Sun, 19 Jan 2014 09:10:02 +0000 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: <52DACE25.1060500@bogus.com> References: <201401181949.47926.mark.tinka@seacom.mu> <52DACE25.1060500@bogus.com> Message-ID: We ended up with 6PE to make the v6 support on our cisco based network behave the same way as v4, IE use TE tunnels, etc. Given the v4 MPLS this was the only real way to make it the same. -----Original Message----- From: joel jaeggli [mailto:joelja at bogus.com] Sent: Saturday, January 18, 2014 10:56 AM To: John van Oppen; 'mark.tinka at seacom.mu'; nanog at nanog.org Subject: Re: Experiences with IPv6 and Routing Efficiency On 1/18/14, 10:30 AM, John van Oppen wrote: > This is exactly what pushed us into 6PE... it was the only way to make performance similar to v4 from a routing standpoint. This statement is a bit facile... What platform are you referring to? > John @ AS11404 > > From saku at ytti.fi Sun Jan 19 10:10:47 2014 From: saku at ytti.fi (Saku Ytti) Date: Sun, 19 Jan 2014 12:10:47 +0200 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: References: <201401181949.47926.mark.tinka@seacom.mu> <52DACE25.1060500@bogus.com> Message-ID: <20140119101047.GA17645@pob.ytti.fi> On (2014-01-19 09:10 +0000), John van Oppen wrote: > We ended up with 6PE to make the v6 support on our cisco based network behave the same way as v4, IE use TE tunnels, etc. Given the v4 MPLS this was the only real way to make it the same. Fully agreed. I have no problem being in 6PE until fork-lift in some future to IPv6 core and 4PE. Signalling AFI in core and AFI sold to customer have little codependency. People have too sentimental view on this, if you label your IPv4 it is silly not to run 6PE, you're just creating complexity and removing functionality. -- ++ytti From mark.tinka at seacom.mu Sun Jan 19 12:38:10 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 19 Jan 2014 14:38:10 +0200 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: <20140119101047.GA17645@pob.ytti.fi> References: <20140119101047.GA17645@pob.ytti.fi> Message-ID: <201401191438.13336.mark.tinka@seacom.mu> On Sunday, January 19, 2014 12:10:47 PM Saku Ytti wrote: > Fully agreed. I have no problem being in 6PE until > fork-lift in some future to IPv6 core and 4PE. Assuming your addressing will continue to grow on IPv6, and remain reasonably static on IPv4, your forklift should allow you to remain native on both (on the basis that at that time, we do have native control planes both for MPLSv4 and MPLSv6, of course). So "4|6PE" would not be necessary. Personally, I think it's unnecessary labor to remove IPv4 in the future, especially when it's not expanding. One is welcome to do this, of course, if they are really bored :-). Removing native IPv4 in the future only to replace it with 4PE seems quite complex, to me. > People have too sentimental view on this, if you label > your IPv4 it is silly not to run 6PE, you're just > creating complexity and removing functionality. Turning on native IPv6 in your core is not adding complexity, I think. Yes, agree that you may lose parity between MPLS-TEv4 and TEv6 as of today, but some would say that MPLS-TE adds quite a bit complexity today, especially if used on a long-term basis. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From nick at foobar.org Sun Jan 19 16:15:34 2014 From: nick at foobar.org (Nick Hilliard) Date: Sun, 19 Jan 2014 16:15:34 +0000 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: References: <52DA71F0.50306@foobar.org> <20140118130018.GA10740@pob.ytti.fi> Message-ID: <52DBFA26.2070901@foobar.org> On 19/01/2014 04:08, Mukom Akong T. wrote: > Just because you can have 2^64 possible hosts on a LAN still doesn't mean > we through principles of good LAN design out the door. :-) So I'd say it's > rather the fault of shoddy network design rather than address policy. no, it's a problem with the number of addresses available on the LAN; nothing to do with shoddy network design. Each device on the LAN will have a certain amount of capacity for caching neighbour addressing details. If some third party decides to send packets to a massive number of addresses on that LAN, then the router which is forwarding these packets will attempt to perform ND for these addresses. This can trivially be used as a cache exhaustion attack, which can cause regular connectivity on that LAN to be trashed. Nick From nick at foobar.org Sun Jan 19 16:11:07 2014 From: nick at foobar.org (Nick Hilliard) Date: Sun, 19 Jan 2014 16:11:07 +0000 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: References: <52DA71F0.50306@foobar.org> Message-ID: <52DBF91B.5030801@foobar.org> On 19/01/2014 04:00, Mukom Akong T. wrote: > Have you found them to be more troublesome to process than IPv4 options > are/were? The problem is that you can have long EH chains, with one after another. Generally speaking, most hardware forwarding engines will perform a lookup based on the first N bytes of a packet. If arbitrary length EHs are not supported by the hardware, then you have 3 options: forward the packets unilaterally, drop the packets unilaterally or punt to a cpu/npu. Punting and forwarding both open up denial of service attacks for hardware-forwarded routers, so generally the only sensible option is to drop packets with long EH chains. Nick From saku at ytti.fi Sun Jan 19 17:05:08 2014 From: saku at ytti.fi (Saku Ytti) Date: Sun, 19 Jan 2014 19:05:08 +0200 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: <52DBF91B.5030801@foobar.org> References: <52DA71F0.50306@foobar.org> <52DBF91B.5030801@foobar.org> Message-ID: <20140119170508.GA4295@pob.ytti.fi> On (2014-01-19 16:11 +0000), Nick Hilliard wrote: > attacks for hardware-forwarded routers, so generally the only sensible > option is to drop packets with long EH chains. I think sensible is to handle HW when possible and punt rate-limited when must. Dropping standard compliant data seems dubious at best. Now should it be standard complaint? http://tools.ietf.org/html/draft-ietf-6man-oversized-header-chain-09 is looking to restrict EH more, I contacted authors, hoping even more limitation than what it currently suggests, they thought 6man would never accept as strict limits as I suggested. My suggestion is that IP + EH (not L4) SHOULD NOT span over 128B and implementation MAY drop frames with larger headers. -- ++ytti From joelja at bogus.com Sun Jan 19 17:52:38 2014 From: joelja at bogus.com (joel jaeggli) Date: Sun, 19 Jan 2014 09:52:38 -0800 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: <20140119170508.GA4295@pob.ytti.fi> References: <52DA71F0.50306@foobar.org> <52DBF91B.5030801@foobar.org> <20140119170508.GA4295@pob.ytti.fi> Message-ID: <52DC10E6.1000400@bogus.com> On 1/19/14, 9:05 AM, Saku Ytti wrote: > On (2014-01-19 16:11 +0000), Nick Hilliard wrote: > >> attacks for hardware-forwarded routers, so generally the only sensible >> option is to drop packets with long EH chains. > > I think sensible is to handle HW when possible and punt rate-limited when > must. Dropping standard compliant data seems dubious at best. There are routers and switches that by design have no recourse to a software forwarding path. It doesn't make a lot of sense to have device that has a nominal capacity of several Tb/s attempt to punt packets up to a control-plane processor that's gig-e connected. > Now should it be standard complaint? > > http://tools.ietf.org/html/draft-ietf-6man-oversized-header-chain-09 is > looking to restrict EH more, I contacted authors, hoping even more limitation > than what it currently suggests, they thought 6man would never accept as > strict limits as I suggested. > My suggestion is that IP + EH (not L4) SHOULD NOT span over 128B and > implementation MAY drop frames with larger headers. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From saku at ytti.fi Sun Jan 19 18:17:38 2014 From: saku at ytti.fi (Saku Ytti) Date: Sun, 19 Jan 2014 20:17:38 +0200 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: <52DC10E6.1000400@bogus.com> References: <52DA71F0.50306@foobar.org> <52DBF91B.5030801@foobar.org> <20140119170508.GA4295@pob.ytti.fi> <52DC10E6.1000400@bogus.com> Message-ID: <20140119181738.GA13786@pob.ytti.fi> On (2014-01-19 09:52 -0800), joel jaeggli wrote: > It doesn't make a lot of sense to have device that has a nominal > capacity of several Tb/s attempt to punt packets up to a control-plane > processor that's gig-e connected. You already punt IP options, vast majority of deployments won't see significant pps for IPV6 EH. As long as you police them to acceptable rate before punt and you don't share the policer with other punt masks, it is the right thing to do, blind dropping standard compliant packets not. -- ++ytti From mukom.tamon at gmail.com Sun Jan 19 18:28:27 2014 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Sun, 19 Jan 2014 22:28:27 +0400 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: <52DBFA26.2070901@foobar.org> References: <52DA71F0.50306@foobar.org> <20140118130018.GA10740@pob.ytti.fi> <52DBFA26.2070901@foobar.org> Message-ID: On Sun, Jan 19, 2014 at 8:15 PM, Nick Hilliard wrote: > If some third party decides to send packets > to a massive number of addresses on that LAN, then the router which is > forwarding these packets will attempt to perform ND for these addresses. > This can trivially be used as a cache exhaustion attack, which can cause > regular connectivity on that LAN to be trashed. > I totally forgot about this scenario. Yes it is a real problem. -- Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ ?When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran ------------------------------------------------------------------------------------------------------------------------------------------- From saku at ytti.fi Sun Jan 19 18:55:56 2014 From: saku at ytti.fi (Saku Ytti) Date: Sun, 19 Jan 2014 20:55:56 +0200 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: References: <52DA71F0.50306@foobar.org> <20140118130018.GA10740@pob.ytti.fi> Message-ID: <20140119185556.GA17952@pob.ytti.fi> On (2014-01-19 08:08 +0400), Mukom Akong T. wrote: > How prevalent is this problem? There might be not point fixing a problem > with a 0.2% probability of occurring, especially as it might be cheaper to > detect and fix the errors at the application layer. I have no data on prevalency. But just this week we caught issue where ingress PE was mangling packets on IP2MPLS encap and calculating correct FCS on the mangled frame. All egress PE routers logged IP checksum error, it was very rare, maybe 1 per 30min on average. If it was IPv6, no error would have been logged, and customers would receive their share of these, <1 per month per customer, for sure, we would have never have found this issue in IPv6 network. > Could you please explain how broadcast is better than solicited node > multicast. In any case we aren't getting round that for now and it is > deeply imbedded in NDP. I am interested in your negative experiences with > solicited node multicasts. It requires group state in switches, potentially 16M groups, switches typically support few thousands and only populate them in SW (but forward on HW once built). Several attack vectors there. > Just because you can have 2^64 possible hosts on a LAN still doesn't mean > we through principles of good LAN design out the door. :-) So I'd say it's > rather the fault of shoddy network design rather than address policy. Nick covered this, thanks. -- ++ytti From mark.tinka at seacom.mu Sun Jan 19 18:58:24 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 19 Jan 2014 20:58:24 +0200 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: <52DC10E6.1000400@bogus.com> References: <20140119170508.GA4295@pob.ytti.fi> <52DC10E6.1000400@bogus.com> Message-ID: <201401192058.27957.mark.tinka@seacom.mu> On Sunday, January 19, 2014 07:52:38 PM joel jaeggli wrote: > It doesn't make a lot of sense to have device that has a > nominal capacity of several Tb/s attempt to punt packets > up to a control-plane processor that's gig-e connected. Not that the control plane would forward said traffic at Gig-E speeds anyway. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From Valdis.Kletnieks at vt.edu Sun Jan 19 20:51:40 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 19 Jan 2014 15:51:40 -0500 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: Your message of "Sun, 19 Jan 2014 08:58:12 +0100." <20140119.085812.74730056.sthaug@nethelp.no> References: <201401181951.11494.mark.tinka@seacom.mu> <20140119.085812.74730056.sthaug@nethelp.no> Message-ID: <213460.1390164700@turing-police.cc.vt.edu> On Sun, 19 Jan 2014 08:58:12 +0100, sthaug at nethelp.no said: > Some of the other claims (e.g. more secure because IPsec is always > available) are simply wrong - there is plenty of IPv6 equipment that > doesn't offer IPsec. Given the incredible market penetration of IPsec on the v4 side of the fence, I guess we've found the true reason people aren't moving to IPv6. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From johnl at iecc.com Sun Jan 19 22:55:23 2014 From: johnl at iecc.com (John Levine) Date: 19 Jan 2014 22:55:23 -0000 Subject: Where does "Downstream server error" come from? Message-ID: <20140119225523.41144.qmail@joyce.lan> I had some problems with incoming mail that I tracked down to a configuration bug, two hosts on the same LAN configured to respond to the IP address of the MX. It's fixed now. While it was broken, attempts to send mail on some other systems got "421 Downstream server error." That is not a message that any of my mail software sends (I grepped for Downstream in the code, it's not there) so I presume it's from some middle box. Does anyone recognize the message, what produces it, and why? There was indeed stuff messed up downstream, but why turn it into a mystery error message? R's, John PS: I wonder how long it'll take for someone to suggest unhelpful configuration changes on my host to fix the problem. From michael at supermathie.net Sun Jan 19 23:33:24 2014 From: michael at supermathie.net (Michael Brown) Date: Sun, 19 Jan 2014 18:33:24 -0500 Subject: Where does "Downstream server error" come from? In-Reply-To: <20140119225523.41144.qmail@joyce.lan> Message-ID: <20140119233324.6099091.87371.2917@supermathie.net> From johnl at iecc.com Mon Jan 20 00:11:34 2014 From: johnl at iecc.com (John R. Levine) Date: 19 Jan 2014 19:11:34 -0500 Subject: Where does "Downstream server error" come from? In-Reply-To: <20140119233324.6099091.87371.2917@supermathie.net> References: <20140119233324.6099091.87371.2917@supermathie.net> Message-ID: > Perhaps the host prior to the ones that had the error were doing recipient checking? Nope, I got the error immediately after trying to connect, before it could even send EHLO. R's, John > M. > From: John Levine > Sent: Sunday, January 19, 2014 17:56 > To: nanog at nanog.org > Subject: Where does "Downstream server error" come from? > > I had some problems with incoming mail that I tracked down to a > configuration bug, two hosts on the same LAN configured to respond to > the IP address of the MX. It's fixed now. > > While it was broken, attempts to send mail on some other systems got > "421 Downstream server error." That is not a message that any of my > mail software sends (I grepped for Downstream in the code, it's not > there) so I presume it's from some middle box. > > Does anyone recognize the message, what produces it, and why? There > was indeed stuff messed up downstream, but why turn it into a mystery > error message? > > R's, > John > > PS: I wonder how long it'll take for someone to suggest unhelpful > configuration changes on my host to fix the problem. > > > Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From scott at doc.net.au Mon Jan 20 00:32:30 2014 From: scott at doc.net.au (Scott Howard) Date: Sun, 19 Jan 2014 16:32:30 -0800 Subject: Where does "Downstream server error" come from? In-Reply-To: <20140119225523.41144.qmail@joyce.lan> References: <20140119225523.41144.qmail@joyce.lan> Message-ID: I've come across this error (or something very similar to it) before. I can't remember the exact product, but it turned out to be a transparent SMTP proxy somewhere in the path - possibly on a UTM firewall, but I could be wrong about that part... Not overly helpful I know, but might point you in the right direction... Scott On Sun, Jan 19, 2014 at 2:55 PM, John Levine wrote: > I had some problems with incoming mail that I tracked down to a > configuration bug, two hosts on the same LAN configured to respond to > the IP address of the MX. It's fixed now. > > While it was broken, attempts to send mail on some other systems got > "421 Downstream server error." That is not a message that any of my > mail software sends (I grepped for Downstream in the code, it's not > there) so I presume it's from some middle box. > > Does anyone recognize the message, what produces it, and why? There > was indeed stuff messed up downstream, but why turn it into a mystery > error message? > > R's, > John > > PS: I wonder how long it'll take for someone to suggest unhelpful > configuration changes on my host to fix the problem. > > From bruns at 2mbit.com Mon Jan 20 01:02:22 2014 From: bruns at 2mbit.com (Brielle Bruns) Date: Sun, 19 Jan 2014 18:02:22 -0700 Subject: Where does "Downstream server error" come from? In-Reply-To: References: <20140119225523.41144.qmail@joyce.lan> Message-ID: <52DC759E.2000809@2mbit.com> On 1/19/14, 5:32 PM, Scott Howard wrote: > I've come across this error (or something very similar to it) before. I > can't remember the exact product, but it turned out to be a transparent > SMTP proxy somewhere in the path - possibly on a UTM firewall, but I could > be wrong about that part... > > Not overly helpful I know, but might point you in the right direction... > Almost sounds like one of those annoying consumer Antivirus programs with the smtp/imap/pop3 proxies that wedge themselves in between mail client connections. Trying to remember what the error it was giving the other day on the machine I worked on, when the proxy itself had been blocked by the local system's firewall... I'd have been curious if you got the same error message trying to go out on 587 instead of 25. Thinking about it, that error screams of something like what a multi-server Exchange setup would say if something went wrong on the backend. Not entirely helpful either, but... never know. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From contact at nullivex.com Mon Jan 20 01:09:56 2014 From: contact at nullivex.com (Bryan Tong) Date: Sun, 19 Jan 2014 18:09:56 -0700 Subject: Where does "Downstream server error" come from? In-Reply-To: <52DC759E.2000809@2mbit.com> References: <20140119225523.41144.qmail@joyce.lan> <52DC759E.2000809@2mbit.com> Message-ID: I was thinking that maybe the rogue host configured on the IP didn't have any mail software installed and it was just a random service returning the error message as it didn't know how to handle the request. On Sunday, January 19, 2014, Brielle Bruns wrote: > On 1/19/14, 5:32 PM, Scott Howard wrote: > >> I've come across this error (or something very similar to it) before. I >> can't remember the exact product, but it turned out to be a transparent >> SMTP proxy somewhere in the path - possibly on a UTM firewall, but I could >> be wrong about that part... >> >> Not overly helpful I know, but might point you in the right direction... >> >> > > Almost sounds like one of those annoying consumer Antivirus programs with > the smtp/imap/pop3 proxies that wedge themselves in between mail client > connections. > > Trying to remember what the error it was giving the other day on the > machine I worked on, when the proxy itself had been blocked by the local > system's firewall... > > I'd have been curious if you got the same error message trying to go out > on 587 instead of 25. > > Thinking about it, that error screams of something like what a > multi-server Exchange setup would say if something went wrong on the > backend. > > > Not entirely helpful either, but... never know. > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > > -- eSited LLC (701) 390-9638 From alex.lopez at opsys.com Sun Jan 19 23:06:18 2014 From: alex.lopez at opsys.com (Alexander Lopez) Date: Sun, 19 Jan 2014 23:06:18 +0000 Subject: Where does "Downstream server error" come from? In-Reply-To: <20140119225523.41144.qmail@joyce.lan> References: <20140119225523.41144.qmail@joyce.lan> Message-ID: I have seen this error whenever the destination server responds with some strange response, I have mostly seen it with iptables mucking packets. Problem occurs on the transport layer not the application so the application has no idea what to make of it... -------- Original message -------- From: John Levine Date:01/19/2014 5:57 PM (GMT-05:00) To: nanog at nanog.org Subject: Where does "Downstream server error" come from? I had some problems with incoming mail that I tracked down to a configuration bug, two hosts on the same LAN configured to respond to the IP address of the MX. It's fixed now. While it was broken, attempts to send mail on some other systems got "421 Downstream server error." That is not a message that any of my mail software sends (I grepped for Downstream in the code, it's not there) so I presume it's from some middle box. Does anyone recognize the message, what produces it, and why? There was indeed stuff messed up downstream, but why turn it into a mystery error message? R's, John PS: I wonder how long it'll take for someone to suggest unhelpful configuration changes on my host to fix the problem. From elouie at yahoo.com Tue Jan 21 00:57:13 2014 From: elouie at yahoo.com (Eric A Louie) Date: Mon, 20 Jan 2014 16:57:13 -0800 (PST) Subject: Dark fiber providers, Southern California Message-ID: <1390265833.84134.YahooMailNeo@web181605.mail.ne1.yahoo.com> Who would I start talking to if I wanted to lease "dark fiber" from point to point? I'm located in San Diego and am interested in leasing fiber from major datacenters in SD and LA I found Freedom Telecommunications (http://freedomtelecommunications.com) - doubtless there are others I can and should talk to. thanks Eric Louie From owen at delong.com Tue Jan 21 09:13:15 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 21 Jan 2014 01:13:15 -0800 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: <52DB7C79.1020808@geier.ne.tz> References: <52DA71F0.50306@foobar.org> <52DB7C79.1020808@geier.ne.tz> Message-ID: <4C6F9F07-E4E3-4E49-9F94-3DDC48B83BBD@delong.com> On Jan 18, 2014, at 23:19 , Frank Habicht wrote: > On 1/19/2014 7:00 AM, Mukom Akong T. wrote: >> On Sat, Jan 18, 2014 at 4:22 PM, Nick Hilliard wrote: >>> extension headers are a poor idea because it's troublesome to process them >>> on cheap hardware. >> >> Have you found them to be more troublesome to process than IPv4 options >> are/were? > > at what position in the packet is the tcp port? > a) in v4 Depends on the IPv4 options. > b) in v6 Assuming (based on (c) below), that this means in v6 without extension headers, then it will be at n+40 octets into the packet where n is the position of the desired port number (where desired is one of {source, destination} within the TCP header. Most of the (cheap) hardware that processes IPv4 punts packets with options to the slow path. In general, it depends on the IPv4 packet not containing options. > c) v6 with a few extension headers In this case, it will be at 40+o+n octets into the packet where o is the number of octets contained in headers prior to the TCP header and n is defined as in (b) above. > now program a chip to filter based on this port number... I think you might want to be more specific. After all, an ARM 9 is a chip which can easily be programmed to do so (in fact, I can point to iptables/ip6tables as running code which does this on the ARM 9). So... I suppose that whether your complaint has merit depends entirely on whether or not extension headers become more common on IPv6 packets than options have become on IPv4 packets or not and also on how hard it is to build fast-path hardware that bypasses extension headers that it does not care about. Since you only need to parse the first two fields of each extension header (Next Header Type and Header Length) to know everything you need to bypass the current header, it shouldn't be too hard to code that into a chip... Owen From geier at geier.ne.tz Tue Jan 21 10:52:15 2014 From: geier at geier.ne.tz (Frank Habicht) Date: Tue, 21 Jan 2014 13:52:15 +0300 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: <4C6F9F07-E4E3-4E49-9F94-3DDC48B83BBD@delong.com> References: <52DA71F0.50306@foobar.org> <52DB7C79.1020808@geier.ne.tz> <4C6F9F07-E4E3-4E49-9F94-3DDC48B83BBD@delong.com> Message-ID: <52DE515F.1040409@geier.ne.tz> Hi Owen, On 1/21/2014 12:13 PM, Owen DeLong wrote: > On Jan 18, 2014, at 23:19 , Frank Habicht wrote: >> c) v6 with a few extension headers > In this case, it will be at 40+o+n octets into the packet where o is the > number of octets contained in headers prior to the TCP header and n is > defined as in (b) above. my point tried to be that it can be hard for an ASIC to know 'o' >> now program a chip to filter based on this port number... > I think you might want to be more specific. After all, an ARM 9 is a > chip which can easily be programmed to do so (in fact, I can point to > iptables/ip6tables as running code which does this on the ARM 9). I was thinking about hardware that's forwarding packets "not in software" some of those boxes probably want to limit tcp ports 179 and 22. > So... I suppose that whether your complaint has merit depends entirely > on whether or not extension headers become more common on IPv6 packets > than options have become on IPv4 packets or not and also on how hard it > is to build fast-path hardware that bypasses extension headers that it > does not care about. Since you only need to parse the first two fields ^^^^ ? > of each extension header (Next Header Type and Header Length) ... recursively for all extension headers ... > to know > everything you need to bypass the current header, it shouldn't be too > hard to code that into a chip... who's done that so far? Up to what number of EHs or octet-length? Thanks, Frank From lorell at hathcock.org Tue Jan 21 16:46:26 2014 From: lorell at hathcock.org (Lorell Hathcock) Date: Tue, 21 Jan 2014 10:46:26 -0600 Subject: OSP Contractors in Lafayette, LA Message-ID: <03ba01cf16c8$53cd2fa0$fb678ee0$@hathcock.org> All: I am seeking referrals for an Outside Plant Fiber installation company that can operate in Lafayette, LA. Contracted activities would include: - Project Design and Planning - Project Management - Obtaining Permits - Boring - Trenching - Installation of Inner duct and conduit - Installation of OM3 fiber - Bonding and Grounding of Fiber - Installation of Fiber Locate Signal Transmission Equipment in Head End - Testing and Certification and Documentation of Installation Project will be on private property. Please respond offline directly to me. Sincerely, Lorell Hathcock From owen at delong.com Tue Jan 21 21:58:43 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 21 Jan 2014 13:58:43 -0800 Subject: Experiences with IPv6 and Routing Efficiency In-Reply-To: <52DE515F.1040409@geier.ne.tz> References: <52DA71F0.50306@foobar.org> <52DB7C79.1020808@geier.ne.tz> <4C6F9F07-E4E3-4E49-9F94-3DDC48B83BBD@delong.com> <52DE515F.1040409@geier.ne.tz> Message-ID: <9B9B7F9C-46B2-4E33-9EC2-99BEF82534F5@delong.com> On Jan 21, 2014, at 02:52 , Frank Habicht wrote: > Hi Owen, > > On 1/21/2014 12:13 PM, Owen DeLong wrote: >> On Jan 18, 2014, at 23:19 , Frank Habicht wrote: >>> c) v6 with a few extension headers >> In this case, it will be at 40+o+n octets into the packet where o is the >> number of octets contained in headers prior to the TCP header and n is >> defined as in (b) above. > > my point tried to be that it can be hard for an ASIC to know 'o' > >>> now program a chip to filter based on this port number... >> I think you might want to be more specific. After all, an ARM 9 is a >> chip which can easily be programmed to do so (in fact, I can point to >> iptables/ip6tables as running code which does this on the ARM 9). > > I was thinking about hardware that's forwarding packets "not in software" > some of those boxes probably want to limit tcp ports 179 and 22. The difference between hardware and software gets blurrier every day. For example, many of the "forwarding ASICs" today are actually FPGAs with "software" loaded into them to do certain forwarding tasks. Yes, I took it to extremes by proposing a more general purpose CPU, but the fact of the matter remains that traversing a header chain in software looking for a known header type that you care about actually isn't complex and can easily be implemented in hardware. The task boils down to: octet i = &packet header; while (headers_remaining && header_type != type_of_interest) { header_type = i[NEXT_HEADER]; i += (i[HDR_LEN]+1) * 8; if (header_type != 0 && header_type != 60 && header_type != 43 && header_type != 44 && header_type != 51 && header_type != 50 && header_type != 60 && header_type != 135) headers_remaining = 0; } if (headers_remaining) { INSPECT THIS HEADER and act accordingly; } else { Punt, header not present; } Not a particularly complex program for a modern ASIC, actually. Where you run into potential problems (and this can apply to IPv4 as well, though less likely) is if you get an IPv6 packet where the header chain is so unreasonably long that the header you want is not in the first fragment. With a minimum MTU of 1280 octets, it's almost impossible to create a legitimate packet with a header chain so long that this would be an issue. That is one of the reasons that there are proposals to consider such packets invalid and why I support those proposals. However, those have nothing to do with ASIC difficulty. The fragment problem is hard to solve no matter how much CPU you throw at it because unless you are the end receiving host, you cannot reliably expect to be able to perform reassembly. > >> So... I suppose that whether your complaint has merit depends entirely >> on whether or not extension headers become more common on IPv6 packets >> than options have become on IPv4 packets or not and also on how hard it >> is to build fast-path hardware that bypasses extension headers that it >> does not care about. Since you only need to parse the first two fields > ^^^^ ? >> of each extension header (Next Header Type and Header Length) > ... recursively for all extension headers ... Which in anything but the most contrived of cases is likely n=0 for 95+% of all (unencrypted) packets and likely n<4 for all others. Further, it's not recursively, it's repetitively. There is a difference. (See above. Note that the loop is _NOT_ recursive, it is repetitive. Recursive would be something like: sub parse_next_header(header) { char * i = header; HDR_PARSE_RESULT result; register char nh = i[NExT_HEADER]; if (nh != 0 && nh != 60 && nh != 43 && nh != 44 && nh != 51 && nh != 50 && nh != 60 && nh != 135) result = parse_next_header(i+(1+i[HDR_LEN])*8); // code to parse this header (modifies result accordingly) return (result); } This might be possible to do in an ASIC, but might be more difficult than the iterative solution proposed above. > >> to know >> everything you need to bypass the current header, it shouldn't be too >> hard to code that into a chip... > who's done that so far? I don't know. > Up to what number of EHs or octet-length? Why would the number of HEs or the octet-length (up to the maximum MTU supported by the box) matter in this question? I understand that if you do it recursively, you get into potential stack resource issues, but with an iterative approach looking for the header of interest, I don't see the issue. Owen From arulgobi at gmail.com Wed Jan 22 07:47:50 2014 From: arulgobi at gmail.com (arulgobinath emmanuel) Date: Wed, 22 Jan 2014 10:47:50 +0300 Subject: Remote Hand support Equinix Palo Alto Message-ID: Dear All, I'm searching RHS company who can do a decommission work at Equinix Palo Alto. Need to decommission and ship back the Router ( GSR) ( Need to handle the Logistic part ) Please unicast the reply . Best Regards, E.A.Gobinath. From mir at ripe.net Wed Jan 22 15:53:18 2014 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 22 Jan 2014 16:53:18 +0100 Subject: NTP Reflections - New article on RIPE Labs by John Kristoff Message-ID: <52DFE96E.5030605@ripe.net> Hello, After the recent amplification attacks involving NTP servers, John Kristoff, a researcher with Team Cymru, kindly agreed to publish an analysis of the history and timeline leading up to the attacks. Please find his contribution on RIPE Labs: https://labs.ripe.net/Members/mirjam/ntp-reflections I thought this might be interesting for this list. Kind regards, Mirjam Kuehne RIPE NCC From jra at baylink.com Wed Jan 22 18:03:21 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 22 Jan 2014 13:03:21 -0500 (EST) Subject: NetSol opts domain customers into $1800 Security program? Message-ID: <16161945.4974.1390413801369.JavaMail.root@benjamin.baylink.com> Brent Simmons is not given to ridiculous overreaction, nor is Lauren. If you have domains registered with NetSol's registrar, it seems you should probably do your diligence on this yourself: http://inessential.com/2014/01/21/network_solutions_auto-enroll_1_850 I have not been fond of NetSol since they kidnapped everyone's free domains back in ... what, 1996 or 7, and started charging for them; I moved to Domain Discover almost immediately... but this seems *wildly* over the top. How many domains do *you* have? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From fergdawgster at mykolab.com Wed Jan 22 18:19:55 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 22 Jan 2014 10:19:55 -0800 Subject: NetSol opts domain customers into $1800 Security program? In-Reply-To: <16161945.4974.1390413801369.JavaMail.root@benjamin.baylink.com> References: <16161945.4974.1390413801369.JavaMail.root@benjamin.baylink.com> Message-ID: <52E00BCB.10805@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 $1800 for standard "Registrar Lock" services does sound a bit expensive. :-( - - ferg On 1/22/2014 10:03 AM, Jay Ashworth wrote: > Brent Simmons is not given to ridiculous overreaction, nor is Lauren. > If you have domains registered with NetSol's registrar, it seems you > should probably do your diligence on this yourself: > > http://inessential.com/2014/01/21/network_solutions_auto-enroll_1_850 > > I have not been fond of NetSol since they kidnapped everyone's free > domains back in ... what, 1996 or 7, and started charging for them; > I moved to Domain Discover almost immediately... but this seems > *wildly* over the top. > > How many domains do *you* have? > > Cheers, > -- jra > - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLgC8sACgkQKJasdVTchbLZVgD/YaEOzUsNqztWwGEUjKpkBc+p w2haABgH1H6wk9bNhtYBAIWrYHwyZ2YTSK7JVMX9010H6i8akm5ktspTIUaG6exy =SHyk -----END PGP SIGNATURE----- From bzs at world.std.com Wed Jan 22 19:20:00 2014 From: bzs at world.std.com (Barry Shein) Date: Wed, 22 Jan 2014 14:20:00 -0500 Subject: NetSol opts domain customers into $1800 Security program? In-Reply-To: <16161945.4974.1390413801369.JavaMail.root@benjamin.baylink.com> References: <16161945.4974.1390413801369.JavaMail.root@benjamin.baylink.com> Message-ID: <21216.6624.153863.965494@world.std.com> They also will change your domains to "auto renew" magically and punch a credit card 90 days in advance of expiry so for example if a domain expires in April expect a charge in January at the latest. Why? I dunno, better to have the money now than later I guess. You'll have to jump through hoops to fix this, cannot be fixed via their online domain admin interface, someone they believe has authority (which may not be as simple as you think if for example your company owns the domain) has to phone and speak to a human about getting the bit unset. P.S. Doing that, removing auto-renew, changes you to receiving urgent email from them once a week or so starting 90 days in advance about how your domain is ABOUT TO EXPIRE! -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From gary.buhrmaster at gmail.com Wed Jan 22 19:26:48 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Wed, 22 Jan 2014 19:26:48 +0000 Subject: NetSol opts domain customers into $1800 Security program? In-Reply-To: <21216.6624.153863.965494@world.std.com> References: <16161945.4974.1390413801369.JavaMail.root@benjamin.baylink.com> <21216.6624.153863.965494@world.std.com> Message-ID: On Wed, Jan 22, 2014 at 7:20 PM, Barry Shein wrote: .... > P.S. Doing that, removing auto-renew, changes you to receiving urgent > email from them once a week or so starting 90 days in advance about > how your domain is ABOUT TO EXPIRE! Sort of reminds me of the late night TV ads for ginsu knives: "So you don't forget, call before midnight tonight!" Gary From patrick at ianai.net Wed Jan 22 19:27:21 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 22 Jan 2014 14:27:21 -0500 Subject: NetSol opts domain customers into $1800 Security program? In-Reply-To: <21216.6624.153863.965494@world.std.com> References: <16161945.4974.1390413801369.JavaMail.root@benjamin.baylink.com> <21216.6624.153863.965494@world.std.com> Message-ID: <1D66D8C4-20A4-4760-9516-0B74F38691A0@ianai.net> On Jan 22, 2014, at 14:20 , Barry Shein wrote: > They also will change your domains to "auto renew" magically and punch > a credit card 90 days in advance of expiry so for example if a domain > expires in April expect a charge in January at the latest. Why? I > dunno, better to have the money now than later I guess. > > You'll have to jump through hoops to fix this, cannot be fixed via > their online domain admin interface, someone they believe has > authority (which may not be as simple as you think if for example your > company owns the domain) has to phone and speak to a human about > getting the bit unset. > > P.S. Doing that, removing auto-renew, changes you to receiving urgent > email from them once a week or so starting 90 days in advance about > how your domain is ABOUT TO EXPIRE! After the issues with NetSol over the last year, why would anyone keep their domains with that registrar? -- TTFN, patrick From jra at baylink.com Wed Jan 22 20:01:03 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 22 Jan 2014 15:01:03 -0500 (EST) Subject: NetSol opts domain customers into $1800 Security program? In-Reply-To: <1D66D8C4-20A4-4760-9516-0B74F38691A0@ianai.net> Message-ID: <7426286.5054.1390420863687.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Patrick W. Gilmore" > After the issues with NetSol over the last year, why would anyone keep > their domains with that registrar? Better question: are they still the *registry*? And how do stupid policies like this on the part of one bode for the other? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From asullivan at dyn.com Wed Jan 22 20:10:18 2014 From: asullivan at dyn.com (Andrew Sullivan) Date: Wed, 22 Jan 2014 15:10:18 -0500 Subject: NetSol opts domain customers into $1800 Security program? In-Reply-To: <7426286.5054.1390420863687.JavaMail.root@benjamin.baylink.com> References: <1D66D8C4-20A4-4760-9516-0B74F38691A0@ianai.net> <7426286.5054.1390420863687.JavaMail.root@benjamin.baylink.com> Message-ID: <20140122201017.GE1156@dyn.com> On Wed, Jan 22, 2014 at 03:01:03PM -0500, Jay Ashworth wrote: > Better question: are they still the *registry*? No, and they haven't been for many years. You're thinking of Verisign. It owned NetSol at one time, but sold the registrar end (which is what's still called Network Solutions) in 2003. A -- Andrew Sullivan Dyn, Inc. asullivan at dyn.com v: +1 603 663 0448 From jra at baylink.com Wed Jan 22 20:23:49 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 22 Jan 2014 15:23:49 -0500 (EST) Subject: [VoiceOps] Phone Numbers with Calling Restrictions In-Reply-To: Message-ID: <13738708.5064.1390422229145.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Tim Donahue" > We ported this to an underlying carrier (the guilty party shall remain > nameless), and according to their engineers they have no option to > disable the SSC. > > I actually have no idea if the call I am making is blocked at the local > switch for my POTS test line, the LD carrier, or inbound to our ULC (or any > other part of the path it might have crossed). This information was not > provided to me in the response from our ULC, but it would be interesting to > know for future reference where these blocks happen. Waitaminnit. The calls are being blocked... well, they'd have to be being blocked *before they get to your gaining carrier, I guess, right? That nearly *requires* the code to be in the LERG, so the originating CO can execute it. We have some people here who know the LERG back and fro; Paul? Anyone else? You ever heard of this? Can you originate a call to that number from a different carrier via PRI, and see which ISDN error you get back? Or have someone else call it that way? ISDN errors tend to have a bit more data in them. I'd do it, but I don't have any PRIs laying around anymore. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Wed Jan 22 20:37:49 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 22 Jan 2014 15:37:49 -0500 (EST) Subject: NetSol opts domain customers into $1800 Security program? In-Reply-To: <20140122201017.GE1156@dyn.com> Message-ID: <3125186.5070.1390423069251.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Andrew Sullivan" > On Wed, Jan 22, 2014 at 03:01:03PM -0500, Jay Ashworth wrote: > > Better question: are they still the *registry*? > > No, and they haven't been for many years. You're thinking of > Verisign. It owned NetSol at one time, but sold the registrar end > (which is what's still called Network Solutions) in 2003. Well, it's sort of metaphysical to ask which company is which, but... Good, I guess. Thanks for the reminder. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From dmburgess at linktechs.net Wed Jan 22 21:02:39 2014 From: dmburgess at linktechs.net (Dennis Burgess) Date: Wed, 22 Jan 2014 15:02:39 -0600 Subject: above.net latencies Message-ID: <50710E9A7E64454C974049FC998EB655018DE4DD@03-exchange.lti.local> Seeing high latency's between LGA and PHL on above.net.. Saw this last night as well but went away by morning.. Anyone confirm or have any status? 8 9 ms 9 ms 9 ms ae5.cr1.ord2.us.above.net [64.125.28.233] 9 31 ms 31 ms 31 ms ae6.cr1.lga5.us.above.net [64.125.24.33] 10 118 ms 119 ms 115 ms xe-1-1-0.mpr3.phl2.us.above.net [64.125.31.33] 11 118 ms 119 ms 113 ms 208.185.20.54.t01657-08.above.net [208.185.20.54 ] Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition " Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs -- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace From asr at latency.net Wed Jan 22 22:52:39 2014 From: asr at latency.net (Adam Rothschild) Date: Wed, 22 Jan 2014 17:52:39 -0500 Subject: [VoiceOps] Phone Numbers with Calling Restrictions In-Reply-To: <13738708.5064.1390422229145.JavaMail.root@benjamin.baylink.com> References: <13738708.5064.1390422229145.JavaMail.root@benjamin.baylink.com> Message-ID: How is this considered even remotely relevant to the NANOG list? VoiceOps, I can sort of see... On Wed, Jan 22, 2014 at 3:23 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Tim Donahue" > >> We ported this to an underlying carrier (the guilty party shall remain >> nameless), and according to their engineers they have no option to >> disable the SSC. >> >> I actually have no idea if the call I am making is blocked at the local >> switch for my POTS test line, the LD carrier, or inbound to our ULC (or any >> other part of the path it might have crossed). This information was not >> provided to me in the response from our ULC, but it would be interesting to >> know for future reference where these blocks happen. > > Waitaminnit. > > The calls are being blocked... well, they'd have to be being blocked > *before they get to your gaining carrier, I guess, right? > > That nearly *requires* the code to be in the LERG, so the originating CO > can execute it. We have some people here who know the LERG back and fro; > Paul? Anyone else? You ever heard of this? > > Can you originate a call to that number from a different carrier via > PRI, and see which ISDN error you get back? Or have someone else call > it that way? > > ISDN errors tend to have a bit more data in them. > > I'd do it, but I don't have any PRIs laying around anymore. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 > From jay at west.net Wed Jan 22 22:57:45 2014 From: jay at west.net (Jay Hennigan) Date: Wed, 22 Jan 2014 14:57:45 -0800 Subject: NetSol opts domain customers into $1800 Security program? In-Reply-To: <16161945.4974.1390413801369.JavaMail.root@benjamin.baylink.com> References: <16161945.4974.1390413801369.JavaMail.root@benjamin.baylink.com> Message-ID: <52E04CE9.4010704@west.net> On 1/22/14 10:03 AM, Jay Ashworth wrote: > Brent Simmons is not given to ridiculous overreaction, nor is Lauren. > > If you have domains registered with NetSol's registrar, it seems you > should probably do your diligence on this yourself: > > http://inessential.com/2014/01/21/network_solutions_auto-enroll_1_850 Holy cow! At first I figured a typo and it was supposed to be $18.50. There are less ridiculous ways to go out of business. Simply announce that you don't want to be a registrar any more and turn out the lights. I'd love to be a fly on the wall for the phone call from their credit card processor regarding chargeback percentage about three weeks after this hits. Popcorn required for sure. -- 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 jayfar at jayfar.com Wed Jan 22 23:49:10 2014 From: jayfar at jayfar.com (Jay Farrell) Date: Wed, 22 Jan 2014 18:49:10 -0500 Subject: NetSol opts domain customers into $1800 Security program? In-Reply-To: <52E04CE9.4010704@west.net> References: <16161945.4974.1390413801369.JavaMail.root@benjamin.baylink.com> <52E04CE9.4010704@west.net> Message-ID: Updated: http://domainnamewire.com/2014/01/22/web-com-weblock-program-will-be-opt-in-not-opt-out/ --quote-- In an interview with Domain Name Wire today, Web.com COO Jason Teichman said the program will actually be opt-in, and no one will be charged for the service unless they agree to add it. ?Candidly, we did not do a good job in wording that [email],? Teichman said. ?Every one of those customers is getting a call. It?s not our intention to enroll anyone in a program they don?t want.? Web.com plans to offer the service to its top 1% of customers according to domain traffic, value of brands, etc. That?s about 30,000 customers in all. It started by notify just 49 customers ?so we can crawl our way into it,? Teichman said. --end quote-- On Wed, Jan 22, 2014 at 5:57 PM, Jay Hennigan wrote: > On 1/22/14 10:03 AM, Jay Ashworth wrote: >> Brent Simmons is not given to ridiculous overreaction, nor is Lauren. >> >> If you have domains registered with NetSol's registrar, it seems you >> should probably do your diligence on this yourself: >> >> http://inessential.com/2014/01/21/network_solutions_auto-enroll_1_850 > > Holy cow! At first I figured a typo and it was supposed to be $18.50. > > There are less ridiculous ways to go out of business. Simply announce > that you don't want to be a registrar any more and turn out the lights. > > I'd love to be a fly on the wall for the phone call from their credit > card processor regarding chargeback percentage about three weeks after > this hits. Popcorn required for sure. > > -- > 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 fergdawgster at mykolab.com Thu Jan 23 00:07:50 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 22 Jan 2014 16:07:50 -0800 Subject: NetSol opts domain customers into $1800 Security program? In-Reply-To: References: <16161945.4974.1390413801369.JavaMail.root@benjamin.baylink.com> <52E04CE9.4010704@west.net> Message-ID: <52E05D56.80300@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 So basically they are charging $1800 for 'Registrar Lock'? Opt-in or Opt-out, it's still way expensive... - - ferg On 1/22/2014 3:49 PM, Jay Farrell wrote: > Updated: > > http://domainnamewire.com/2014/01/22/web-com-weblock-program-will-be-opt-in-not-opt-out/ > > --quote-- In an interview with Domain Name Wire today, Web.com COO > Jason Teichman said the program will actually be opt-in, and no one > will be charged for the service unless they agree to add it. > > ?Candidly, we did not do a good job in wording that [email],? > Teichman said. ?Every one of those customers is getting a call. > It?s not our intention to enroll anyone in a program they don?t > want.? > > Web.com plans to offer the service to its top 1% of customers > according to domain traffic, value of brands, etc. That?s about > 30,000 customers in all. It started by notify just 49 customers ?so > we can crawl our way into it,? Teichman said. > > --end quote-- > > On Wed, Jan 22, 2014 at 5:57 PM, Jay Hennigan > wrote: >> On 1/22/14 10:03 AM, Jay Ashworth wrote: >>> Brent Simmons is not given to ridiculous overreaction, nor is >>> Lauren. >>> >>> If you have domains registered with NetSol's registrar, it >>> seems you should probably do your diligence on this yourself: >>> >>> http://inessential.com/2014/01/21/network_solutions_auto-enroll_1_850 >> >> >>> Holy cow! At first I figured a typo and it was supposed to be $18.50. >> >> There are less ridiculous ways to go out of business. Simply >> announce that you don't want to be a registrar any more and turn >> out the lights. >> >> I'd love to be a fly on the wall for the phone call from their >> credit card processor regarding chargeback percentage about three >> weeks after this hits. Popcorn required for sure. >> >> -- 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 >> > > > - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLgXVYACgkQKJasdVTchbJ+HgD9Eou5ccLrDmdOHztAfn4flu+t ZlL688jNqv84ZqgmreYBAMULZOgQUbepSBRraF24hZPu9+egb+bx1y5d9gc6ev3q =T1mq -----END PGP SIGNATURE----- From jra at baylink.com Thu Jan 23 00:31:15 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 22 Jan 2014 19:31:15 -0500 Subject: [VoiceOps] Phone Numbers with Calling Restrictions In-Reply-To: References: <13738708.5064.1390422229145.JavaMail.root@benjamin.baylink.com> Message-ID: <83a35dc3-8360-4d7a-b934-6fe2059a4198@email.android.com> Sorry. VO correctly doesn't set reply-to, and my MUA, Zimbra, doesn't do reply-to lisr. I typed it by hand, and put in the wrong list name. - jra Adam Rothschild wrote: >How is this considered even remotely relevant to the NANOG list? > >VoiceOps, I can sort of see... > >On Wed, Jan 22, 2014 at 3:23 PM, Jay Ashworth wrote: >> ----- Original Message ----- >>> From: "Tim Donahue" >> >>> We ported this to an underlying carrier (the guilty party shall >remain >>> nameless), and according to their engineers they have no option to >>> disable the SSC. >>> >>> I actually have no idea if the call I am making is blocked at the >local >>> switch for my POTS test line, the LD carrier, or inbound to our ULC >(or any >>> other part of the path it might have crossed). This information was >not >>> provided to me in the response from our ULC, but it would be >interesting to >>> know for future reference where these blocks happen. >> >> Waitaminnit. >> >> The calls are being blocked... well, they'd have to be being blocked >> *before they get to your gaining carrier, I guess, right? >> >> That nearly *requires* the code to be in the LERG, so the originating >CO >> can execute it. We have some people here who know the LERG back and >fro; >> Paul? Anyone else? You ever heard of this? >> >> Can you originate a call to that number from a different carrier via >> PRI, and see which ISDN error you get back? Or have someone else >call >> it that way? >> >> ISDN errors tend to have a bit more data in them. >> >> I'd do it, but I don't have any PRIs laying around anymore. >> >> Cheers, >> -- jra >> -- >> Jay R. Ashworth Baylink >jra at baylink.com >> Designer The Things I Think >RFC 2100 >> Ashworth & Associates http://www.bcp38.info 2000 Land >Rover DII >> St Petersburg FL USA BCP38: Ask For It By Name! +1 727 >647 1274 >> -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From johnl at iecc.com Thu Jan 23 01:13:42 2014 From: johnl at iecc.com (John Levine) Date: 23 Jan 2014 01:13:42 -0000 Subject: NetSol opts domain customers into $1800 Security program? In-Reply-To: <3125186.5070.1390423069251.JavaMail.root@benjamin.baylink.com> Message-ID: <20140123011342.34705.qmail@joyce.lan> >> No, and they haven't been for many years. You're thinking of >> Verisign. It owned NetSol at one time, but sold the registrar end >> (which is what's still called Network Solutions) in 2003. > >Well, it's sort of metaphysical to ask which company is which, but... NetSol and Verisign have been separate, unrelated companies for more than a decade. I'm astounded if anyone here hasn't gotten the memo. R's, John From jra at baylink.com Thu Jan 23 02:14:37 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 22 Jan 2014 21:14:37 -0500 (EST) Subject: Fwd: [ PRIVACY Forum ] Network Solutions/Web.com apologizes for email about credit card charges In-Reply-To: <20140122224411.GE22610@vortex.com> Message-ID: <8951943.5148.1390443277494.JavaMail.root@benjamin.baylink.com> NetSol: Oops. We goofed. Why they didn't clarify this when Brent queried them is unclear; I infer (but cannot, of course, prove) backpedaling. Cheers, -- jra ----- Forwarded Message ----- > From: "PRIVACY Forum mailing list" > To: privacy-list at vortex.com > Sent: Wednesday, January 22, 2014 5:44:11 PM > Subject: [ PRIVACY Forum ] Network Solutions/Web.com apologizes for email about credit card charges > Network Solutions/Web.com apologizes for email about credit card > charges > > I just got off the phone with the COO, CTO, and others from Network > Solutions/Web.com, regarding today's furor over an email suggesting an > almost $2K charge for a new domain security program unless the > addressee opted out. > > They are apologetic about the email, which they say mischaracterized > the program aimed at the top 1% of their customers, and assert that > nobody would have been charged that fee without affirmatively agreeing > to enter the program -- irrespective of what the email appeared to be > saying. > > I also took the opportunity to discuss other aspects of their email > notifications, such as those WHOIS confirmation notices I received a > few > days ago, that looked for all the world like phishing attempts. > > All other aspects of today's story aside, I think it's more clear than > ever that messaging really matters. > > My thanks to Network Solutions/Web.com for taking the time to discuss > these > issues with me directly. > > --Lauren-- > Lauren Weinstein (lauren at vortex.com): http://www.vortex.com/lauren > Co-Founder: People For Internet Responsibility: > http://www.pfir.org/pfir-info > Founder: > - Network Neutrality Squad: http://www.nnsquad.org > - PRIVACY Forum: http://www.vortex.com/privacy-info > Member: ACM Committee on Computers and Public Policy > Lauren's Blog: http://lauren.vortex.com > Google+: http://google.com/+LaurenWeinstein > Twitter: http://twitter.com/laurenweinstein > Tel: +1 (818) 225-2800 / Skype: vortex.com > > _______________________________________________ > privacy mailing list > http://lists.vortex.com/mailman/listinfo/privacy -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jared at puck.nether.net Thu Jan 23 02:23:05 2014 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 22 Jan 2014 21:23:05 -0500 Subject: "trivial" changes to DNS (was: OpenNTPProject.org) In-Reply-To: References: <654ffad2725247a1a0386fd7a29b1ffb@CAMPUSCAS3.usask.ca> <4C973546-A414-41C8-8C2B-AEED1678B30B@lists.zabbadoz.net> <20140114071830.GA18152@pob.ytti.fi> <20140116162727.GQ22344@dyn.com> <20140116163945.GU22344@dyn.com> <20140116175518.GA27572@puck.nether.net> Message-ID: <05F439F6-09A7-4355-9252-A1C3AFCDF3FF@puck.nether.net> On Jan 17, 2014, at 6:44 AM, Tony Finch wrote: > Jared Mauch wrote: >> >> I can point anyone interested to the place in the >> bind source to force it to reply to all UDP queries with TC=1 >> to force TCP. should be safe on any authority servers, as a recursive >> server should be able to do outbound TCP. > > However see http://www.potaroo.net/ispcol/2013-09/dnstcp.html Yes, I?m aware of the excellent work by Geoff on this topic. There are many things that could be done, including the nonce (or similar) approach NTP took with MONLIST vs MRULIST. Perhaps it?s something like this: http://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03 - Jared From morrowc.lists at gmail.com Thu Jan 23 04:22:34 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 22 Jan 2014 23:22:34 -0500 Subject: NetSol opts domain customers into $1800 Security program? In-Reply-To: <52E05D56.80300@mykolab.com> References: <16161945.4974.1390413801369.JavaMail.root@benjamin.baylink.com> <52E04CE9.4010704@west.net> <52E05D56.80300@mykolab.com> Message-ID: On Wed, Jan 22, 2014 at 7:07 PM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > So basically they are charging $1800 for 'Registrar Lock'? > > Opt-in or Opt-out, it's still way expensive... is it though? is it REALLY?? What's the cost for a lost domain for ~1 day while you try to haggle with netsol (good luck!) on the phone to recover your domain? (for someone who actually makes money on the internet I mean.. fergdawg.com.net.org.com doesn't count for this conversation :) ) I suppose they COULD move their domain to a registrar that does registrar-lock for 'free', but that's a cost too, right? man power, configuration mistakes, other billing things to setup... 1800 might be 'ok' for someone who's making a bunch of money/day. right? and heck... if netsol gets 10 people to buy it they probably paid for the work to actually do the 'registrar lock' right? :) > On 1/22/2014 3:49 PM, Jay Farrell wrote: > >> Updated: >> >> http://domainnamewire.com/2014/01/22/web-com-weblock-program-will-be-opt-in-not-opt-out/ >> >> --quote-- In an interview with Domain Name Wire today, Web.com COO >> Jason Teichman said the program will actually be opt-in, and no one >> will be charged for the service unless they agree to add it. >> >> ?Candidly, we did not do a good job in wording that [email],? >> Teichman said. ?Every one of those customers is getting a call. >> It?s not our intention to enroll anyone in a program they don?t >> want.? >> >> Web.com plans to offer the service to its top 1% of customers >> according to domain traffic, value of brands, etc. That?s about >> 30,000 customers in all. It started by notify just 49 customers ?so >> we can crawl our way into it,? Teichman said. >> >> --end quote-- >> >> On Wed, Jan 22, 2014 at 5:57 PM, Jay Hennigan >> wrote: >>> On 1/22/14 10:03 AM, Jay Ashworth wrote: >>>> Brent Simmons is not given to ridiculous overreaction, nor is >>>> Lauren. >>>> >>>> If you have domains registered with NetSol's registrar, it >>>> seems you should probably do your diligence on this yourself: >>>> >>>> http://inessential.com/2014/01/21/network_solutions_auto-enroll_1_850 >>> >>> >>>> > Holy cow! At first I figured a typo and it was supposed to be $18.50. >>> >>> There are less ridiculous ways to go out of business. Simply >>> announce that you don't want to be a registrar any more and turn >>> out the lights. >>> >>> I'd love to be a fly on the wall for the phone call from their >>> credit card processor regarding chargeback percentage about three >>> weeks after this hits. Popcorn required for sure. >>> >>> -- 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 >>> >> >> >> > > > - -- > Paul Ferguson > PGP Public Key ID: 0x54DC85B2 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlLgXVYACgkQKJasdVTchbJ+HgD9Eou5ccLrDmdOHztAfn4flu+t > ZlL688jNqv84ZqgmreYBAMULZOgQUbepSBRraF24hZPu9+egb+bx1y5d9gc6ev3q > =T1mq > -----END PGP SIGNATURE----- > From johnl at iecc.com Thu Jan 23 05:19:02 2014 From: johnl at iecc.com (John Levine) Date: 23 Jan 2014 05:19:02 -0000 Subject: NetSol opts domain customers into $1800 Security program? In-Reply-To: Message-ID: <20140123051902.35394.qmail@joyce.lan> >I suppose they COULD move their domain to a registrar that does >registrar-lock for 'free', but that's a cost too, right? man power, >configuration mistakes, other billing things to setup... 1800 might be >'ok' for someone who's making a bunch of money/day. right? That is the only plausible reason that NetSol has any remaining customers at all. There's a bazillion other registrars that provide better service at lower prices, with nothing but inertia keeping people from moving. From morrowc.lists at gmail.com Thu Jan 23 05:29:38 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 23 Jan 2014 00:29:38 -0500 Subject: NetSol opts domain customers into $1800 Security program? In-Reply-To: <20140123051902.35394.qmail@joyce.lan> References: <20140123051902.35394.qmail@joyce.lan> Message-ID: On Thu, Jan 23, 2014 at 12:19 AM, John Levine wrote: >>I suppose they COULD move their domain to a registrar that does >>registrar-lock for 'free', but that's a cost too, right? man power, >>configuration mistakes, other billing things to setup... 1800 might be >>'ok' for someone who's making a bunch of money/day. right? > > That is the only plausible reason that NetSol has any remaining > customers at all. There's a bazillion other registrars that provide > better service at lower prices, with nothing but inertia keeping > people from moving. hurray for inertia? :) (note I'm not actually a netsol customer either... so I'm not advocating them for this role) From Jason at viviotech.net Thu Jan 23 08:56:52 2014 From: Jason at viviotech.net (Jason) Date: Thu, 23 Jan 2014 00:56:52 -0800 Subject: GoDaddy DNS Message-ID: <52E0D954.4080709@viviotech.net> We're starting to see errors with Go Daddy DNS. Is anyone else experiencing issues? -J From ahebert at pubnix.net Thu Jan 23 13:31:45 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 23 Jan 2014 08:31:45 -0500 Subject: NetSol opts domain customers into $1800 Security program? In-Reply-To: <20140123051902.35394.qmail@joyce.lan> References: <20140123051902.35394.qmail@joyce.lan> Message-ID: <52E119C1.6080509@pubnix.net> Or a low priority on a very long ToDo list. Also, moving them to: . GoDaddy feel cheap for some reason. . Tucows, expected; . resellerclub, scary; . enom, pricey; Any suggestion for one with a good API will be appreciated, off-list obviously. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 01/23/14 00:19, John Levine wrote: >> I suppose they COULD move their domain to a registrar that does >> registrar-lock for 'free', but that's a cost too, right? man power, >> configuration mistakes, other billing things to setup... 1800 might be >> 'ok' for someone who's making a bunch of money/day. right? > That is the only plausible reason that NetSol has any remaining > customers at all. There's a bazillion other registrars that provide > better service at lower prices, with nothing but inertia keeping > people from moving. > > > From maillist at webjogger.net Thu Jan 23 15:41:23 2014 From: maillist at webjogger.net (Adam Greene) Date: Thu, 23 Jan 2014 10:41:23 -0500 Subject: GoDaddy DNS In-Reply-To: <52E0D954.4080709@viviotech.net> References: <52E0D954.4080709@viviotech.net> Message-ID: <01ac01cf1851$91e16880$b5a43980$@webjogger.net> We noticed some issues to Google & Level3 DNS last night: 8.8.8.8 8.8.4.4 4.2.2.2 1/23/14 00:55:17 - 00:55:47 (UTC-5) 1/23/14 01:09:32 - 01:11:03 (UTC-5) Have not yet determined if it was a local carrier issue. Someone on outages at outages.org reported issues getting to eBay / Paypal IP's at roughly the same time. I wonder if there was a general brief carrier issue last night. -----Original Message----- From: Jason [mailto:Jason at viviotech.net] Sent: Thursday, January 23, 2014 3:57 AM To: nanog at nanog.org Subject: GoDaddy DNS We're starting to see errors with Go Daddy DNS. Is anyone else experiencing issues? -J From morrowc.lists at gmail.com Thu Jan 23 15:45:14 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 23 Jan 2014 10:45:14 -0500 Subject: GoDaddy DNS In-Reply-To: <01ac01cf1851$91e16880$b5a43980$@webjogger.net> References: <52E0D954.4080709@viviotech.net> <01ac01cf1851$91e16880$b5a43980$@webjogger.net> Message-ID: On Thu, Jan 23, 2014 at 10:41 AM, Adam Greene wrote: > We noticed some issues to Google & Level3 DNS last night: > > 8.8.8.8 > 8.8.4.4 > 4.2.2.2 > > 1/23/14 00:55:17 - 00:55:47 (UTC-5) > 1/23/14 01:09:32 - 01:11:03 (UTC-5) > > Have not yet determined if it was a local carrier issue. > > Someone on outages at outages.org reported issues getting to eBay / Paypal IP's > at roughly the same time. > > I wonder if there was a general brief carrier issue last night. > > -----Original Message----- > From: Jason [mailto:Jason at viviotech.net] > Sent: Thursday, January 23, 2014 3:57 AM > To: nanog at nanog.org > Subject: GoDaddy DNS > > We're starting to see errors with Go Daddy DNS. Is anyone else experiencing > issues? always helps to have examples of the problems... ie: I did - dig www.godaddy.com @8.8.8.8 I expected: ;; QUESTION SECTION: ;www.godaddy.com. IN A ;; ANSWER SECTION: www.godaddy.com. 29 IN CNAME www.godaddy.com.edgekey.net. www.godaddy.com.edgekey.net. 550 IN CNAME e8804.a.akamaiedge.net. e8804.a.akamaiedge.net. 14 IN A 23.79.77.116 but I got: ;; QUESTION SECTION: ;www.godaddy.com. IN A www.godaddy.com. 14 IN A zippidy-doo.com!. I made my query from the north-east elbonian region of youville. -chris From morrowc.lists at gmail.com Thu Jan 23 15:59:19 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 23 Jan 2014 10:59:19 -0500 Subject: GoDaddy DNS In-Reply-To: References: <52E0D954.4080709@viviotech.net> <01ac01cf1851$91e16880$b5a43980$@webjogger.net> Message-ID: On Thu, Jan 23, 2014 at 10:45 AM, Christopher Morrow wrote: > On Thu, Jan 23, 2014 at 10:41 AM, Adam Greene wrote: >> We noticed some issues to Google & Level3 DNS last night: >> >> 8.8.8.8 >> 8.8.4.4 >> 4.2.2.2 >> >> 1/23/14 00:55:17 - 00:55:47 (UTC-5) >> 1/23/14 01:09:32 - 01:11:03 (UTC-5) >> >> Have not yet determined if it was a local carrier issue. >> >> Someone on outages at outages.org reported issues getting to eBay / Paypal IP's >> at roughly the same time. >> >> I wonder if there was a general brief carrier issue last night. >> >> -----Original Message----- >> From: Jason [mailto:Jason at viviotech.net] >> Sent: Thursday, January 23, 2014 3:57 AM >> To: nanog at nanog.org >> Subject: GoDaddy DNS >> >> We're starting to see errors with Go Daddy DNS. Is anyone else experiencing >> issues? > > always helps to have examples of the problems... ie: > I did - dig www.godaddy.com @8.8.8.8 > I expected: > > ;; QUESTION SECTION: > ;www.godaddy.com. IN A > ;; ANSWER SECTION: > www.godaddy.com. 29 IN CNAME www.godaddy.com.edgekey.net. > www.godaddy.com.edgekey.net. 550 IN CNAME e8804.a.akamaiedge.net. > e8804.a.akamaiedge.net. 14 IN A 23.79.77.116 > > > but I got: > ;; QUESTION SECTION: > ;www.godaddy.com. IN A > www.godaddy.com. 14 IN A zippidy-doo.com!. > I should be clear that there are no bangs (!) in dns.... so this above is clearly fictious dig output (the first instance is actual output... I was lazy and copy/pasted edited the output. > > I made my query from the north-east elbonian region of youville. also, there is no elbonia... there may be a youville though, and i'm sorry for slurring the youville inhabitants with the stink of elbonia :( From jjn at nuge.com Thu Jan 23 17:08:57 2014 From: jjn at nuge.com (Jay Nugent) Date: Thu, 23 Jan 2014 12:08:57 -0500 (EST) Subject: NetSol opts domain customers into $1800 Security program? In-Reply-To: <52E119C1.6080509@pubnix.net> References: <20140123051902.35394.qmail@joyce.lan> <52E119C1.6080509@pubnix.net> Message-ID: Greetings, On Thu, 23 Jan 2014, Alain Hebert wrote: > Or a low priority on a very long ToDo list. > > Also, moving them to: > > . GoDaddy feel cheap for some reason. > . Tucows, expected; > . resellerclub, scary; > . enom, pricey; > > Any suggestion for one with a good API will be appreciated, off-list > obviously. Years ago when NetSol cost too much and became too clunky to work with, I switched some 70+ domains over to Dotster. Easy UI, friendly folk, won't charge $$$ to get your domain out of hock if you miss the payment deadline (just pay for a year and you're back in business). --- Jay Nugent Nugent Telecommunications o Wars waged o Orgies organized o Embedded system design o Prototype design o UNIX/Linux SysAdmin classes taught () ascii ribbon campaign in /\ support of plain text e-mail o Averaging at least 3 days of MTBWTF!?!?!? o The solution for long term Internet growth is IPv6. +------------------------------------------------------------------------+ | Jay Nugent jjn at nuge.com (734)484-5105 (734)649-0850/Cell | | Nugent Telecommunications [www.nuge.com] | | Internet Consulting/Linux SysAdmin/Engineering & Design | | ISP Monitoring [www.ispmonitor.org] ISP & Modem Performance Monitoring | +------------------------------------------------------------------------+ 12:01:01 up 101 days, 2:34, 2 users, load average: 0.85, 0.73, 0.52 From jra at baylink.com Thu Jan 23 17:31:18 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 23 Jan 2014 12:31:18 -0500 (EST) Subject: bcp38.info -- Heeeeellpp!!! :-) Message-ID: <1083733.5240.1390498278204.JavaMail.root@benjamin.baylink.com> If you run an eyeball or transit network, and you are already implementing BCP38 filtering, could I get you to take a moment, and apply some love to http://www.bcp38.info/index.php/Information_for_%27eyeball%27_networks or http://www.bcp38.info/index.php/Information_for_transit_providers this weekend? I'm hoping for something similar in style and overall content to http://www.bcp38.info/index.php/Information_for_end-users though in a bit more detail, as you'd expect for the people who have to actually turn the knobs. Instructions on how to enable 38 compliant filtering for specific gear are welcome as well, but should be put each in their own article. Since I don't myself actually know the things necessary to write those pages, I am sadly reduced to cheerleading you guys to do it. :-) Cheers, -- jra -- Jay R. Ashworth jra at baylink.com Designer RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From Valdis.Kletnieks at vt.edu Thu Jan 23 17:41:13 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 23 Jan 2014 12:41:13 -0500 Subject: GoDaddy DNS In-Reply-To: Your message of "Thu, 23 Jan 2014 10:59:19 -0500." References: <52E0D954.4080709@viviotech.net> <01ac01cf1851$91e16880$b5a43980$@webjogger.net> Message-ID: <8346.1390498873@turing-police.cc.vt.edu> On Thu, 23 Jan 2014 10:59:19 -0500, Christopher Morrow said: > also, there is no elbonia... You sure? Over the years, I've dealt with a lot of gear designed and built there. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jra at baylink.com Thu Jan 23 18:07:47 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 23 Jan 2014 13:07:47 -0500 (EST) Subject: GoDaddy DNS In-Reply-To: <8346.1390498873@turing-police.cc.vt.edu> Message-ID: <16405124.5250.1390500467658.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > On Thu, 23 Jan 2014 10:59:19 -0500, Christopher Morrow said: > > also, there is no elbonia... > > You sure? Over the years, I've dealt with a lot of gear designed and > built there. Hell; all of China's traffic got mysteriously routed there last week... http://news.techworld.com/security/3498153/mysterious-networking-error-stifles-internet-access-in-china/ Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From mstaudinger at corp.earthlink.com Thu Jan 23 20:43:04 2014 From: mstaudinger at corp.earthlink.com (Staudinger, Malcolm) Date: Thu, 23 Jan 2014 20:43:04 +0000 Subject: NetSol opts domain customers into $1800 Security program? In-Reply-To: References: <20140123051902.35394.qmail@joyce.lan> <52E119C1.6080509@pubnix.net> Message-ID: <2883e24b3a584f89b76348e22c791017@EDGMBXV06.marvel.elnk.net> Dotster was eaten a few years back by the hosting conglomerate Endurance International, and is only a shadow of its former self, unfortunately. /ex Dotster employee from the glory days Malcolm Staudinger EarthLink -----Original Message----- From: Jay Nugent [mailto:jjn at nuge.com] Sent: Thursday, January 23, 2014 9:09 AM To: Alain Hebert Cc: NANOG Subject: Re: NetSol opts domain customers into $1800 Security program? Greetings, On Thu, 23 Jan 2014, Alain Hebert wrote: > Or a low priority on a very long ToDo list. > > Also, moving them to: > > . GoDaddy feel cheap for some reason. > . Tucows, expected; > . resellerclub, scary; > . enom, pricey; > > Any suggestion for one with a good API will be appreciated, > off-list obviously. Years ago when NetSol cost too much and became too clunky to work with, I switched some 70+ domains over to Dotster. Easy UI, friendly folk, won't charge $$$ to get your domain out of hock if you miss the payment deadline (just pay for a year and you're back in business). --- Jay Nugent Nugent Telecommunications o Wars waged o Orgies organized o Embedded system design o Prototype design o UNIX/Linux SysAdmin classes taught () ascii ribbon campaign in /\ support of plain text e-mail o Averaging at least 3 days of MTBWTF!?!?!? o The solution for long term Internet growth is IPv6. +------------------------------------------------------------------------+ | Jay Nugent jjn at nuge.com (734)484-5105 (734)649-0850/Cell | | Nugent Telecommunications [www.nuge.com] | | Internet Consulting/Linux SysAdmin/Engineering & Design | | ISP Monitoring [www.ispmonitor.org] ISP & Modem Performance Monitoring | | +------------------------------------------------------------------------+ 12:01:01 up 101 days, 2:34, 2 users, load average: 0.85, 0.73, 0.52 From ESundberg at nitelusa.com Fri Jan 24 00:47:47 2014 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Fri, 24 Jan 2014 00:47:47 +0000 Subject: OSPF Costs Formula that include delay. Message-ID: <495D0934DA46854A9CA758393724D5903B8375@NI-MAIL02.nii.ads> What is everyone using for an OSPF cost formula that factors in a circuits delay and bandwidth (10M-100G)??? Thanks in advance ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From tglassey at earthlink.net Fri Jan 24 00:58:51 2014 From: tglassey at earthlink.net (TGLASSEY) Date: Thu, 23 Jan 2014 16:58:51 -0800 Subject: GoDaddy DNS In-Reply-To: <01ac01cf1851$91e16880$b5a43980$@webjogger.net> References: <52E0D954.4080709@viviotech.net> <01ac01cf1851$91e16880$b5a43980$@webjogger.net> Message-ID: <52E1BACB.5060408@earthlink.net> This has been going on off and on for a while. Todd On 1/23/2014 7:41 AM, Adam Greene wrote: > We noticed some issues to Google & Level3 DNS last night: > > 8.8.8.8 > 8.8.4.4 > 4.2.2.2 > > 1/23/14 00:55:17 - 00:55:47 (UTC-5) > 1/23/14 01:09:32 - 01:11:03 (UTC-5) > > Have not yet determined if it was a local carrier issue. > > Someone on outages at outages.org reported issues getting to eBay / Paypal IP's > at roughly the same time. > > I wonder if there was a general brief carrier issue last night. > > -----Original Message----- > From: Jason [mailto:Jason at viviotech.net] > Sent: Thursday, January 23, 2014 3:57 AM > To: nanog at nanog.org > Subject: GoDaddy DNS > > We're starting to see errors with Go Daddy DNS. Is anyone else experiencing > issues? > > > -J > > > > > -- ------------- Personal Email - Disclaimers Apply From randy_94108 at yahoo.com Fri Jan 24 03:02:39 2014 From: randy_94108 at yahoo.com (Randy) Date: Thu, 23 Jan 2014 19:02:39 -0800 (PST) Subject: OSPF Costs Formula that include delay. In-Reply-To: <495D0934DA46854A9CA758393724D5903B8375@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D5903B8375@NI-MAIL02.nii.ads> Message-ID: <1390532559.26143.YahooMailNeo@web181703.mail.ne1.yahoo.com> ----- Original Message ----- > From: Erik Sundberg > To: "nanog at nanog.org" > Cc: > Sent: Thursday, January 23, 2014 4:47 PM > Subject: OSPF Costs Formula that include delay. > > What is everyone using for an OSPF cost formula that factors in a circuits delay > and bandwidth (10M-100G)??? > > Thanks in advance umm..are you sure your question is not about EIGRP? OSPF has no concept of interface-delays. The default reference bandwidth for OSPF is 100M In your case if you set your reference bandwidth to 100000 your 100G links would have a link cost of 1, 10G - 10, 1G-100, 100M-1000 and 10M-10000 A vendor specific list would be a better place to ask. ./Randy From jra at baylink.com Fri Jan 24 04:03:20 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 23 Jan 2014 23:03:20 -0500 (EST) Subject: bcp38.info wiki signup problem Message-ID: <815309.5332.1390536200685.JavaMail.root@benjamin.baylink.com> A kind soul has just pointed out to me that the register link on the BCP38 wiki: http://www.bcp38.info/index.php?title=Special:UserLogin&returnto=Main+Page&type=signup isn't, um, working right now. I guess that might explain the lack of contributions. Oops. We'll get right on that, folks. :-} Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From mysidia at gmail.com Fri Jan 24 13:04:38 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 24 Jan 2014 07:04:38 -0600 Subject: EIGRP support !Cisco In-Reply-To: References: <6434672$51e7277a$2af2e41c$@flhsi.com> <52D017C3.40805@foobar.org> Message-ID: On Fri, Jan 10, 2014 at 9:57 AM, Christopher Morrow wrote: > On Fri, Jan 10, 2014 at 10:54 AM, Nick Hilliard wrote: > > On 08/01/2014 18:14, Christopher Morrow wrote: > >> question... there's people that have done this before even :) > > https://www.nanog.org/meetings/nanog29/presentations/gill.pdf > > oh yea! that guy! I hear he's done this sort of thing a few times > now... probably has practice and tools and stuff :) > Hey... Tools.... why not... Control+Click... select all the routers.... Right click "Upgrade IGP to ISIS" Go grab a drink... Come back... "Done" click OK. No more Eigrp. I suppose PuTTy / SecureCRT haven't added the feature yet... perhaps in a few releases? :) -- -JH From ahebert at pubnix.net Fri Jan 24 13:43:09 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 24 Jan 2014 08:43:09 -0500 Subject: bcp38.info wiki signup problem In-Reply-To: <815309.5332.1390536200685.JavaMail.root@benjamin.baylink.com> References: <815309.5332.1390536200685.JavaMail.root@benjamin.baylink.com> Message-ID: <52E26DED.4000101@pubnix.net> Well, Out of 25 accounts, 22 where for spamming. Even with captcha, etc. Since then I put a mention to contact moderator at bcp38.info for account creation. You'll see it if you are going through the [Log in] link http://www.bcp38.info/index.php?title=Special:UserLogin&returnto=Main+Page You're right, directly to [Sign up] wont work. Sorry :( ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 01/23/14 23:03, Jay Ashworth wrote: > A kind soul has just pointed out to me that the register link on the > BCP38 wiki: > > http://www.bcp38.info/index.php?title=Special:UserLogin&returnto=Main+Page&type=signup > > isn't, um, working right now. I guess that might explain the lack of > contributions. > > Oops. > > We'll get right on that, folks. :-} > > Cheers, > -- jra From ahebert at pubnix.net Fri Jan 24 14:22:57 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 24 Jan 2014 09:22:57 -0500 Subject: About ddos-response@nfoservers.com Message-ID: <52E27741.5090507@pubnix.net> Well, Those poor guys are under perma DNS Amplifcation DDoS for what seems to be 2 weeks now. About 7 days ago they started sending us emails for what is less than 2MB worth of data (~500 packets) which is about how long it takes for filters to take effect. But after 1 week of communication they are not changing their procedures :( Anyone else receiving those emails? ----- Since most providers (at any level) are not putting any effort on BCP38. Is there a [Spoofing Tracking Squad] out there? ( We're on GT-T/nLayer/Tinet ) -- ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 From morrowc.lists at gmail.com Fri Jan 24 14:33:49 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 24 Jan 2014 09:33:49 -0500 Subject: About ddos-response@nfoservers.com In-Reply-To: <52E27741.5090507@pubnix.net> References: <52E27741.5090507@pubnix.net> Message-ID: On Fri, Jan 24, 2014 at 9:22 AM, Alain Hebert wrote: > Well, > > Those poor guys are under perma DNS Amplifcation DDoS for what seems > to be 2 weeks now. > they seem to be hosted at internap, you'd think they could just ask internap to fix this for them instead, eh? From jared at puck.nether.net Fri Jan 24 14:36:27 2014 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 24 Jan 2014 09:36:27 -0500 Subject: About ddos-response@nfoservers.com In-Reply-To: <52E27741.5090507@pubnix.net> References: <52E27741.5090507@pubnix.net> Message-ID: <8CFB098F-1C79-4555-B21B-AACA4E9F74D0@puck.nether.net> On Jan 24, 2014, at 9:22 AM, Alain Hebert wrote: > > Is there a [Spoofing Tracking Squad] out there? > ( We're on GT-T/nLayer/Tinet ) You haven?t been able to get GTT/nLayer/TINet to track the traffic back? Details are welcome, either here or in private. There are plenty of people who will chase and fix this stuff when they?re aware of it. - Jared From cboyd at gizmopartners.com Fri Jan 24 15:23:47 2014 From: cboyd at gizmopartners.com (Chris Boyd) Date: Fri, 24 Jan 2014 09:23:47 -0600 Subject: About ddos-response@nfoservers.com In-Reply-To: <8CFB098F-1C79-4555-B21B-AACA4E9F74D0@puck.nether.net> References: <52E27741.5090507@pubnix.net> <8CFB098F-1C79-4555-B21B-AACA4E9F74D0@puck.nether.net> Message-ID: <81CDF960-7192-4B39-8226-075A052D0B67@gizmopartners.com> On Jan 24, 2014, at 8:36 AM, Jared Mauch wrote: > You haven?t been able to get GTT/nLayer/TINet to track the traffic back? > > Details are welcome, either here or in private. There are plenty of people who will chase and fix this stuff when they?re aware of it. When OpenResolver Project was announced, there were about 60 abusable addresses in my corner of the Internet. I was able to get that number down under 20 by asking politely. The NFOserver reports have been a pretty good stick to get the number down below 10. --Chris From oscar.vives at gmail.com Fri Jan 24 15:40:02 2014 From: oscar.vives at gmail.com (Tei) Date: Fri, 24 Jan 2014 16:40:02 +0100 Subject: About ddos-response@nfoservers.com In-Reply-To: <81CDF960-7192-4B39-8226-075A052D0B67@gizmopartners.com> References: <52E27741.5090507@pubnix.net> <8CFB098F-1C79-4555-B21B-AACA4E9F74D0@puck.nether.net> <81CDF960-7192-4B39-8226-075A052D0B67@gizmopartners.com> Message-ID: On 24 January 2014 16:23, Chris Boyd wrote: > > On Jan 24, 2014, at 8:36 AM, Jared Mauch wrote: > >> You haven?t been able to get GTT/nLayer/TINet to track the traffic back? >> >> Details are welcome, either here or in private. There are plenty of people who will chase and fix this stuff when they?re aware of it. > > When OpenResolver Project was announced, there were about 60 abusable addresses in my corner of the Internet. I was able to get that number down under 20 by asking politely. The NFOserver reports have been a pretty good stick to get the number down below 10. > http://dns.measurement-factory.com/surveys/openresolvers/ASN-reports/latest.html Uh.. Oh. I see a lot of references to Tel?fonica in Latin America. -- -- ?in del ?ensaje. From source_route at yahoo.com Fri Jan 24 15:53:05 2014 From: source_route at yahoo.com (Philip Lavine) Date: Fri, 24 Jan 2014 07:53:05 -0800 (PST) Subject: L2TPv3 - and layer 2 PDU's Message-ID: <1390578785.32280.YahooMailNeo@web122506.mail.ne1.yahoo.com> To all, Has anyone successfully tunneled L2 PDU's (STP, CDP, LLDP) over a L2TPv3 pseudowire tunnel, i.e. should I be able to see?CDP neighbors across the tunnel? For some reason if I encapsulated dot1q on a router sub-interface and try and pass traffic across the trunk the downstream switch port will go into err-disable. Thx Philip From jeff.tantsura at ericsson.com Fri Jan 24 16:55:07 2014 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Fri, 24 Jan 2014 16:55:07 +0000 Subject: L2TPv3 - and layer 2 PDU's In-Reply-To: <1390578785.32280.YahooMailNeo@web122506.mail.ne1.yahoo.com> References: <1390578785.32280.YahooMailNeo@web122506.mail.ne1.yahoo.com> Message-ID: <4BA9B0A5-D188-47D0-BDC9-313055710BBA@ericsson.com> Yes, 10 years ago on 10720, CDP and LACP worked like a charm Regards, Jeff > On Jan 24, 2014, at 7:55 AM, "Philip Lavine" wrote: > > To all, > > Has anyone successfully tunneled L2 PDU's (STP, CDP, LLDP) over a L2TPv3 pseudowire tunnel, i.e. should I be able to see CDP neighbors across the tunnel? For some reason if I encapsulated dot1q on a router sub-interface and try and pass traffic across the trunk the downstream switch port will go into err-disable. > > Thx > > Philip > From mailinglists at expresswebsystems.com Fri Jan 24 16:59:26 2014 From: mailinglists at expresswebsystems.com (Tom Walsh - EWS) Date: Fri, 24 Jan 2014 10:59:26 -0600 Subject: Time Warner RoadRunner Residental NOC Contact? Message-ID: <018701cf1925$a3efcd80$ebcf6880$@com> Sorry for the noise, but we are looking for somebody that can help us track down a single IP address that is seemingly blackholed by TW/RR in a core somewhere in Atlanta. We have verified that the IP doesn't have any abuse history and isn't blackholed from our end. Just started this morning. Any assistance is appreciated. Tom Walsh EWS - ASN53255 --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From cscora at apnic.net Fri Jan 24 18:13:21 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 25 Jan 2014 04:13:21 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201401241813.s0OIDLiS019504@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 25 Jan, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 479892 Prefixes after maximum aggregation: 190818 Deaggregation factor: 2.51 Unique aggregates announced to Internet: 237486 Total ASes present in the Internet Routing Table: 45998 Prefixes per ASN: 10.43 Origin-only ASes present in the Internet Routing Table: 35541 Origin ASes announcing only one prefix: 16285 Transit ASes present in the Internet Routing Table: 6006 Transit-only ASes present in the Internet Routing Table: 168 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 2707 Unregistered ASNs in the Routing Table: 648 Number of 32-bit ASNs allocated by the RIRs: 5746 Number of 32-bit ASNs visible in the Routing Table: 4451 Prefixes from 32-bit ASNs in the Routing Table: 14112 Number of bogon 32-bit ASNs visible in the Routing Table: 1 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 2018 Number of addresses announced to Internet: 2663146148 Equivalent to 158 /8s, 188 /16s and 98 /24s Percentage of available address space announced: 71.9 Percentage of allocated address space announced: 71.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 95.4 Total number of prefixes smaller than registry allocations: 166690 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 114387 Total APNIC prefixes after maximum aggregation: 34391 APNIC Deaggregation factor: 3.33 Prefixes being announced from the APNIC address blocks: 116810 Unique aggregates announced from the APNIC address blocks: 48876 APNIC Region origin ASes present in the Internet Routing Table: 4888 APNIC Prefixes per ASN: 23.90 APNIC Region origin ASes announcing only one prefix: 1224 APNIC Region transit ASes present in the Internet Routing Table: 840 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 28 Number of APNIC region 32-bit ASNs visible in the Routing Table: 814 Number of APNIC addresses announced to Internet: 729945088 Equivalent to 43 /8s, 130 /16s and 20 /24s Percentage of available APNIC address space announced: 85.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 163875 Total ARIN prefixes after maximum aggregation: 82068 ARIN Deaggregation factor: 2.00 Prefixes being announced from the ARIN address blocks: 164320 Unique aggregates announced from the ARIN address blocks: 75852 ARIN Region origin ASes present in the Internet Routing Table: 15934 ARIN Prefixes per ASN: 10.31 ARIN Region origin ASes announcing only one prefix: 5966 ARIN Region transit ASes present in the Internet Routing Table: 1673 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 59 Number of ARIN addresses announced to Internet: 1071108864 Equivalent to 63 /8s, 215 /16s and 211 /24s Percentage of available ARIN address space announced: 56.7 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 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, 23/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, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 120956 Total RIPE prefixes after maximum aggregation: 61508 RIPE Deaggregation factor: 1.97 Prefixes being announced from the RIPE address blocks: 124705 Unique aggregates announced from the RIPE address blocks: 79612 RIPE Region origin ASes present in the Internet Routing Table: 17616 RIPE Prefixes per ASN: 7.08 RIPE Region origin ASes announcing only one prefix: 8342 RIPE Region transit ASes present in the Internet Routing Table: 2854 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2590 Number of RIPE addresses announced to Internet: 656353156 Equivalent to 39 /8s, 31 /16s and 39 /24s Percentage of available RIPE address space announced: 95.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, 56320-58367 59392-61439, 61952-62463, 196608-200191 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 53799 Total LACNIC prefixes after maximum aggregation: 9925 LACNIC Deaggregation factor: 5.42 Prefixes being announced from the LACNIC address blocks: 59419 Unique aggregates announced from the LACNIC address blocks: 27533 LACNIC Region origin ASes present in the Internet Routing Table: 2059 LACNIC Prefixes per ASN: 28.86 LACNIC Region origin ASes announcing only one prefix: 555 LACNIC Region transit ASes present in the Internet Routing Table: 403 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 35 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 979 Number of LACNIC addresses announced to Internet: 148668192 Equivalent to 8 /8s, 220 /16s and 127 /24s Percentage of available LACNIC address space announced: 88.6 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 11899 Total AfriNIC prefixes after maximum aggregation: 2606 AfriNIC Deaggregation factor: 4.57 Prefixes being announced from the AfriNIC address blocks: 12620 Unique aggregates announced from the AfriNIC address blocks: 4088 AfriNIC Region origin ASes present in the Internet Routing Table: 697 AfriNIC Prefixes per ASN: 18.11 AfriNIC Region origin ASes announcing only one prefix: 198 AfriNIC Region transit ASes present in the Internet Routing Table: 149 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 9 Number of AfriNIC addresses announced to Internet: 50232320 Equivalent to 2 /8s, 254 /16s and 124 /24s Percentage of available AfriNIC address space announced: 49.9 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2937 11557 951 Korea Telecom 17974 2737 902 88 PT Telekomunikasi Indonesia 7545 2146 320 116 TPG Telecom Limited 4755 1828 394 200 TATA Communications formerly 9829 1591 1282 44 National Internet Backbone 9583 1297 101 533 Sify Limited 7552 1235 1080 13 Viettel Corporation 9498 1213 309 68 BHARTI Airtel Ltd. 4808 1172 2121 348 CNCGROUP IP network China169 24560 1093 382 167 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3028 3688 53 BellSouth.net Inc. 22773 2324 2940 138 Cox Communications Inc. 1785 2154 689 127 PaeTec Communications, Inc. 18566 2048 379 178 MegaPath Corporation 20115 1684 1668 586 Charter Communications 4323 1629 1089 407 tw telecom holdings, inc. 701 1499 11173 768 MCI Communications Services, 30036 1376 297 570 Mediacom Communications Corp 7018 1299 18004 845 AT&T Services, Inc. 6983 1295 756 581 ITC^Deltacom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1842 544 16 OJSC "Vimpelcom" 34984 1393 244 225 TELLCOM ILETISIM HIZMETLERI A 20940 1224 460 924 Akamai International B.V. 13188 1039 99 30 TOV "Bank-Inform" 31148 1013 45 21 Freenet Ltd. 6849 873 362 37 JSC "Ukrtelecom" 8551 851 370 38 Bezeq International-Ltd 6830 772 2327 425 Liberty Global Operations B.V 12479 697 797 55 France Telecom Espana SA 35228 553 246 16 Telefonica UK Limited Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3325 1862 78 NET Servi?os de Comunica??o S 10620 2681 434 237 Telmex Colombia S.A. 18881 1831 909 21 Global Village Telecom 7303 1744 1165 223 Telecom Argentina S.A. 8151 1376 2884 427 Uninet S.A. de C.V. 11830 869 364 15 Instituto Costarricense de El 7738 847 1626 39 Telemar Norte Leste S.A. 6503 838 434 60 Axtel, S.A.B. de C.V. 27947 836 93 94 Telconet S.A 6147 773 373 27 Telefonica del Peru S.A.A. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1810 240 6 Sudanese Mobile Telephone (ZA 24863 909 380 28 Link Egypt (Link.NET) 6713 600 653 27 Office National des Postes et 8452 471 956 9 TE-AS 24835 298 144 9 Vodafone Data 3741 246 921 208 Internet Solutions 29571 242 21 14 Cote d'Ivoire Telecom 36992 239 783 24 ETISALAT MISR 15706 219 32 6 Sudatel (Sudan Telecom Co. Lt 29975 192 668 21 Vodacom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3325 1862 78 NET Servi?os de Comunica??o S 6389 3028 3688 53 BellSouth.net Inc. 4766 2937 11557 951 Korea Telecom 17974 2737 902 88 PT Telekomunikasi Indonesia 10620 2681 434 237 Telmex Colombia S.A. 22773 2324 2940 138 Cox Communications Inc. 1785 2154 689 127 PaeTec Communications, Inc. 7545 2146 320 116 TPG Telecom Limited 18566 2048 379 178 MegaPath Corporation 8402 1842 544 16 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3028 2975 BellSouth.net Inc. 17974 2737 2649 PT Telekomunikasi Indonesia 10620 2681 2444 Telmex Colombia S.A. 22773 2324 2186 Cox Communications Inc. 7545 2146 2030 TPG Telecom Limited 1785 2154 2027 PaeTec Communications, Inc. 4766 2937 1986 Korea Telecom 18566 2048 1870 MegaPath Corporation 8402 1842 1826 OJSC "Vimpelcom" 18881 1831 1810 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.192.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.196.0/22 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.200.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.202.0/23 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 62828 UNALLOCATED 8.21.130.0/24 4323 tw telecom holdings, 62850 UNALLOCATED 8.25.147.0/24 46887 Lightower Fiber Netw 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.90.128.0/18 27418 OUTOFWALL INC. 23.91.0.0/19 40676 Psychz Networks 23.91.14.0/24 40676 Psychz Networks 23.91.32.0/19 36315 Servpac Inc. 23.91.80.0/20 21560 Netstream Communications, LLC 23.91.96.0/20 40676 Psychz Networks 23.91.111.0/24 49544 i3d B.V. 23.91.112.0/21 32475 SingleHop 23.91.120.0/21 36351 SoftLayer Technologies Inc. 23.91.128.0/19 5645 TekSavvy Solutions, Inc. Complete listing at http://thyme.rand.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:16 /9:11 /10:30 /11:92 /12:253 /13:475 /14:944 /15:1650 /16:12879 /17:6819 /18:11477 /19:23690 /20:33430 /21:36046 /22:51022 /23:44484 /24:254375 /25:784 /26:941 /27:426 /28:12 /29:16 /30:9 /31:0 /32:11 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2003 2048 MegaPath Corporation 36998 1771 1810 Sudanese Mobile Telephone (ZA 6389 1698 3028 BellSouth.net Inc. 22773 1568 2324 Cox Communications Inc. 8402 1523 1842 OJSC "Vimpelcom" 30036 1216 1376 Mediacom Communications Corp 1785 1161 2154 PaeTec Communications, Inc. 11492 1157 1194 CABLE ONE, INC. 6983 1036 1295 ITC^Deltacom 22561 980 1261 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:939 2:811 3:3 4:16 5:891 6:21 8:640 12:1869 13:3 14:920 15:9 16:3 17:23 18:19 20:36 23:665 24:1726 27:1723 31:1540 32:44 33:2 34:5 36:114 37:1922 38:916 39:4 40:188 41:3259 42:245 44:14 46:2135 47:12 49:663 50:864 52:12 54:44 55:4 57:26 58:1139 59:624 60:370 61:1575 62:1197 63:1958 64:4394 65:2315 66:4141 67:2042 68:1077 69:3277 70:916 71:505 72:2041 74:2620 75:315 76:307 77:1147 78:1030 79:692 80:1321 81:1080 82:683 83:741 84:662 85:1238 86:424 87:989 88:495 89:1617 90:146 91:5719 92:661 93:1636 94:2061 95:1473 96:536 97:349 98:1067 99:41 100:32 101:719 103:4036 105:534 106:142 107:411 108:548 109:2046 110:979 111:1214 112:614 113:819 114:774 115:1153 116:1026 117:834 118:1244 119:1304 120:322 121:900 122:1926 123:1266 124:1431 125:1455 128:630 129:242 130:359 131:661 132:354 133:159 134:318 135:72 136:281 137:317 138:351 139:143 140:205 141:356 142:550 143:414 144:504 145:96 146:590 147:426 148:783 149:356 150:151 151:476 152:413 153:208 154:79 155:521 156:317 157:421 158:294 159:832 160:359 161:464 162:1056 163:218 164:672 165:591 166:272 167:638 168:1045 169:123 170:1169 171:191 172:12 173:1620 174:687 175:567 176:1409 177:2689 178:1954 179:398 180:1607 181:953 182:1392 183:495 184:635 185:1197 186:2762 187:1443 188:2030 189:1270 190:7365 191:25 192:7046 193:5434 194:4020 195:3391 196:1350 197:1085 198:4841 199:5512 200:6078 201:2512 202:9019 203:8912 204:4509 205:2653 206:2917 207:2820 208:3947 209:3688 210:3131 211:1624 212:2216 213:1973 214:882 215:83 216:5455 217:1687 218:604 219:347 220:1268 221:593 222:334 223:577 End of report From rwebb at ropeguru.com Fri Jan 24 18:14:06 2014 From: rwebb at ropeguru.com (Robert Webb) Date: Fri, 24 Jan 2014 13:14:06 -0500 Subject: AOL Email Blocking Message-ID: <52E2AD6E.1070609@ropeguru.com> A while back I enlisted help for setting up a small email list server. It is now complete but only AOL is blocking my outbound email. Using their tools they did not report my IP as having a bad reputation. I applied for white listing my single IP and provided ALL the necessary feedback and white listing was denied. Can anyone here point me to someone to get this fixed. It is a small private email list for a local fire department with all consenting recipients. Robert From fmartin at linkedin.com Fri Jan 24 19:11:09 2014 From: fmartin at linkedin.com (Franck Martin) Date: Fri, 24 Jan 2014 19:11:09 +0000 Subject: AOL Email Blocking In-Reply-To: <52E2AD6E.1070609@ropeguru.com> References: <52E2AD6E.1070609@ropeguru.com> Message-ID: <77426B543150464AA3F30DF1A91365DE6AFF5C01@ESV4-MBX01.linkedin.biz> On Jan 24, 2014, at 10:14 AM, Robert Webb wrote: > A while back I enlisted help for setting up a small email list server. It is now complete but only AOL is blocking my outbound email. > > Using their tools they did not report my IP as having a bad reputation. I applied for white listing my single IP and provided ALL the necessary feedback and white listing was denied. > > Can anyone here point me to someone to get this fixed. It is a small private email list for a local fire department with all consenting recipients. > What your logs are saying? Have you read the bounces? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rwebb at ropeguru.com Fri Jan 24 19:53:14 2014 From: rwebb at ropeguru.com (Robert Webb) Date: Fri, 24 Jan 2014 14:53:14 -0500 Subject: AOL Email Blocking In-Reply-To: <52E2AD6E.1070609@ropeguru.com> References: <52E2AD6E.1070609@ropeguru.com> Message-ID: <52E2C4AA.7080705@ropeguru.com> On 01/24/2014 01:14 PM, Robert Webb wrote: > A while back I enlisted help for setting up a small email list server. > It is now complete but only AOL is blocking my outbound email. > > Using their tools they did not report my IP as having a bad > reputation. I applied for white listing my single IP and provided ALL > the necessary feedback and white listing was denied. > > Can anyone here point me to someone to get this fixed. It is a small > private email list for a local fire department with all consenting > recipients. > > Robert > > Thanks to everyone that has responded. The issue has been addressed and worked out. For those of you that asked, I was getting the following: 421 DYN:T1 * The IP address you are sending from has been temporarily rate limited due to lack of whitelisting , unexpected changes in volume, or poor IP reputation . Robert Webb From rob at invaluement.com Fri Jan 24 20:05:11 2014 From: rob at invaluement.com (Rob McEwen) Date: Fri, 24 Jan 2014 15:05:11 -0500 Subject: AOL Email Blocking In-Reply-To: <52E2C4AA.7080705@ropeguru.com> References: <52E2AD6E.1070609@ropeguru.com> <52E2C4AA.7080705@ropeguru.com> Message-ID: <52E2C777.9080301@invaluement.com> On 1/24/2014 2:53 PM, Robert Webb wrote: > A while back I enlisted help for setting up a small email list server. > It is now complete but only AOL is blocking my outbound email. Send me your IP (off list if desired) and I'll evaluate it and possibly provide some feedback that may be helpful! -- Rob McEwen http://dnsbl.invaluement.com/ rob at invaluement.com +1 (478) 475-9032 From jra at baylink.com Fri Jan 24 20:08:36 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 24 Jan 2014 15:08:36 -0500 (EST) Subject: Google causes 40% drop in traffic? Message-ID: <11055999.5376.1390594116454.JavaMail.root@benjamin.baylink.com> Given how much traffic these days is CDN and streaming, is that number really supportable? http://www.marketplace.org/topics/tech/down-goes-google-down-goes-internet Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From mksmith at mac.com Fri Jan 24 20:16:34 2014 From: mksmith at mac.com (Michael Smith) Date: Fri, 24 Jan 2014 12:16:34 -0800 Subject: Google causes 40% drop in traffic? In-Reply-To: <11055999.5376.1390594116454.JavaMail.root@benjamin.baylink.com> References: <11055999.5376.1390594116454.JavaMail.root@benjamin.baylink.com> Message-ID: On Jan 24, 2014, at 12:08 PM, Jay Ashworth wrote: > Given how much traffic these days is CDN and streaming, is that number > really supportable? > > http://www.marketplace.org/topics/tech/down-goes-google-down-goes-internet > http://www.seattleix.net/agg.htm http://www.torix.ca/stats.php Obviously not definitive, but I don't see a massive drop in traffic during the outage, at least on the two public exchanges listed above. It would be interesting to see if there was a concurrent increase in traffic to other sites (Facebook, Yahoo, etc.) while people couldn't check their email. Mike From nanog at stefan-neufeind.de Fri Jan 24 20:22:58 2014 From: nanog at stefan-neufeind.de (Stefan Neufeind) Date: Fri, 24 Jan 2014 21:22:58 +0100 Subject: Google causes 40% drop in traffic? In-Reply-To: <11055999.5376.1390594116454.JavaMail.root@benjamin.baylink.com> References: <11055999.5376.1390594116454.JavaMail.root@benjamin.baylink.com> Message-ID: <52E2CBA2.9000503@stefan-neufeind.de> On 01/24/2014 09:08 PM, Jay Ashworth wrote: > Given how much traffic these days is CDN and streaming, is that number > really supportable? > > http://www.marketplace.org/topics/tech/down-goes-google-down-goes-internet In the interview they are saying that if Google is down, lots of people don't have DNS anymore. So that accounts for an even larger drop than just "no Youtube". Hmm - why would people use those resolvers, besides being lazy in configuring a proper resolver-address. Of course if Google is down we have no Google search (well, might be a problem in some cases), no Gmail etc. (fine with me) and no Youtube (hmm, but we'll survive without it). Come on ... If the average user is *so* dependent on Google, we have an even larger problem. Maybe like IPv6-day etc. lets try a "Google outage day" once a year as a training :-) Regards, Stefan From ESundberg at nitelusa.com Fri Jan 24 20:26:39 2014 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Fri, 24 Jan 2014 20:26:39 +0000 Subject: OSPF Costs Formula that include delay. In-Reply-To: <1390532559.26143.YahooMailNeo@web181703.mail.ne1.yahoo.com> References: <495D0934DA46854A9CA758393724D5903B8375@NI-MAIL02.nii.ads> <1390532559.26143.YahooMailNeo@web181703.mail.ne1.yahoo.com> Message-ID: <495D0934DA46854A9CA758393724D5903B9787@NI-MAIL02.nii.ads> I understand OSPF default calculation for cost doesn't include delay. I am looking for a formula that I can use to manually set the OSPF costs that factors in delay. When using OSPF's default costs, the shortest path is not always the optimal path. Example New York to Los Angeles. Assuming all links are the same bandwidth and have a ospf cost of 1. Path 1 (75ms) - OSPF Cost 2 - New York > Dallas > Los Angeles Path 2 (65ms) - OSPF Cost 3 - New York > Chicago > Denver > Los Angeles If I left the default cost's alone then path 1 would win because it has a lower ospf cost, however it take traffic 10ms longer to get there. However I would like traffic to take Path 2 by adjusting the OSPF cost. I am looking for a formula that other people are using .p Thanks Erik -----Original Message----- From: Randy [mailto:randy_94108 at yahoo.com] Sent: Thursday, January 23, 2014 9:03 PM To: Erik Sundberg; nanog at nanog.org Subject: Re: OSPF Costs Formula that include delay. ----- Original Message ----- > From: Erik Sundberg > To: "nanog at nanog.org" > Cc: > Sent: Thursday, January 23, 2014 4:47 PM > Subject: OSPF Costs Formula that include delay. > > What is everyone using for an OSPF cost formula that factors in a > circuits delay and bandwidth (10M-100G)??? > > Thanks in advance umm..are you sure your question is not about EIGRP? OSPF has no concept of interface-delays. The default reference bandwidth for OSPF is 100M In your case if you set your reference bandwidth to 100000 your 100G links would have a link cost of 1, 10G - 10, 1G-100, 100M-1000 and 10M-10000 A vendor specific list would be a better place to ask. ./Randy ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From jra at baylink.com Fri Jan 24 20:31:02 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 24 Jan 2014 15:31:02 -0500 (EST) Subject: Google causes 40% drop in traffic? In-Reply-To: <11055999.5376.1390594116454.JavaMail.root@benjamin.baylink.com> Message-ID: <21093881.5384.1390595462863.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jay Ashworth" > http://www.marketplace.org/topics/tech/down-goes-google-down-goes-internet It's just been pointed out to me that, even though Marketplace just posted the link to that piece, the dateline is from August. My apologies for not noticing. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From morrowc.lists at gmail.com Fri Jan 24 20:34:33 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 24 Jan 2014 15:34:33 -0500 Subject: Google causes 40% drop in traffic? In-Reply-To: <52E2CBA2.9000503@stefan-neufeind.de> References: <11055999.5376.1390594116454.JavaMail.root@benjamin.baylink.com> <52E2CBA2.9000503@stefan-neufeind.de> Message-ID: On Fri, Jan 24, 2014 at 3:22 PM, Stefan Neufeind wrote: > In the interview they are saying that if Google is down, lots of people > don't have DNS anymore. So that accounts for an even larger drop than > just "no Youtube". Hmm - why would people use those resolvers, besides > being lazy in configuring a proper resolver-address. it's a bit perjorative to say 'lazy' isn't it? what if your ISP does monkey business with nxdomain or other requests? would you like it better if people used opendns? or 4.2.2.2? (a non-sla service from a fourth party...) I'm a fan of my own resolver, but not everyone has a dns resolver in they back pocket, right? From owen at delong.com Fri Jan 24 20:36:48 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 24 Jan 2014 12:36:48 -0800 Subject: OSPF Costs Formula that include delay. In-Reply-To: <495D0934DA46854A9CA758393724D5903B9787@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D5903B8375@NI-MAIL02.nii.ads> <1390532559.26143.YahooMailNeo@web181703.mail.ne1.yahoo.com> <495D0934DA46854A9CA758393724D5903B9787@NI-MAIL02.nii.ads> Message-ID: <7C20A721-0F11-4368-ADA4-11E512C06777@delong.com> Some networks I have worked with took the average latency of each link and assigned that (with some constant multiple) as the interface cost. Of course this all fails miserably if you are using anything like MPLS underneath your OSPF. Owen On Jan 24, 2014, at 12:26 PM, Erik Sundberg wrote: > I understand OSPF default calculation for cost doesn't include delay. I am looking for a formula that I can use to manually set the OSPF costs that factors in delay. > > When using OSPF's default costs, the shortest path is not always the optimal path. > > > Example > > New York to Los Angeles. Assuming all links are the same bandwidth and have a ospf cost of 1. > > Path 1 (75ms) - OSPF Cost 2 - New York > Dallas > Los Angeles > > Path 2 (65ms) - OSPF Cost 3 - New York > Chicago > Denver > Los Angeles > > If I left the default cost's alone then path 1 would win because it has a lower ospf cost, however it take traffic 10ms longer to get there. > > However I would like traffic to take Path 2 by adjusting the OSPF cost. > > > I am looking for a formula that other people are using .p > > Thanks > > Erik > > > -----Original Message----- > From: Randy [mailto:randy_94108 at yahoo.com] > Sent: Thursday, January 23, 2014 9:03 PM > To: Erik Sundberg; nanog at nanog.org > Subject: Re: OSPF Costs Formula that include delay. > > > > ----- Original Message ----- >> From: Erik Sundberg >> To: "nanog at nanog.org" >> Cc: >> Sent: Thursday, January 23, 2014 4:47 PM >> Subject: OSPF Costs Formula that include delay. >> >> What is everyone using for an OSPF cost formula that factors in a >> circuits delay and bandwidth (10M-100G)??? >> >> Thanks in advance > > > > umm..are you sure your question is not about EIGRP? > OSPF has no concept of interface-delays. > > The default reference bandwidth for OSPF is 100M > > In your case if you set your reference bandwidth to 100000 your 100G links would have a link cost of 1, 10G - 10, 1G-100, 100M-1000 and 10M-10000 > > A vendor specific list would be a better place to ask. > > > ./Randy > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From jra at baylink.com Fri Jan 24 20:38:12 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 24 Jan 2014 15:38:12 -0500 (EST) Subject: Google causes 40% drop in traffic? In-Reply-To: <52E2CBA2.9000503@stefan-neufeind.de> Message-ID: <19581141.5388.1390595892322.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Stefan Neufeind" > On 01/24/2014 09:08 PM, Jay Ashworth wrote: > > Given how much traffic these days is CDN and streaming, is that > > number really supportable? > > > > http://www.marketplace.org/topics/tech/down-goes-google-down-goes-internet > > In the interview they are saying that if Google is down, lots of people > don't have DNS anymore. So that accounts for an even larger drop than > just "no Youtube". Hmm - why would people use those resolvers, besides > being lazy in configuring a proper resolver-address. The amount of fun I had before I discovered "ipconfig /flushdns" suggests to me that that's not really a supportable argument. > Of course if Google is down we have no Google search (well, might be a > problem in some cases), no Gmail etc. (fine with me) and no Youtube > (hmm, but we'll survive without it). Come on ... > > If the average user is *so* dependent on Google, we have an even larger > problem. Maybe like IPv6-day etc. lets try a "Google outage day" once > a year as a training :-) We just did; weren't you paying attention? :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From shrdlu at deaddrop.org Fri Jan 24 20:40:59 2014 From: shrdlu at deaddrop.org (Shrdlu) Date: Fri, 24 Jan 2014 12:40:59 -0800 Subject: Google causes 40% drop in traffic? In-Reply-To: <21093881.5384.1390595462863.JavaMail.root@benjamin.baylink.com> References: <21093881.5384.1390595462863.JavaMail.root@benjamin.baylink.com> Message-ID: <52E2CFDB.2050303@deaddrop.org> On 1/24/2014 12:31 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Jay Ashworth" > >> http://www.marketplace.org/topics/tech/down-goes-google-down-goes-internet > > It's just been pointed out to me that, even though Marketplace just posted > the link to that piece, the dateline is from August. My apologies for > not noticing. You sure? I think that there is an actual outage, unrelated to the article you'd posted. http://techcrunch.com/2014/01/24/gmail-glitch-is-causing-thousands-of-emails-to-be-sent-to-one-mans-hotmail-account/ Of course, I could be wrong. I've been wrong before. -- "Reality is that which, when you stop believing in it, doesn't go away." "How To Build A Universe That Doesn't Fall Apart Two Days Later" Philip K. Dick (1928?1982) From ray at oneunified.net Fri Jan 24 20:41:15 2014 From: ray at oneunified.net (Raymond Burkholder) Date: Fri, 24 Jan 2014 16:41:15 -0400 Subject: OSPF Costs Formula that include delay. In-Reply-To: <7C20A721-0F11-4368-ADA4-11E512C06777@delong.com> References: <495D0934DA46854A9CA758393724D5903B8375@NI-MAIL02.nii.ads> <1390532559.26143.YahooMailNeo@web181703.mail.ne1.yahoo.com> <495D0934DA46854A9CA758393724D5903B9787@NI-MAIL02.nii.ads> <7C20A721-0F11-4368-ADA4-11E512C06777@delong.com> Message-ID: <0bca01cf1944$a0a4d020$e1ee7060$@oneunified.net> > > Some networks I have worked with took the average latency of each link and > assigned that (with some constant multiple) as the interface cost. > > Of course this all fails miserably if you are using anything like MPLS > underneath your OSPF. > But then when using MPLS underneath, then MPLS Traffic Engineering can be used to do some interesting path computations and resiliency configurations. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From Valdis.Kletnieks at vt.edu Fri Jan 24 20:46:17 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 24 Jan 2014 15:46:17 -0500 Subject: Google causes 40% drop in traffic? In-Reply-To: Your message of "Fri, 24 Jan 2014 21:22:58 +0100." <52E2CBA2.9000503@stefan-neufeind.de> References: <11055999.5376.1390594116454.JavaMail.root@benjamin.baylink.com> <52E2CBA2.9000503@stefan-neufeind.de> Message-ID: <26320.1390596377@turing-police.cc.vt.edu> On Fri, 24 Jan 2014 21:22:58 +0100, Stefan Neufeind said: > just "no Youtube". Hmm - why would people use those resolvers, besides > being lazy in configuring a proper resolver-address. A lot of people make value judgements on the relative likelyhood of finding evil in DNS packets coming from 8.8.8.8 versus DNS packets coming from the IP address handed to you in the DHCP reply.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From ahebert at pubnix.net Fri Jan 24 20:50:06 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 24 Jan 2014 15:50:06 -0500 Subject: About ddos-response@nfoservers.com In-Reply-To: <8CFB098F-1C79-4555-B21B-AACA4E9F74D0@puck.nether.net> References: <52E27741.5090507@pubnix.net> <8CFB098F-1C79-4555-B21B-AACA4E9F74D0@puck.nether.net> Message-ID: <52E2D1FE.7000401@pubnix.net> Hi, Well the abusers started to use burst and then switching targeted IP. Last time I opened a ticket with GT-T/nLayer for a ~120Mbps NTP DDoS Amplification "attempt" toward 2 of my IP's. . after 2h, I called them directly to be told they lost my original request; . after 4h, got told it wasn't assigned yet; . after 12h, they finally applied the filter as the amp attempt stopped; Based on that experience... why bother. To give you an idea, in the past 4 days and 30m queries, I'm up to 1100 blocked targets on one of my DNS Servers. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 01/24/14 09:36, Jared Mauch wrote: > On Jan 24, 2014, at 9:22 AM, Alain Hebert wrote: > >> Is there a [Spoofing Tracking Squad] out there? >> ( We're on GT-T/nLayer/Tinet ) > You haven?t been able to get GTT/nLayer/TINet to track the traffic back? > > Details are welcome, either here or in private. There are plenty of people who will chase and fix this stuff when they?re aware of it. > > - Jared > From gabe at teksavvy.ca Fri Jan 24 20:50:32 2014 From: gabe at teksavvy.ca (Gabriel Blanchard) Date: Fri, 24 Jan 2014 15:50:32 -0500 Subject: Google causes 40% drop in traffic? In-Reply-To: <52E2CFDB.2050303@deaddrop.org> References: <21093881.5384.1390595462863.JavaMail.root@benjamin.baylink.com> <52E2CFDB.2050303@deaddrop.org> Message-ID: <52E2D218.3040509@teksavvy.ca> On 14-01-24 03:40 PM, Shrdlu wrote: > On 1/24/2014 12:31 PM, Jay Ashworth wrote: >> ----- Original Message ----- >>> From: "Jay Ashworth" >> >>> http://www.marketplace.org/topics/tech/down-goes-google-down-goes-internet >>> >> >> It's just been pointed out to me that, even though Marketplace just >> posted >> the link to that piece, the dateline is from August. My apologies for >> not noticing. > > You sure? I think that there is an actual outage, unrelated to the > article you'd posted. > > http://techcrunch.com/2014/01/24/gmail-glitch-is-causing-thousands-of-emails-to-be-sent-to-one-mans-hotmail-account/ > > > Of course, I could be wrong. I've been wrong before. > Actual source http://www.google.com/appsstatus#hl=en&v=status -Gabe From jeff.tantsura at ericsson.com Fri Jan 24 20:58:12 2014 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Fri, 24 Jan 2014 20:58:12 +0000 Subject: OSPF Costs Formula that include delay. In-Reply-To: <495D0934DA46854A9CA758393724D5903B9787@NI-MAIL02.nii.ads> Message-ID: Eric, Issues: 1.OSPF (SPF) can only produce a SPT based on cost (metric). Anything else would require CSPF rather than SPF. 2. Delay is not distributed as part of an IGP update Typical constrains distributed are: bandwidth, color, some others In IETF we are working to also be able to distribute those kinds of metrics (draft-ietf-ospf/isis-te-metric-extensions) draft-ietf-mpls-te-express-path defines how to use these metrics for RSVP-TE (computation result is an ERO) however theoretically nothing precludes one (implementation) to use those for more comprehensive computation, i.e. delay could be taken into consideration as long as the path is loop free. So it would look like - compute all loop free paths to a destination and then choose one with the smallest cumulative delay. BTW - segment routing will give you this functionality day one :) Cheers, Jeff -----Original Message----- From: Erik Sundberg Date: Friday, January 24, 2014 12:26 PM To: Randy , "nanog at nanog.org" Subject: RE: OSPF Costs Formula that include delay. >I understand OSPF default calculation for cost doesn't include delay. I >am looking for a formula that I can use to manually set the OSPF costs >that factors in delay. > >When using OSPF's default costs, the shortest path is not always the >optimal path. > > >Example > >New York to Los Angeles. Assuming all links are the same bandwidth and >have a ospf cost of 1. > >Path 1 (75ms) - OSPF Cost 2 - New York > Dallas > Los Angeles > >Path 2 (65ms) - OSPF Cost 3 - New York > Chicago > Denver > Los Angeles > >If I left the default cost's alone then path 1 would win because it has a >lower ospf cost, however it take traffic 10ms longer to get there. > >However I would like traffic to take Path 2 by adjusting the OSPF cost. > > >I am looking for a formula that other people are using .p > >Thanks > >Erik > > >-----Original Message----- >From: Randy [mailto:randy_94108 at yahoo.com] >Sent: Thursday, January 23, 2014 9:03 PM >To: Erik Sundberg; nanog at nanog.org >Subject: Re: OSPF Costs Formula that include delay. > > > >----- Original Message ----- >> From: Erik Sundberg >> To: "nanog at nanog.org" >> Cc: >> Sent: Thursday, January 23, 2014 4:47 PM >> Subject: OSPF Costs Formula that include delay. >> >> What is everyone using for an OSPF cost formula that factors in a >> circuits delay and bandwidth (10M-100G)??? >> >> Thanks in advance > > > >umm..are you sure your question is not about EIGRP? >OSPF has no concept of interface-delays. > >The default reference bandwidth for OSPF is 100M > >In your case if you set your reference bandwidth to 100000 your 100G >links would have a link cost of 1, 10G - 10, 1G-100, 100M-1000 and >10M-10000 > >A vendor specific list would be a better place to ask. > > >./Randy > >________________________________ > >CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, >files or previous e-mail messages attached to it may contain confidential >information that is legally privileged. If you are not the intended >recipient, or a person responsible for delivering it to the intended >recipient, you are hereby notified that any disclosure, copying, >distribution or use of any of the information contained in or attached to >this transmission is STRICTLY PROHIBITED. If you have received this >transmission in error please notify the sender immediately by replying to >this e-mail. You must destroy the original transmission and its >attachments without reading or saving in any manner. Thank you. > From owen at delong.com Fri Jan 24 20:59:19 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 24 Jan 2014 12:59:19 -0800 Subject: OSPF Costs Formula that include delay. In-Reply-To: <0bca01cf1944$a0a4d020$e1ee7060$@oneunified.net> References: <495D0934DA46854A9CA758393724D5903B8375@NI-MAIL02.nii.ads> <1390532559.26143.YahooMailNeo@web181703.mail.ne1.yahoo.com> <495D0934DA46854A9CA758393724D5903B9787@NI-MAIL02.nii.ads> <7C20A721-0F11-4368-ADA4-11E512C06777@delong.com> <0bca01cf1944$a0a4d020$e1ee7060$@oneunified.net> Message-ID: <81568F67-1A4A-4E2D-80A3-6CDA6BA0BBF6@delong.com> On Jan 24, 2014, at 12:41 PM, Raymond Burkholder wrote: >> >> Some networks I have worked with took the average latency of each link and >> assigned that (with some constant multiple) as the interface cost. >> >> Of course this all fails miserably if you are using anything like MPLS >> underneath your OSPF. >> > > But then when using MPLS underneath, then MPLS Traffic Engineering can be > used to do some interesting path computations and resiliency configurations. I wasn?t attempting to promote or discourage use of MPLS. I was merely endeavoring to point out that in an MPLS world, OSPF costs are not how you want to manage your traffic. Owen From vsubramanian12 at aol.com Fri Jan 24 18:20:28 2014 From: vsubramanian12 at aol.com (Vishwanath Subramanian) Date: Fri, 24 Jan 2014 13:20:28 -0500 (EST) Subject: AOL Email Blocking In-Reply-To: <52E2AD6E.1070609@ropeguru.com> References: <52E2AD6E.1070609@ropeguru.com> Message-ID: <8D0E7481802870C-1C14-95E0@webmail-d262.sysops.aol.com> Robert, Please email me the details. Also please provide the ticket number for investigation. Thanks. Vish Subramanian AOL Mail Postmaster Operations -----Original Message----- From: Robert Webb To: nanog Sent: Fri, Jan 24, 2014 1:17 pm Subject: AOL Email Blocking A while back I enlisted help for setting up a small email list server. It is now complete but only AOL is blocking my outbound email. Using their tools they did not report my IP as having a bad reputation. I applied for white listing my single IP and provided ALL the necessary feedback and white listing was denied. Can anyone here point me to someone to get this fixed. It is a small private email list for a local fire department with all consenting recipients. Robert From palaemon at palaemon.es Fri Jan 24 09:37:14 2014 From: palaemon at palaemon.es (Octavio Alfageme) Date: Fri, 24 Jan 2014 10:37:14 +0100 (CET) Subject: Opensource tools for inventory and troubleticketing In-Reply-To: <1393125223.37939.1390555230304.open-xchange@ox-webdesk.1and1.es> References: <1393125223.37939.1390555230304.open-xchange@ox-webdesk.1and1.es> Message-ID: <1619681351.38746.1390556234448.open-xchange@ox-webdesk.1and1.es> Hello everyone, I work for a small service provider starting to offer MPLS services between Europe and several african countries. At present time we own a small Cisco network, but we are starting to need a better inventory of services and network resources and better troubleticketing procedures. We can not afford acquiring complicated and expensive tools at present time.I would be grateful if you could recommend me opensource tools to cover these needs. Thanks in advance Kind regards Octavio From jra at baylink.com Fri Jan 24 21:17:26 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 24 Jan 2014 16:17:26 -0500 (EST) Subject: Google causes 40% drop in traffic? In-Reply-To: <52E2CFDB.2050303@deaddrop.org> Message-ID: <30498590.5390.1390598246345.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Shrdlu" > You sure? I think that there is an actual outage, unrelated to the > article you'd posted. > > http://techcrunch.com/2014/01/24/gmail-glitch-is-causing-thousands-of-emails-to-be-sent-to-one-mans-hotmail-account/ There was an outage today, and that was why Marketplace linked their piece on Facebook, which is where I saw, it, but the piece was not about today's outage. I was mislead, because there were 2 or 3 other pieces in the tech press already in other places that *were* about today's outage. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Fri Jan 24 21:22:21 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 24 Jan 2014 16:22:21 -0500 (EST) Subject: Opensource tools for inventory and troubleticketing In-Reply-To: <1619681351.38746.1390556234448.open-xchange@ox-webdesk.1and1.es> Message-ID: <24682329.5392.1390598541847.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Octavio Alfageme" > we are starting to need a better inventory of services and network > resources and better troubleticketing procedures. We can not afford acquiring > complicated and expensive tools at present time.I would be grateful if > you could recommend me opensource tools to cover these needs. Yeah, it was about time for this thread again. My networks are smaller than yours, but I have found that you can stretch Bugzilla a lot farther as a ticketing system than it's software development roots might suggest. It handles workflow, to a degree, and is pretty easy to learn. If you can't, RT is pretty nice, though quite a bit more complex. It used to have an asset tracking snap-on, but I don't know what the status of that is now that the main package has revved to 4.0. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From morrowc.lists at gmail.com Fri Jan 24 21:38:21 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 24 Jan 2014 16:38:21 -0500 Subject: About ddos-response@nfoservers.com In-Reply-To: <52E2D1FE.7000401@pubnix.net> References: <52E27741.5090507@pubnix.net> <8CFB098F-1C79-4555-B21B-AACA4E9F74D0@puck.nether.net> <52E2D1FE.7000401@pubnix.net> Message-ID: On Fri, Jan 24, 2014 at 3:50 PM, Alain Hebert wrote: > Hi, > > Well the abusers started to use burst and then switching targeted IP. > > Last time I opened a ticket with GT-T/nLayer for a ~120Mbps NTP DDoS > Amplification "attempt" toward 2 of my IP's. > > . after 2h, I called them directly to be told they lost my > original request; > > . after 4h, got told it wasn't assigned yet; > > . after 12h, they finally applied the filter as the amp attempt > stopped; > > Based on that experience... why bother. there are providers that have services to stop this sort of thing, there is at least one provider that does that stuff for free... you could vote with your wallet, of course. > To give you an idea, in the past 4 days and 30m queries, I'm up to > 1100 blocked targets on one of my DNS Servers. that's a bummer. From cidr-report at potaroo.net Fri Jan 24 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 24 Jan 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201401242200.s0OM00PX018897@wattle.apnic.net> This report has been generated at Fri Jan 24 21:13:35 2014 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/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 17-01-14 489707 274073 18-01-14 489328 274221 19-01-14 489528 274495 20-01-14 489868 274381 21-01-14 490079 274474 22-01-14 490317 274692 23-01-14 489912 274919 24-01-14 490385 275014 AS Summary 46141 Number of ASes in routing system 18935 Number of ASes announcing only one prefix 4428 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 119231744 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 24Jan14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 491049 275037 216012 44.0% All ASes AS28573 3327 83 3244 97.5% NET Servi?os de Comunica??o S.A. AS6389 3028 56 2972 98.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS7029 4428 1671 2757 62.3% WINDSTREAM - Windstream Communications Inc AS17974 2736 181 2555 93.4% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS22773 2327 194 2133 91.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4766 2937 960 1977 67.3% KIXS-AS-KR Korea Telecom AS1785 2154 404 1750 81.2% AS-PAETEC-NET - PaeTec Communications, Inc. AS18881 1833 90 1743 95.1% Global Village Telecom AS36998 1810 97 1713 94.6% SDN-MOBITEL AS10620 2686 1104 1582 58.9% Telmex Colombia S.A. AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath Corporation AS4323 2944 1513 1431 48.6% TWTC - tw telecom holdings, inc. AS7303 1744 451 1293 74.1% Telecom Argentina S.A. AS4755 1828 603 1225 67.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7545 2152 989 1163 54.0% TPG-INTERNET-AP TPG Telecom Limited AS7552 1260 156 1104 87.6% VIETEL-AS-AP Viettel Corporation AS22561 1261 227 1034 82.0% AS22561 - CenturyTel Internet Holdings, Inc. AS9829 1591 678 913 57.4% BSNL-NIB National Internet Backbone AS18101 990 184 806 81.4% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS35908 903 103 800 88.6% VPLSNET - Krypt Technologies AS4808 1172 387 785 67.0% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS17908 834 57 777 93.2% TCISL Tata Communications AS701 1499 768 731 48.8% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business AS24560 1093 369 724 66.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS8151 1384 662 722 52.2% Uninet S.A. de C.V. AS6983 1295 581 714 55.1% ITCDELTA - ITC^Deltacom AS13977 856 145 711 83.1% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS7738 847 150 697 82.3% Telemar Norte Leste S.A. AS4788 930 237 693 74.5% TMNET-AS-AP TM Net, Internet Service Provider AS855 745 56 689 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. Total 54641 13721 40920 74.9% Top 30 total Possible Bogus Routes 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 41.73.2.0/24 AS37004 41.73.10.0/24 AS37004 41.73.11.0/24 AS37004 41.73.12.0/24 AS37004 41.73.13.0/24 AS37004 41.73.15.0/24 AS37004 41.73.16.0/24 AS37004 41.73.18.0/24 AS37004 41.73.20.0/24 AS37004 41.73.21.0/24 AS37004 41.76.48.0/21 AS36969 MTL-AS 41.78.120.0/23 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.87.32.0/19 AS37242 41.190.72.0/23 AS37451 CongoTelecom 41.190.74.0/23 AS37451 CongoTelecom 41.191.92.0/22 AS37245 41.191.108.0/22 AS37004 41.191.108.0/24 AS37004 41.191.109.0/24 AS37004 41.191.110.0/24 AS37004 41.191.111.0/24 AS37004 41.217.208.0/22 AS37158 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.122.216.0/22 AS48727 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos 63.247.0.0/24 AS27609 63.247.1.0/24 AS27609 63.247.2.0/24 AS27609 63.247.3.0/24 AS27609 63.247.4.0/24 AS27609 63.247.5.0/24 AS27609 63.247.6.0/24 AS27609 63.247.7.0/24 AS27609 63.247.8.0/24 AS27609 63.247.9.0/24 AS27609 63.247.10.0/24 AS27609 63.247.11.0/24 AS27609 63.247.13.0/24 AS27609 63.247.14.0/24 AS27609 63.247.15.0/24 AS27609 63.247.16.0/24 AS27609 63.247.17.0/24 AS27609 63.247.18.0/24 AS27609 63.247.19.0/24 AS27609 63.247.20.0/24 AS27609 63.247.21.0/24 AS27609 63.247.22.0/24 AS27609 63.247.23.0/24 AS27609 63.247.24.0/24 AS27609 63.247.25.0/24 AS27609 63.247.26.0/24 AS27609 63.247.27.0/24 AS27609 63.247.28.0/24 AS27609 63.247.29.0/24 AS27609 64.25.16.0/23 AS19535 64.25.20.0/24 AS19535 64.25.21.0/24 AS19535 64.25.22.0/24 AS19535 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business 64.111.0.0/20 AS8039 CCC-ASN-1 - Cinergy Communications 64.111.160.0/20 AS40551 64.111.160.0/24 AS40551 64.111.161.0/24 AS40551 64.111.162.0/24 AS40551 64.111.167.0/24 AS40551 64.111.169.0/24 AS40551 64.111.170.0/24 AS40551 64.111.171.0/24 AS40551 64.111.172.0/24 AS40551 64.111.173.0/24 AS40551 64.111.174.0/24 AS40551 64.111.175.0/24 AS40551 64.119.240.0/22 AS26072 64.119.240.0/23 AS26072 64.119.242.0/23 AS26072 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.202.48.0/22 AS23380 64.202.52.0/23 AS23380 64.202.54.0/24 AS23380 64.202.55.0/24 AS23380 64.202.56.0/22 AS23380 64.202.60.0/24 AS23380 64.202.61.0/24 AS23380 64.202.62.0/24 AS23380 64.202.63.0/24 AS23380 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc. 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc. 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.11.112.0/20 AS14572 66.55.96.0/23 AS17203 66.55.98.0/24 AS17203 66.55.99.0/24 AS17203 66.55.100.0/22 AS17203 66.55.102.0/23 AS17203 66.55.104.0/21 AS17203 66.159.98.0/24 AS17206 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc. 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 66.206.208.0/22 AS23380 66.206.211.0/24 AS14288 MPINET - MPInet 66.206.212.0/24 AS23380 66.206.213.0/24 AS14288 MPINET - MPInet 66.206.214.0/24 AS23380 66.206.215.0/24 AS23380 66.206.216.0/23 AS14288 MPINET - MPInet 66.206.218.0/23 AS23380 66.206.220.0/22 AS23380 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.254.160.0/20 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.176.0/21 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 66.254.184.0/22 AS11402 CCCAS-1 - Charlotte Colocation Center, LLc 67.21.144.0/22 AS174 COGENT Cogent/PSI 67.21.148.0/22 AS174 COGENT Cogent/PSI 69.46.224.0/20 AS32592 HT-HB32592 - HuntTel 69.46.236.0/24 AS32592 HT-HB32592 - HuntTel 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.232.0/21 AS6246 AVALONTEL - AvalonTel 74.112.100.0/22 AS16764 74.113.200.0/23 AS46939 74.114.52.0/22 AS40818 74.114.52.0/23 AS40818 74.114.52.0/24 AS40818 74.114.53.0/24 AS40818 74.114.54.0/23 AS40818 74.114.54.0/24 AS40818 74.114.55.0/24 AS40818 74.114.140.0/22 AS32757 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 74.118.132.0/22 AS5117 77.243.80.0/24 AS42597 77.243.81.0/24 AS42597 77.243.88.0/24 AS42597 77.243.91.0/24 AS42597 77.243.94.0/24 AS42597 77.243.95.0/24 AS42597 80.248.64.0/20 AS30982 CAFETG AS de CAFE Informatique 80.248.64.0/21 AS8513 SKYVISION SkyVision Global Networks Ltd 80.248.64.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.65.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.66.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.67.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.68.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.69.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.70.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.71.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.72.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.73.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.74.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.75.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.76.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.77.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.78.0/24 AS30982 CAFETG AS de CAFE Informatique 80.248.79.0/24 AS30982 CAFETG AS de CAFE Informatique 80.250.32.0/22 AS37106 ODUA-AS 85.202.160.0/20 AS44404 91.193.60.0/22 AS3356 LEVEL3 Level 3 Communications 91.195.66.0/23 AS3356 LEVEL3 Level 3 Communications 91.197.36.0/22 AS43359 91.199.90.0/24 AS44330 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD 91.207.1.0/24 AS174 COGENT Cogent/PSI 91.207.152.0/24 AS64100 91.207.153.0/24 AS64100 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal 91.220.176.0/24 AS16265 LEASEWEB LeaseWeb B.V. 91.229.182.0/24 AS56960 91.229.186.0/24 AS56967 93.190.10.0/24 AS47254 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.11.1.0/24 AS9822 AMNET-AU-AP Amnet IT Services Pty Ltd 103.11.216.0/24 AS13208 103.11.217.0/24 AS13208 103.11.218.0/23 AS13117 KINGCORP-AS-IX Opennet Internet Exchange 103.11.219.0/24 AS13208 103.13.184.0/23 AS58674 103.15.228.0/22 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.228.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 103.15.230.0/23 AS38809 NXGNET-AS-AP Nextgen Networks 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 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 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange 151.216.128.0/17 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM" 151.216.128.0/18 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM" 151.216.192.0/18 AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM" 164.40.184.0/24 AS19821 172.85.0.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 174.136.192.0/18 AS14572 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL 178.218.240.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.241.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.242.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.243.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.244.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.245.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.246.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.247.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.248.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.249.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.250.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.251.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.252.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.253.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.254.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 178.218.255.0/24 AS44109 PROJECT-A-AS Stroy-Industria-1 LLC 185.64.0.0/23 AS6870 H1ASN H1 LLC 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A. 190.124.252.0/22 AS7303 Telecom Argentina S.A. 192.166.32.0/20 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.9.59.0/24 AS1257 TELE2 193.16.106.0/24 AS31539 193.16.145.0/24 AS31392 193.22.224.0/20 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF 193.26.0.0/24 AS34028 193.33.6.0/23 AS3356 LEVEL3 Level 3 Communications 193.138.168.0/22 AS3356 LEVEL3 Level 3 Communications 193.164.152.0/24 AS3356 LEVEL3 Level 3 Communications 193.178.217.0/24 AS20737 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc. 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company 193.200.52.0/23 AS16276 OVH OVH Systems 193.200.244.0/24 AS3356 LEVEL3 Level 3 Communications 193.201.244.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.201.245.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.201.246.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH 193.227.109.0/24 AS3356 LEVEL3 Level 3 Communications 193.254.218.0/23 AS25229 VOLIA-AS Kyivski Telekomunikatsiyni Merezhi LLC 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH 194.50.82.0/24 AS16276 OVH OVH Systems 194.63.152.0/22 AS3356 LEVEL3 Level 3 Communications 194.88.226.0/23 AS3356 LEVEL3 Level 3 Communications 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service 194.126.152.0/23 AS3356 LEVEL3 Level 3 Communications 194.126.219.0/24 AS34545 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd 195.28.168.0/23 AS8655 195.64.128.0/23 AS8751 MEDIASAT Media Sat SRL 195.85.194.0/24 AS3356 LEVEL3 Level 3 Communications 195.114.4.0/23 AS41158 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB 195.130.208.0/24 AS16265 LEASEWEB LeaseWeb B.V. 195.140.128.0/23 AS24722 BABILON-AS Babilon-T 195.149.119.0/24 AS3356 LEVEL3 Level 3 Communications 195.189.174.0/23 AS3356 LEVEL3 Level 3 Communications 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA 195.234.156.0/24 AS25028 195.242.182.0/24 AS3356 LEVEL3 Level 3 Communications 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.18.112.0/20 AS1916 Associa??o Rede Nacional de Ensino e Pesquisa 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 203.142.219.0/24 AS45149 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc. 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.187.11.0/24 AS51113 ELEKTA-AS Elekta 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc. 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp. 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 205.236.71.0/24 AS852 ASN852 - TELUS Communications Inc. 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.66.120.0/22 AS32757 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc. 208.69.192.0/23 AS6461 MFNX MFN - Metromedia Fiber Network 208.69.195.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 208.74.224.0/22 AS174 COGENT Cogent/PSI 208.75.152.0/21 AS32146 208.76.20.0/24 AS31812 208.76.21.0/24 AS31812 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc. 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.84.232.0/24 AS33131 208.84.234.0/24 AS33131 208.84.237.0/24 AS33131 208.84.238.0/24 AS33131 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C. 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.164.0/22 AS46099 208.92.224.0/22 AS32757 208.92.226.0/24 AS32757 209.161.96.0/20 AS8039 CCC-ASN-1 - Cinergy Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.193.112.0/20 AS209 ASN-QWEST-US NOVARTIS-DMZ-US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP. 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 212.119.32.0/19 AS12550 213.184.64.0/24 AS13071 213.184.65.0/24 AS13071 213.184.66.0/24 AS13071 213.184.67.0/24 AS13071 213.184.68.0/24 AS13071 213.184.69.0/24 AS13071 213.184.70.0/24 AS13071 213.184.71.0/24 AS13071 213.184.72.0/24 AS13071 213.184.73.0/24 AS13071 213.184.74.0/24 AS13071 213.184.75.0/24 AS13071 213.184.76.0/24 AS13071 213.184.77.0/24 AS13071 213.184.78.0/24 AS13071 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.14.64.0/20 AS14728 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Jan 24 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 24 Jan 2014 22:00:01 GMT Subject: BGP Update Report Message-ID: <201401242200.s0OM01hN018912@wattle.apnic.net> BGP Update Report Interval: 16-Jan-14 -to- 23-Jan-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS14420 44341 2.2% 183.2 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 2 - AS8402 32997 1.6% 16.7 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS24560 23921 1.2% 23.3 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 4 - AS13118 23897 1.2% 543.1 -- ASN-YARTELECOM OJSC Rostelecom 5 - AS9829 23469 1.2% 33.5 -- BSNL-NIB National Internet Backbone 6 - AS35181 23126 1.1% 1927.2 -- PWC Autonomous System Number for Public WareHouse Company 7 - AS9299 21287 1.1% 58.5 -- IPG-AS-AP Philippine Long Distance Telephone Company 8 - AS6713 19155 0.9% 34.1 -- IAM-AS 9 - AS4775 17805 0.9% 195.7 -- GLOBE-TELECOM-AS Globe Telecoms 10 - AS41691 17692 0.9% 491.4 -- SUMTEL-AS-RIPE Summa Telecom LLC 11 - AS45899 16871 0.8% 52.2 -- VNPT-AS-VN VNPT Corp 12 - AS14287 15745 0.8% 2624.2 -- TRIAD-TELECOM - Triad Telecom, Inc. 13 - AS9498 15070 0.8% 19.5 -- BBIL-AP BHARTI Airtel Ltd. 14 - AS59217 14853 0.7% 14853.0 -- AZONNELIMITED-AS-AP Azonne Limited 15 - AS27947 14493 0.7% 40.6 -- Telconet S.A 16 - AS27738 13784 0.7% 23.9 -- Ecuadortelecom S.A. 17 - AS28573 12948 0.6% 10.1 -- NET Servi?os de Comunica??o S.A. 18 - AS11976 12381 0.6% 229.3 -- FIDN - Fidelity Communication International Inc. 19 - AS62904 11220 0.6% 127.5 -- SERVERHUB-DALLAS - Eonix Corporation 20 - AS17557 10983 0.6% 439.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 - AS59217 14853 0.7% 14853.0 -- AZONNELIMITED-AS-AP Azonne Limited 2 - AS12922 6592 0.3% 6592.0 -- MULTITRADE-AS CEDACRI S.P.A. 3 - AS30437 4406 0.2% 4406.0 -- GE-MS003 - General Electric Company 4 - AS6629 8683 0.4% 4341.5 -- NOAA-AS - NOAA 5 - AS7202 8596 0.4% 4298.0 -- FAMU - Florida A & M University 6 - AS19406 3584 0.2% 3584.0 -- TWRS-MA - Towerstream I, Inc. 7 - AS16561 3433 0.2% 3433.0 -- ARIBANETWORK Ariba Inc. Autonomous System 8 - AS54465 8743 0.4% 2914.3 -- QPM-AS-1 - QuickPlay Media Inc. 9 - AS14287 15745 0.8% 2624.2 -- TRIAD-TELECOM - Triad Telecom, Inc. 10 - AS62431 2181 0.1% 2181.0 -- NCSC-IE-AS National Cyber Security Centre 11 - AS62751 2082 0.1% 2082.0 -- HSAUWC-AS - HSA-UWC 12 - AS35181 23126 1.1% 1927.2 -- PWC Autonomous System Number for Public WareHouse Company 13 - AS11533 1653 0.1% 1653.0 -- VERITY-AS - Verity, Inc. 14 - AS7247 1575 0.1% 1575.0 -- MOJO - Mojo Networks 15 - AS39810 2830 0.1% 1415.0 -- UA-WICOM The national operator of wireless communication "WiMAX-Ukraine" 16 - AS51861 1215 0.1% 1215.0 -- SHARED-AS Eric Dorr 17 - AS32528 7276 0.4% 909.5 -- ABBOTT Abbot Labs 18 - AS45806 2454 0.1% 818.0 -- SCB-TH-AS-AP Siam Commercial Bank 19 - AS11054 9474 0.5% 789.5 -- LIVEPERSON LivePerson, Inc 20 - AS23295 781 0.0% 781.0 -- EA-01 - Extend America TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/20 23680 1.1% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 85.239.28.0/24 23096 1.1% AS35181 -- PWC Autonomous System Number for Public WareHouse Company 3 - 103.243.164.0/22 14853 0.7% AS59217 -- AZONNELIMITED-AS-AP Azonne Limited 4 - 89.221.206.0/24 10364 0.5% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 5 - 206.152.15.0/24 8731 0.4% AS54465 -- QPM-AS-1 - QuickPlay Media Inc. 6 - 120.28.62.0/24 8726 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 7 - 222.127.0.0/24 8711 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 8 - 192.58.232.0/24 8681 0.4% AS6629 -- NOAA-AS - NOAA 9 - 85.249.160.0/20 7121 0.3% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 10 - 216.109.107.0/24 6866 0.3% AS11486 -- COLO-PREM-VZB - Verizon Online LLC AS16561 -- ARIBANETWORK Ariba Inc. Autonomous System 11 - 67.210.190.0/23 6780 0.3% AS11976 -- FIDN - Fidelity Communication International Inc. 12 - 194.105.61.0/24 6592 0.3% AS12922 -- MULTITRADE-AS CEDACRI S.P.A. 13 - 67.210.188.0/23 5446 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. 14 - 199.187.118.0/24 4741 0.2% AS11054 -- LIVEPERSON LivePerson, Inc 15 - 165.156.25.0/24 4406 0.2% AS30437 -- GE-MS003 - General Electric Company 16 - 168.223.206.0/23 4308 0.2% AS7202 -- FAMU - Florida A & M University 17 - 168.223.200.0/22 4288 0.2% AS7202 -- FAMU - Florida A & M University 18 - 130.36.35.0/24 3635 0.2% AS32528 -- ABBOTT Abbot Labs 19 - 130.36.34.0/24 3626 0.2% AS32528 -- ABBOTT Abbot Labs 20 - 69.38.178.0/24 3584 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From nanog at stefan-neufeind.de Fri Jan 24 22:23:53 2014 From: nanog at stefan-neufeind.de (Stefan Neufeind) Date: Fri, 24 Jan 2014 23:23:53 +0100 Subject: Google causes 40% drop in traffic? In-Reply-To: <26320.1390596377@turing-police.cc.vt.edu> References: <11055999.5376.1390594116454.JavaMail.root@benjamin.baylink.com> <52E2CBA2.9000503@stefan-neufeind.de> <26320.1390596377@turing-police.cc.vt.edu> Message-ID: <52E2E7F9.3040101@stefan-neufeind.de> On 01/24/2014 09:46 PM, Valdis.Kletnieks at vt.edu wrote: > On Fri, 24 Jan 2014 21:22:58 +0100, Stefan Neufeind said: > >> just "no Youtube". Hmm - why would people use those resolvers, besides >> being lazy in configuring a proper resolver-address. > > A lot of people make value judgements on the relative likelyhood of finding > evil in DNS packets coming from 8.8.8.8 versus DNS packets coming from the > IP address handed to you in the DHCP reply.... If it's just "some" DNS your provider hands out, I agree it's not much better as well. (But you might possibly assume your provider has less interst to spy on all your emails, your dns-queries and the like.) What imho you'll want is a reliable resolver which is as close to you as possible (and have it do DNSSEC-validation etc.). Regards, Stefan From jra at baylink.com Fri Jan 24 22:30:10 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 24 Jan 2014 17:30:10 -0500 (EST) Subject: Google causes 40% drop in traffic? In-Reply-To: <52E2E7F9.3040101@stefan-neufeind.de> Message-ID: <18234095.5423.1390602610252.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Stefan Neufeind" > If it's just "some" DNS your provider hands out, I agree it's not much > better as well. (But you might possibly assume your provider has less > interst to spy on all your emails, your dns-queries and the like.) You might assume that, I wouldn't. If your access provider is a commercial eyeball network like, say, Road Runner or Comcast, then there is, I believe, evidence that they do DPI and possibly even ad injection, in addition to playing NXDOMAIN games. > What imho you'll want is a reliable resolver which is as close to you > as possible (and have it do DNSSEC-validation etc.). Sure; everyone should have their recursing resolver at the edge of their network. But most consumers don't. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From scott at doc.net.au Fri Jan 24 22:52:49 2014 From: scott at doc.net.au (Scott Howard) Date: Fri, 24 Jan 2014 17:52:49 -0500 Subject: Google causes 40% drop in traffic? In-Reply-To: <11055999.5376.1390594116454.JavaMail.root@benjamin.baylink.com> References: <11055999.5376.1390594116454.JavaMail.root@benjamin.baylink.com> Message-ID: There was a lot of discussion about this figure back in August when the relevant outage occurred. >From memory, a large percentage of the traffic drop was from other sites breaking as a result of Google not being available. ie, a site completely unrelated to Google, potentially being served by a CDN, that was using Google Analytics on every page could fail to load and/or load/render slower as a result of the specific outage that Google had at the time. This resulted in a traffic drop for far more traffic than just that sourced from Google. A non-trivial percentage of the Internet is in some way or other dependent on things like Google Analytics/maps/etc, Facebook likes, Twitter recent tweets, etc, such that if any of those services are not available the site fails to load, either correctly or sometimes at all. The same is true in many causes for javascript/etc libraries being loaded from 3rd party sites like Google. Scott On Fri, Jan 24, 2014 at 3:08 PM, Jay Ashworth wrote: > Given how much traffic these days is CDN and streaming, is that number > really supportable? > > http://www.marketplace.org/topics/tech/down-goes-google-down-goes-internet > > Cheers, > -- jra > > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land > Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 > 1274 > > From morrowc.lists at gmail.com Fri Jan 24 23:02:51 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 24 Jan 2014 18:02:51 -0500 Subject: Google causes 40% drop in traffic? In-Reply-To: <52E2E7F9.3040101@stefan-neufeind.de> References: <11055999.5376.1390594116454.JavaMail.root@benjamin.baylink.com> <52E2CBA2.9000503@stefan-neufeind.de> <26320.1390596377@turing-police.cc.vt.edu> <52E2E7F9.3040101@stefan-neufeind.de> Message-ID: On Fri, Jan 24, 2014 at 5:23 PM, Stefan Neufeind wrote: > interst to spy on all your emails, your dns-queries and the like.) FUD much? have you read the public-dns ToS and privacy statements? if you haven't you might want to: > What imho you'll want is a reliable resolver which is as close to you as > possible (and have it do DNSSEC-validation etc.). you might also want to read: and for some (quite a few) users of 8.8.8.8 it's faster and closer than their ISP dns... which says something about the ISP provided DNS server(s) I suppose :( It's certainly not the answer for everyone, or everything, but shrugging it off for FUD reasons is just silly and makes little sense. -chris From jra at baylink.com Fri Jan 24 23:07:51 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 24 Jan 2014 18:07:51 -0500 (EST) Subject: Google causes 40% drop in traffic? In-Reply-To: Message-ID: <24482423.5427.1390604871728.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Howard" > A non-trivial percentage of the Internet is in some way or other dependent > on things like Google Analytics/maps/etc, Facebook likes, Twitter recent > tweets, etc, such that if any of those services are not available the site > fails to load, either correctly or sometimes at all. The same is true in > many causes for javascript/etc libraries being loaded from 3rd party sites > like Google. I wonder what percentage of large website operators whose site designs have such external dependencies have had it occur to them to include those external services in their monitoring systems? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From mysidia at gmail.com Sat Jan 25 00:31:58 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 24 Jan 2014 18:31:58 -0600 Subject: OSPF Costs Formula that include delay. In-Reply-To: References: <495D0934DA46854A9CA758393724D5903B9787@NI-MAIL02.nii.ads> Message-ID: On Fri, Jan 24, 2014 at 2:58 PM, Jeff Tantsura wrote: > Eric, > Issues: > 1.OSPF (SPF) can only produce a SPT based on cost (metric). > Anything else would require CSPF rather than SPF. > A CSPF based protocol would be a suitable algorithm for adding hard constraints, instead of preference, such as path delay must be less than X, instead of just a weight for each edge of the graph. However, if you like: you can use a manually set cost for every link ------- manually figure a weight based on bandwidth or delay at ideal utilization (but not both delay and bandwidth simultaneously). For example, if you equate cost to delay, then you might decide that the greatest delay any path through your AS/routing domain should ever see, from any pair of routers end-to-end is 120 milliseconds. Then you can scribble that down, and figure out what fraction of 120ms the delay for every IGP link is, under ideal conditions, to set your weight to the corresponding fraction of your chosen maximum weight. Then decide on a reference scale, for example: 100% = cost of 16384 Within that model, a link with 120 milliseconds delay, traversing that link costs 16384. Traversing a link with 10 milliseconds delay should have cost 1366, etc. Over multiple hops, the costs will then sum together, to give delay under idealized conditions. > 2. Delay is not distributed as part of an IGP update > Typical constrains distributed are: bandwidth, color, some others [snip] > > RSVP-TE (computation result is an ERO) however theoretically nothing > precludes one (implementation) to use those for more comprehensive > computation, i.e. delay could be taken into consideration as long as the > path is loop free. So it would look like - compute all loop free paths to > a destination and then choose one with the smallest cumulative delay. > What I would like to see is dynamic computation of Delay and Utilization. Instead of merely "choose the one with the smallest cumulative delay" ----- choose the one with the smallest cumulative delay, BUT, offer load balancing over the N lowest delay links in proportion to the available utilization. For instance... if one of the paths has a link somewhere in it is that 90% congested, load balance unequally, and send a majority of packets over the path with the maximum 25% utilization, that has less than 10% in additional delay. BTW - segment routing will give you this functionality day one :) > > Cheers, > Jeff -- -JH From ispbuilder at gmail.com Sat Jan 25 00:38:38 2014 From: ispbuilder at gmail.com (Mike) Date: Fri, 24 Jan 2014 20:38:38 -0400 Subject: Opensource tools for inventory and troubleticketing In-Reply-To: <24682329.5392.1390598541847.JavaMail.root@benjamin.baylink.com> References: <24682329.5392.1390598541847.JavaMail.root@benjamin.baylink.com> Message-ID: <52E3078E.1090300@gmail.com> On 14-01-24 05:22 PM, Jay Ashworth wrote: > If you can't, RT is pretty nice, though quite a bit more complex. It used > to have an asset tracking snap-on, but I don't know what the status of that > is now that the main package has revved to 4.0. > +1 on RT being awesome, but a little daunting to set up. like so many things, it's easy once you know how. Asset tracking of network-enabled devices can be done with netdot very nicely, as long as the devices implement SNMP properly. -- Looking for (employment|contract) work in the Internet industry, preferably working remotely. Building / Supporting the net since 2400 baud was the hot thing. Ask for a resume! ispbuilder at gmail.com From fmartin at linkedin.com Sat Jan 25 01:13:17 2014 From: fmartin at linkedin.com (Franck Martin) Date: Sat, 25 Jan 2014 01:13:17 +0000 Subject: Opensource tools for inventory and troubleticketing In-Reply-To: <1619681351.38746.1390556234448.open-xchange@ox-webdesk.1and1.es> References: <1393125223.37939.1390555230304.open-xchange@ox-webdesk.1and1.es> <1619681351.38746.1390556234448.open-xchange@ox-webdesk.1and1.es> Message-ID: <77426B543150464AA3F30DF1A91365DE6AFF9606@ESV4-MBX01.linkedin.biz> On Jan 24, 2014, at 1:37 AM, Octavio Alfageme wrote: > Hello everyone, > > I work for a small service provider starting to offer MPLS services between > Europe and several african countries. At present time we own a small Cisco > network, but we are starting to need a better inventory of services and network > resources and better troubleticketing procedures. We can not afford acquiring > complicated and expensive tools at present time.I would be grateful if you could > recommend me opensource tools to cover these needs. > try https://abusehq.abusix.com/ or http://wordtothewise.com/products/abacus.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From cody at killsudo.info Sat Jan 25 02:16:14 2014 From: cody at killsudo.info (Cody Rose) Date: Fri, 24 Jan 2014 20:16:14 -0600 Subject: Charter routing issues Message-ID: <52E31E6E.9070605@killsudo.info> Hello, Can someone from Charter Communications enlighten us to if you are having any issues or reach out to me directly. We are seeing some interesting traceroutes from St. Louis, Mo to St. Louis Charter customers via Level3, Qwest, or Cogent. Packets are being sent all over resulting in traceroutes 20 hops long. We are also seeing high latency between Qwest to XO for some routes. 1184.175.64.225 (184.175.64.225) 0.267 ms 0.241 ms 0.419 ms 2 172.23.27.2 (172.23.27.2) 30.195 ms 30.184 ms 30.176 ms 3 te-8-3.car1.StLouis1.Level3.net (4.53.161.53) 0.784 ms 0.782 ms 0.923 ms 4 ae-6-6.ebr2.Denver1.Level3.net (4.69.132.182) 33.222 ms 33.314 ms 33.295 ms 5 ae-1-100.ebr1.Denver1.Level3.net (4.69.151.181) 33.401 ms 33.358 ms 33.361 ms 6 ae-2-2.ebr2.Dallas1.Level3.net (4.69.132.106) 33.181 ms 32.876 ms 32.874 ms 7 ae-82-82.csw3.Dallas1.Level3.net (4.69.151.153) 32.871 ms ae-92-92.csw4.Dallas1.Level3.net (4.69.151.165) 33.111 ms ae-72-72.csw2.Dallas1.Level3.net (4.69.151.141) 33.600 ms 8 ae-2-70.edge2.Dallas1.Level3.net (4.69.145.75) 33.047 ms ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 32.879 ms 33.072 ms 9 CHARTER-COM.edge2.Dallas1.Level3.net (4.71.220.254) 34.095 ms CHARTER-COM.edge2.Dallas1.Level3.net (4.71.221.34) 32.178 ms CHARTER-COM.edge2.Dallas1.Level3.net (4.71.221.58) 35.925 ms 10 dtr01ovldmo-bue-4.ovld.mo.charter.com (96.34.2.19) 30.266 ms 30.263 ms 30.546 ms 11 crr01ovldmo-bue-100.ovld.mo.charter.com (96.34.49.220) 30.347 ms 30.563 ms 30.151 ms 12 crr02rxnail-tge-0-7-0-17.rxna.il.charter.com (96.34.50.115) 31.103 ms crr02rxnail-tge-0-7-0-19.rxna.il.charter.com (96.34.50.119) 31.106 ms crr02rxnail-tge-0-7-0-17.rxna.il.charter.com (96.34.50.115) 31.153 ms 13 crr01rxnail-tge-0-6-1-1.rxna.il.charter.com (96.34.50.16) 31.151 ms crr01rxnail-tge-0-6-1-2.rxna.il.charter.com (96.34.50.18) 31.219 ms crr01rxnail-tge-0-6-1-3.rxna.il.charter.com (96.34.49.190) 32.047 ms 14 crr02blvlil-bue-2.blvl.il.charter.com (96.34.50.97) 32.156 ms 32.249 ms 32.247 ms 15 dtr02blvlil-bue-100.blvl.il.charter.com (96.34.50.149) 31.599 ms crr01blvlil-bue-1.blvl.il.charter.com (96.34.49.232) 31.828 ms 31.552 ms 16 dtr01blvlil-bue-3.blvl.il.charter.com (96.34.49.139) 31.719 ms 32.340 ms 32.284 ms 17 dtr01osbhmo-tge-0-7-1-3.osbh.mo.charter.com (96.34.48.124) 36.638 ms 36.646 ms 36.640 ms 18 acr01osbhmo-tge-3-2.osbh.mo.charter.com (96.34.50.35) 36.762 ms 36.850 ms * 19 cts01osbhmo-tge-1-0-0.osbh.mo.charter.com (96.34.56.15) 36.001 ms 36.926 ms 36.926 ms 20 10.174.65.96 (10.174.65.96) 48.686 ms 48.686 ms 48.659 ms 21 24-240-188-2.static.stls.mo.charter.com (24.240.188.2) 44.111 ms 48.208 ms 53.722 ms # traceroute 75.128.167.38 traceroute to 75.128.167.38 (75.128.167.38), 30 hops max, 60 byte packets 1 bowser.video-direct.net (184.175.64.225) 0.246 ms 0.266 ms 0.262 ms 2 172.23.27.2 (172.23.27.2) 1.555 ms 1.593 ms 1.594 ms 3 crt1-crt2.cybercon.com (216.15.195.182) 1.402 ms 1.472 ms 1.471 ms 4 kcm-edge-17.inet.qwest.net (65.116.48.245) 13.336 ms 13.410 ms 13.405 ms 5 dap-brdr-04.inet.qwest.net (67.14.2.170) 19.025 ms 19.025 ms 18.969 ms 6 * 63.146.26.170 (63.146.26.170) 113.851 ms 113.746 ms 7 207.88.14.238.ptr.us.xo.net (207.88.14.238) 128.318 ms 128.282 ms 128.294 ms 8 ae0d0.mcr1.marylandheights-mo.us.xo.net (216.156.0.178) 126.072 ms 125.980 ms 126.079 ms 9 206.181.23.182 (206.181.23.182) 126.051 ms 126.140 ms 126.108 ms 10 dtr01blvlil-bue-1.blvl.il.charter.com (96.34.2.21) 126.034 ms 125.998 ms * 11 dtr01osbhmo-tge-0-7-1-3.osbh.mo.charter.com (96.34.48.124) 126.074 ms * * 12 acr01osbhmo-tge-3-2.osbh.mo.charter.com (96.34.50.35) 125.978 ms * 122.677 ms 13 cts01osbhmo-tge-1-0-0.osbh.mo.charter.com (96.34.56.15) 122.372 ms 121.404 ms 121.776 ms 14 10.174.64.247 (10.174.64.247) 136.737 ms 136.770 ms 131.410 ms 15 75-128-167-38.static.stls.mo.charter.com (75.128.167.38) 136.380 ms 131.092 ms 134.433 ms Inbound traffic routes seem normal but latency is high. 1 1 ms <1 ms <1 ms 10.0.0.1 2 9 ms 9 ms 9 ms 10.160.192.1 3 10 ms 9 ms 9 ms dtr01ovldmo-tge-0-3-0-13.ovld.mo.charter.com [96.34.52.8] 4 16 ms 17 ms 19 ms bbr01olvemo-bue-4.olve.mo.charter.com [96.34.2.18] 5 117 ms 122 ms 119 ms 63-156-122-145.dia.static.qwest.net [63.156.122.145] 6 120 ms 121 ms 121 ms kcm-edge-17.inet.qwest.net [67.14.11.174] 7 126 ms * 123 ms qwest-gige.cybercon.com [65.116.48.246] 8 40 ms 44 ms 41 ms 216.15.195.205 9 123 ms 124 ms 129 ms65.175.114.250 [65.175.114.250] cody at crt1-re1> show route aspath-regex "^174 20115" active-path match-prefix */24 | match BGP | count Count: 128 lines {master} cody at crt1-re1> show route aspath-regex "^209 20115" active-path match-prefix */24 | match BGP | count Count: 15 lines {master} cody at crt1-re1> show route aspath-regex "^3356 20115" active-path match-prefix */24 | match BGP | count Count: 77 lines cody at crt1-re1> show route aspath-regex "^209 20115" active-path | match BGP | count Count: 161 lines {master} cody at crt1-re1> show route aspath-regex "^174 20115" active-path | match BGP | count Count: 578 lines {master} cody at crt1-re1> show route aspath-regex "^3356 20115" active-path | match BGP | count Count: 396 lines From graham at apolix.co.za Sat Jan 25 06:10:54 2014 From: graham at apolix.co.za (Graham Beneke) Date: Sat, 25 Jan 2014 08:10:54 +0200 Subject: OSPF Costs Formula that include delay. In-Reply-To: <495D0934DA46854A9CA758393724D5903B9787@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D5903B8375@NI-MAIL02.nii.ads> <1390532559.26143.YahooMailNeo@web181703.mail.ne1.yahoo.com> <495D0934DA46854A9CA758393724D5903B9787@NI-MAIL02.nii.ads> Message-ID: <52E3556E.4060705@apolix.co.za> The auto-cost capability in some vendors devices seems to have left many people ignoring the link metrics within their IGP. From what I recall in the standards - bandwidth is one possible link metric but certainly not the only one. Network designers are free (and I would encourage to) pick whatever metric is relevant to them. On 24/01/2014 22:26, Erik Sundberg wrote: > I am looking for a formula that other people are using .p I've started to use a combination of 3 metrics to determine my costing: * The traditional auto-cost calculation based on a 100Gbps reference which gives far more useful values than the old 100Mbps reference. * An average or nominal link latency multiplied by a factor of 200. Sometimes adjusted if I want two geographically diverse paths between the same endpoints to have equivalent costs. * Path length in km multiplied by 2. This accounts for situations when the nominal latency is too small to accurately determine and assumes 1 ms per 100 km. I then pick the largest of the above 3 metrics as my OSPF cost. -- Graham Beneke From rdobbins at arbor.net Sat Jan 25 06:29:54 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 25 Jan 2014 06:29:54 +0000 Subject: Google causes 40% drop in traffic? In-Reply-To: <24482423.5427.1390604871728.JavaMail.root@benjamin.baylink.com> References: <24482423.5427.1390604871728.JavaMail.root@benjamin.baylink.com> Message-ID: <8141186F-AE2D-4F95-A4DC-36E956EFAF7A@arbor.net> On Jan 25, 2014, at 6:07 AM, Jay Ashworth wrote: > I wonder what percentage of large website operators whose site designs have such external dependencies have had it occur to them to include those > external services in their monitoring systems? This presupposes that they actually have monitoring systems which actually perform useful checks. All too often, this isn't the case. ;> ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From randy at psg.com Sat Jan 25 08:39:38 2014 From: randy at psg.com (Randy Bush) Date: Sat, 25 Jan 2014 17:39:38 +0900 Subject: GoDaddy DNS In-Reply-To: References: <52E0D954.4080709@viviotech.net> <01ac01cf1851$91e16880$b5a43980$@webjogger.net> Message-ID: > I should be clear that there are no bangs (!) in dns. the dns is 8-bit clean. bangs, dots (not as separators), blanks, etc. are all valid. some applications may have trouble with use of some of these :) randy From mysidia at gmail.com Sat Jan 25 09:20:07 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 25 Jan 2014 03:20:07 -0600 Subject: GoDaddy DNS In-Reply-To: References: <52E0D954.4080709@viviotech.net> <01ac01cf1851$91e16880$b5a43980$@webjogger.net> Message-ID: On Sat, Jan 25, 2014 at 2:39 AM, Randy Bush wrote: > > I should be clear that there are no bangs (!) in dns. > > the dns is 8-bit clean. bangs, dots (not as separators), blanks, etc. > are all valid. some applications may have trouble with use of some of > these :) > Not in the right-hand side (RDATA portion) of a type A record. The 32 bits will be interpreted as the bits of an IPv4 address, which are always 4 numeric values (0 to 255) separated by dots. "www.godaddy.com. 14 IN A zippidty-doo.com!" Is right out. If it were a "HS TXT", CH TXT, IN TXT, IN CNAME, IN NS, IN MX, IN SRV, or other similar fields, then sure. > randy > -- -JH From asullivan at dyn.com Sat Jan 25 12:51:11 2014 From: asullivan at dyn.com (Andrew Sullivan) Date: Sat, 25 Jan 2014 07:51:11 -0500 Subject: GoDaddy DNS In-Reply-To: References: <52E0D954.4080709@viviotech.net> <01ac01cf1851$91e16880$b5a43980$@webjogger.net> Message-ID: <20140125125111.GF2583@dyn.com> On Sat, Jan 25, 2014 at 03:20:07AM -0600, Jimmy Hess wrote: > The 32 bits will be interpreted as the bits of an IPv4 address, which are > always 4 numeric values (0 to 255) separated by dots. Well, that's how they're listed in master files, anyway; that's the only constraint RFC 1035 makes (see section 3.4.1). If you're outputting them for human consumption, you could of course output them in some other format. That might be surprising to some. (It's sure not what dig does.) I have heard claims that some hosts on the Internet did use other representations of v4 addresses for human consumption. I have never observed this. Certainly, the wire format is not dotted-quad, of course. (None of this is to disagree that anything other than a 32 bit Internet address would be ill-formed RDATA for an A record.) A -- Andrew Sullivan Dyn, Inc. asullivan at dyn.com v: +1 603 663 0448 From s+Mailinglisten.nanog at sloc.de Sat Jan 25 13:56:16 2014 From: s+Mailinglisten.nanog at sloc.de (Sebastian Spies) Date: Sat, 25 Jan 2014 14:56:16 +0100 Subject: Route Server Filters at IXPs and 4-byte ASNs Message-ID: <52E3C280.2060100@sloc.de> Hi there, as 2-byte ASNs are close to depletion (see NRO announcement this week), we have come across a topic, that might influence the adoption of 4-byte ASNs. First of all, we have no data or experience about 4-byte ASN adoption and are therefore unable to evaluate, if we should rush for the last available numbers. So here's the thing: IXPs usually implement N:M filtering based on standard community strings. As standard BGP communities support only 4 bytes, this only works for IXPs with 2-byte ASNs and peers with 2-byte ASNs. Extended communities to the rescue? We are not sure: While RFC4260 (Extended Communities) allows for : community strings (3.1 Two-Octet AS Specific Extended Community), this works as long as the IXP itself uses a 2-byte ASN. What happens, if the IXP uses a 4-byte ASN? RFC5668 (4-Octet AS Specific BGP Extended Community) defines :. I have been asking some IXP operators, about their practice and their reply was "4-byte ASNs are supported by our RS". What's your experience? Did you see IXPs, that do not support them? Do you think, the IXP operators are aware of this limitation? Have you seen IXPs with 4-byte ASNs or do RIRs reserve 2-byte ASNs for future IXPs? What other operational problems did you experience while using 4-byte ASNs? A lot of questions. I am very curious about your answers. Cheers, Sebastian -- SEBASTIAN SPIES lnked.in/sspies From rubensk at gmail.com Sat Jan 25 14:16:08 2014 From: rubensk at gmail.com (Rubens Kuhl) Date: Sat, 25 Jan 2014 12:16:08 -0200 Subject: Route Server Filters at IXPs and 4-byte ASNs In-Reply-To: <52E3C280.2060100@sloc.de> References: <52E3C280.2060100@sloc.de> Message-ID: > > What happens, if the IXP uses a 4-byte ASN? RFC5668 (4-Octet AS Specific > BGP Extended Community) defines : 2bytes>. > > I have been asking some IXP operators, about their practice and their > reply was "4-byte ASNs are supported by our RS". What's your experience? > Did you see IXPs, that do not support them? Do you think, the IXP > operators are aware of this limitation? Have you seen IXPs with 4-byte > ASNs or do RIRs reserve 2-byte ASNs for future IXPs? What other > operational problems did you experience while using 4-byte ASNs? > Do you see an issue with future IXP or future IXP members ? You can see at this list of members of one IXP that there are both 2-byte and 4-byte ASNs living in harmony, with a large number of 4-byte ones: http://ptt.br/particip/sp The IXP itself is using a 2-byte public ASN, so if at some point communities are used (although there are route-servers capable of granular policy without communities), they could use standard 2-byte community format. And with a bit coordination, 2-byte private ASNs and communities could be used to overcome limitations in member routers support of 4-byte ASNs. Rubens telnet lg.sp.ptt.br Trying 200.160.1.3... Connected to lg.sp.ptt.br. Escape character is '^]'. ============================================== = PTTMetro SP = = Contact: eng at ptt.br = = +55 11 5509-3550 = = inoc-dba: 22548*100 = = = = Looking Glass Server = = All connections and keystrokes logged = ============================================== lg.sp.ptt.br> show ip bgp summary BGP router identifier 187.16.218.252, local AS number 20121 RIB entries 32868, using 3081 KiB of memory Peers 4, using 18 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 187.16.216.253 4 26162 3294906 1619885 0 0 0 05w0d23h 19247 187.16.216.254 4 26162 3468468 1617924 0 0 0 01w5d06h 19227 Total number of neighbors 2 From job.snijders at hibernianetworks.com Sat Jan 25 14:26:23 2014 From: job.snijders at hibernianetworks.com (Job Snijders) Date: Sat, 25 Jan 2014 15:26:23 +0100 Subject: Route Server Filters at IXPs and 4-byte ASNs In-Reply-To: <52E3C280.2060100@sloc.de> References: <52E3C280.2060100@sloc.de> Message-ID: <20140125142623.GC2913@Eleanor.local> Dear Sebastian, On Sat, Jan 25, 2014 at 02:56:16PM +0100, Sebastian Spies wrote: > So here's the thing: IXPs usually implement N:M filtering based on > standard community strings. As standard BGP communities support only 4 > bytes, this only works for IXPs with 2-byte ASNs and peers with 2-byte > ASNs. There are various directions in which a workable solution may for IXP Operators: - Use a mapping table: 32 bit values to 16 bit values. Every participant with a 4-byte ASN is represented with 2-bytes, there are pro's and con's to this approach. - Use an out-of-band mechanism which allows IXP participants to signal the desired routing policy to the Route Server. (VIX.at offers a web-interface where people can click and point to which ASNs they want to export or not). Another approach would be to signal the desired routing policy through RPSL. I've been working on some extensions which would allow an IXP participant to publish what the Route Server should do on their behalf, in this example 6777 is a Route Server and AS4247483647 is an IXP participant with a 4-byte ASN: import-via: AS6777 from AS4247483647 accept AS4247483647 export-via: AS6777 to AS4247483647 announce AS-ATRATO (read more here: http://tools.ietf.org/html/draft-snijders-rpsl-via ) Support for these extensions will be available in the next release of the RIPE Whois Database. After that IXP Operators can consider implementing support for RPSL-via. All of the above approaches have disadvantages: - Mapping tables add complexity - Most Out-of-band methods would differ from each other - RPSL-via is has yet to be implemented in the wild > Extended communities to the rescue? Nope. Not as it stands today. > I have been asking some IXP operators, about their practice and their > reply was "4-byte ASNs are supported by our RS". What's your experience? Most of them are lying through their teeth. :-) Kind regards, Job -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 873 bytes Desc: not available URL: From bryan at serverstack.com Sat Jan 25 15:04:30 2014 From: bryan at serverstack.com (Bryan Socha) Date: Sat, 25 Jan 2014 10:04:30 -0500 Subject: Route Server Filters at IXPs and 4-byte ASNs In-Reply-To: <20140125142623.GC2913@Eleanor.local> References: <52E3C280.2060100@sloc.de> <20140125142623.GC2913@Eleanor.local> Message-ID: I have over 100,000 servers located in routing diverse datacenters with 4byte ASN numbers and have not had 1 problem or complaint related to the ASN for not able to communicate with the datacenter. The first 1 did make me really nervous for all of the reasons already mentioned but turned out to be a non-issue. While it would be nice to see community string support increase to 4byte, I think this is more of an educational challenge for the IXPs on how to setup your community strings to work and not really a technical problem. Bryan From job.snijders at hibernianetworks.com Sat Jan 25 15:18:59 2014 From: job.snijders at hibernianetworks.com (Job Snijders) Date: Sat, 25 Jan 2014 16:18:59 +0100 Subject: Route Server Filters at IXPs and 4-byte ASNs In-Reply-To: References: <52E3C280.2060100@sloc.de> <20140125142623.GC2913@Eleanor.local> Message-ID: <20140125151859.GD2913@Eleanor.local> On Sat, Jan 25, 2014 at 10:04:30AM -0500, Bryan Socha wrote: > I have over 100,000 servers located in routing diverse datacenters > with 4byte ASN numbers and have not had 1 problem or complaint related > to the ASN for not able to communicate with the datacenter. The first > 1 did make me really nervous for all of the reasons already mentioned > but turned out to be a non-issue. This thread is not about reachability of prefixes announced by 4-byte ASNs. This thread is about prefix filtering on Route Servers at Internet Exchanges. > While it would be nice to see community string support increase to 4byte, I > think this is more of an educational challenge for the IXPs on how to setup > your community strings to work and not really a technical problem. Can you elaborate on how you would setup 'community strings'? Kind regards, Job -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 873 bytes Desc: not available URL: From bryan at serverstack.com Sat Jan 25 15:38:11 2014 From: bryan at serverstack.com (Bryan Socha) Date: Sat, 25 Jan 2014 10:38:11 -0500 Subject: Route Server Filters at IXPs and 4-byte ASNs In-Reply-To: <20140125151859.GD2913@Eleanor.local> References: <52E3C280.2060100@sloc.de> <20140125142623.GC2913@Eleanor.local> <20140125151859.GD2913@Eleanor.local> Message-ID: Re-reading, I was thinking of someone connecting to an IXP, not a new IXP needing a 2Byte. This is an interesting situation and you are correct, my comment was off topic. *Bryan Socha* Network Engineer 646.450.0472 | *bryan at serverstack.com * *ServerStack* | Scale Big On Sat, Jan 25, 2014 at 10:18 AM, Job Snijders < job.snijders at hibernianetworks.com> wrote: > On Sat, Jan 25, 2014 at 10:04:30AM -0500, Bryan Socha wrote: > > I have over 100,000 servers located in routing diverse datacenters > > with 4byte ASN numbers and have not had 1 problem or complaint related > > to the ASN for not able to communicate with the datacenter. The first > > 1 did make me really nervous for all of the reasons already mentioned > > but turned out to be a non-issue. > > This thread is not about reachability of prefixes announced by 4-byte > ASNs. This thread is about prefix filtering on Route Servers at Internet > Exchanges. > > > While it would be nice to see community string support increase to > 4byte, I > > think this is more of an educational challenge for the IXPs on how to > setup > > your community strings to work and not really a technical problem. > > Can you elaborate on how you would setup 'community strings'? > > Kind regards, > > Job > From s+Mailinglisten.nanog at sloc.de Sat Jan 25 15:48:32 2014 From: s+Mailinglisten.nanog at sloc.de (Sebastian Spies) Date: Sat, 25 Jan 2014 16:48:32 +0100 Subject: Route Server Filters at IXPs and 4-byte ASNs In-Reply-To: References: <52E3C280.2060100@sloc.de> <20140125142623.GC2913@Eleanor.local> <20140125151859.GD2913@Eleanor.local> Message-ID: <52E3DCD0.2060101@sloc.de> Am 25.01.2014 16:38, schrieb Bryan Socha: > Re-reading, I was thinking of someone connecting to an IXP, not a new > IXP needing a 2Byte. This is an interesting situation and you are > correct, my comment was off topic. Sorry for not mentioning the beef: Extended Communities effectively leave 6 bytes to the user. So, it is not possible, that a 4-byte-ASN IXP encodes its own 4-byte-ASN and a 4-byte-ASN customer in one extended community string. This is needed, as the IXP RS usually interpret their own ASN and a peer ASN as: "Send this prefix out to the peer ASN". To make things worse: even if the IXPs ASN is 2-byte, I would assume, that RS implementors chose to interpret extended community strings as always being in the format 4-byte:2-byte (see RFC5668). Best regards, Sebastian From vireak.ouk at gmail.com Sat Jan 25 14:41:37 2014 From: vireak.ouk at gmail.com (Vireak Ouk) Date: Sat, 25 Jan 2014 21:41:37 +0700 Subject: Opensource tools for inventory and troubleticketing In-Reply-To: <77426B543150464AA3F30DF1A91365DE6AFF9606@ESV4-MBX01.linkedin.biz> References: <1393125223.37939.1390555230304.open-xchange@ox-webdesk.1and1.es> <1619681351.38746.1390556234448.open-xchange@ox-webdesk.1and1.es> <77426B543150464AA3F30DF1A91365DE6AFF9606@ESV4-MBX01.linkedin.biz> Message-ID: We decided against RT and use Redmine for tickets instead. We find Redmine to be much more user-friendly. On Jan 25, 2014 8:14 AM, "Franck Martin" wrote: > > On Jan 24, 2014, at 1:37 AM, Octavio Alfageme > wrote: > > > Hello everyone, > > > > I work for a small service provider starting to offer MPLS services > between > > Europe and several african countries. At present time we own a small > Cisco > > network, but we are starting to need a better inventory of services and > network > > resources and better troubleticketing procedures. We can not afford > acquiring > > complicated and expensive tools at present time.I would be grateful if > you could > > recommend me opensource tools to cover these needs. > > > > try https://abusehq.abusix.com/ or > http://wordtothewise.com/products/abacus.html > > From mark.tinka at seacom.mu Sat Jan 25 17:03:05 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 25 Jan 2014 19:03:05 +0200 Subject: OSPF Costs Formula that include delay. In-Reply-To: <7C20A721-0F11-4368-ADA4-11E512C06777@delong.com> References: <495D0934DA46854A9CA758393724D5903B8375@NI-MAIL02.nii.ads> <495D0934DA46854A9CA758393724D5903B9787@NI-MAIL02.nii.ads> <7C20A721-0F11-4368-ADA4-11E512C06777@delong.com> Message-ID: <201401251903.08615.mark.tinka@seacom.mu> On Friday, January 24, 2014 10:36:48 PM Owen DeLong wrote: > Of course this all fails miserably if you are using > anything like MPLS underneath your OSPF. Specifically, fails miserably if you use RSVP-TE to build your MPLS backbone. LDP follows IGP cost (has to be manually enabled in Junos), so no issues there if your MPLS domain is LDP-signaled. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Sat Jan 25 17:12:10 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 25 Jan 2014 19:12:10 +0200 Subject: OSPF Costs Formula that include delay. In-Reply-To: <81568F67-1A4A-4E2D-80A3-6CDA6BA0BBF6@delong.com> References: <495D0934DA46854A9CA758393724D5903B8375@NI-MAIL02.nii.ads> <0bca01cf1944$a0a4d020$e1ee7060$@oneunified.net> <81568F67-1A4A-4E2D-80A3-6CDA6BA0BBF6@delong.com> Message-ID: <201401251912.11028.mark.tinka@seacom.mu> On Friday, January 24, 2014 10:59:19 PM Owen DeLong wrote: > I wasn?t attempting to promote or discourage use of MPLS. > I was merely endeavoring to point out that in an MPLS > world, OSPF costs are not how you want to manage your > traffic. Again, only an issue when using RSVP-TE. I'd recommend MPLS-TE (especially core-to-core, as that is more scalable) when looking at making more aggregate routing decisions when dealing with a bandwidth vs. latency conundrum. Adjusting IGP costs in favour of latency works well, but can have pile-on effects behind or in front of the links being worked on, which can be confusing to troubleshoot when taking other PoP-specific factors into account. It also obliterates any sane cost-assignment mechanism you might have developed (or at best, makes it overly complex). There is room for both options, typically depending on network size, number of links, rate of topology change in your network and skill level of your network engineering team. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mfidelman at meetinghouse.net Sat Jan 25 17:24:33 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 25 Jan 2014 12:24:33 -0500 Subject: opensource tools for IP & DNS management [was: Opensource tools for inventory and troubleticketing] In-Reply-To: References: <1393125223.37939.1390555230304.open-xchange@ox-webdesk.1and1.es> <1619681351.38746.1390556234448.open-xchange@ox-webdesk.1and1.es> <77426B543150464AA3F30DF1A91365DE6AFF9606@ESV4-MBX01.linkedin.biz> Message-ID: <52E3F351.8090608@meetinghouse.net> Along related lines: Anybody have any suggestions for good opensource tools for managing blocks of IP addresses, and domain name assignments - ideally with hooks for updating nameservers and registry databases? Last time I looked everyone was still using either spreadsheets or high-priced proprietary tools - figure it's time to ask again. Thanks, Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From eyeronic.design at gmail.com Sat Jan 25 17:38:39 2014 From: eyeronic.design at gmail.com (Mike Hale) Date: Sat, 25 Jan 2014 09:38:39 -0800 Subject: opensource tools for IP & DNS management [was: Opensource tools for inventory and troubleticketing] In-Reply-To: <52E3F351.8090608@meetinghouse.net> References: <1393125223.37939.1390555230304.open-xchange@ox-webdesk.1and1.es> <1619681351.38746.1390556234448.open-xchange@ox-webdesk.1and1.es> <77426B543150464AA3F30DF1A91365DE6AFF9606@ESV4-MBX01.linkedin.biz> <52E3F351.8090608@meetinghouse.net> Message-ID: I've used IPPlan in the past to keep track of both internal and external assignments, and it worked really well. Super simple to use and setup. It's a bit of a dated project, but it'll still work pretty well. I also just saw this: http://phpipam.net/ It looks pretty slick. Haven't used it myself, but it looks like it does the trick as well. I don't know if there's hooks for updating anything, but since it's coded in PHP, you should be able to write something up pretty easily. On Sat, Jan 25, 2014 at 9:24 AM, Miles Fidelman wrote: > Along related lines: > > Anybody have any suggestions for good opensource tools for managing blocks > of IP addresses, and domain name assignments - ideally with hooks for > updating nameservers and registry databases? Last time I looked everyone > was still using either spreadsheets or high-priced proprietary tools - > figure it's time to ask again. > > Thanks, > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From mark.tinka at seacom.mu Sat Jan 25 17:47:18 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 25 Jan 2014 19:47:18 +0200 Subject: OSPF Costs Formula that include delay. In-Reply-To: <52E3556E.4060705@apolix.co.za> References: <495D0934DA46854A9CA758393724D5903B8375@NI-MAIL02.nii.ads> <495D0934DA46854A9CA758393724D5903B9787@NI-MAIL02.nii.ads> <52E3556E.4060705@apolix.co.za> Message-ID: <201401251947.21936.mark.tinka@seacom.mu> On Saturday, January 25, 2014 08:10:54 AM Graham Beneke wrote: > The auto-cost capability in some vendors devices seems to > have left many people ignoring the link metrics within > their IGP. From what I recall in the standards - > bandwidth is one possible link metric but certainly not > the only one. Network designers are free (and I would > encourage to) pick whatever metric is relevant to them. I think hard-coding cost on every link is better than relying on automatic application of the same by the IGP. Folk that use IS-IS have had to do this since the beginning. But given OSPF implementations support the manual setting of cost as well, you get the same benefits. > * The traditional auto-cost calculation based on a > 100Gbps reference which gives far more useful values > than the old 100Mbps reference. We use a reference bandwidth of 1Tbps, and manually calculate cost based on that. Admittedly, in 2014, bandwidth is probably less of a useful metric than latency, given 10Gbps links are "relatively" easy to get if you take the global capacity average into account, as well as the proliferation of CDN edge extensions and the data-centre-of- things rampage going on at the moment. > * An average or nominal link latency multiplied by a > factor of 200. Sometimes adjusted if I want two > geographically diverse paths between the same endpoints > to have equivalent costs. > > * Path length in km multiplied by 2. This accounts for > situations when the nominal latency is too small to > accurately determine and assumes 1 ms per 100 km. We are toying with a couple of models for doing this scalably in the IGP. The idea is to find a model that is as generic as possible, and doesn't take too many environmental considerations into account, but allows for them at a mid level. It is also equally important to use a model which will survive staffing churn and ease training/understanding, particularly in multi-vendor networks. Of course, in the worst of cases, MPLS-TE will be deployed to smoothen all of this out; and in fairness, barring any major developments in IS-IS and OSPF, may be the most scalable solution until SR (Segment Routing) takes hold. I hope to report back, say in a year from now, once the dust settles. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mis at seiden.com Sat Jan 25 18:25:31 2014 From: mis at seiden.com (Mark Seiden) Date: Sat, 25 Jan 2014 10:25:31 -0800 Subject: opensource tools for IP & DNS management [was: Opensource tools for inventory and troubleticketing] In-Reply-To: <52E3F351.8090608@meetinghouse.net> References: <1393125223.37939.1390555230304.open-xchange@ox-webdesk.1and1.es> <1619681351.38746.1390556234448.open-xchange@ox-webdesk.1and1.es> <77426B543150464AA3F30DF1A91365DE6AFF9606@ESV4-MBX01.linkedin.biz> <52E3F351.8090608@meetinghouse.net> Message-ID: <278727A3-1C93-4609-A99A-63051A6951B4@seiden.com> i am aware of http://www.stanford.edu/group/networking/netdb which is used widely at stanford and few other places. it?s going through some improvements, according to my reading of the list. tilburg university appears to be adopting it. not sure if it?s suitable mostly for an ISP. it uses oracle as the db although the storage layer is supposedly abstracted enough so another db could be substituted. On Jan 25, 2014, at 9:24 AM, Miles Fidelman wrote: > Along related lines: > > Anybody have any suggestions for good opensource tools for managing blocks of IP addresses, and domain name assignments - ideally with hooks for updating nameservers and registry databases? Last time I looked everyone was still using either spreadsheets or high-priced proprietary tools - figure it's time to ask again. > > Thanks, > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From nick at foobar.org Sat Jan 25 18:37:42 2014 From: nick at foobar.org (Nick Hilliard) Date: Sat, 25 Jan 2014 18:37:42 +0000 Subject: Route Server Filters at IXPs and 4-byte ASNs In-Reply-To: <52E3DCD0.2060101@sloc.de> References: <52E3C280.2060100@sloc.de> <20140125142623.GC2913@Eleanor.local> <20140125151859.GD2913@Eleanor.local> <52E3DCD0.2060101@sloc.de> Message-ID: <52E40476.20200@foobar.org> On 25/01/2014 15:48, Sebastian Spies wrote: > To make things worse: even if the IXPs ASN is 2-byte, I would assume, > that RS implementors chose to interpret extended community strings as > always being in the format 4-byte:2-byte (see RFC5668). some ixp operators (e.g. me) are rather enthusiastic about the idea of a modified form of draft-raszuk-wide-bgp-communities getting more traction. This would solve this particular problem and many others. Nick From alexmern at xi.uz Sat Jan 25 18:49:17 2014 From: alexmern at xi.uz (Alexander Merniy) Date: Sat, 25 Jan 2014 23:49:17 +0500 Subject: opensource tools for IP & DNS management [was: Opensource tools for inventory and troubleticketing] In-Reply-To: <278727A3-1C93-4609-A99A-63051A6951B4@seiden.com> References: <1393125223.37939.1390555230304.open-xchange@ox-webdesk.1and1.es> <1619681351.38746.1390556234448.open-xchange@ox-webdesk.1and1.es> <77426B543150464AA3F30DF1A91365DE6AFF9606@ESV4-MBX01.linkedin.biz> <52E3F351.8090608@meetinghouse.net> <278727A3-1C93-4609-A99A-63051A6951B4@seiden.com> Message-ID: <06B03CFD-FC78-4C59-B505-9C5517CB9162@xi.uz> Try this: http://nocproject.org On 25 Jan 2014, at 23:25, Mark Seiden wrote: > i am aware of > > http://www.stanford.edu/group/networking/netdb > > which is used widely at stanford and few other places. it?s going through some improvements, according to > my reading of the list. tilburg university appears to be adopting it. not sure if it?s suitable mostly > for an ISP. it uses oracle as the db although the storage layer is supposedly abstracted enough so another > db could be substituted. > > On Jan 25, 2014, at 9:24 AM, Miles Fidelman wrote: > >> Along related lines: >> >> Anybody have any suggestions for good opensource tools for managing blocks of IP addresses, and domain name assignments - ideally with hooks for updating nameservers and registry databases? Last time I looked everyone was still using either spreadsheets or high-priced proprietary tools - figure it's time to ask again. >> >> Thanks, >> >> Miles Fidelman >> >> -- >> In theory, there is no difference between theory and practice. >> In practice, there is. .... Yogi Berra >> >> > From bblackford at gmail.com Sat Jan 25 18:49:39 2014 From: bblackford at gmail.com (Bill Blackford) Date: Sat, 25 Jan 2014 10:49:39 -0800 Subject: OSPF Costs Formula that include delay. In-Reply-To: <7C20A721-0F11-4368-ADA4-11E512C06777@delong.com> References: <495D0934DA46854A9CA758393724D5903B8375@NI-MAIL02.nii.ads> <1390532559.26143.YahooMailNeo@web181703.mail.ne1.yahoo.com> <495D0934DA46854A9CA758393724D5903B9787@NI-MAIL02.nii.ads> <7C20A721-0F11-4368-ADA4-11E512C06777@delong.com> Message-ID: +1 On Jan 24, 2014 12:41 PM, "Owen DeLong" wrote: > Some networks I have worked with took the average latency of each link and > assigned that (with some constant multiple) as the interface cost. > > Of course this all fails miserably if you are using anything like MPLS > underneath your OSPF. > > Owen > > On Jan 24, 2014, at 12:26 PM, Erik Sundberg > wrote: > > > I understand OSPF default calculation for cost doesn't include delay. I > am looking for a formula that I can use to manually set the OSPF costs that > factors in delay. > > > > When using OSPF's default costs, the shortest path is not always the > optimal path. > > > > > > Example > > > > New York to Los Angeles. Assuming all links are the same bandwidth and > have a ospf cost of 1. > > > > Path 1 (75ms) - OSPF Cost 2 - New York > Dallas > Los Angeles > > > > Path 2 (65ms) - OSPF Cost 3 - New York > Chicago > Denver > Los Angeles > > > > If I left the default cost's alone then path 1 would win because it has > a lower ospf cost, however it take traffic 10ms longer to get there. > > > > However I would like traffic to take Path 2 by adjusting the OSPF cost. > > > > > > I am looking for a formula that other people are using .p > > > > Thanks > > > > Erik > > > > > > -----Original Message----- > > From: Randy [mailto:randy_94108 at yahoo.com] > > Sent: Thursday, January 23, 2014 9:03 PM > > To: Erik Sundberg; nanog at nanog.org > > Subject: Re: OSPF Costs Formula that include delay. > > > > > > > > ----- Original Message ----- > >> From: Erik Sundberg > >> To: "nanog at nanog.org" > >> Cc: > >> Sent: Thursday, January 23, 2014 4:47 PM > >> Subject: OSPF Costs Formula that include delay. > >> > >> What is everyone using for an OSPF cost formula that factors in a > >> circuits delay and bandwidth (10M-100G)??? > >> > >> Thanks in advance > > > > > > > > umm..are you sure your question is not about EIGRP? > > OSPF has no concept of interface-delays. > > > > The default reference bandwidth for OSPF is 100M > > > > In your case if you set your reference bandwidth to 100000 your 100G > links would have a link cost of 1, 10G - 10, 1G-100, 100M-1000 and 10M-10000 > > > > A vendor specific list would be a better place to ask. > > > > > > ./Randy > > > > ________________________________ > > > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, > files or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > > > From jeff.tantsura at ericsson.com Sat Jan 25 18:56:14 2014 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Sat, 25 Jan 2014 18:56:14 +0000 Subject: OSPF Costs Formula that include delay. In-Reply-To: <52E3556E.4060705@apolix.co.za> References: <495D0934DA46854A9CA758393724D5903B8375@NI-MAIL02.nii.ads> <1390532559.26143.YahooMailNeo@web181703.mail.ne1.yahoo.com> <495D0934DA46854A9CA758393724D5903B9787@NI-MAIL02.nii.ads>, <52E3556E.4060705@apolix.co.za> Message-ID: <79CC4209-F221-4FE4-83AE-2091C758E15A@ericsson.com> A path to a destination must be loop free, irrespectively. So it is not a combination of multiple but rather a list of loop free paths to a destination where any other metrics are used as tie-breakers. Another story - how do you get all that state distributed, inter-area cases, how do you make it actually useful ( LSDB vs TED ) and not to forget - FEC definition. Regards, Jeff > On Jan 24, 2014, at 10:13 PM, "Graham Beneke" wrote: > > The auto-cost capability in some vendors devices seems to have left many > people ignoring the link metrics within their IGP. From what I recall in > the standards - bandwidth is one possible link metric but certainly not > the only one. Network designers are free (and I would encourage to) pick > whatever metric is relevant to them. > >> On 24/01/2014 22:26, Erik Sundberg wrote: >> I am looking for a formula that other people are using .p > > I've started to use a combination of 3 metrics to determine my costing: > > * The traditional auto-cost calculation based on a 100Gbps reference > which gives far more useful values than the old 100Mbps reference. > > * An average or nominal link latency multiplied by a factor of 200. > Sometimes adjusted if I want two geographically diverse paths between > the same endpoints to have equivalent costs. > > * Path length in km multiplied by 2. This accounts for situations when > the nominal latency is too small to accurately determine and assumes 1 > ms per 100 km. > > I then pick the largest of the above 3 metrics as my OSPF cost. > > -- > Graham Beneke > From jra at baylink.com Sat Jan 25 19:08:00 2014 From: jra at baylink.com (Jay Ashworth) Date: Sat, 25 Jan 2014 14:08:00 -0500 (EST) Subject: BCP38.info Message-ID: <7053728.5481.1390676880367.JavaMail.root@benjamin.baylink.com> Well, coming up with a Mediawiki registration protocol that's hard to spam is apparently more difficult than I'd thought. For the moment, anyone who wants to contribute to the wiki, and to the expanded deployment of BCP38, is invited to toss a note to moderator [at] bcp38.info with a username, and we'll tell it to set you up an account and mail you a password manually. Sorry for the speedbump. I just want to tell you good luck. We're all counting on you. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jakob.heitz at ericsson.com Sat Jan 25 19:26:35 2014 From: jakob.heitz at ericsson.com (Jakob Heitz) Date: Sat, 25 Jan 2014 19:26:35 +0000 Subject: Route Server Filters at IXPs and 4-byte ASNs Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F670C5@eusaamb109.ericsson.se> I would support that. http://tools.ietf.org/search/draft-raszuk-wide-bgp-communities-03 How would you modify it? To me, that draft looks hugely complicated, like everything you could possibly think of was thrown in. I would support a simplified version (and be able to code it without bugs) if it contained just useful stuff. -- Jakob Heitz. ________________________________________ Date: Sat, 25 Jan 2014 18:37:42 +0000 From: Nick Hilliard To: Sebastian Spies , nanog at nanog.org Subject: Re: Route Server Filters at IXPs and 4-byte ASNs Message-ID: <52E40476.20200 at foobar.org> Content-Type: text/plain; charset=ISO-8859-1 On 25/01/2014 15:48, Sebastian Spies wrote: > To make things worse: even if the IXPs ASN is 2-byte, I would assume, > that RS implementors chose to interpret extended community strings as > always being in the format 4-byte:2-byte (see RFC5668). some ixp operators (e.g. me) are rather enthusiastic about the idea of a modified form of draft-raszuk-wide-bgp-communities getting more traction. This would solve this particular problem and many others. Nick From drew.linsalata at gmail.com Sat Jan 25 21:17:17 2014 From: drew.linsalata at gmail.com (Drew Linsalata) Date: Sat, 25 Jan 2014 16:17:17 -0500 Subject: Will a single /27 get fully routed these days? Message-ID: Yeah, its been a while since I had to get involved in this. We have a customer with their own IPv4 allocation that wants us to announce a /27 for them. Back in "the day", it was /24 or larger or all bets were off. Is that still the case now? From sethm at rollernet.us Sat Jan 25 21:19:38 2014 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 25 Jan 2014 13:19:38 -0800 Subject: Will a single /27 get fully routed these days? In-Reply-To: References: Message-ID: <52E42A6A.9050504@rollernet.us> On 1/25/14, 13:17, Drew Linsalata wrote: > Yeah, its been a while since I had to get involved in this. We have a > customer with their own IPv4 allocation that wants us to announce a /27 for > them. Back in "the day", it was /24 or larger or all bets were off. Is > that still the case now? > /24 hasn't changed and is not likely to. ~Seth From laszlo at heliacal.net Sat Jan 25 21:20:59 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Sat, 25 Jan 2014 21:20:59 +0000 Subject: Will a single /27 get fully routed these days? In-Reply-To: References: Message-ID: <23C17E48-C7FD-459A-9B80-5BEBE93B5AF8@heliacal.net> Yes, a /27 is too small. You need at least a /24. On Jan 25, 2014, at 9:17 PM, Drew Linsalata wrote: > Yeah, its been a while since I had to get involved in this. We have a > customer with their own IPv4 allocation that wants us to announce a /27 for > them. Back in "the day", it was /24 or larger or all bets were off. Is > that still the case now? From morrowc.lists at gmail.com Sat Jan 25 21:22:44 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 25 Jan 2014 16:22:44 -0500 Subject: Will a single /27 get fully routed these days? In-Reply-To: References: Message-ID: On Sat, Jan 25, 2014 at 4:17 PM, Drew Linsalata wrote: > Yeah, its been a while since I had to get involved in this. We have a > customer with their own IPv4 allocation that wants us to announce a /27 for > them. Back in "the day", it was /24 or larger or all bets were off. Is > that still the case now? yes. From streiner at cluebyfour.org Sat Jan 25 18:08:09 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 25 Jan 2014 13:08:09 -0500 (EST) Subject: Will a single /27 get fully routed these days? In-Reply-To: References: Message-ID: On Sat, 25 Jan 2014, Drew Linsalata wrote: > Yeah, its been a while since I had to get involved in this. We have a > customer with their own IPv4 allocation that wants us to announce a /27 for > them. Back in "the day", it was /24 or larger or all bets were off. Is > that still the case now? Things haven't changed. /24 is the smallest IPv4 prefix many providers will accept. jms From sander at steffann.nl Sat Jan 25 21:59:40 2014 From: sander at steffann.nl (Sander Steffann) Date: Sat, 25 Jan 2014 22:59:40 +0100 Subject: Will a single /27 get fully routed these days? In-Reply-To: References: Message-ID: <1D452F18-4D66-4B11-B190-B508E7C4DD26@steffann.nl> Hi, > Yeah, its been a while since I had to get involved in this. We have a > customer with their own IPv4 allocation that wants us to announce a /27 for > them. Back in "the day", it was /24 or larger or all bets were off. Is > that still the case now? This is still the case today. I wonder what will change (if anything) when ARIN runs out of IPv4 space. Geoff's current predictions say Feb 2015, but I wouldn't be surprised if it turns out to be sooner than that. But, when that happens ARIN will only have the 'Dedicated IPv4 block to facilitate IPv6 Deployment' [1] left, and it will use 'a minimum size allocation of /28 and a maximum size allocation of /24' for that block. The block is meant for things like dual stacked DNS servers, NAT64 and other IPv6 deployments where a bit of IPv4 is still necessary. I wonder how reachable those systems will be... Will people adjust their filters, or will most usage of this block (and thereby all new entrants in the ISP market in the ARIN region) just be doomed? Cheers, Sander [1] https://www.arin.net/policy/nrpm.html#four10 From jeff-kell at utc.edu Sat Jan 25 22:05:17 2014 From: jeff-kell at utc.edu (Jeff Kell) Date: Sat, 25 Jan 2014 17:05:17 -0500 Subject: Will a single /27 get fully routed these days? In-Reply-To: <1D452F18-4D66-4B11-B190-B508E7C4DD26@steffann.nl> References: <1D452F18-4D66-4B11-B190-B508E7C4DD26@steffann.nl> Message-ID: <52E4351D.7080608@utc.edu> (snip) I doubt that anything > /24 will ever be eligible as a "portable" provider independent block. If within a provider, you can slice and dice as you wish. Jeff From sander at steffann.nl Sat Jan 25 22:15:57 2014 From: sander at steffann.nl (Sander Steffann) Date: Sat, 25 Jan 2014 23:15:57 +0100 Subject: Will a single /27 get fully routed these days? In-Reply-To: <52E4351D.7080608@utc.edu> References: <1D452F18-4D66-4B11-B190-B508E7C4DD26@steffann.nl> <52E4351D.7080608@utc.edu> Message-ID: <84814A48-12F3-49A0-B1C9-2C776A61DD3B@steffann.nl> Hi, Op 25 jan. 2014, om 23:05 heeft Jeff Kell het volgende geschreven: > (snip) > > I doubt that anything > /24 will ever be eligible as a "portable" > provider independent block. If within a provider, you can slice and > dice as you wish. Sure, but the text I quoted is about ARIN allocations, so ARIN -> ISP. So the /28 is not provider-independent. It *is* the provider... And yes: I think this will become a mess in ARIN land :( Cheers, Sander From philfagan at gmail.com Sat Jan 25 22:32:20 2014 From: philfagan at gmail.com (Phil Fagan) Date: Sat, 25 Jan 2014 15:32:20 -0700 Subject: Will a single /27 get fully routed these days? In-Reply-To: References: Message-ID: I would imagine this should be announced with the larger block owner. On Jan 25, 2014 2:19 PM, "Drew Linsalata" wrote: > Yeah, its been a while since I had to get involved in this. We have a > customer with their own IPv4 allocation that wants us to announce a /27 for > them. Back in "the day", it was /24 or larger or all bets were off. Is > that still the case now? > From randy at psg.com Sat Jan 25 22:50:53 2014 From: randy at psg.com (Randy Bush) Date: Sun, 26 Jan 2014 07:50:53 +0900 Subject: Route Server Filters at IXPs and 4-byte ASNs In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F670C5@eusaamb109.ericsson.se> References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F670C5@eusaamb109.ericsson.se> Message-ID: > http://tools.ietf.org/search/draft-raszuk-wide-bgp-communities-03 > To me, that draft looks hugely complicated, like everything you > could possibly think of was thrown in. do we have a chat with robert or push an alternative so that the wg is pushed to compromise? randy From mysidia at gmail.com Sat Jan 25 23:17:49 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 25 Jan 2014 17:17:49 -0600 Subject: Will a single /27 get fully routed these days? In-Reply-To: <84814A48-12F3-49A0-B1C9-2C776A61DD3B@steffann.nl> References: <1D452F18-4D66-4B11-B190-B508E7C4DD26@steffann.nl> <52E4351D.7080608@utc.edu> <84814A48-12F3-49A0-B1C9-2C776A61DD3B@steffann.nl> Message-ID: On Sat, Jan 25, 2014 at 4:15 PM, Sander Steffann wrote: > > Sure, but the text I quoted is about ARIN allocations, so ARIN -> ISP. So > the /28 is not provider-independent. It *is* the provider... And yes: I > think this will become a mess in ARIN land :( > There aren't any /27 or /28 Allocations from ARIN to an ISP.... A /28 is longer than the ARIN Minimum allocation block size of /22, and longer than the minimum transfer size of a /24 block. -- -JH From nick at foobar.org Sat Jan 25 23:26:00 2014 From: nick at foobar.org (Nick Hilliard) Date: Sat, 25 Jan 2014 23:26:00 +0000 Subject: Route Server Filters at IXPs and 4-byte ASNs In-Reply-To: References: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F670C5@eusaamb109.ericsson.se> Message-ID: <52E44808.70101@foobar.org> On 25/01/2014 22:50, Randy Bush wrote: > do we have a chat with robert or push an alternative so that the wg is > pushed to compromise? i get the impression that Robert realises that the current draft is unworkably complicated. Nick From sander at steffann.nl Sat Jan 25 23:46:10 2014 From: sander at steffann.nl (Sander Steffann) Date: Sun, 26 Jan 2014 00:46:10 +0100 Subject: Will a single /27 get fully routed these days? In-Reply-To: References: <1D452F18-4D66-4B11-B190-B508E7C4DD26@steffann.nl> <52E4351D.7080608@utc.edu> <84814A48-12F3-49A0-B1C9-2C776A61DD3B@steffann.nl> Message-ID: Hi Jimmy, > There aren't any /27 or /28 Allocations from ARIN to an ISP.... > A /28 is longer than the ARIN Minimum allocation block size of /22, and longer than the minimum transfer size of a /24 block. Now: yes. Soon: no. Read https://www.arin.net/policy/nrpm.html#four10 Sander From cgrundemann at gmail.com Sun Jan 26 00:57:49 2014 From: cgrundemann at gmail.com (Chris Grundemann) Date: Sun, 26 Jan 2014 09:57:49 +0900 Subject: BCP38.info In-Reply-To: <7053728.5481.1390676880367.JavaMail.root@benjamin.baylink.com> References: <7053728.5481.1390676880367.JavaMail.root@benjamin.baylink.com> Message-ID: Perhaps instead of trying to do this as a new independent activity (with all of the difficulties that entails), the community would be better served by documenting this information as a BCOP or two or three??? >>> http://bcop.nanog.org/ <<< $0.02 ~Chris On Sun, Jan 26, 2014 at 4:08 AM, Jay Ashworth wrote: > Well, coming up with a Mediawiki registration protocol that's hard to > spam is apparently more difficult than I'd thought. > > For the moment, anyone who wants to contribute to the wiki, and to the > expanded deployment of BCP38, is invited to toss a note to moderator [at] > bcp38.info with a username, and we'll tell it to set you up an account and > mail you a password manually. > > Sorry for the speedbump. > > I just want to tell you good luck. We're all counting on you. > > Cheers, > -- jra > > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land > Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 > 1274 > > -- @ChrisGrundemann http://chrisgrundemann.com From ttauber at 1-4-5.net Sun Jan 26 04:11:24 2014 From: ttauber at 1-4-5.net (Tony Tauber) Date: Sat, 25 Jan 2014 23:11:24 -0500 Subject: BCP38.info In-Reply-To: References: <7053728.5481.1390676880367.JavaMail.root@benjamin.baylink.com> Message-ID: Good stuff on this topic assembled by Barry Greene here: http://confluence.senki.org/pages/viewpage.action?pageId=1474569 Tony On Sat, Jan 25, 2014 at 7:57 PM, Chris Grundemann wrote: > Perhaps instead of trying to do this as a new independent activity (with > all of the difficulties that entails), the community would be better served > by documenting this information as a BCOP or two or three??? > > >>> http://bcop.nanog.org/ <<< > > $0.02 > ~Chris > > > > > On Sun, Jan 26, 2014 at 4:08 AM, Jay Ashworth wrote: > > > Well, coming up with a Mediawiki registration protocol that's hard to > > spam is apparently more difficult than I'd thought. > > > > For the moment, anyone who wants to contribute to the wiki, and to the > > expanded deployment of BCP38, is invited to toss a note to moderator [at] > > bcp38.info with a username, and we'll tell it to set you up an account > and > > mail you a password manually. > > > > Sorry for the speedbump. > > > > I just want to tell you good luck. We're all counting on you. > > > > Cheers, > > -- jra > > > > -- > > Jay R. Ashworth Baylink > > jra at baylink.com > > Designer The Things I Think RFC > > 2100 > > Ashworth & Associates http://www.bcp38.info 2000 Land > > Rover DII > > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 > > 1274 > > > > > > > -- > @ChrisGrundemann > http://chrisgrundemann.com > From owen at delong.com Sun Jan 26 04:36:33 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 25 Jan 2014 20:36:33 -0800 Subject: Will a single /27 get fully routed these days? In-Reply-To: <1D452F18-4D66-4B11-B190-B508E7C4DD26@steffann.nl> References: <1D452F18-4D66-4B11-B190-B508E7C4DD26@steffann.nl> Message-ID: <39AD07A9-FED1-4E04-BFCF-9A169CF6E5EB@delong.com> On Jan 25, 2014, at 13:59 , Sander Steffann wrote: > Hi, > >> Yeah, its been a while since I had to get involved in this. We have a >> customer with their own IPv4 allocation that wants us to announce a /27 for >> them. Back in "the day", it was /24 or larger or all bets were off. Is >> that still the case now? > > This is still the case today. > > I wonder what will change (if anything) when ARIN runs out of IPv4 space. Geoff's current predictions say Feb 2015, but I wouldn't be surprised if it turns out to be sooner than that. But, when that happens ARIN will only have the 'Dedicated IPv4 block to facilitate IPv6 Deployment' [1] left, and it will use 'a minimum size allocation of /28 and a maximum size allocation of /24' for that block. The block is meant for things like dual stacked DNS servers, NAT64 and other IPv6 deployments where a bit of IPv4 is still necessary. > > I wonder how reachable those systems will be... Will people adjust their filters, or will most usage of this block (and thereby all new entrants in the ISP market in the ARIN region) just be doomed? > That's actually may not be the best question. That block will come from within a specific prefix and I suspect that ISPs and the like will adjust their filters FOR THAT PREFIX. Consider the possibility of a policy change which allows the transfer of smaller blocks (current ARIN policy limits this to /24 minimum, but ARIN policy is not immutable, we have a policy development process so that anyone who wants to can start the process of changing it.) Owen From sander at steffann.nl Sun Jan 26 07:56:16 2014 From: sander at steffann.nl (Sander Steffann) Date: Sun, 26 Jan 2014 08:56:16 +0100 Subject: Will a single /27 get fully routed these days? In-Reply-To: <39AD07A9-FED1-4E04-BFCF-9A169CF6E5EB@delong.com> References: <1D452F18-4D66-4B11-B190-B508E7C4DD26@steffann.nl> <39AD07A9-FED1-4E04-BFCF-9A169CF6E5EB@delong.com> Message-ID: <25FB4102-C989-4C55-A883-46B5FDE52B4F@steffann.nl> Hi Owen, Op 26 jan. 2014, om 05:36 heeft Owen DeLong het volgende geschreven: > On Jan 25, 2014, at 13:59 , Sander Steffann wrote: > >> Hi, >> >>> [?] But, when that happens ARIN will only have the 'Dedicated IPv4 block to facilitate IPv6 Deployment' [1] left, and it will use 'a minimum size allocation of /28 and a maximum size allocation of /24' for that block. The block is meant for things like dual stacked DNS servers, NAT64 and other IPv6 deployments where a bit of IPv4 is still necessary. >> >> I wonder how reachable those systems will be... Will people adjust their filters, or will most usage of this block (and thereby all new entrants in the ISP market in the ARIN region) just be doomed? > > That's actually may not be the best question. That block will come from within a specific prefix and I suspect that ISPs and the like will adjust their filters FOR THAT PREFIX. Same question? Will people adjust their filters, (even if only for that prefix)? All over the world? I think 'will adjust their filters for XYZ' is highly optimistic, but let's hope it will work, otherwise the ISPs in the ARIN region will have a problem. (Or maybe not: existing ISPs (for who a /2[4-8] is not a significant amount) might not mind if a new competitors only gets a /2[5-8] that they cannot route globally. But I really hope it doesn't come to that.) But more important: which /10 is set aside for this? It is not listed on https://www.arin.net/knowledge/ip_blocks.html > Consider the possibility of a policy change which allows the transfer of smaller blocks (current ARIN policy limits this to /24 minimum, but ARIN policy is not immutable, we have a policy development process so that anyone who wants to can start the process of changing it.) I?m well aware of that, but I?ll stick to RIPE policies for now :-) Cheers, Sander From owen at delong.com Sun Jan 26 08:12:10 2014 From: owen at delong.com (Owen DeLong) Date: Sun, 26 Jan 2014 00:12:10 -0800 Subject: Will a single /27 get fully routed these days? In-Reply-To: <25FB4102-C989-4C55-A883-46B5FDE52B4F@steffann.nl> References: <1D452F18-4D66-4B11-B190-B508E7C4DD26@steffann.nl> <39AD07A9-FED1-4E04-BFCF-9A169CF6E5EB@delong.com> <25FB4102-C989-4C55-A883-46B5FDE52B4F@steffann.nl> Message-ID: <7FAEDEE0-575B-4D9B-A0A9-E77B352AB172@delong.com> On Jan 25, 2014, at 23:56 , Sander Steffann wrote: > Hi Owen, > > Op 26 jan. 2014, om 05:36 heeft Owen DeLong het volgende geschreven: > >> On Jan 25, 2014, at 13:59 , Sander Steffann wrote: >> >>> Hi, >>> >>>> [?] But, when that happens ARIN will only have the 'Dedicated IPv4 block to facilitate IPv6 Deployment' [1] left, and it will use 'a minimum size allocation of /28 and a maximum size allocation of /24' for that block. The block is meant for things like dual stacked DNS servers, NAT64 and other IPv6 deployments where a bit of IPv4 is still necessary. >>> >>> I wonder how reachable those systems will be... Will people adjust their filters, or will most usage of this block (and thereby all new entrants in the ISP market in the ARIN region) just be doomed? >> >> That's actually may not be the best question. That block will come from within a specific prefix and I suspect that ISPs and the like will adjust their filters FOR THAT PREFIX. > > Same question? Will people adjust their filters, (even if only for that prefix)? All over the world? I think 'will adjust their filters for XYZ' is highly optimistic, but let's hope it will work, otherwise the ISPs in the ARIN region will have a problem. (Or maybe not: existing ISPs (for who a /2[4-8] is not a significant amount) might not mind if a new competitors only gets a /2[5-8] that they cannot route globally. But I really hope it doesn't come to that.) > Realistically, anyone depending on IPv4 is going to has a growing problem which will only continue to grow. > But more important: which /10 is set aside for this? It is not listed on https://www.arin.net/knowledge/ip_blocks.html I'm not sure it has been determined yet, let alone announced. > >> Consider the possibility of a policy change which allows the transfer of smaller blocks (current ARIN policy limits this to /24 minimum, but ARIN policy is not immutable, we have a policy development process so that anyone who wants to can start the process of changing it.) > > I?m well aware of that, but I?ll stick to RIPE policies for now :-) I admit I'm not familiar with the details of the RIPE policy in this regard. Do they allow longer prefixes to be transferred and/or acquired? I will point out that the NA in NANOG mostly refers to the ARIN region. Owen From eric at ericheather.com Sun Jan 26 08:29:04 2014 From: eric at ericheather.com (Eric C. Miller) Date: Sun, 26 Jan 2014 08:29:04 +0000 Subject: L2TPv3/MPLS (TP) Pseudowire to preserve In-Reply-To: References: Message-ID: Have you looked at Cisco CEF Load Sharing? Eric Miller, CCNP Network Engineering Consultant (407) 257-5115 -----Original Message----- From: Herro91 [mailto:herro91 at gmail.com] Sent: Wednesday, January 08, 2014 10:19 AM To: Cisco-nsp; nanog at nanog.org; Juniper-Nsp Subject: L2TPv3/MPLS (TP) Pseudowire to preserve Hi, We have a new requirement to load balance across a couple of point to point ethernet links. The previous solution was handled by a few TDM circuits and MLPPP so that traffic was load balanced and any fragmentation/reassembly was handled by ML/PPP. Load balancing per flow is not really an option because we have a single IPSec tunnel (ESP-mode) and there is Layer 4 information to make a better decision to balance the load. I have been considering the use of L2TPv3 or an MPLS Pseudowire as a potential solution as they seem to have mechanisms to ensure packets are not misordered. I would appreciate any feedback/suggestions that the community can offer. Best, -Doug From sander at steffann.nl Sun Jan 26 08:39:12 2014 From: sander at steffann.nl (Sander Steffann) Date: Sun, 26 Jan 2014 09:39:12 +0100 Subject: Will a single /27 get fully routed these days? In-Reply-To: <7FAEDEE0-575B-4D9B-A0A9-E77B352AB172@delong.com> References: <1D452F18-4D66-4B11-B190-B508E7C4DD26@steffann.nl> <39AD07A9-FED1-4E04-BFCF-9A169CF6E5EB@delong.com> <25FB4102-C989-4C55-A883-46B5FDE52B4F@steffann.nl> <7FAEDEE0-575B-4D9B-A0A9-E77B352AB172@delong.com> Message-ID: Hi Owen, >> Same question? Will people adjust their filters, (even if only for that prefix)? All over the world? I think 'will adjust their filters for XYZ' is highly optimistic, but let's hope it will work, otherwise the ISPs in the ARIN region will have a problem. (Or maybe not: existing ISPs (for who a /2[4-8] is not a significant amount) might not mind if a new competitors only gets a /2[5-8] that they cannot route globally. But I really hope it doesn't come to that.) > > Realistically, anyone depending on IPv4 is going to has a growing problem which will only continue to grow. Yes, but those last IPv4 addresses are for ISPs who work with IPv6 and need a little bit of IPv4 to communicate with the legacy world. If they can't even do that it will be extra hard (impossible?) for them to function. >> But more important: which /10 is set aside for this? It is not listed on https://www.arin.net/knowledge/ip_blocks.html > > I'm not sure it has been determined yet, let alone announced. According to https://www.arin.net/resources/request/ipv4_countdown.html phase one it should have been done in September 2012: 'IPv4 address space required for NRPM 4.10, which sets aside a contiguous IPv4 /10 block to facilitate IPv6 deployment, was reserved and removed from the remaining IPv4 address pool.' I can't find anything more specific though... >>> Consider the possibility of a policy change which allows the transfer of smaller blocks (current ARIN policy limits this to /24 minimum, but ARIN policy is not immutable, we have a policy development process so that anyone who wants to can start the process of changing it.) >> >> I?m well aware of that, but I?ll stick to RIPE policies for now :-) > > I admit I'm not familiar with the details of the RIPE policy in this regard. Do they allow longer prefixes to be transferred and/or acquired? Allow: yes. Anybody doing that for globally routable purposes: no. Although it can be used for networks that don't need to be in the global BGP table. > I will point out that the NA in NANOG mostly refers to the ARIN region. ??? No idea what this comment is supposed to mean. You may find this weird, but since the Internet is actually a global network I do care about what happens in NA... Cheers, Sander From me at geordish.org Sun Jan 26 09:35:20 2014 From: me at geordish.org (Dave Bell) Date: Sun, 26 Jan 2014 09:35:20 +0000 Subject: Will a single /27 get fully routed these days? In-Reply-To: <25FB4102-C989-4C55-A883-46B5FDE52B4F@steffann.nl> References: <1D452F18-4D66-4B11-B190-B508E7C4DD26@steffann.nl> <39AD07A9-FED1-4E04-BFCF-9A169CF6E5EB@delong.com> <25FB4102-C989-4C55-A883-46B5FDE52B4F@steffann.nl> Message-ID: > But more important: which /10 is set aside for this? It is not listed on https://www.arin.net/knowledge/ip_blocks.html 100.64/10 http://tools.ietf.org/search/rfc6598 From randy at psg.com Sun Jan 26 09:41:19 2014 From: randy at psg.com (Randy Bush) Date: Sun, 26 Jan 2014 18:41:19 +0900 Subject: Will a single /27 get fully routed these days? In-Reply-To: <25FB4102-C989-4C55-A883-46B5FDE52B4F@steffann.nl> References: <1D452F18-4D66-4B11-B190-B508E7C4DD26@steffann.nl> <39AD07A9-FED1-4E04-BFCF-9A169CF6E5EB@delong.com> <25FB4102-C989-4C55-A883-46B5FDE52B4F@steffann.nl> Message-ID: sander, i suspect that, as multi-homing continues to grow and ipv4 space fragments to be used in core-facing nat[64]-like things, a decade from now we'll see the boundary move to the right. randy From alexander at neilson.net.nz Sun Jan 26 10:16:09 2014 From: alexander at neilson.net.nz (Alexander Neilson) Date: Sun, 26 Jan 2014 23:16:09 +1300 Subject: Will a single /27 get fully routed these days? In-Reply-To: References: <1D452F18-4D66-4B11-B190-B508E7C4DD26@steffann.nl> <39AD07A9-FED1-4E04-BFCF-9A169CF6E5EB@delong.com> <25FB4102-C989-4C55-A883-46B5FDE52B4F@steffann.nl> Message-ID: <27B79152-8CBA-4F59-9E8B-3F2C0A59DEDE@neilson.net.nz> Regards Alexander Alexander Neilson Neilson Productions Limited alexander at neilson.net.nz 021 329 681 022 456 2326 On 26/01/2014, at 10:35 pm, Dave Bell wrote: >> But more important: which /10 is set aside for this? It is not listed on > https://www.arin.net/knowledge/ip_blocks.html > > 100.64/10 > > http://tools.ietf.org/search/rfc6598 Correct me if I am wrong but this is the space reserved for internal use by providers for space for CGN systems that is not 1918 space so it doesn?t conflict with customers internal network IP Space. If I am correct the question is for which block has been reserved by ARIN for ?address space for v6 devices they need to talk to v4 world? which is a globally unique allocation from their final /8 which they reference "Per policy, a /10 was reserved out of the last /8 to facilitate IPv6 deployment and that space is not included in our inventory count.? at https://www.arin.net/resources/request/ipv4_countdown.html which I think nobody has yet answered. Looking at 4.10 it doesn?t require the /10 block to be taken from their ?Final /8? allocation (104/8) so I think it would be nice for someone from ARIN to come on here and confirm for all of us what the /10 is and ARIN?s thinking around the use of this space and their allocations being a max /24. Knowing the space now and whether larger transit providers will be issued it in /24?s for their transit customers which would mean they could announce the entire /24 and not require action from most AS?s or if the allocations will range in size directly to end users as standard issued space and ARIN asks us to accept it in our filters would be useful to know now so I can prepare the filters and it gives most AS?s time to implement this next large edit rather than make it a tweak when it begins to cause issues / issues are reported. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4154 bytes Desc: not available URL: From sander at steffann.nl Sun Jan 26 11:48:13 2014 From: sander at steffann.nl (Sander Steffann) Date: Sun, 26 Jan 2014 12:48:13 +0100 Subject: Will a single /27 get fully routed these days? In-Reply-To: <27B79152-8CBA-4F59-9E8B-3F2C0A59DEDE@neilson.net.nz> References: <1D452F18-4D66-4B11-B190-B508E7C4DD26@steffann.nl> <39AD07A9-FED1-4E04-BFCF-9A169CF6E5EB@delong.com> <25FB4102-C989-4C55-A883-46B5FDE52B4F@steffann.nl> <27B79152-8CBA-4F59-9E8B-3F2C0A59DEDE@neilson.net.nz> Message-ID: <4F26C6F4-D769-400C-9B09-99B919F7C362@steffann.nl> Hi, > On 26/01/2014, at 10:35 pm, Dave Bell wrote: >>> But more important: which /10 is set aside for this? It is not listed on >> https://www.arin.net/knowledge/ip_blocks.html >> >> 100.64/10 >> >> http://tools.ietf.org/search/rfc6598 > > Correct me if I am wrong but this is the space reserved for internal use by providers for space for CGN systems that is not 1918 space so it doesn?t conflict with customers internal network IP Space. You're correct. I actually assumed the 100.64/10 answer was meant as a joke :-) Cheers, Sander From sander at steffann.nl Sun Jan 26 11:59:46 2014 From: sander at steffann.nl (Sander Steffann) Date: Sun, 26 Jan 2014 12:59:46 +0100 Subject: Will a single /27 get fully routed these days? In-Reply-To: References: <1D452F18-4D66-4B11-B190-B508E7C4DD26@steffann.nl> <39AD07A9-FED1-4E04-BFCF-9A169CF6E5EB@delong.com> <25FB4102-C989-4C55-A883-46B5FDE52B4F@steffann.nl> Message-ID: Hi Randy, > i suspect that, as multi-homing continues to grow and ipv4 space > fragments to be used in core-facing nat[64]-like things, a decade from > now we'll see the boundary move to the right. Maybe, if the equipment can handle the number of routes. I actually see two opposing things: the scarcity will require more fragmentation with smaller fragments, which requires less strict filtering. On the other hand the fragmentation will already start with e.g. /20s being fragmented into /24s. That might already cause problems for current hardware, which might cause people to filter more strictly. Unfortunately my crystal ball is broken at the moment. When ARIN starts allocating /28s from the reserved /10 in ?12 months I wonder which direction it will go... I hope for the ARIN region that the majority of operators globally will loosen up their filters for at least that /10 within those 12 months so the allocations will actually be usable. For that to happen it would be very useful to know *which* /10 has been reserved in 2012 though... 12 months is not much for global communication, education and filter adjustments. And anyway, who needs IPv4 a decade from now? ;) Cheers, Sander From bross at pobox.com Sun Jan 26 17:22:42 2014 From: bross at pobox.com (Brandon Ross) Date: Sun, 26 Jan 2014 12:22:42 -0500 (EST) Subject: opensource tools for IP & DNS management [was: Opensource tools for inventory and troubleticketing] In-Reply-To: <52E3F351.8090608@meetinghouse.net> References: <1393125223.37939.1390555230304.open-xchange@ox-webdesk.1and1.es> <1619681351.38746.1390556234448.open-xchange@ox-webdesk.1and1.es> <77426B543150464AA3F30DF1A91365DE6AFF9606@ESV4-MBX01.linkedin.biz> <52E3F351.8090608@meetinghouse.net> Message-ID: On Sat, 25 Jan 2014, Miles Fidelman wrote: > Anybody have any suggestions for good opensource tools for managing blocks of > IP addresses, and domain name assignments - ideally with hooks for updating > nameservers and registry databases? Last time I looked everyone was still > using either spreadsheets or high-priced proprietary tools - figure it's time > to ask again. I guess it depends on how you define high-priced, but we find the 6connect stuff to be very reasonably priced for a commercial tool with support. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross From jra at baylink.com Sun Jan 26 17:47:29 2014 From: jra at baylink.com (Jay Ashworth) Date: Sun, 26 Jan 2014 12:47:29 -0500 (EST) Subject: BCP38.info In-Reply-To: Message-ID: <5569484.5623.1390758449655.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Chris Grundemann" > Perhaps instead of trying to do this as a new independent activity > (with > all of the difficulties that entails), the community would be better > served > by documenting this information as a BCOP or two or three??? > > >>> http://bcop.nanog.org/ <<< Answering this on my phone last night, I didn't see Chris had carboned the group, so I will repeat on-list my observation that I stood up http://bestpractices.wikia.com something like 6 years ago, and couldn't get any traction on it then; I'm not sure I think much has changed -- apparently, extracting your BP thoughts from mailing list postings and putting them into a wiki is more effort than most NANOGers are up to. So no, perhaps attempting to load a rifle will be easier than a shotgun[1]. Cheers, -- jra [1] Firearms analogy not intended to encourage gun violence[2]. [2] Duh. -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From johnl at iecc.com Sun Jan 26 19:45:26 2014 From: johnl at iecc.com (John Levine) Date: 26 Jan 2014 19:45:26 -0000 Subject: Will a single /27 get fully routed these days? In-Reply-To: <1D452F18-4D66-4B11-B190-B508E7C4DD26@steffann.nl> Message-ID: <20140126194526.2444.qmail@joyce.lan> >I wonder what will change (if anything) when ARIN runs out of IPv4 space. In routing, probably not much. The market in used IPv4 space will come out from the shadows, and we'll see endless arguments between buyers of IPv4 space and ARIN, when ARIN refuses the updates to the address registry. I don't see any reason for the people who run defaultless routers all over the world to change the /24 rule. If they accept longer prefixes it'll cost them real money as their route tables bloat, and all they get is some marginal connectivity to people too dumb or too cheap to find a /24 of their own. Anyone who buys a /27 without an arrangement for backup routing from whoever routes the surrounding /24 is a fool. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly PS: Yes, I know you don't "buy" space from ARIN. From jra at baylink.com Sun Jan 26 21:04:17 2014 From: jra at baylink.com (Jay Ashworth) Date: Sun, 26 Jan 2014 16:04:17 -0500 Subject: Neighborhood mesh statistical multiplexing Message-ID: I wonder if they'll break BCP 38... or vice-versa... http://arstechnica.com/business/2014/01/bewifi-lets-you-steal-your-neighbors-bandwidth-when-theyre-not-using-it/ -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From pvanstaveren at mintel.com Sun Jan 26 06:00:29 2014 From: pvanstaveren at mintel.com (Patrick van Staveren) Date: Sun, 26 Jan 2014 14:00:29 +0800 Subject: China ISPs DNS problems on Jan 22nd - any idea what happened? Message-ID: This past Tuesday the 22nd I was witness to a widespread DNS poisoning problem in China, whereby a lot of DNS queries were all returning the same IP address, 65.49.2.178. Our websites became unavailable for most of our customers in China, as with many other websites. The major difficulty that we had with one of our websites is that we use Akamai's CDN, and Akamai's servers within China were unable to reach our origin server in London - so it originally appeared as if Akamai was having an issue before unofficial news surfaced that there was a larger problem going on. I have two questions for anyone: 1) I've found quite a bit of unofficial news [1] [2] on what happened, but does anyone know what *actually* happened? The only official news from the government that I can find says, "It was probably a cyberattack, but really, we don't know." [3] 2) As a website & network operator who strives to keep their product always available, is there anything I can actually do to prevent from this in the future? The most fun question I think everyone would love to know is - does anyone from Hurricane Electric have a throughput graph showing the traffic surge caused by this? It must be epic. Cheers, Patrick 1: http://gizmodo.com/most-of-chinas-web-traffic-wound-up-at-a-tiny-wyoming-1506486072 2: http://chinadigitaltimes.net/2014/01/massive-internet-failure-caused-great-firewall/ 3: http://news.xinhuanet.com/english/china/2014-01/23/c_133067744.htm -- Patrick van Staveren Head of IT, APAC & Global Head of IT Infrastructure Mintel Group Ltd. PNVS-ARIN


Mintel Group Limited | 25th Floor Broad Silver International Building 398 Huaihai Zhong Road | Shanghai, P.R. China 200020

Contact details for our offices can be found at http://www.mintel.com/office-locations.

This email and any attachments may include content that is confidential, privileged, or otherwise protected
under applicable law. Unauthorised disclosure, copying, distribution, or use of the contents is prohibited 
and may be unlawful. If you have received this email in error, including without appropriate authorisation, 
then please reply to the sender about the error and delete this email and any attachments.

From Valdis.Kletnieks at vt.edu  Mon Jan 27 00:45:09 2014
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 26 Jan 2014 19:45:09 -0500
Subject: Route Server Filters at IXPs and 4-byte ASNs
In-Reply-To: Your message of "Sat, 25 Jan 2014 14:56:16 +0100."
 <52E3C280.2060100@sloc.de>
References: <52E3C280.2060100@sloc.de>
Message-ID: <156866.1390783509@turing-police.cc.vt.edu>

On Sat, 25 Jan 2014 14:56:16 +0100, Sebastian Spies said:

> ASNs. First of all, we have no data or experience about 4-byte ASN
> adoption and are therefore unable to evaluate, if we should rush for the
> last available numbers.

2-byte ASN depletion - the other white meat....

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: 

From drc at virtualized.org  Mon Jan 27 01:26:18 2014
From: drc at virtualized.org (David Conrad)
Date: Sun, 26 Jan 2014 17:26:18 -0800
Subject: Will a single /27 get fully routed these days?
In-Reply-To: <20140126194526.2444.qmail@joyce.lan>
References: <20140126194526.2444.qmail@joyce.lan>
Message-ID: <06DCB8F8-A41F-4860-B638-66A8646EB9FF@virtualized.org>

On Jan 26, 2014, at 11:45 AM, John Levine  wrote:
>> I wonder what will change (if anything) when ARIN runs out of IPv4 space.
> The market in used IPv4 space will come out from the shadows,

It mostly has already done so in the APNIC and RIPE regions out of necessity.

> and we'll see endless arguments between
> buyers of IPv4 space and ARIN, when ARIN refuses the updates to the
> address registry.

This would be "bad". I can think of few more effective ways of destroying the RIR system than by refusing to update the address registry. IMHO, the primary function of the Registries is to, you know, register. Not act as policy police, particularly of policies defined by a handful of folks who bother to participate in the ARIN public policy processes.

> I don't see any reason for the people who run defaultless routers all over the world to change the /24 rule.  

So IIUC, the theory goes that ISPs will be encouraged by their customers (upon pain of those customers becoming former customers) to announce their long prefixes, even though the ISPs will say "but nobody will listen".  However, some ISPs _do_ listen (or rather, _don't_ filter) so the long prefix customers will get partial (i.e., worse than normal) reachability. Said customers will then whine at their ISPs saying "fix it!" and said ISPs will go to their peers and grovel, perhaps offering the Faustian bargain of "I'll accept yours if you accept mine and our respective customers will stop whining at us about each other". And then the apocalypse occurs. Or something like that.

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: 

From johnl at iecc.com  Mon Jan 27 02:02:28 2014
From: johnl at iecc.com (John R. Levine)
Date: 26 Jan 2014 21:02:28 -0500
Subject: Will a single /27 get fully routed these days?
In-Reply-To: <06DCB8F8-A41F-4860-B638-66A8646EB9FF@virtualized.org>
References: <20140126194526.2444.qmail@joyce.lan>
 <06DCB8F8-A41F-4860-B638-66A8646EB9FF@virtualized.org>
Message-ID: 

>> and we'll see endless arguments between buyers of IPv4 space and ARIN, 
>> when ARIN refuses the updates to the address registry.

> This would be "bad". I can think of few more effective ways of 
> destroying the RIR system than by refusing to update the address 
> registry.

I completely agree, but there are other places to argue about that 
particular question.

>> I don't see any reason for the people who run defaultless routers all 
>> over the world to change the /24 rule.
>
> So IIUC, the theory goes that ISPs will be encouraged by their customers 
> (upon pain of those customers becoming former customers) to announce 
> their long prefixes, even though the ISPs will say "but nobody will 
> listen".  ...

Well, maybe.  My vision is that the ISP calls up their upstreams and/or 
peers, some say OK, many say, sorry, unless you're offering to fund some 
very expen$ive router upgrade$, we can't do it.  Even the ones who say OK 
will have little incentive to push their peers, so there will be flaky 
islands of routing.

The customer will continue to whine, of course, at which point the ISP has 
the bright idea to do some traceroutes and figure out which ISP announces 
the enclosing block.  They call up that ISP and ask, what would you charge 
to tunnel that traffic back to us?  The other ISP, who's been throwing 
away the /27's traffic anyway, quotes a reasonable price, and now we have 
universal reachability, accompanied by endless route flaps and very 
inconsistent performance.

The customer continues to whine about performance.  Our ISP says, ah, you 
need our Preferred Thoughput Upgrade Innovation (PTUI), available at 
modest extra cost.  The extra cost, of course, it what it costs to buy a 
/24 and get the customer into the real routing table.

Regards,
John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

PS: In the sequel, some ill-advised LIR starts handing out /27s with no 
enclosing block, so a bunch of little ISPs get into a flapping contest to 
see who's going to announce the /24 and get everyone else to pay them to 
tunnel the traffic back.


From mysidia at gmail.com  Mon Jan 27 02:50:43 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 26 Jan 2014 20:50:43 -0600
Subject: Will a single /27 get fully routed these days?
In-Reply-To: 
References: <20140126194526.2444.qmail@joyce.lan>
 <06DCB8F8-A41F-4860-B638-66A8646EB9FF@virtualized.org>
 
Message-ID: 

On Sun, Jan 26, 2014 at 8:02 PM, John R. Levine  wrote:

I don't see ARIN recognizing bogus transfers in the registry -- if the
transfer policy wasn't followed, then no transfer occurred.


>  Well, maybe.  My vision is that the ISP calls up their upstreams and/or
> peers, some say OK, many say, sorry, unless you're offering to fund some
> very expen$ive router upgrade$, we can't do it.  Even the ones who say OK
> will have little incentive to push their peers, so there will be flaky
> islands of routing.
>
> The customer will continue to whine, of course, at which point the ISP has
> the bright idea to do some traceroutes and figure out which ISP announces
> the enclosing block.  They call up that ISP and ask, what would you charge
> to tunnel that traffic back to us?

[snip]
>

If it's a /28 allocation under ARIN NRPM 4.10;  there is no  assignee that
gets to announce the enclosing /24.

I do not see in the cards, a lot of /28 allocations occuring.

Since 4.10 addresses are exclusively for IPv6 transition,  immediate need
criteria must be met, and "the applicant must demonstrate that no other
allocations or assignments will meet this need";  I doubt there will be a
significant number of /28s that will fit the need.

More likely, those that would utilize 4.10 will be asking for a /24
 allocation, if addresses need to be routed.

Or a /28;  if the transition function where the addresses are required are
small,  and they do not require global reachability.

Another answer for end users may well be.... instead of accepting /28s into
your table:  implement IPv6 instead,  so you are not needing IPv4  to
connect to these networks that have deployed IPv6 and are requiring the /28
for a special IPv4 to IPv6 transition purpose.

-- 
-JH

From johnl at iecc.com  Mon Jan 27 03:15:55 2014
From: johnl at iecc.com (John R. Levine)
Date: 26 Jan 2014 22:15:55 -0500
Subject: Will a single /27 get fully routed these days?
In-Reply-To: 
References: <20140126194526.2444.qmail@joyce.lan>
 <06DCB8F8-A41F-4860-B638-66A8646EB9FF@virtualized.org>
 
 
Message-ID: 

> I don't see ARIN recognizing bogus transfers in the registry -- if the
> transfer policy wasn't followed, then no transfer occurred.

I expect the party that paid good money for the address space, and the 
party who they paid, and their respective attorneys, will strenously 
disagree with you, but as I noted, there's other places to discuss this.

> Another answer for end users may well be.... instead of accepting /28s into
> your table:  implement IPv6 instead,  so you are not needing IPv4  to
> connect to these networks that have deployed IPv6 and are requiring the /28
> for a special IPv4 to IPv6 transition purpose.

Yeah, yeah, we did that, we have buttloads of V6 space, but we need this 
stuff to work now, not in 2025.

I'm fully dual stack both at home (T-W native) and on my servers (HE 
tunnel to my LAN), and v6 is still painfully flaky.  Just this afternoon, 
my home network started acting like someone had poured glue into it, 
because of an internal T-W routing screwup so that my router was reachable 
over v6, but the /64 they assign to my home network wasn't.  When I turned 
off v6, everything worked just dandy again.  Now the v6 routing seems to 
be OK, until the next time it happens.

Re the /28 with no enclosing space, see the PS to my previous note you 
seem to have missed.

Regards,
John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly


From geoffk at geoffk.org  Mon Jan 27 03:50:34 2014
From: geoffk at geoffk.org (Geoffrey Keating)
Date: 26 Jan 2014 19:50:34 -0800
Subject: China ISPs DNS problems on Jan 22nd - any idea what happened?
In-Reply-To: 
References: 
Message-ID: 

Patrick van Staveren  writes:

> This past Tuesday the 22nd I was witness to a widespread DNS poisoning
> problem in China, whereby a lot of DNS queries were all returning the same
> IP address, 65.49.2.178.  Our websites became unavailable for most of our
> customers in China, as with many other websites.
...
> I have two questions for anyone:
> 1) I've found quite a bit of unofficial news [1] [2] on what happened, but
> does anyone know what *actually* happened?  The only official news from the
> government that I can find says, "It was probably a cyberattack, but
> really, we don't know." [3]
> 2) As a website & network operator who strives to keep their product always
> available, is there anything I can actually do to prevent from this in the
> future?

I believe the protocol feature specifically designed to prevent this
kind of thing is DNSSEC.

However, it seems like the common explanation now is an operator error
while administrating the Great Firewall.  I don't think there's
anything technical you can do about that.


From patrick at ianai.net  Mon Jan 27 04:09:49 2014
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Sun, 26 Jan 2014 23:09:49 -0500
Subject: China ISPs DNS problems on Jan 22nd - any idea what happened?
In-Reply-To: 
References: 
 
Message-ID: <62D21CE0-2CA6-44BC-A739-F67F444D2674@ianai.net>

On Jan 26, 2014, at 22:50 , Geoffrey Keating  wrote:
> Patrick van Staveren  writes:

>> This past Tuesday the 22nd I was witness to a widespread DNS poisoning
>> problem in China, whereby a lot of DNS queries were all returning the same
>> IP address, 65.49.2.178.  Our websites became unavailable for most of our
>> customers in China, as with many other websites.
> ...
>> I have two questions for anyone:
>> 1) I've found quite a bit of unofficial news [1] [2] on what happened, but
>> does anyone know what *actually* happened?  The only official news from the
>> government that I can find says, "It was probably a cyberattack, but
>> really, we don't know." [3]
>> 2) As a website & network operator who strives to keep their product always
>> available, is there anything I can actually do to prevent from this in the
>> future?
> 
> I believe the protocol feature specifically designed to prevent this
> kind of thing is DNSSEC.

DNSSEC would not have helped.

Without DNSSEC: The cache asked for the IP address of the origin based on the hostname. It was given the incorrect IP address, did an HTTP GET to that address, got an error. The cache does not serve the content to the user.

With DNSSEC: The cache asks for the IP address of the origin based on the hostname. It was given the incorrect IP address and the cache knows it is incorrect, the cache knows it is incorrect and never tries to get the origin content. The cache does not serve the content to the user.

Not sure how DNSSEC solves the problem.

Now, if someone were intentionally trying to impersonate the origin to, for instance, inject malicious content, then DNSSEC will help. But in this case, DNSSEC is not useful other than keeping some poor soul from being DDOS'ed.


> However, it seems like the common explanation now is an operator error
> while administrating the Great Firewall.  I don't think there's
> anything technical you can do about that.

Not serve traffic from behind the GFW?

Performance will be worse, but that has to be balanced against a sovereign nation unintentionally (or sometimes intentionally) modifying your traffic.

-- 
TTFN,
patrick



From mohta at necom830.hpcl.titech.ac.jp  Mon Jan 27 05:14:59 2014
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Mon, 27 Jan 2014 14:14:59 +0900
Subject: Will a single /27 get fully routed these days?
In-Reply-To: 
References: 
 <1D452F18-4D66-4B11-B190-B508E7C4DD26@steffann.nl>
 <39AD07A9-FED1-4E04-BFCF-9A169CF6E5EB@delong.com>
 <25FB4102-C989-4C55-A883-46B5FDE52B4F@steffann.nl>
 
 
Message-ID: <52E5EB53.6030701@necom830.hpcl.titech.ac.jp>

Sander Steffann wrote:

>> i suspect that, as multi-homing continues to grow and ipv4 space
>> fragments to be used in core-facing nat[64]-like things, a decade
>> from now we'll see the boundary move to the right.
>
> Maybe, if the equipment can handle the number of routes. I actually
> see two opposing things: the scarcity will require more fragmentation
> with smaller fragments, which requires less strict filtering.

The problem is not prefix length (it is a problem if >32, which is
the case with IPv6) but the number of routes, which grows because
of not fragmentation but poor way of multihoming through routing.

Note that if IPv6 will be as popular as IPv4, it has almost equal
number of routes for multihoming.

> On the
> other hand the fragmentation will already start with e.g. /20s being
> fragmented into /24s. That might already cause problems for current
> hardware, which might cause people to filter more strictly.
> Unfortunately my crystal ball is broken at the moment.

Considering that a fast cheap 18bit 16M entry 1 chip SRAM has been
available for many years, route vendors do not have to deploy
slow and complicated logic for route look up, unless they want
to make IPv4 route look up as slow as that of IPv6.

Even 4G entry will not be a problem, except that it may cause BGP
update computation slower.

						Masataka Ohta



From randy at psg.com  Mon Jan 27 06:47:31 2014
From: randy at psg.com (Randy Bush)
Date: Mon, 27 Jan 2014 15:47:31 +0900
Subject: Will a single /27 get fully routed these days?
In-Reply-To: 
References: <20140126194526.2444.qmail@joyce.lan>
 <06DCB8F8-A41F-4860-B638-66A8646EB9FF@virtualized.org>
 
 
Message-ID: 

> I don't see ARIN recognizing bogus transfers in the registry -- if the
> transfer policy wasn't followed, then no transfer occurred.

do you share what you are smoking?


From owen at delong.com  Mon Jan 27 08:07:41 2014
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Jan 2014 00:07:41 -0800
Subject: Will a single /27 get fully routed these days?
In-Reply-To: 
References: 
 <1D452F18-4D66-4B11-B190-B508E7C4DD26@steffann.nl>
 <39AD07A9-FED1-4E04-BFCF-9A169CF6E5EB@delong.com>
 <25FB4102-C989-4C55-A883-46B5FDE52B4F@steffann.nl>
 <7FAEDEE0-575B-4D9B-A0A9-E77B352AB172@delong.com>
 
Message-ID: <7D4E381D-CEC8-40A1-A28E-9EB41F88AB8B@delong.com>


On Jan 26, 2014, at 00:39 , Sander Steffann  wrote:

> Hi Owen,
> 
>>> Same question? Will people adjust their filters, (even if only for that prefix)? All over the world? I think 'will adjust their filters for XYZ' is highly optimistic, but let's hope it will work, otherwise the ISPs in the ARIN region will have a problem. (Or maybe not: existing ISPs (for who a /2[4-8] is not a significant amount) might not mind if a new competitors only gets a /2[5-8] that they cannot route globally. But I really hope it doesn't come to that.)
>> 
>> Realistically, anyone depending on IPv4 is going to has a growing problem which will only continue to grow.
> 
> Yes, but those last IPv4 addresses are for ISPs who work with IPv6 and need a little bit of IPv4 to communicate with the legacy world. If they can't even do that it will be extra hard (impossible?) for them to function.

Which is precisely why I authored that particular policy at the time.

>>> But more important: which /10 is set aside for this? It is not listed on https://www.arin.net/knowledge/ip_blocks.html
>> 
>> I'm not sure it has been determined yet, let alone announced.
> 
> According to https://www.arin.net/resources/request/ipv4_countdown.html phase one it should have been done in September 2012: 'IPv4 address space required for NRPM 4.10, which sets aside a contiguous IPv4 /10 block to facilitate IPv6 deployment, was reserved and removed from the remaining IPv4 address pool.'  I can't find anything more specific though...

OK, then I'm sure it's been determined, but I can't really fault them for not announcing it yet.

>>>> Consider the possibility of a policy change which allows the transfer of smaller blocks (current ARIN policy limits this to /24 minimum, but ARIN policy is not immutable, we have a policy development process so that anyone who wants to can start the process of changing it.)
>>> 
>>> I?m well aware of that, but I?ll stick to RIPE policies for now :-)
>> 
>> I admit I'm not familiar with the details of the RIPE policy in this regard. Do they allow longer prefixes to be transferred and/or acquired?
> 
> Allow: yes. Anybody doing that for globally routable purposes: no. Although it can be used for networks that don't need to be in the global BGP table.
> 
>> I will point out that the NA in NANOG mostly refers to the ARIN region.
> 
> ??? No idea what this comment is supposed to mean. You may find this weird, but since the Internet is actually a global network I do care about what happens in NA...

You made the comment that you would "...stick to RIPE...". I pointed out that ARIN was the RIR of record for most of the territory for which this list is focused.

Owen



From sander at steffann.nl  Mon Jan 27 09:09:32 2014
From: sander at steffann.nl (Sander Steffann)
Date: Mon, 27 Jan 2014 10:09:32 +0100
Subject: Will a single /27 get fully routed these days?
In-Reply-To: <7D4E381D-CEC8-40A1-A28E-9EB41F88AB8B@delong.com>
References: 
 <1D452F18-4D66-4B11-B190-B508E7C4DD26@steffann.nl>
 <39AD07A9-FED1-4E04-BFCF-9A169CF6E5EB@delong.com>
 <25FB4102-C989-4C55-A883-46B5FDE52B4F@steffann.nl>
 <7FAEDEE0-575B-4D9B-A0A9-E77B352AB172@delong.com>
 
 <7D4E381D-CEC8-40A1-A28E-9EB41F88AB8B@delong.com>
Message-ID: <71BA4C50-7B3B-436B-9B43-9F3E3EC14FD3@steffann.nl>

> 
>>>> But more important: which /10 is set aside for this? It is not listed on https://www.arin.net/knowledge/ip_blocks.html
>>> 
>>> I'm not sure it has been determined yet, let alone announced.
>> 
>> According to https://www.arin.net/resources/request/ipv4_countdown.html phase one it should have been done in September 2012: 'IPv4 address space required for NRPM 4.10, which sets aside a contiguous IPv4 /10 block to facilitate IPv6 deployment, was reserved and removed from the remaining IPv4 address pool.'  I can't find anything more specific though...
> 
> OK, then I'm sure it's been determined, but I can't really fault them for not announcing it yet.

?!?!?  How are people supposed to prepare their filters for those tiny allocations if the corresponding prefix is not published?

This is not making any sense...
Sander



From tore at fud.no  Mon Jan 27 09:49:12 2014
From: tore at fud.no (Tore Anderson)
Date: Mon, 27 Jan 2014 10:49:12 +0100
Subject: Will a single /27 get fully routed these days?
In-Reply-To: <25FB4102-C989-4C55-A883-46B5FDE52B4F@steffann.nl>
References: 
 <1D452F18-4D66-4B11-B190-B508E7C4DD26@steffann.nl>
 <39AD07A9-FED1-4E04-BFCF-9A169CF6E5EB@delong.com>
 <25FB4102-C989-4C55-A883-46B5FDE52B4F@steffann.nl>
Message-ID: <52E62B98.2090500@fud.no>

* Sander Steffann

> But more important: which /10 is set aside for this? It is not listed
> on https://www.arin.net/knowledge/ip_blocks.html

Probably 23.128/10:

arin||ipv4|23.128.0.0|4194304||reserved|

Tore


From sander at steffann.nl  Mon Jan 27 10:05:05 2014
From: sander at steffann.nl (Sander Steffann)
Date: Mon, 27 Jan 2014 11:05:05 +0100
Subject: Will a single /27 get fully routed these days?
In-Reply-To: <52E62B98.2090500@fud.no>
References: 
 <1D452F18-4D66-4B11-B190-B508E7C4DD26@steffann.nl>
 <39AD07A9-FED1-4E04-BFCF-9A169CF6E5EB@delong.com>
 <25FB4102-C989-4C55-A883-46B5FDE52B4F@steffann.nl> <52E62B98.2090500@fud.no>
Message-ID: <46EF5901-E93E-4C52-95A9-06A0A291AA72@steffann.nl>

Hi,

> Op 27 jan. 2014 om 10:49 heeft Tore Anderson  het volgende geschreven:
> 
> * Sander Steffann
> 
>> But more important: which /10 is set aside for this? It is not listed
>> on https://www.arin.net/knowledge/ip_blocks.html
> 
> Probably 23.128/10:
> 
> arin||ipv4|23.128.0.0|4194304||reserved|

Now that is useful information! Can someone from ARIN confirm this?

Cheers,
Sander

From jason at jasonantman.com  Mon Jan 27 12:38:31 2014
From: jason at jasonantman.com (Jason Antman)
Date: Mon, 27 Jan 2014 07:38:31 -0500
Subject: Opensource tools for inventory and troubleticketing
In-Reply-To: 
References: <1393125223.37939.1390555230304.open-xchange@ox-webdesk.1and1.es>
 <1619681351.38746.1390556234448.open-xchange@ox-webdesk.1and1.es>
 <77426B543150464AA3F30DF1A91365DE6AFF9606@ESV4-MBX01.linkedin.biz>
 
Message-ID: <52E65347.4070106@jasonantman.com>

+1 for Redmine. I've used most of the open source ticketing systems out 
there at one time or another, and greatly prefer Redmine over all of 
them. I've always been a big proponent of open source and only using 
proprietary software if you absolutely have to (to the point of 
deploying Linux for internal small-scale firewalling and routing (i.e. 
VM clusters, test environments) before I'll concede that hardware is 
required), but I'll admit that Atlassian Jira is probably the best 
ticketing product out there right now. But it's proprietary and costs 
money. Other than that, Redmine is the way to go.

-Jason

On 01/25/2014 09:41 AM, Vireak Ouk wrote:
> We decided against RT and use Redmine for tickets instead. We find Redmine
> to be much more user-friendly.
>   On Jan 25, 2014 8:14 AM, "Franck Martin"  wrote:
>
>> On Jan 24, 2014, at 1:37 AM, Octavio Alfageme 
>> wrote:
>>
>>> Hello everyone,
>>>
>>> I work for a small service provider starting to offer MPLS services
>> between
>>> Europe and several african countries. At present time we own a small
>> Cisco
>>> network, but we are starting to need a better inventory of services and
>> network
>>> resources and better troubleticketing procedures. We can not afford
>> acquiring
>>> complicated and expensive tools at present time.I would be grateful if
>> you could
>>> recommend me opensource tools to cover these needs.
>>>
>> try https://abusehq.abusix.com/ or
>> http://wordtothewise.com/products/abacus.html
>>
>>

-- 

Jason Antman | Systems Engineer | CMGdigital
jason.antman at coxinc.com | p: 678-645-4155



From patrick at ianai.net  Mon Jan 27 16:44:46 2014
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Mon, 27 Jan 2014 11:44:46 -0500
Subject: Will a single /27 get fully routed these days?
In-Reply-To: <06DCB8F8-A41F-4860-B638-66A8646EB9FF@virtualized.org>
References: <20140126194526.2444.qmail@joyce.lan>
 <06DCB8F8-A41F-4860-B638-66A8646EB9FF@virtualized.org>
Message-ID: <7AF75A16-7F93-45CB-A14C-863E01154EA4@ianai.net>

> [...] particularly of policies defined by a handful of folks who bother to participate in the ARIN public policy processes

I love this part.

"I was told a billion times where and how to participate in the policy debate - to the point where many people complain they are being told too many times - yet still did not 'bother' to participate. And now I am going to bitch and moan about the policy because, well, OTHER PEOPLE WROTE IT WITHOUT MY INPUT."

Whot-EVA.

ARIN is community owned & operated. You don't like it, fine, but don't complain when policies are turned out that you don't like if you don't even 'bother' to participate.

-- 
TTFN,
patrick



On Jan 26, 2014, at 20:26 , David Conrad  wrote:

> On Jan 26, 2014, at 11:45 AM, John Levine  wrote:
>>> I wonder what will change (if anything) when ARIN runs out of IPv4 space.
>> The market in used IPv4 space will come out from the shadows,
> 
> It mostly has already done so in the APNIC and RIPE regions out of necessity.
> 
>> and we'll see endless arguments between
>> buyers of IPv4 space and ARIN, when ARIN refuses the updates to the
>> address registry.
> 
> This would be "bad". I can think of few more effective ways of destroying the RIR system than by refusing to update the address registry. IMHO, the primary function of the Registries is to, you know, register. Not act as policy police, particularly of policies defined by a handful of folks who bother to participate in the ARIN public policy processes.
> 
>> I don't see any reason for the people who run defaultless routers all over the world to change the /24 rule.  
> 
> So IIUC, the theory goes that ISPs will be encouraged by their customers (upon pain of those customers becoming former customers) to announce their long prefixes, even though the ISPs will say "but nobody will listen".  However, some ISPs _do_ listen (or rather, _don't_ filter) so the long prefix customers will get partial (i.e., worse than normal) reachability. Said customers will then whine at their ISPs saying "fix it!" and said ISPs will go to their peers and grovel, perhaps offering the Faustian bargain of "I'll accept yours if you accept mine and our respective customers will stop whining at us about each other". And then the apocalypse occurs. Or something like that.
> 
> Regards,
> -drc
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 535 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: 

From patrick at ianai.net  Mon Jan 27 16:49:27 2014
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Mon, 27 Jan 2014 11:49:27 -0500
Subject: Neighborhood mesh statistical multiplexing
In-Reply-To: 
References: 
Message-ID: <0196330E-FBDF-4FF9-A4BB-E4D0E73D7E07@ianai.net>

On Jan 26, 2014, at 16:04 , Jay Ashworth  wrote:

> I wonder if they'll break BCP 38... or vice-versa...
> 
> http://arstechnica.com/business/2014/01/bewifi-lets-you-steal-your-neighbors-bandwidth-when-theyre-not-using-it/

As long as Telefonica customers only use other Telefonica links within WiFi range, Telefonica can ensure it will have no effect on BCP38. Worst case, I can "ddos" the guy in the next apartment by spoofing his address. Best case, they ensure the BeWifi software disallows such things.

And I don't see other broadband networks allowing Telefonica customers to ride their links.

I also wonder why Telefonica would do this as opposed to telling people to upgrade their DSL?

-- 
TTFN,
patrick




From jra at baylink.com  Mon Jan 27 16:58:22 2014
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 27 Jan 2014 11:58:22 -0500 (EST)
Subject: Neighborhood mesh statistical multiplexing
In-Reply-To: <0196330E-FBDF-4FF9-A4BB-E4D0E73D7E07@ianai.net>
Message-ID: <8473482.5767.1390841902479.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Patrick W. Gilmore" 

> On Jan 26, 2014, at 16:04 , Jay Ashworth  wrote:
> 
> > I wonder if they'll break BCP 38... or vice-versa...
> >
> > http://arstechnica.com/business/2014/01/bewifi-lets-you-steal-your-neighbors-bandwidth-when-theyre-not-using-it/
> 
> As long as Telefonica customers only use other Telefonica links within
> WiFi range, Telefonica can ensure it will have no effect on BCP38.
> Worst case, I can "ddos" the guy in the next apartment by spoofing his
> address. Best case, they ensure the BeWifi software disallows such
> things.
> 
> And I don't see other broadband networks allowing Telefonica customers
> to ride their links.
> 
> I also wonder why Telefonica would do this as opposed to telling
> people to upgrade their DSL?

Unless I misread the piece, Pat, they *do* intend for customers to 
mesh non-Telefonica links, which is half of your answer.

"All our customers are at max rate for their distance" is probably the
other half.

I was making the former assumption in my musing.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From jra at baylink.com  Mon Jan 27 17:00:52 2014
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 27 Jan 2014 12:00:52 -0500 (EST)
Subject: Will a single /27 get fully routed these days?
In-Reply-To: 
Message-ID: <25335858.5769.1390842052797.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "John R. Levine" 

> The customer continues to whine about performance. Our ISP says, ah, you
> need our Preferred Thoughput Upgrade Innovation (PTUI), available at
> modest extra cost. The extra cost, of course, it what it costs to buy
> a /24 and get the customer into the real routing table.

And John wins the Internet for today.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From patrick at ianai.net  Mon Jan 27 17:03:38 2014
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Mon, 27 Jan 2014 12:03:38 -0500
Subject: Neighborhood mesh statistical multiplexing
In-Reply-To: <8473482.5767.1390841902479.JavaMail.root@benjamin.baylink.com>
References: <8473482.5767.1390841902479.JavaMail.root@benjamin.baylink.com>
Message-ID: 

On Jan 27, 2014, at 11:58 , Jay Ashworth  wrote:
> From: "Patrick W. Gilmore" 

>> On Jan 26, 2014, at 16:04 , Jay Ashworth  wrote:
>> 
>>> I wonder if they'll break BCP 38... or vice-versa...
>>> 
>>> http://arstechnica.com/business/2014/01/bewifi-lets-you-steal-your-neighbors-bandwidth-when-theyre-not-using-it/
>> 
>> As long as Telefonica customers only use other Telefonica links within
>> WiFi range, Telefonica can ensure it will have no effect on BCP38.
>> Worst case, I can "ddos" the guy in the next apartment by spoofing his
>> address. Best case, they ensure the BeWifi software disallows such
>> things.
>> 
>> And I don't see other broadband networks allowing Telefonica customers
>> to ride their links.
>> 
>> I also wonder why Telefonica would do this as opposed to telling
>> people to upgrade their DSL?
> 
> Unless I misread the piece, Pat, they *do* intend for customers to 
> mesh non-Telefonica links, which is half of your answer.

I guess we read it differently.

They even mention "Telefonica is currently looking towards developing economies and its huge customer base".

Finally, assuming they ask someone else to do this, can you imagine another network saying "sure, use my DSL link to make your customer happier..."?


> "All our customers are at max rate for their distance" is probably the
> other half.

Thought about that, but they discuss customers on different tariffs.

It might be useful when everyone is limited to 128 Kbps or something.


> I was making the former assumption in my musing.

You know what you do when you make an assumption, right? You make an ASS out of U and MPTION. :)

-- 
TTFN,
patrick



From jra at baylink.com  Mon Jan 27 17:19:14 2014
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 27 Jan 2014 12:19:14 -0500 (EST)
Subject: Neighborhood mesh statistical multiplexing
In-Reply-To: 
Message-ID: <30036200.5795.1390843154491.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Patrick W. Gilmore" 

> > Unless I misread the piece, Pat, they *do* intend for customers to
> > mesh non-Telefonica links, which is half of your answer.
> 
> I guess we read it differently.
> 
> They even mention "Telefonica is currently looking towards developing
> economies and its huge customer base".
> 
> Finally, assuming they ask someone else to do this, can you imagine
> another network saying "sure, use my DSL link to make your customer
> happier..."?

Nope, sure can't.

> > "All our customers are at max rate for their distance" is probably
> > the other half.
> 
> Thought about that, but they discuss customers on different tariffs.
> 
> It might be useful when everyone is limited to 128 Kbps or something.
> 
> 
> > I was making the former assumption in my musing.
> 
> You know what you do when you make an assumption, right? You make an
> ASS out of U and MPTION. :)

Thank you, Tony Randall.  :-)

(You know, I can't find an earlier citation for that riff than the Odd
Couple episode...)

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From jra at baylink.com  Mon Jan 27 17:21:52 2014
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 27 Jan 2014 12:21:52 -0500 (EST)
Subject: Neighborhood mesh statistical multiplexing
In-Reply-To: 
Message-ID: <25929399.5797.1390843312809.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Patrick W. Gilmore" 

> I guess we read it differently.

[ rereads ]

I'm wrong; you win; shut up.  :-)

I did find *this* amusing, though:

"""
Another unexpected finding was that people do not use the Internet heavily all at exactly the same time?a concern at the beginning of the trial?but in sporadic bursts. This means there is nearly always some spare bandwidth available to be recycled.
"""

It was unexpected, to them?  Really?  Has streaming widened out the
end-user consumption so much that statmuxing isn't thought to be useful
anymore?

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From dfsfsdfsdsdf at libero.it  Mon Jan 27 10:26:20 2014
From: dfsfsdfsdsdf at libero.it (dfsfsdfsdsdf at libero.it)
Date: Mon, 27 Jan 2014 11:26:20 +0100 (CET)
Subject: ipx routing
Message-ID: <1306562571.2271811390818380808.JavaMail.defaultUser@defaultHost>

hi there,

i'm trying to figure out how i can redirect all the home router's traffic to a 
public server, using IPX and SPX (or in any other way).
just a detail: i don't have access to the home router to change its 
configuration, and i have to do all this from Internet.

i'm hoping someone here could enlighten me.

thanks in advance!


From PKeyser at fibertech.com  Mon Jan 27 18:40:18 2014
From: PKeyser at fibertech.com (Keyser, Philip)
Date: Mon, 27 Jan 2014 18:40:18 +0000
Subject: Fiber Bypass Switch
Message-ID: <7F1FDFB0ED229645954504A27329312D608AE05C@fiber-mail05.CORP.FIBERTECH.com>

Does anyone have any recommendations for a fiber bypass switch? I am looking for something capable of 10G that when there is a power hit will fail over to route traffic out the network ports and away from that site's with the customer handoff.

Thanks,
Phil Keyser


From matthew at corp.crocker.com  Mon Jan 27 19:15:31 2014
From: matthew at corp.crocker.com (Matthew Crocker)
Date: Mon, 27 Jan 2014 14:15:31 -0500
Subject: Fiber Bypass Switch
In-Reply-To: <7F1FDFB0ED229645954504A27329312D608AE05C@fiber-mail05.CORP.FIBERTECH.com>
References: <7F1FDFB0ED229645954504A27329312D608AE05C@fiber-mail05.CORP.FIBERTECH.com>
Message-ID: <095BAD08-58B1-4798-90C6-546C7EB18D18@corp.crocker.com>



Something like this?

http://www.alcon-tech.com/pdfs/Optical-Protection-Switch-FSXpert.pdf



--
Matthew S. Crocker
President
Crocker Communications, Inc.
PO BOX 710
Greenfield, MA 01302-0710

E: matthew at crocker.com
P: (413) 746-2760
F: (413) 746-3704
W: http://www.crocker.com



On Jan 27, 2014, at 1:40 PM, Keyser, Philip  wrote:

> Does anyone have any recommendations for a fiber bypass switch? I am looking for something capable of 10G that when there is a power hit will fail over to route traffic out the network ports and away from that site's with the customer handoff.
> 
> Thanks,
> Phil Keyser
> 
> 



From PKeyser at fibertech.com  Mon Jan 27 19:26:14 2014
From: PKeyser at fibertech.com (Keyser, Philip)
Date: Mon, 27 Jan 2014 19:26:14 +0000
Subject: Fiber Bypass Switch
In-Reply-To: <095BAD08-58B1-4798-90C6-546C7EB18D18@corp.crocker.com>
References: <7F1FDFB0ED229645954504A27329312D608AE05C@fiber-mail05.CORP.FIBERTECH.com>
 <095BAD08-58B1-4798-90C6-546C7EB18D18@corp.crocker.com>
Message-ID: <7F1FDFB0ED229645954504A27329312D608AE0DB@fiber-mail05.CORP.FIBERTECH.com>

Looking for something similar to this.



http://www.moxa.com/product/OBU-102_Series.htm



-----Original Message-----
From: Matthew Crocker [mailto:matthew at corp.crocker.com]
Sent: Monday, January 27, 2014 2:16 PM
To: Keyser, Philip
Cc: nanog at nanog.org
Subject: Re: Fiber Bypass Switch







Something like this?



http://www.alcon-tech.com/pdfs/Optical-Protection-Switch-FSXpert.pdf







--

Matthew S. Crocker

President

Crocker Communications, Inc.

PO BOX 710

Greenfield, MA 01302-0710



E: matthew at crocker.com

P: (413) 746-2760

F: (413) 746-3704

W: http://www.crocker.com







On Jan 27, 2014, at 1:40 PM, Keyser, Philip > wrote:



> Does anyone have any recommendations for a fiber bypass switch? I am looking for something capable of 10G that when there is a power hit will fail over to route traffic out the network ports and away from that site's with the customer handoff.

>

> Thanks,

> Phil Keyser

>

>



______________________________________________________________________

This email has been scanned for spam and viruses by the MessageLabs Email Security System.

For all email inquiries, please submit a ticket to the IT Helpdesk:  ithelpdesk at fibertech.com ______________________________________________________________________

From wbailey at satelliteintelligencegroup.com  Mon Jan 27 23:14:30 2014
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Mon, 27 Jan 2014 23:14:30 +0000
Subject: Terremark Miami
Message-ID: 

Anyone out there listening have experience getting traffic originating at NAP of Americas in Miami to AWS in a non-suck (internet) manner? I know AWS has direct connect, but they are mum about options in MIA.

Thanks in advance!
//warren

From faisal at snappytelecom.net  Mon Jan 27 23:43:29 2014
From: faisal at snappytelecom.net (Faisal Imtiaz)
Date: Mon, 27 Jan 2014 23:43:29 +0000 (GMT)
Subject: Terremark Miami
In-Reply-To: 
References: 
Message-ID: <228610997.594393.1390866209195.JavaMail.root@snappytelecom.net>

What kind of issue are you running into ?

I believe AWS is present on the NOTA/NAP peering fabric, and as such if one was to get access to the NOTA/NAP peering fabric they should be able to peer / pass traffic directly to them.

Regards.

Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232

Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net 

----- Original Message -----
> From: "Warren Bailey" 
> To: nanog at nanog.org
> Sent: Monday, January 27, 2014 6:14:30 PM
> Subject: Terremark Miami
> 
> Anyone out there listening have experience getting traffic originating at NAP
> of Americas in Miami to AWS in a non-suck (internet) manner? I know AWS has
> direct connect, but they are mum about options in MIA.
> 
> Thanks in advance!
> //warren
> 


From wbailey at satelliteintelligencegroup.com  Tue Jan 28 03:55:08 2014
From: wbailey at satelliteintelligencegroup.com (Warren Bailey)
Date: Tue, 28 Jan 2014 03:55:08 +0000
Subject: Terremark Miami
In-Reply-To: <228610997.594393.1390866209195.JavaMail.root@snappytelecom.net>
References: 
 <228610997.594393.1390866209195.JavaMail.root@snappytelecom.net>
Message-ID: 

We?re looking at potential connectivity need of 100mbps from a customer
colocated in NAP of America?s in Miami to some stuff living in AWS land.
We weren?t particularly thrilled about the aspect of a GRE tunnel over the
internet (our AWS stuff does some data manipulation) and wanted to use the
Amazon Direct Connect functionality. It seems like they do this direct
connect as select peering points, and there were no options for anything
in Miami. It may just be easier to buy something off of the provider to
run the traffic over to a colo with AWS connectivity. I?m really just
looking for sexy ways to avoid the internet as a transit route for this
data (the data doesn?t have anything to do with the internet).

On 1/27/14, 3:43 PM, "Faisal Imtiaz"  wrote:

>What kind of issue are you running into ?
>
>I believe AWS is present on the NOTA/NAP peering fabric, and as such if
>one was to get access to the NOTA/NAP peering fabric they should be able
>to peer / pass traffic directly to them.
>
>Regards.
>
>Faisal Imtiaz
>Snappy Internet & Telecom
>7266 SW 48 Street
>Miami, FL 33155
>Tel: 305 663 5518 x 232
>
>Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net
>
>----- Original Message -----
>> From: "Warren Bailey" 
>> To: nanog at nanog.org
>> Sent: Monday, January 27, 2014 6:14:30 PM
>> Subject: Terremark Miami
>> 
>> Anyone out there listening have experience getting traffic originating
>>at NAP
>> of Americas in Miami to AWS in a non-suck (internet) manner? I know AWS
>>has
>> direct connect, but they are mum about options in MIA.
>> 
>> Thanks in advance!
>> //warren
>> 



From jared at puck.nether.net  Tue Jan 28 13:06:31 2014
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 28 Jan 2014 08:06:31 -0500
Subject: BCP38.info
In-Reply-To: <5569484.5623.1390758449655.JavaMail.root@benjamin.baylink.com>
References: <5569484.5623.1390758449655.JavaMail.root@benjamin.baylink.com>
Message-ID: 


On Jan 26, 2014, at 12:47 PM, Jay Ashworth  wrote:

> something like 6 years ago, and couldn't get any traction on it then; 
> I'm not sure I think much has changed -- apparently, extracting your
> BP thoughts from mailing list postings and putting them into a wiki is
> more effort than most NANOGers are up to.

I do have a list of the top ASNs that can be shown to allow IP spoofing by looking at
the DNS scans part of the OpenResolverProject:

  52731 ASN7922
  31251 ASN9394
  25241 ASN17964
  15951 ASN4847
   7576 ASN17430
   5800 ASN17430
   4110 ASN7497
   3645 ASN9812
   3492 ASN6854

http://openresolverproject.org/spoof-src-dst-asns-20140126.txt

What the data is:

It includes IP address where you send a DNS packet to it and another IP address responds to the query, e.g.:

[jared at hostname ~/spoof]$ dig @101.0.37.11
;; reply from unexpected source: 182.19.83.65#53, expected 101.0.37.11#53

The data only includes those where the ?source-ASN? and ?dest-asn? of these packets don?t match.

- Jared




From ab at lists.gxis.de  Tue Jan 28 15:08:04 2014
From: ab at lists.gxis.de (Alexander Bochmann)
Date: Tue, 28 Jan 2014 16:08:04 +0100
Subject: Opensource tools for inventory and troubleticketing
In-Reply-To: <1619681351.38746.1390556234448.open-xchange@ox-webdesk.1and1.es>
References: <1393125223.37939.1390555230304.open-xchange@ox-webdesk.1and1.es>
 <1619681351.38746.1390556234448.open-xchange@ox-webdesk.1and1.es>
Message-ID: <20140128150804.GB9504@gxis.de>

...on Fri, Jan 24, 2014 at 10:37:14AM +0100, Octavio Alfageme wrote:

 > network, but we are starting to need a better inventory of services and network
 > resources and better troubleticketing procedures. We can not afford acquiring

For the inventory and documentation part, Netdot is pretty cool:
https://osl.uoregon.edu/redmine/projects/netdot/wiki

There's a few things missing for datacenter use (VLANs and address ranges 
can only exist once), but I guess that's not particularly relevant for 
ISP work. Nevertheless, the network inventory functions are immensely 
useful for us - we don't even use most of the advanced functions.

As for ticketing, around here quite a few people are using OTRS 
(http://otrs.org/) - but I have no experience with that myself. 
Something like Redmine should be more leightweight and will probably 
do the job too...

Alex.



From tglassey at earthlink.net  Tue Jan 28 18:27:24 2014
From: tglassey at earthlink.net (TGLASSEY)
Date: Tue, 28 Jan 2014 10:27:24 -0800
Subject: BCP38.info
In-Reply-To: 
References: <5569484.5623.1390758449655.JavaMail.root@benjamin.baylink.com>
 
Message-ID: <52E7F68C.3020708@earthlink.net>

We see this all the time with banking sites and some of the stock 
trading ones

Todd

On 1/28/2014 5:06 AM, Jared Mauch wrote:
> On Jan 26, 2014, at 12:47 PM, Jay Ashworth  wrote:
>
>> something like 6 years ago, and couldn't get any traction on it then;
>> I'm not sure I think much has changed -- apparently, extracting your
>> BP thoughts from mailing list postings and putting them into a wiki is
>> more effort than most NANOGers are up to.
> I do have a list of the top ASNs that can be shown to allow IP spoofing by looking at
> the DNS scans part of the OpenResolverProject:
>
>    52731 ASN7922
>    31251 ASN9394
>    25241 ASN17964
>    15951 ASN4847
>     7576 ASN17430
>     5800 ASN17430
>     4110 ASN7497
>     3645 ASN9812
>     3492 ASN6854
>
> http://openresolverproject.org/spoof-src-dst-asns-20140126.txt
>
> What the data is:
>
> It includes IP address where you send a DNS packet to it and another IP address responds to the query, e.g.:
>
> [jared at hostname ~/spoof]$ dig @101.0.37.11
> ;; reply from unexpected source: 182.19.83.65#53, expected 101.0.37.11#53
>
> The data only includes those where the ?source-ASN? and ?dest-asn? of these packets don?t match.
>
> - Jared
>
>
>
>
>

-- 
-------------

Personal Email - Disclaimers Apply



From jra at baylink.com  Tue Jan 28 18:41:44 2014
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 28 Jan 2014 13:41:44 -0500 (EST)
Subject: From Outages - AT&T outage in Maryland area
In-Reply-To: 
Message-ID: <3076754.6151.1390934504736.JavaMail.root@benjamin.baylink.com>

Tracking a really world-class AT&T fiber outage in MD:

> >  Our AT&T service delivery manager just updated the list for us:
> >
> > ? 7 OC192s
> > ? 7 OC48
> > ? 22 Core T3/DS3s
> > ? 8 additional T3/DS3s

[ Apologies for the lack of attribution; they fell apart while I was 
trying to clip the quote. ]

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274


From Valdis.Kletnieks at vt.edu  Tue Jan 28 18:50:07 2014
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 28 Jan 2014 13:50:07 -0500
Subject: BCP38.info
In-Reply-To: Your message of "Tue, 28 Jan 2014 08:06:31 -0500."
 
References: <5569484.5623.1390758449655.JavaMail.root@benjamin.baylink.com>
 
Message-ID: <14976.1390935007@turing-police.cc.vt.edu>

On Tue, 28 Jan 2014 08:06:31 -0500, Jared Mauch said:

>   52731 ASN7922

> It includes IP address where you send a DNS packet to it and another IP address responds to the query, e.g.:

> The data only includes those where the ?source-ASN? and ?dest-asn? of these packets don?t match.

Hang on Jared, I'm trying to wrap my head around this.  You're saying that
AS7922 has over 50K IP addresses which, if you send a DNS query to that IP,
you get an answer back from *an entirely different ASN*? How the heck does
*that* happen?

Hmm.. Comcast.  Anybody over there have an explanation what's going on there?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: 

From jared at puck.nether.net  Tue Jan 28 19:16:09 2014
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 28 Jan 2014 14:16:09 -0500
Subject: BCP38.info
In-Reply-To: <14976.1390935007@turing-police.cc.vt.edu>
References: <5569484.5623.1390758449655.JavaMail.root@benjamin.baylink.com>
 
 <14976.1390935007@turing-police.cc.vt.edu>
Message-ID: <3D726033-682D-4743-8BC7-6E2A41FB3AF3@puck.nether.net>


On Jan 28, 2014, at 1:50 PM, Valdis.Kletnieks at vt.edu wrote:

> On Tue, 28 Jan 2014 08:06:31 -0500, Jared Mauch said:
> 
>>  52731 ASN7922
> 
>> It includes IP address where you send a DNS packet to it and another IP address responds to the query, e.g.:
> 
>> The data only includes those where the ?source-ASN? and ?dest-asn? of these packets don?t match.
> 
> Hang on Jared, I'm trying to wrap my head around this.  You're saying that
> AS7922 has over 50K IP addresses which, if you send a DNS query to that IP,
> you get an answer back from *an entirely different ASN*? How the heck does
> *that* happen?

Yup.

> Hmm.. Comcast.  Anybody over there have an explanation what's going on there?

Most of these devices are CPE that perform DNS redirection/proxy wrong because they didn't constrain their udp/53 rule in iptables to only work on the "inside" interface.  They then send the packet to their configured DNS server (eg: 8.8.8.8) and rewrite the source address in the packet to be the IP address of the OpenResolverProject.org scanning server.  They then spoof me to 8.8.8.8 and I get the response from there.

I have a unique QNAME per-IP i send, so I can decrypt/decode this to get the original destination to detect this.

I mentioned this in the past, so please don't act so surprised :)

http://mailman.nanog.org/pipermail/nanog/2013-August/060246.html

- Jared



From dmiller at tiggee.com  Tue Jan 28 19:46:39 2014
From: dmiller at tiggee.com (David Miller)
Date: Tue, 28 Jan 2014 14:46:39 -0500
Subject: BCP38.info
In-Reply-To: <3D726033-682D-4743-8BC7-6E2A41FB3AF3@puck.nether.net>
References: <5569484.5623.1390758449655.JavaMail.root@benjamin.baylink.com>
 
 <14976.1390935007@turing-police.cc.vt.edu>
 <3D726033-682D-4743-8BC7-6E2A41FB3AF3@puck.nether.net>
Message-ID: <52E8091F.20401@tiggee.com>



On 1/28/2014 2:16 PM, Jared Mauch wrote:
> 
> On Jan 28, 2014, at 1:50 PM, Valdis.Kletnieks at vt.edu wrote:
> 
>> On Tue, 28 Jan 2014 08:06:31 -0500, Jared Mauch said:
>>
>>>  52731 ASN7922
>>
>>> It includes IP address where you send a DNS packet to it and another IP address responds to the query, e.g.:
>>
>>> The data only includes those where the ?source-ASN? and ?dest-asn? of these packets don?t match.
>>
>> Hang on Jared, I'm trying to wrap my head around this.  You're saying that
>> AS7922 has over 50K IP addresses which, if you send a DNS query to that IP,
>> you get an answer back from *an entirely different ASN*? How the heck does
>> *that* happen?
> 
> Yup.

Jared,

What you detected is a misconfiguration of devices on those networks,
but that misconfiguration (in and of itself) is not necessarily what is
commonly referred to as "IP spoofing" in the context of BCP38.

You have *not* "shown" that these ASNs "allow IP spoofing".  You have
collected one data point that indicates the mere possibility that these
ASNs allow IP spoofing.

In the example that you provided, you sent a DNS query to a Pacenet
(India) IP and received a response from a Vodafone (India) IP address.
The IP from which you received the invalid response is an open resolver
(bad thing).  It is completely plausible that whatever device is being
queried has interfaces on both networks.

To have "shown" that this ASN "allows IP spoofing" you must have
demonstrated that this response packet, sourced from a Vodafone IP,
entered the "Internet" from a Pacenet router interface.  Unless I am
missing something here, you haven't come close to showing that.

-DMM


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: 

From sfrost at snowman.net  Tue Jan 28 19:56:15 2014
From: sfrost at snowman.net (Stephen Frost)
Date: Tue, 28 Jan 2014 14:56:15 -0500
Subject: BCP38.info
In-Reply-To: <52E8091F.20401@tiggee.com>
References: <5569484.5623.1390758449655.JavaMail.root@benjamin.baylink.com>
 
 <14976.1390935007@turing-police.cc.vt.edu>
 <3D726033-682D-4743-8BC7-6E2A41FB3AF3@puck.nether.net>
 <52E8091F.20401@tiggee.com>
Message-ID: <20140128195615.GO31026@tamriel.snowman.net>

David,

* David Miller (dmiller at tiggee.com) wrote:
> > On Jan 28, 2014, at 1:50 PM, Valdis.Kletnieks at vt.edu wrote:
> >> Hang on Jared, I'm trying to wrap my head around this.  You're saying that
> >> AS7922 has over 50K IP addresses which, if you send a DNS query to that IP,
> >> you get an answer back from *an entirely different ASN*? How the heck does
> >> *that* happen?
> > 
> > Yup.
> 
> What you detected is a misconfiguration of devices on those networks,
> but that misconfiguration (in and of itself) is not necessarily what is
> commonly referred to as "IP spoofing" in the context of BCP38.
> 
> You have *not* "shown" that these ASNs "allow IP spoofing".  You have
> collected one data point that indicates the mere possibility that these
> ASNs allow IP spoofing.

Sounds like he's got about 50k such data points, in some cases.

> In the example that you provided, you sent a DNS query to a Pacenet
> (India) IP and received a response from a Vodafone (India) IP address.
> The IP from which you received the invalid response is an open resolver
> (bad thing).  It is completely plausible that whatever device is being
> queried has interfaces on both networks.

If it was only one (and for those ASNs where it *is* only one, or even a
few, IPs) then I'd tend to agree with you, however...

> To have "shown" that this ASN "allows IP spoofing" you must have
> demonstrated that this response packet, sourced from a Vodafone IP,
> entered the "Internet" from a Pacenet router interface.  Unless I am
> missing something here, you haven't come close to showing that.

We're talking about 50,000 distinct IPs which are doing this in some
cases.  It strikes me as at least pretty unlikely that all 50,000
devices (or 25,000 or 10,000 or what-have-you, if you want to consider
that some devices might have multiple IPs) out there have multiple
interfaces which cross ASN boundaries.  Sure sounds to me like
*someone* out there has some serious issues to deal with, and the rest
of us are paying the price of their inaction.

	Thanks,

		Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: 

From nick at flhsi.com  Tue Jan 28 19:57:57 2014
From: nick at flhsi.com (Nick Olsen)
Date: Tue, 28 Jan 2014 14:57:57 -0500
Subject: BCP38.info
Message-ID: <939fe1a$25013901$31ba95f6$@flhsi.com>

Agreed.

Our's listed for AS36295 are two customers, Which I know for a fact have their default route set out of a GRE tunnel interface. So while we hand them the request to their interface IP we've assigned them. The response is actually sent, And transported via the customers GRE Tunnel, And HQ's Dedicated internet access where their tunneling to. Making it appear that the reply has been spoofed. When in reality. it was just silent transported to another area before being sent to the src. 

Nick Olsen
 Network Operations 
(855) FLSPEED  x106

----------------------------------------
From: "David Miller" 
Sent: Tuesday, January 28, 2014 2:47 PM
To: "Jared Mauch" , Valdis.Kletnieks at vt.edu
Cc: "NANOG" 
Subject: Re: BCP38.info

On 1/28/2014 2:16 PM, Jared Mauch wrote:
> 
> On Jan 28, 2014, at 1:50 PM, Valdis.Kletnieks at vt.edu wrote:
> 
>> On Tue, 28 Jan 2014 08:06:31 -0500, Jared Mauch said:
>>
>>>  52731 ASN7922
>>
>>> It includes IP address where you send a DNS packet to it and another IP address responds to the query, e.g.:
>>
>>> The data only includes those where the "source-ASN" and "dest-asn" of these packets don't match.
>>
>> Hang on Jared, I'm trying to wrap my head around this.  You're saying that
>> AS7922 has over 50K IP addresses which, if you send a DNS query to that IP,
>> you get an answer back from *an entirely different ASN*? How the heck does
>> *that* happen?
> 
> Yup.

Jared,

What you detected is a misconfiguration of devices on those networks,
but that misconfiguration (in and of itself) is not necessarily what is
commonly referred to as "IP spoofing" in the context of BCP38.

You have *not* "shown" that these ASNs "allow IP spoofing".  You have
collected one data point that indicates the mere possibility that these
ASNs allow IP spoofing.

In the example that you provided, you sent a DNS query to a Pacenet
(India) IP and received a response from a Vodafone (India) IP address.
The IP from which you received the invalid response is an open resolver
(bad thing).  It is completely plausible that whatever device is being
queried has interfaces on both networks.

To have "shown" that this ASN "allows IP spoofing" you must have
demonstrated that this response packet, sourced from a Vodafone IP,
entered the "Internet" from a Pacenet router interface.  Unless I am
missing something here, you haven't come close to showing that.

-DMM



From jared at puck.nether.net  Tue Jan 28 19:58:33 2014
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 28 Jan 2014 14:58:33 -0500
Subject: BCP38.info
In-Reply-To: <52E8091F.20401@tiggee.com>
References: <5569484.5623.1390758449655.JavaMail.root@benjamin.baylink.com>
 
 <14976.1390935007@turing-police.cc.vt.edu>
 <3D726033-682D-4743-8BC7-6E2A41FB3AF3@puck.nether.net>
 <52E8091F.20401@tiggee.com>
Message-ID: <76EC259C-E813-4E24-832D-6097386A6B0B@puck.nether.net>


On Jan 28, 2014, at 2:46 PM, David Miller  wrote:

> 
> 
> On 1/28/2014 2:16 PM, Jared Mauch wrote:
>> 
>> On Jan 28, 2014, at 1:50 PM, Valdis.Kletnieks at vt.edu wrote:
>> 
>>> On Tue, 28 Jan 2014 08:06:31 -0500, Jared Mauch said:
>>> 
>>>> 52731 ASN7922
>>> 
>>>> It includes IP address where you send a DNS packet to it and another IP address responds to the query, e.g.:
>>> 
>>>> The data only includes those where the ?source-ASN? and ?dest-asn? of these packets don?t match.
>>> 
>>> Hang on Jared, I'm trying to wrap my head around this.  You're saying that
>>> AS7922 has over 50K IP addresses which, if you send a DNS query to that IP,
>>> you get an answer back from *an entirely different ASN*? How the heck does
>>> *that* happen?
>> 
>> Yup.
> 
> Jared,
> 
> What you detected is a misconfiguration of devices on those networks,
> but that misconfiguration (in and of itself) is not necessarily what is
> commonly referred to as "IP spoofing" in the context of BCP38.
> 
> You have *not* "shown" that these ASNs "allow IP spoofing".  You have
> collected one data point that indicates the mere possibility that these
> ASNs allow IP spoofing.
> 
> In the example that you provided, you sent a DNS query to a Pacenet
> (India) IP and received a response from a Vodafone (India) IP address.
> The IP from which you received the invalid response is an open resolver
> (bad thing).  It is completely plausible that whatever device is being
> queried has interfaces on both networks.
> 
> To have "shown" that this ASN "allows IP spoofing" you must have
> demonstrated that this response packet, sourced from a Vodafone IP,
> entered the "Internet" from a Pacenet router interface.  Unless I am
> missing something here, you haven't come close to showing that.

No, i've shown that I send a packet to an IP address and It forwards a packet with *my* source address to a 3rd IP address (the configured DNS server).

That DNS server is what responds to me.

The 101.0.37.11 IP is allowed to spoof my IP address.

Feel free to look at the other 261k lines in that file and let me know where I'm wrong.  These are only the ones where the Cymru IP <-> ASN mapping service shows them in a *different* ASN, I have many others of these.  Go ahead and search for 8.8.8.8 or 4.2.2.1 and similar at the website and look at these.  You may find one in your network.

If you compare this to the MIT spoofer project, they had ~18k samples from opt-in.  This here could (in theory) be a larger dataset and generated by this indirect measurement.  Since I have about a years of this data and have worked with others on researching some of these broken CPE behaviors with ISPs, the CPE vendors and others, I'm fairly confident in these results.

Happy to continue the discussion here either on-list or off-list and in private with any networks trying to understand what is happening.

I would love to hear from CPE vendors as well, but I've been doing a lot of other stuff so this isn't my primary focus.

- Jared

From jared at puck.nether.net  Tue Jan 28 20:03:45 2014
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 28 Jan 2014 15:03:45 -0500
Subject: BCP38.info
In-Reply-To: <939fe1a$25013901$31ba95f6$@flhsi.com>
References: <939fe1a$25013901$31ba95f6$@flhsi.com>
Message-ID: <40F74E06-0BC1-4177-838B-8A13CA752BE5@puck.nether.net>


On Jan 28, 2014, at 2:57 PM, Nick Olsen  wrote:

> Agreed.
> 
> Our's listed for AS36295 are two customers, Which I know for a fact have their default route set out of a GRE tunnel interface. So while we hand them the request to their interface IP we've assigned them. The response is actually sent, And transported via the customers GRE Tunnel, And HQ's Dedicated internet access where their tunneling to. Making it appear that the reply has been spoofed. When in reality. it was just silent transported to another area before being sent to the src. 

Sure, but this means that network is allowing the spoofing :)

What I did last night was automated comparing the source ASN to the dest ASN mapped to and reported both the IP + ASN on a single line for those that were interested.

I'm seeing a lot of other email related to BCP-38 right now on another list, but I wanted to share some data (again) in public regarding the state of network spoofing out there.

I'd rather share some data and how others can observe this to determine how we can approach a fix.  Someone spoofing your IP address out some other carrier is something you may be interested to know about, even if you have a non-spoofing network.

- jared

From nick at flhsi.com  Tue Jan 28 21:07:16 2014
From: nick at flhsi.com (Nick Olsen)
Date: Tue, 28 Jan 2014 16:07:16 -0500
Subject: BCP38.info
Message-ID: <25c18b08$e24670d$4597c3a5$@flhsi.com>

While I see what you're saying. It's still not "Spoofed".

The device in question receives the request. And then generates a response 
with the src address of the egress interface of the device dst to the IP 
and port that requested it... In this case. The GRE tunnel. Unless I'm 
missing something here about replying to a request only on the interface 
which it ingressed the device. And the fact that it's UDP. not TCP. So it's 
fire-and-forget.

Thus, Nothing was ever spoofed. It just simply was returned from a 
different interface of the same device. From our point of view. We saw the 
packet of DNS-SRC>OurCustomer. And the other ISP, Which transported the 
reply. only saw Customer-SRC>DNS-DST.

Obviously, This only works because it's UDP. And TCP would be broken.

Nick Olsen
 Network Operations 
(855) FLSPEED  x106

----------------------------------------
From: "Jared Mauch" 
Sent: Tuesday, January 28, 2014 3:04 PM
To: nick at flhsi.com
Cc: "David Miller" , Valdis.Kletnieks at vt.edu, "NANOG" 

Subject: Re: BCP38.info

On Jan 28, 2014, at 2:57 PM, Nick Olsen  wrote:

> Agreed.
> 
> Our's listed for AS36295 are two customers, Which I know for a fact have 
their default route set out of a GRE tunnel interface. So while we hand 
them the request to their interface IP we've assigned them. The response is 
actually sent, And transported via the customers GRE Tunnel, And HQ's 
Dedicated internet access where their tunneling to. Making it appear that 
the reply has been spoofed. When in reality. it was just silent transported 
to another area before being sent to the src. 

Sure, but this means that network is allowing the spoofing :)

What I did last night was automated comparing the source ASN to the dest 
ASN mapped to and reported both the IP + ASN on a single line for those 
that were interested.

I'm seeing a lot of other email related to BCP-38 right now on another 
list, but I wanted to share some data (again) in public regarding the state 
of network spoofing out there.

I'd rather share some data and how others can observe this to determine how 
we can approach a fix.  Someone spoofing your IP address out some other 
carrier is something you may be interested to know about, even if you have 
a non-spoofing network.

- jared


From jared at puck.nether.net  Tue Jan 28 21:11:16 2014
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 28 Jan 2014 16:11:16 -0500
Subject: BCP38.info
In-Reply-To: <25c18b08$e24670d$4597c3a5$@flhsi.com>
References: <25c18b08$e24670d$4597c3a5$@flhsi.com>
Message-ID: 


On Jan 28, 2014, at 4:07 PM, Nick Olsen  wrote:

> While I see what you're saying. It's still not "Spoofed".
> 
> The device in question receives the request. And then generates a response with the src address of the egress interface of the device dst to the IP and port that requested it... In this case. The GRE tunnel. Unless I'm missing something here about replying to a request only on the interface which it ingressed the device. And the fact that it's UDP. not TCP. So it's fire-and-forget.
> 
> Thus, Nothing was ever spoofed. It just simply was returned from a different interface of the same device. From our point of view. We saw the packet of DNS-SRC>OurCustomer. And the other ISP, Which transported the reply. only saw Customer-SRC>DNS-DST.

Nope, what happens is I send from my IP address (lets say 10.0.0.1).  I send a packet to 192.168.0.1.  It has 172.16.0.1 as it's DNS server.

192.168.0.1 has a rule that says send UDP/53 packets I process to 172.16.0.1.  Since i'm "outside" it's "NAT", the rule ends up taking the source IP, which isn't part of it's "NAT" set, and ends up copying my "source" IP into the packet, then forwards it to the DNS server.

172.16.0.1 is responding to 10.0.0.1 DIRECTLY.

It took me awhile in looking at this to figure out what was happening.  Was interesting when you find out the 192.168.0.1 CPE was doing.

You may not call it "spoofing" as it's doing what it was supposed to do/configured to do, but it shouldn't be sending the packet with *my* IP address.

- Jared

From marka at isc.org  Tue Jan 28 21:39:53 2014
From: marka at isc.org (Mark Andrews)
Date: Wed, 29 Jan 2014 08:39:53 +1100
Subject: BCP38.info
In-Reply-To: Your message of "Tue, 28 Jan 2014 16:11:16 -0500."
 
References: <25c18b08$e24670d$4597c3a5$@flhsi.com>
 
Message-ID: <20140128213953.83830DED27A@rock.dv.isc.org>


Jarad is correct.  There is lack of BCP38 filtering in the CPE ASN.

Either the packet has gone

	"probe" -> CPE ->(*) recursive server -> "probe"

or

	"probe" -> CPE -> recursive server -> CPE ->(*) "probe"

(*) indicates the packet that should have been blocked depending apon
how the NAT worked.

In either case the CPE ASN had failed to check the source address of
a packet.  In the first case the source address of the query to the
recursive server.  In the second case the source address of the reply
back to the probe after it had been through the NAT process.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From nick at flhsi.com  Tue Jan 28 21:47:36 2014
From: nick at flhsi.com (Nick Olsen)
Date: Tue, 28 Jan 2014 16:47:36 -0500
Subject: BCP38.info
Message-ID: <2232e78b$617bc9ca$169fef59$@flhsi.com>

Correct, The assumption is that NAT was in use here.

After a quick phone conversation with Jared. We concluded that at least in 
the specific case I was speaking about, I was correct in that nothing was 
"Spoofed". However, Explained further in detail about what he sees from 
other IP's on that list. And it clicked when he pointed out how many times 
8.8.8.8 and 4.2.2.1..etc. pop up as the src of the reply.

Nick Olsen
 Network Operations 
(855) FLSPEED  x106

----------------------------------------
From: "Mark Andrews" 
Sent: Tuesday, January 28, 2014 4:40 PM
To: "Jared Mauch" 
Cc: nick at flhsi.com, "NANOG" 
Subject: Re: BCP38.info

Jarad is correct.  There is lack of BCP38 filtering in the CPE ASN.

Either the packet has gone

	"probe" -> CPE ->(*) recursive server -> "probe"

or

	"probe" -> CPE -> recursive server -> CPE ->(*) "probe"

(*) indicates the packet that should have been blocked depending apon
how the NAT worked.

In either case the CPE ASN had failed to check the source address of
a packet.  In the first case the source address of the query to the
recursive server.  In the second case the source address of the reply
back to the probe after it had been through the NAT process.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



From tglassey at earthlink.net  Tue Jan 28 21:58:14 2014
From: tglassey at earthlink.net (TGLASSEY)
Date: Tue, 28 Jan 2014 13:58:14 -0800
Subject: BCP38.info
In-Reply-To: <25c18b08$e24670d$4597c3a5$@flhsi.com>
References: <25c18b08$e24670d$4597c3a5$@flhsi.com>
Message-ID: <52E827F6.4060809@earthlink.net>


On 1/28/2014 1:07 PM, Nick Olsen wrote:
> While I see what you're saying. It's still not "Spoofed".
>
> The device in question receives the request. And then generates a response
> with the src address of the egress interface of the device dst to the IP
> and port that requested it... In this case. The GRE tunnel. Unless I'm
> missing something here about replying to a request only on the interface
> which it ingressed the device. And the fact that it's UDP. not TCP. So it's
> fire-and-forget.

No in this case the system is being hit with a MITM type attack
>
> Thus, Nothing was ever spoofed. It just simply was returned from a
> different interface of the same device. From our point of view. We saw the
> packet of DNS-SRC>OurCustomer. And the other ISP, Which transported the
> reply. only saw Customer-SRC>DNS-DST.
>
> Obviously, This only works because it's UDP. And TCP would be broken.
>
> Nick Olsen
>   Network Operations
> (855) FLSPEED  x106
>
> ----------------------------------------
> From: "Jared Mauch" 
> Sent: Tuesday, January 28, 2014 3:04 PM
> To: nick at flhsi.com
> Cc: "David Miller" , Valdis.Kletnieks at vt.edu, "NANOG"
> 
> Subject: Re: BCP38.info
>
> On Jan 28, 2014, at 2:57 PM, Nick Olsen  wrote:
>
>> Agreed.
>>
>> Our's listed for AS36295 are two customers, Which I know for a fact have
> their default route set out of a GRE tunnel interface. So while we hand
> them the request to their interface IP we've assigned them. The response is
> actually sent, And transported via the customers GRE Tunnel, And HQ's
> Dedicated internet access where their tunneling to. Making it appear that
> the reply has been spoofed. When in reality. it was just silent transported
> to another area before being sent to the src.
>
> Sure, but this means that network is allowing the spoofing :)
>
> What I did last night was automated comparing the source ASN to the dest
> ASN mapped to and reported both the IP + ASN on a single line for those
> that were interested.
>
> I'm seeing a lot of other email related to BCP-38 right now on another
> list, but I wanted to share some data (again) in public regarding the state
> of network spoofing out there.
>
> I'd rather share some data and how others can observe this to determine how
> we can approach a fix.  Someone spoofing your IP address out some other
> carrier is something you may be interested to know about, even if you have
> a non-spoofing network.
>
> - jared
>
>
>

-- 
-------------

Personal Email - Disclaimers Apply



From mark.tinka at seacom.mu  Tue Jan 28 14:58:49 2014
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Tue, 28 Jan 2014 16:58:49 +0200
Subject: Fwd: [afnog] Introducing Southern Africa Network Operators Group -
 SAFNOG
Message-ID: <201401281658.53434.mark.tinka@seacom.mu>

Hello all.

Kindly see below/attached, per subject.

Please distribute within your local/regional communities. 
Thanks.

Cheers,

Mark.
-------------- next part --------------
An embedded message was scrubbed...
From: Kevin Chege 
Subject: [afnog] Introducing Southern Africa Network Operators Group - SAFNOG
Date: Tue, 28 Jan 2014 11:25:26 +0000
Size: 5260
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: 

From faisal at snappytelecom.net  Wed Jan 29 01:29:08 2014
From: faisal at snappytelecom.net (Faisal Imtiaz)
Date: Wed, 29 Jan 2014 01:29:08 +0000 (GMT)
Subject: Terremark Miami
In-Reply-To: 
References: 
 <228610997.594393.1390866209195.JavaMail.root@snappytelecom.net>
 
Message-ID: <946878424.600361.1390958948430.JavaMail.root@snappytelecom.net>

So essentially, you are looking for a 'direct' x-connect to AWS ?
and not wanting to go thru a peering fabric or any other network ?


Regards

Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232

Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net 

----- Original Message -----
> From: "Warren Bailey" 
> To: "Faisal Imtiaz" 
> Cc: nanog at nanog.org
> Sent: Monday, January 27, 2014 10:55:08 PM
> Subject: Re: Terremark Miami
> 
> We?re looking at potential connectivity need of 100mbps from a customer
> colocated in NAP of America?s in Miami to some stuff living in AWS land.
> We weren?t particularly thrilled about the aspect of a GRE tunnel over the
> internet (our AWS stuff does some data manipulation) and wanted to use the
> Amazon Direct Connect functionality. It seems like they do this direct
> connect as select peering points, and there were no options for anything
> in Miami. It may just be easier to buy something off of the provider to
> run the traffic over to a colo with AWS connectivity. I?m really just
> looking for sexy ways to avoid the internet as a transit route for this
> data (the data doesn?t have anything to do with the internet).
> 
> On 1/27/14, 3:43 PM, "Faisal Imtiaz"  wrote:
> 
> >What kind of issue are you running into ?
> >
> >I believe AWS is present on the NOTA/NAP peering fabric, and as such if
> >one was to get access to the NOTA/NAP peering fabric they should be able
> >to peer / pass traffic directly to them.
> >
> >Regards.
> >
> >Faisal Imtiaz
> >Snappy Internet & Telecom
> >7266 SW 48 Street
> >Miami, FL 33155
> >Tel: 305 663 5518 x 232
> >
> >Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net
> >
> >----- Original Message -----
> >> From: "Warren Bailey" 
> >> To: nanog at nanog.org
> >> Sent: Monday, January 27, 2014 6:14:30 PM
> >> Subject: Terremark Miami
> >> 
> >> Anyone out there listening have experience getting traffic originating
> >>at NAP
> >> of Americas in Miami to AWS in a non-suck (internet) manner? I know AWS
> >>has
> >> direct connect, but they are mum about options in MIA.
> >> 
> >> Thanks in advance!
> >> //warren
> >> 
> 
> 


From wolfgang.nagele at ausregistry.com.au  Wed Jan 29 02:00:20 2014
From: wolfgang.nagele at ausregistry.com.au (Wolfgang Nagele)
Date: Wed, 29 Jan 2014 02:00:20 +0000
Subject: Terremark Miami
In-Reply-To: 
References: 
 <228610997.594393.1390866209195.JavaMail.root@snappytelecom.net>
 
Message-ID: 

There are plenty Direct Connect partners that?ll be happy to take your data from NOTA in Miami to a remote AWS location. See: http://aws.amazon.com/directconnect/partners/

On 1/28/14, 2:55 PM, "Warren Bailey" > wrote:

We?re looking at potential connectivity need of 100mbps from a customer
colocated in NAP of America?s in Miami to some stuff living in AWS land.
We weren?t particularly thrilled about the aspect of a GRE tunnel over the
internet (our AWS stuff does some data manipulation) and wanted to use the
Amazon Direct Connect functionality. It seems like they do this direct
connect as select peering points, and there were no options for anything
in Miami. It may just be easier to buy something off of the provider to
run the traffic over to a colo with AWS connectivity. I?m really just
looking for sexy ways to avoid the internet as a transit route for this
data (the data doesn?t have anything to do with the internet).

On 1/27/14, 3:43 PM, "Faisal Imtiaz" > wrote:

What kind of issue are you running into ?

I believe AWS is present on the NOTA/NAP peering fabric, and as such if
one was to get access to the NOTA/NAP peering fabric they should be able
to peer / pass traffic directly to them.

Regards.

Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232

Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net

----- Original Message -----
From: "Warren Bailey" >
To: nanog at nanog.org
Sent: Monday, January 27, 2014 6:14:30 PM
Subject: Terremark Miami
Anyone out there listening have experience getting traffic originating
at NAP
of Americas in Miami to AWS in a non-suck (internet) manner? I know AWS
has
direct connect, but they are mum about options in MIA.
Thanks in advance!
//warren




From jared at puck.nether.net  Wed Jan 29 02:18:27 2014
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 28 Jan 2014 21:18:27 -0500
Subject: BCP38.info
In-Reply-To: <3D726033-682D-4743-8BC7-6E2A41FB3AF3@puck.nether.net>
References: <5569484.5623.1390758449655.JavaMail.root@benjamin.baylink.com>
 
 <14976.1390935007@turing-police.cc.vt.edu>
 <3D726033-682D-4743-8BC7-6E2A41FB3AF3@puck.nether.net>
Message-ID: 


On Jan 28, 2014, at 2:16 PM, Jared Mauch  wrote:

> 
> On Jan 28, 2014, at 1:50 PM, Valdis.Kletnieks at vt.edu wrote:
> 
>> On Tue, 28 Jan 2014 08:06:31 -0500, Jared Mauch said:
>> 
>>> 52731 ASN7922
>> 
>>> It includes IP address where you send a DNS packet to it and another IP address responds to the query, e.g.:
>> 
>>> The data only includes those where the ?source-ASN? and ?dest-asn? of these packets don?t match.
>> 
>> Hang on Jared, I'm trying to wrap my head around this.  You're saying that
>> AS7922 has over 50K IP addresses which, if you send a DNS query to that IP,
>> you get an answer back from *an entirely different ASN*? How the heck does
>> *that* happen?
> 
> Yup.
> 
>> Hmm.. Comcast.  Anybody over there have an explanation what's going on there?

So I owe an apology to Comcast for a few things here.. Thanks to a few people (Tony Tauber, Aaron Hopkins)
I found an error in one of the scripts that decodes the ?encoded? dns query name.  It was misprocessing some
data and it resulted in the 73.73.73.73 IP address occurring when it should not have.  This IP maps to Comcast
and resulted in wrong data here.

This also means I need to go back and reprocess all the old data to correct for this constraint problem.  (that should
take awhile ?)

Once again, sorry to Comcast for this.  Their numbers should be much lower.

- Jared

From randy at psg.com  Wed Jan 29 05:32:08 2014
From: randy at psg.com (Randy Bush)
Date: Wed, 29 Jan 2014 14:32:08 +0900
Subject: ntp defence preso at apricot
Message-ID: 

i am on the apricot 2014 pc.  we do not have a submission on ntp
defense.  can someone please do one?

randy


From rdobbins at arbor.net  Wed Jan 29 05:57:52 2014
From: rdobbins at arbor.net (Roland Dobbins)
Date: Wed, 29 Jan 2014 18:57:52 +1300
Subject: ntp defence preso at apricot
In-Reply-To: 
References: 
Message-ID: <8226b1b9-8e0a-4066-9505-40547e32cea5@email.android.com>



Randy Bush  wrote:

>i am on the apricot 2014 pc.  we do not have a submission on nap defense.  can someone please do one?

I can, see my reply on apops. 



---------------------------------------
Roland Dobbins 


From mark.tinka at seacom.mu  Wed Jan 29 07:38:50 2014
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Wed, 29 Jan 2014 09:38:50 +0200
Subject: Fwd: [afnog] Introducing Southern Africa Network Operators Group -
 SAFNOG
Message-ID: <201401290938.50888.mark.tinka@seacom.mu>

FYI.

Cheers,

Mark.
-------------- next part --------------
An embedded message was scrubbed...
From: Kevin Chege 
Subject: [afnog] Introducing Southern Africa Network Operators Group - SAFNOG
Date: Tue, 28 Jan 2014 11:25:26 +0000
Size: 5260
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: 

From robachevsky at isoc.org  Wed Jan 29 10:11:00 2014
From: robachevsky at isoc.org (Andrei Robachevsky)
Date: Wed, 29 Jan 2014 11:11:00 +0100
Subject: BCP38.info
In-Reply-To: 
References: <25c18b08$e24670d$4597c3a5$@flhsi.com>
 
Message-ID: <52E8D3B4.2070604@isoc.org>

Jared Mauch wrote on 1/28/14 10:11 PM:
> 192.168.0.1 has a rule that says send UDP/53 packets I process to 172.16.0.1.  Since i'm "outside" it's "NAT", the rule ends up taking the source IP, which isn't part of it's "NAT" set, and ends up copying my "source" IP into the packet, then forwards it to the DNS server.

This is really broken. Do you have any idea as to why such rule is
implemented? I also heard that some CPE implement exactly the same logic
if one spoof src IP inside their NAT. I think that the Spoofer project
discards tests from the inside NAT, but maybe they track such cases?

Andrei


From robachevsky at isoc.org  Wed Jan 29 10:16:41 2014
From: robachevsky at isoc.org (Andrei Robachevsky)
Date: Wed, 29 Jan 2014 11:16:41 +0100
Subject: BCP38.info
In-Reply-To: <40F74E06-0BC1-4177-838B-8A13CA752BE5@puck.nether.net>
References: <939fe1a$25013901$31ba95f6$@flhsi.com>
 <40F74E06-0BC1-4177-838B-8A13CA752BE5@puck.nether.net>
Message-ID: <52E8D509.8020008@isoc.org>

Hi,

Jared Mauch wrote on 1/28/14 9:03 PM:
> I'd rather share some data and how others can observe this to determine how we can approach a fix.  Someone spoofing your IP address out some other carrier is something you may be interested to know about, even if you have a non-spoofing network.

At the Internet Society we are flashing out an idea of an anti-spoofing
"movement", where ISPs can list themselves as not spoofing-capable on
our website. The requirement is that they can demonstrate that they
block spoofed packets, for instance by successfully running the Spoofer
test. I think your, Jared, test can add to this picture.

Sort of a positive spin on the name and shame technique.

It is not ideal, as one test is not a real proof of such capability, but
might help raising awareness, at least. Does this sound as something
that can be useful and fly?

Andrei


From ispbuilder at gmail.com  Wed Jan 29 11:12:48 2014
From: ispbuilder at gmail.com (Mike)
Date: Wed, 29 Jan 2014 07:12:48 -0400
Subject: Opensource tools for inventory and troubleticketing
In-Reply-To: <20140128150804.GB9504@gxis.de>
References: <1393125223.37939.1390555230304.open-xchange@ox-webdesk.1and1.es>
 <1619681351.38746.1390556234448.open-xchange@ox-webdesk.1and1.es>
 <20140128150804.GB9504@gxis.de>
Message-ID: <52E8E230.7090205@gmail.com>

On 14-01-28 11:08 AM, Alexander Bochmann wrote:
> ...on Fri, Jan 24, 2014 at 10:37:14AM +0100, Octavio Alfageme wrote:
>
>  > network, but we are starting to need a better inventory of services and network
>  > resources and better troubleticketing procedures. We can not afford acquiring
>
> For the inventory and documentation part, Netdot is pretty cool:
> https://osl.uoregon.edu/redmine/projects/netdot/wiki
Netdot is awesome, single set of VLANs and address ranges aside. If your
switches / devices support all the proper SNMP MIBs, it will draw your
network topology for you.

> As for ticketing, around here quite a few people are using OTRS 
> (http://otrs.org/) - but I have no experience with that myself. 
> Something like Redmine should be more leightweight and will probably 
> do the job too...
>
I've heard good things about OTRS but my personal favorite is Request
Tracker (http://www.bestpractical.com/rt/). It can be a bit daunting to
get running the first time due to the sheer number of perl modules
required, I'm always happy to help if anyone needs a hand getting it
working.

-- 
Looking for (employment|contract) work in the
Internet industry, preferably working remotely. 
Building / Supporting the net since 2400 baud was
the hot thing. Ask for a resume! ispbuilder at gmail.com



From joe at breathe-underwater.com  Wed Jan 29 11:32:17 2014
From: joe at breathe-underwater.com (Joseph Jenkins)
Date: Wed, 29 Jan 2014 03:32:17 -0800
Subject: BGP multihoming with two address spaces
Message-ID: <9C17D85A-5889-4B4F-AB81-DBACFC3205B1@breathe-underwater.com>

I am seeking some feedback/help with my BGP configuration.  I am peering with two providers level3 and tw.  Unfortunately all of my address spaces are preferring the route over tw rather than level3.  I have tried Prepending my AS and the carriers AS to the path on the tw side and I see those update being accepted by internet routers, but everyone is still preferring to install the tw routes rather than level3.  I was trying to advertise each provider's address space out their connections and then use the other for backup.  Now however everything is coming in through tw and no one seems to like level3.


Thanks in advance for any guidance or assistance.

Joe


From ristic.sasa at gmail.com  Wed Jan 29 12:21:49 2014
From: ristic.sasa at gmail.com (Sasa Ristic)
Date: Wed, 29 Jan 2014 13:21:49 +0100
Subject: BGP multihoming with two address spaces
In-Reply-To: <9C17D85A-5889-4B4F-AB81-DBACFC3205B1@breathe-underwater.com>
References: <9C17D85A-5889-4B4F-AB81-DBACFC3205B1@breathe-underwater.com>
Message-ID: 

How are you announcing your address space now?

On Wed, Jan 29, 2014 at 12:32 PM, Joseph Jenkins
 wrote:
> I am seeking some feedback/help with my BGP configuration.  I am peering with two providers level3 and tw.  Unfortunately all of my address spaces are preferring the route over tw rather than level3.  I have tried Prepending my AS and the carriers AS to the path on the tw side and I see those update being accepted by internet routers, but everyone is still preferring to install the tw routes rather than level3.  I was trying to advertise each provider's address space out their connections and then use the other for backup.  Now however everything is coming in through tw and no one seems to like level3.
>
>
> Thanks in advance for any guidance or assistance.
>
> Joe
>



-- 
Ristic Sasa
--
mob: +381652221123
fax: +381618208488
--
Molim Vas da ne ?tampate ovaj e-mail ukoliko Vam zaista nije potreban
na papiru. Hvala!


From joe at breathe-underwater.com  Wed Jan 29 12:44:53 2014
From: joe at breathe-underwater.com (Joseph Jenkins)
Date: Wed, 29 Jan 2014 04:44:53 -0800
Subject: BGP multihoming with two address spaces
In-Reply-To: 
References: <9C17D85A-5889-4B4F-AB81-DBACFC3205B1@breathe-underwater.com>
 
Message-ID: <6021F051-9518-4191-BC87-46578707A5A1@breathe-underwater.com>

I am announcing two separate /24s.  8.37.93.0 and 207.114.212.0.


Joe

On Jan 29, 2014, at 4:21 AM, Sasa Ristic  wrote:

> How are you announcing your address space now?
> 
> On Wed, Jan 29, 2014 at 12:32 PM, Joseph Jenkins
>  wrote:
>> I am seeking some feedback/help with my BGP configuration.  I am peering with two providers level3 and tw.  Unfortunately all of my address spaces are preferring the route over tw rather than level3.  I have tried Prepending my AS and the carriers AS to the path on the tw side and I see those update being accepted by internet routers, but everyone is still preferring to install the tw routes rather than level3.  I was trying to advertise each provider's address space out their connections and then use the other for backup.  Now however everything is coming in through tw and no one seems to like level3.
>> 
>> 
>> Thanks in advance for any guidance or assistance.
>> 
>> Joe
>> 
> 
> 
> 
> -- 
> Ristic Sasa
> --
> mob: +381652221123
> fax: +381618208488
> --
> Molim Vas da ne ?tampate ovaj e-mail ukoliko Vam zaista nije potreban
> na papiru. Hvala!
> 


From maillist at webjogger.net  Wed Jan 29 14:20:32 2014
From: maillist at webjogger.net (Adam Greene)
Date: Wed, 29 Jan 2014 09:20:32 -0500
Subject: BGP multihoming with two address spaces
In-Reply-To: <6021F051-9518-4191-BC87-46578707A5A1@breathe-underwater.com>
References: <9C17D85A-5889-4B4F-AB81-DBACFC3205B1@breathe-underwater.com>
 
 <6021F051-9518-4191-BC87-46578707A5A1@breathe-underwater.com>
Message-ID: <00e201cf1cfd$451d5e90$cf581bb0$@webjogger.net>

Perhaps L3 is preferring the routes it hears from TW over the ones it hears
from you. Perhaps there is a community string you can attach to your
announcements to one or both providers which can help you further manipulate
what they do with your routes ...

-----Original Message-----
From: Joseph Jenkins [mailto:joe at breathe-underwater.com] 
Sent: Wednesday, January 29, 2014 7:45 AM
Cc: nanog at nanog.org
Subject: Re: BGP multihoming with two address spaces

I am announcing two separate /24s.  8.37.93.0 and 207.114.212.0.


Joe

On Jan 29, 2014, at 4:21 AM, Sasa Ristic  wrote:

> How are you announcing your address space now?
> 
> On Wed, Jan 29, 2014 at 12:32 PM, Joseph Jenkins 
>  wrote:
>> I am seeking some feedback/help with my BGP configuration.  I am peering
with two providers level3 and tw.  Unfortunately all of my address spaces
are preferring the route over tw rather than level3.  I have tried
Prepending my AS and the carriers AS to the path on the tw side and I see
those update being accepted by internet routers, but everyone is still
preferring to install the tw routes rather than level3.  I was trying to
advertise each provider's address space out their connections and then use
the other for backup.  Now however everything is coming in through tw and no
one seems to like level3.
>> 
>> 
>> Thanks in advance for any guidance or assistance.
>> 
>> Joe
>> 
> 
> 
> 
> --
> Ristic Sasa
> --
> mob: +381652221123
> fax: +381618208488
> --
> Molim Vas da ne ?tampate ovaj e-mail ukoliko Vam zaista nije potreban 
> na papiru. Hvala!
> 




From faisal at snappytelecom.net  Wed Jan 29 14:40:38 2014
From: faisal at snappytelecom.net (Faisal Imtiaz)
Date: Wed, 29 Jan 2014 14:40:38 +0000 (GMT)
Subject: BGP multihoming with two address spaces
In-Reply-To: <00e201cf1cfd$451d5e90$cf581bb0$@webjogger.net>
References: <9C17D85A-5889-4B4F-AB81-DBACFC3205B1@breathe-underwater.com>
 
 <6021F051-9518-4191-BC87-46578707A5A1@breathe-underwater.com>
 <00e201cf1cfd$451d5e90$cf581bb0$@webjogger.net>
Message-ID: <1980468403.603103.1391006438769.JavaMail.root@snappytelecom.net>

Another thing to keep in mind that some providers will use local pref. as well for traffic engineering,
Looking at the TW Telecom Community strings, it would appear that they do...

http://www.onesc.net/communities/as4323/

http://www.onesc.net/communities/as3356/

Try using the communities to influence your traffic engineering.

BTW, I took a quick look at Routeviews looking glass for you ...

Here is what I see....

8.37.93.0/24 is only being advertised via your TW Telecom connection .... (Possible Filters issues with Level3 ?)
207.114.212.0/24 is being advertised via both TW Telecom and Level3.. and in case of Routeviews, it is preferring the Level3 connection.

The above is for inbound traffic only...

For outbound, if you want to use both connections, then you will have to create an ACL to change the Local Pref so that you can use one or the other provider as the preferred route.

Regards.


Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232

Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net 

----- Original Message -----
> From: "Adam Greene" 
> To: nanog at nanog.org
> Sent: Wednesday, January 29, 2014 9:20:32 AM
> Subject: RE: BGP multihoming with two address spaces
> 
> Perhaps L3 is preferring the routes it hears from TW over the ones it hears
> from you. Perhaps there is a community string you can attach to your
> announcements to one or both providers which can help you further manipulate
> what they do with your routes ...
> 
> -----Original Message-----
> From: Joseph Jenkins [mailto:joe at breathe-underwater.com]
> Sent: Wednesday, January 29, 2014 7:45 AM
> Cc: nanog at nanog.org
> Subject: Re: BGP multihoming with two address spaces
> 
> I am announcing two separate /24s.  8.37.93.0 and 207.114.212.0.
> 
> 
> Joe
> 
> On Jan 29, 2014, at 4:21 AM, Sasa Ristic  wrote:
> 
> > How are you announcing your address space now?
> > 
> > On Wed, Jan 29, 2014 at 12:32 PM, Joseph Jenkins
> >  wrote:
> >> I am seeking some feedback/help with my BGP configuration.  I am peering
> with two providers level3 and tw.  Unfortunately all of my address spaces
> are preferring the route over tw rather than level3.  I have tried
> Prepending my AS and the carriers AS to the path on the tw side and I see
> those update being accepted by internet routers, but everyone is still
> preferring to install the tw routes rather than level3.  I was trying to
> advertise each provider's address space out their connections and then use
> the other for backup.  Now however everything is coming in through tw and no
> one seems to like level3.
> >> 
> >> 
> >> Thanks in advance for any guidance or assistance.
> >> 
> >> Joe
> >> 
> > 
> > 
> > 
> > --
> > Ristic Sasa
> > --
> > mob: +381652221123
> > fax: +381618208488
> > --
> > Molim Vas da ne ?tampate ovaj e-mail ukoliko Vam zaista nije potreban
> > na papiru. Hvala!
> > 
> 
> 
> 
>


From jakob.heitz at ericsson.com  Wed Jan 29 15:35:29 2014
From: jakob.heitz at ericsson.com (Jakob Heitz)
Date: Wed, 29 Jan 2014 15:35:29 +0000
Subject: BGP multihoming with two address spaces
In-Reply-To: 
References: 
Message-ID: <0006F560-5443-4BD4-876A-D11C762E768B@ericsson.com>

It is likely that level3 is aggregating your route, but tw can't. Longest match wins.

--
Jakob Heitz.


> Date: Wed, 29 Jan 2014 03:32:17 -0800
> From: Joseph Jenkins 
> 
> I am seeking some feedback/help with my BGP configuration.  I am peering with two providers level3 and tw.  Unfortunately all of my address spaces are preferring the route over tw rather than level3.  I have tried Prepending my AS and the carriers AS to the path on the tw side and I see those update being accepted by internet routers, but everyone is still preferring to install the tw routes rather than level3.  I was trying to advertise each provider's address space out their connections and then use the other for backup.  Now however everything is coming in through tw and no one seems to like level3.
> 
> 
> Thanks in advance for any guidance or assistance.
> 
> Joe


From Curtis at GreenKey.net  Wed Jan 29 16:03:37 2014
From: Curtis at GreenKey.net (Curtis Doty)
Date: Wed, 29 Jan 2014 08:03:37 -0800
Subject: BGP multihoming with two address spaces
In-Reply-To: <9C17D85A-5889-4B4F-AB81-DBACFC3205B1@breathe-underwater.com>
References: <9C17D85A-5889-4B4F-AB81-DBACFC3205B1@breathe-underwater.com>
Message-ID: 

According to telnet://route-server.twtelecom.net and
http://lookingglass.level3.net/bgp/lg_bgp_main.php BGP is working as
designed. Your single prepend on one prefix with TWTC causes a slight
preference for LVL3. Add another prepend if you want to further balance
your ingress load away from TWTC.

Or for more coarse adjustment, use the TWTC feature communities to reduce
their local preference below that of customer default (115 for TWTC). Use
4323:100 for transit default.

../C



On Wed, Jan 29, 2014 at 3:32 AM, Joseph Jenkins
wrote:

> I am seeking some feedback/help with my BGP configuration.  I am peering
> with two providers level3 and tw.  Unfortunately all of my address spaces
> are preferring the route over tw rather than level3.  I have tried
> Prepending my AS and the carriers AS to the path on the tw side and I see
> those update being accepted by internet routers, but everyone is still
> preferring to install the tw routes rather than level3.  I was trying to
> advertise each provider's address space out their connections and then use
> the other for backup.  Now however everything is coming in through tw and
> no one seems to like level3.
>
>
> Thanks in advance for any guidance or assistance.
>
> Joe
>
>

From aledm at qix.co.uk  Wed Jan 29 17:06:45 2014
From: aledm at qix.co.uk (Aled Morris)
Date: Wed, 29 Jan 2014 17:06:45 +0000
Subject: Fiber Bypass Switch
In-Reply-To: <7F1FDFB0ED229645954504A27329312D608AE0DB@fiber-mail05.CORP.FIBERTECH.com>
References: <7F1FDFB0ED229645954504A27329312D608AE05C@fiber-mail05.CORP.FIBERTECH.com>
 <095BAD08-58B1-4798-90C6-546C7EB18D18@corp.crocker.com>
 <7F1FDFB0ED229645954504A27329312D608AE0DB@fiber-mail05.CORP.FIBERTECH.com>
Message-ID: 

NTT-AT presented their optical bypass products at LINX81, seems like they
might do what you want:

http://www.ntt-at.com/product/optical-switch/

I haven't used them myself.

Aled


On 27 January 2014 19:26, Keyser, Philip  wrote:

> Looking for something similar to this.
>
>
>
> http://www.moxa.com/product/OBU-102_Series.htm
>
>
>
> -----Original Message-----
> From: Matthew Crocker [mailto:matthew at corp.crocker.com]
> Sent: Monday, January 27, 2014 2:16 PM
> To: Keyser, Philip
> Cc: nanog at nanog.org
> Subject: Re: Fiber Bypass Switch
>
>
>
>
>
>
>
> Something like this?
>
>
>
> http://www.alcon-tech.com/pdfs/Optical-Protection-Switch-FSXpert.pdf
>
>
>
>
>
>
>
> --
>
> Matthew S. Crocker
>
> President
>
> Crocker Communications, Inc.
>
> PO BOX 710
>
> Greenfield, MA 01302-0710
>
>
>
> E: matthew at crocker.com
>
> P: (413) 746-2760
>
> F: (413) 746-3704
>
> W: http://www.crocker.com
>
>
>
>
>
>
>
> On Jan 27, 2014, at 1:40 PM, Keyser, Philip  PKeyser at fibertech.com>> wrote:
>
>
>
> > Does anyone have any recommendations for a fiber bypass switch? I am
> looking for something capable of 10G that when there is a power hit will
> fail over to route traffic out the network ports and away from that site's
> with the customer handoff.
>
> >
>
> > Thanks,
>
> > Phil Keyser
>
> >
>
> >
>
>
>
> ______________________________________________________________________
>
> This email has been scanned for spam and viruses by the MessageLabs Email
> Security System.
>
> For all email inquiries, please submit a ticket to the IT Helpdesk:
> ithelpdesk at fibertech.com
> ______________________________________________________________________
>

From source_route at yahoo.com  Wed Jan 29 17:35:25 2014
From: source_route at yahoo.com (Philip Lavine)
Date: Wed, 29 Jan 2014 09:35:25 -0800 (PST)
Subject: Fw: ipv6 newbie question
In-Reply-To: <1391011638.2024.YahooMailNeo@web140705.mail.bf1.yahoo.com>
References: <1391011638.2024.YahooMailNeo@web140705.mail.bf1.yahoo.com>
Message-ID: <1391016925.68774.YahooMailNeo@web140703.mail.bf1.yahoo.com>

?

? 
Is it best practice to have the internet facing BGP router's peering ip?(or for that matter any key gateway or security appliance) use a statically configured address or use EUI-64 auto config?

I have seen comments on both sides and am leaning to EUI-64 (except for the VIP's like the ASA's?failover ip?)

-Philip

From jared at puck.nether.net  Wed Jan 29 17:47:42 2014
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 29 Jan 2014 12:47:42 -0500
Subject: ipv6 newbie question
In-Reply-To: <1391016925.68774.YahooMailNeo@web140703.mail.bf1.yahoo.com>
References: <1391011638.2024.YahooMailNeo@web140705.mail.bf1.yahoo.com>
 <1391016925.68774.YahooMailNeo@web140703.mail.bf1.yahoo.com>
Message-ID: <9AB5CD2E-1BB0-4B7B-B15D-1E6036710DEC@puck.nether.net>


On Jan 29, 2014, at 12:35 PM, Philip Lavine  wrote:
  
> Is it best practice to have the internet facing BGP router's peering ip (or for that matter any key gateway or security appliance) use a statically configured address or use EUI-64 auto config?
> 
> I have seen comments on both sides and am leaning to EUI-64 (except for the VIP's like the ASA's failover ip )

We configure customers with a statically assigned IP address for BGP peering.

They get the IP assigned to them as part of the turn-up process.

The same process happens for "IP Classic" aka v4 as v6.

- Jared

(If you are a AS2914 customer and aren't doing IPv6 with us, don't hesitate to ping me and I will get your information over to that team).

From nick at foobar.org  Wed Jan 29 17:47:59 2014
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 29 Jan 2014 17:47:59 +0000
Subject: Fw: ipv6 newbie question
In-Reply-To: <1391016925.68774.YahooMailNeo@web140703.mail.bf1.yahoo.com>
References: <1391011638.2024.YahooMailNeo@web140705.mail.bf1.yahoo.com>
 <1391016925.68774.YahooMailNeo@web140703.mail.bf1.yahoo.com>
Message-ID: <52E93ECF.6010900@foobar.org>

On 29/01/2014 17:35, Philip Lavine wrote:
> Is it best practice to have the internet facing BGP router's peering ip
> (or for that matter any key gateway or security appliance) use a
> statically configured address or use EUI-64 auto config?

how are you going to set up the bgp session from the remote side to an
eui-64 auto configured address on your side?

best use static here.  And make sure to disable RA (with fire, i.e. disable
send + receive + answering solicited requests) and EUI64.  If it's a point
to point link, use a /126 or /127 netmask.

Nick



From sander at steffann.nl  Wed Jan 29 17:59:31 2014
From: sander at steffann.nl (Sander Steffann)
Date: Wed, 29 Jan 2014 18:59:31 +0100
Subject: ipv6 newbie question
In-Reply-To: <1391016925.68774.YahooMailNeo@web140703.mail.bf1.yahoo.com>
References: <1391011638.2024.YahooMailNeo@web140705.mail.bf1.yahoo.com>
 <1391016925.68774.YahooMailNeo@web140703.mail.bf1.yahoo.com>
Message-ID: <3BCDF0E9-ECEC-41EC-96BC-57D650832B20@steffann.nl>

Hi,

> Is it best practice to have the internet facing BGP router's peering ip (or for that matter any key gateway or security appliance) use a statically configured address or use EUI-64 auto config?
> 
> I have seen comments on both sides and am leaning to EUI-64 (except for the VIP's like the ASA's failover ip )

Static. You don't want to have to contact all of your peers when the EUI-64 address changes when you replace hardware.

Cheers
Sander



From streiner at cluebyfour.org  Wed Jan 29 14:44:18 2014
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Wed, 29 Jan 2014 09:44:18 -0500 (EST)
Subject: Fw: ipv6 newbie question
In-Reply-To: <52E93ECF.6010900@foobar.org>
References: <1391011638.2024.YahooMailNeo@web140705.mail.bf1.yahoo.com>
 <1391016925.68774.YahooMailNeo@web140703.mail.bf1.yahoo.com>
 <52E93ECF.6010900@foobar.org>
Message-ID: 

On Wed, 29 Jan 2014, Nick Hilliard wrote:

> On 29/01/2014 17:35, Philip Lavine wrote:
>> Is it best practice to have the internet facing BGP router's peering ip
>> (or for that matter any key gateway or security appliance) use a
>> statically configured address or use EUI-64 auto config?
>
> how are you going to set up the bgp session from the remote side to an
> eui-64 auto configured address on your side?
>
> best use static here.  And make sure to disable RA (with fire, i.e. disable
> send + receive + answering solicited requests) and EUI64.  If it's a point
> to point link, use a /126 or /127 netmask.

+1.  I've seem some providers do /64 on their point-to-point links.  I 
don't have an issue with that, and the whole /64 vs /126 or /127 debate 
has been thoroughly beaten into the ground.  No need to re-hash it.

I have never seen a provider use a pseudo-dynamic address on an 
interface/BGP peer.  Having to reconfigure a BGP session because a 
provider did a hardware upgrade or moved my link to a new interface would 
not make me happy.

jms


From Jack.Stonebraker at mygrande.com  Wed Jan 29 18:10:11 2014
From: Jack.Stonebraker at mygrande.com (Jack Stonebraker)
Date: Wed, 29 Jan 2014 18:10:11 +0000
Subject: Fw: ipv6 newbie question
In-Reply-To: 
References: <1391011638.2024.YahooMailNeo@web140705.mail.bf1.yahoo.com>
 <1391016925.68774.YahooMailNeo@web140703.mail.bf1.yahoo.com>
 <52E93ECF.6010900@foobar.org>
 
Message-ID: <1C88157B8801CB448C108286C81ECB630B0C46@SRV-SAM-MBOX02.lan.thrifty.net>

Agreed,

We do a /64 allocation which is reserved for each point to point link, but then subnet it to a /126 for actual use.  That way we've got a /64 available if it's ever needed, while keeping the broadcast domain small for now when we don't.

JJ Stonebraker
IP Network Engineering
Grande Communications
512.878.5627

-----Original Message-----
From: Justin M. Streiner [mailto:streiner at cluebyfour.org] 
Sent: Wednesday, January 29, 2014 8:44 AM
To: NANOG list
Subject: Re: Fw: ipv6 newbie question

On Wed, 29 Jan 2014, Nick Hilliard wrote:

> On 29/01/2014 17:35, Philip Lavine wrote:
>> Is it best practice to have the internet facing BGP router's peering ip
>> (or for that matter any key gateway or security appliance) use a
>> statically configured address or use EUI-64 auto config?
>
> how are you going to set up the bgp session from the remote side to an
> eui-64 auto configured address on your side?
>
> best use static here.  And make sure to disable RA (with fire, i.e. disable
> send + receive + answering solicited requests) and EUI64.  If it's a point
> to point link, use a /126 or /127 netmask.

+1.  I've seem some providers do /64 on their point-to-point links.  I 
don't have an issue with that, and the whole /64 vs /126 or /127 debate 
has been thoroughly beaten into the ground.  No need to re-hash it.

I have never seen a provider use a pseudo-dynamic address on an 
interface/BGP peer.  Having to reconfigure a BGP session because a 
provider did a hardware upgrade or moved my link to a new interface would 
not make me happy.

jms



From owen at delong.com  Wed Jan 29 18:03:48 2014
From: owen at delong.com (Owen DeLong)
Date: Wed, 29 Jan 2014 13:03:48 -0500
Subject: ipv6 newbie question
In-Reply-To: <1391016925.68774.YahooMailNeo@web140703.mail.bf1.yahoo.com>
References: <1391011638.2024.YahooMailNeo@web140705.mail.bf1.yahoo.com>
 <1391016925.68774.YahooMailNeo@web140703.mail.bf1.yahoo.com>
Message-ID: <2A8DAC87-5CD3-4F66-A6CA-59D9F9135AB5@delong.com>

There are tradeoffs in both directions.

Personally I think administrative simplicity wins over security through obscurity, so I recommend each organization pick a random pair of static addresses and use those two addresses for all of their point to point links.

e.g. If your prefix for a given link is 2001:db8:xxxx:yyyy::/64, and you randomly choose the suffixes dead:beef:cafe:babe and dead:beef:cafe:feed as your end-point addresses, then the links would be numbered 2001:db8:xxxx:yyyy:dead:beef:cafe:{babe,feed}.

YMMV and I don't recommend using my examples in practice.

Owen


> On Jan 29, 2014, at 12:35 PM, Philip Lavine  wrote:
> 
>  
> 
>   
> Is it best practice to have the internet facing BGP router's peering ip (or for that matter any key gateway or security appliance) use a statically configured address or use EUI-64 auto config?
> 
> I have seen comments on both sides and am leaning to EUI-64 (except for the VIP's like the ASA's failover ip )
> 
> -Philip


From stillwaxin at gmail.com  Wed Jan 29 18:44:36 2014
From: stillwaxin at gmail.com (Michael Still)
Date: Wed, 29 Jan 2014 13:44:36 -0500
Subject: Fw: ipv6 newbie question
In-Reply-To: <1391016925.68774.YahooMailNeo@web140703.mail.bf1.yahoo.com>
References: <1391011638.2024.YahooMailNeo@web140705.mail.bf1.yahoo.com>
 <1391016925.68774.YahooMailNeo@web140703.mail.bf1.yahoo.com>
Message-ID: 

If only there was a best practices doc to help here...  Oh wait there is!

http://bcop.nanog.org/index.php/IPv6_Subnetting

It doesn't specifically mention BGP so as to be protocol agnostic but
does recommend allocating a /64 and using a /126 or /127.



On Wed, Jan 29, 2014 at 12:35 PM, Philip Lavine  wrote:
>
>
>
> Is it best practice to have the internet facing BGP router's peering ip (or for that matter any key gateway or security appliance) use a statically configured address or use EUI-64 auto config?
>
> I have seen comments on both sides and am leaning to EUI-64 (except for the VIP's like the ASA's failover ip )
>
> -Philip



-- 
[stillwaxin at gmail.com ~]$ cat .signature
cat: .signature: No such file or directory
[stillwaxin at gmail.com ~]$


From bill at herrin.us  Wed Jan 29 18:44:53 2014
From: bill at herrin.us (William Herrin)
Date: Wed, 29 Jan 2014 13:44:53 -0500
Subject: BGP multihoming with two address spaces
In-Reply-To: <9C17D85A-5889-4B4F-AB81-DBACFC3205B1@breathe-underwater.com>
References: <9C17D85A-5889-4B4F-AB81-DBACFC3205B1@breathe-underwater.com>
Message-ID: 

On Wed, Jan 29, 2014 at 6:32 AM, Joseph Jenkins
 wrote:
> I am seeking some feedback/help with my BGP configuration.
> I am peering with two providers level3 and tw.  Unfortunately all of
> my address spaces are preferring the route over tw rather than level3.

Hi Joe,

I had a situation like this a couple months ago but my two providers
were: Centurylink and Centurylink. No matter how many prepends I
added, the traffic preferred the slow link in one state to the fast
link in another.

It turned out that Centurylink (Embarq) gets to the Internet via
Centurylink (Qwest). Unless modified by communities, Qwest has a local
pref that delivers traffic to direct customers in preference to other
ASes. And the folks in Embarq's support had no idea what Qwest was
doing.

This sort of local-pref default seems to be a common practice with
backbones. It's very annoying. I wish they'd stop.

Regards,
Bill Herrin

-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: 
Falls Church, VA 22042-3004


From ryandelgrosso at gmail.com  Wed Jan 29 19:25:27 2014
From: ryandelgrosso at gmail.com (Ryan Delgrosso)
Date: Wed, 29 Jan 2014 11:25:27 -0800
Subject: Tata communications issues
Message-ID: <52E955A7.1040603@gmail.com>

I am looking for a clueful networking contact at Tata communications as 
the IP noc is not being terribly helpful. When i turn up advertisements 
to you I suddenly become unreachable to large swaths of the Internet.

Please contact me off-list

Thanks in advance
-Ryan


From owen at delong.com  Wed Jan 29 19:34:24 2014
From: owen at delong.com (Owen DeLong)
Date: Wed, 29 Jan 2014 14:34:24 -0500
Subject: BGP multihoming with two address spaces
In-Reply-To: 
References: <9C17D85A-5889-4B4F-AB81-DBACFC3205B1@breathe-underwater.com>
 
Message-ID: <16EF1A61-5E38-498E-B64A-3854F834289F@delong.com>

> This sort of local-pref default seems to be a common practice with
> backbones. It's very annoying. I wish they'd stop.

Most of their customers would actually be very unhappy if they stopped. This local-pref default prevents many many problems and in the vast majority of cases provides the desired result. Yes, it's important to know what is going on and to be able to ask your providers to make necessary changes in circumstances where this is not optimal (either via community or ticket), but I assure you that if every backbone turned this off suddenly, most internet users would be very !HAPPY.

Owen



From m.hallgren at free.fr  Wed Jan 29 20:24:26 2014
From: m.hallgren at free.fr (Michael Hallgren)
Date: Wed, 29 Jan 2014 21:24:26 +0100
Subject: BGP multihoming with two address spaces
In-Reply-To: <16EF1A61-5E38-498E-B64A-3854F834289F@delong.com>
References: <9C17D85A-5889-4B4F-AB81-DBACFC3205B1@breathe-underwater.com>
 
 <16EF1A61-5E38-498E-B64A-3854F834289F@delong.com>
Message-ID: <52E9637A.9000906@free.fr>

Le 29/01/2014 20:34, Owen DeLong a ?crit :
>> This sort of local-pref default seems to be a common practice with
>> backbones. It's very annoying. I wish they'd stop.
> Most of their customers would actually be very unhappy if they stopped. This local-pref default prevents many many problems and in the vast majority of cases provides the desired result. Yes, it's important to know what is going on and to be able to ask your providers to make necessary changes in circumstances where this is not optimal (either via community or ticket), but I assure you that if every backbone turned this off suddenly, most internet users would be very !HAPPY.

The underlying reason for this type of local preference has to do with
an assumption of cost
(which, given current transit prices, may be true or not):

        cost(customer) < 0 < cost(peer) < cost(provider) ..., thus

        local_pref(customer) > local_pref(peer) > local_pref(provider),

and as you say Owen, many actors sharing a policy simplifies our view of
things a bit. Another
way of assigning local preference of a route may factor in measured or
perceived path quality,
slightly more complex, but not a crime at all :-).

Cheers,
mh


>
> Owen
>
>



From baldur.norddahl at gmail.com  Wed Jan 29 20:32:57 2014
From: baldur.norddahl at gmail.com (Baldur Norddahl)
Date: Wed, 29 Jan 2014 21:32:57 +0100
Subject: BGP multihoming
Message-ID: 

Apologies for a RIPE question on NANOG, although I believe this issue will
soon enough to be relevant for the ARIN region as well.

I had a customer ask if we could provide him with BGP such that he could be
multihomed. He already has 128 IP addresses from another ISP. Obviously a
/25 is a non go for multihoming as everyone are going to ignore his route.

I would then need to help him with acquiring a /24 PI. Which appears to be
impossible as RIPE does no longer assign PI space and PI can not be
reassigned and thus be bought.

Is assigning a /24 from my own PA space for the purpose of BGP multihoming
considered sufficient "need"?

Could he get some PI from another region, such as ARIN? How does others
handle this situation?

Regards,

Baldur

From streiner at cluebyfour.org  Wed Jan 29 17:25:55 2014
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Wed, 29 Jan 2014 12:25:55 -0500 (EST)
Subject: BGP multihoming
In-Reply-To: 
References: 
Message-ID: 

On Wed, 29 Jan 2014, Baldur Norddahl wrote:

> I had a customer ask if we could provide him with BGP such that he could be
> multihomed. He already has 128 IP addresses from another ISP. Obviously a
> /25 is a non go for multihoming as everyone are going to ignore his route.

Not necessarily everyone, but a lot of providers will filter that.  More 
headaches than it's worth.

> I would then need to help him with acquiring a /24 PI. Which appears to be
> impossible as RIPE does no longer assign PI space and PI can not be
> reassigned and thus be bought.
> 
> Is assigning a /24 from my own PA space for the purpose of BGP multihoming
> considered sufficient "need"?

I haven't looked at RIPE policies in a while, but I would imagine that 
assigning a customer a /24 of your space because they need to multihome is 
considered a justifiable use.

> Could he get some PI from another region, such as ARIN? How does others
> handle this situation?

Most likely no, for two reasons.  1. Most RIRs don't assign IPv4 /24s to 
end-users except in very special cases, 2. The smallest PI block they 
would assign is usually something like a /21 or /22, so your customer 
would need to be justifiably using that much space before they could apply 
for a PI block, and 3, if the customer is in an area outside of $RIR's 
service area, they would direct them to contact the appropriate RIR.

I also hope your customer is making plans for IPv6 deployment.

jms


From michbrau at cisco.com  Wed Jan 29 20:45:36 2014
From: michbrau at cisco.com (Michael Braun (michbrau))
Date: Wed, 29 Jan 2014 20:45:36 +0000
Subject: BGP multihoming
In-Reply-To: 
References: 
Message-ID: 

Interesting question, and to add to that, I have another one.  With the
rapid depletion of IPv4 address space from ARIN, are there private
end-user companies that are leasing off unused portions of their assigned
address blocks to other private and unrelated end user companies?  Does
that cause any problems where address space is being advertised from a
non-assigned AS?

Thanks,

Mike  

On 1/29/14 12:32 PM, "Baldur Norddahl"  wrote:

>Apologies for a RIPE question on NANOG, although I believe this issue will
>soon enough to be relevant for the ARIN region as well.
>
>I had a customer ask if we could provide him with BGP such that he could
>be
>multihomed. He already has 128 IP addresses from another ISP. Obviously a
>/25 is a non go for multihoming as everyone are going to ignore his route.
>
>I would then need to help him with acquiring a /24 PI. Which appears to be
>impossible as RIPE does no longer assign PI space and PI can not be
>reassigned and thus be bought.
>
>Is assigning a /24 from my own PA space for the purpose of BGP multihoming
>considered sufficient "need"?
>
>Could he get some PI from another region, such as ARIN? How does others
>handle this situation?
>
>Regards,
>
>Baldur



From tore at fud.no  Wed Jan 29 21:09:10 2014
From: tore at fud.no (Tore Anderson)
Date: Wed, 29 Jan 2014 22:09:10 +0100
Subject: BGP multihoming
In-Reply-To: 
References: 
Message-ID: <52E96DF6.1@fud.no>

* Baldur Norddahl

> Apologies for a RIPE question on NANOG, although I believe this issue
> will soon enough to be relevant for the ARIN region as well.

Relevant perhaps, but as the policies differ, so may the correct answers...

> I had a customer ask if we could provide him with BGP such that he
> could be multihomed. He already has 128 IP addresses from another
> ISP. Obviously a /25 is a non go for multihoming as everyone are
> going to ignore his route.
> 
> I would then need to help him with acquiring a /24 PI. Which appears
> to be impossible as RIPE does no longer assign PI space and PI can
> not be reassigned and thus be bought.

There is another option, namely if your customer becomes a RIPE NCC
member (i.e., an LIR), he'll get a PA /22. (Of course, you could offer
to perform all the administrative work is to start and operate an LIR on
your customer's behalf, for a reasonable fee.)

> Is assigning a /24 from my own PA space for the purpose of BGP
> multihoming considered sufficient "need"?

Not with current policies, no, as the multihoming clause only applied
specifically to PI assignments, not pA. However, if you customer can
show that he'll be using at least 128 addresses (i.e., 50% of a /24)
within a year, he does qualify for an assignment of a /24. Plans to
renumber out of his current /25 would count towards that.

Tore



From leslien at arin.net  Wed Jan 29 22:01:50 2014
From: leslien at arin.net (Leslie Nobile)
Date: Wed, 29 Jan 2014 22:01:50 +0000
Subject: FW: Updated ARIN allocation information
In-Reply-To: 
Message-ID: 


ARIN would like to share two items of information that may be of interest to the community.

First, ARIN has recently begun to issue address space from its last contiguous /8, 104.0.0.0 /8.  The minimum allocation size for this /8 will be a /24.  You may wish to adjust any filters you have in place accordingly.

More information on the IP address space administered by ARIN can be found on our web site at:

https://www.arin.net/knowledge/ip_blocks.html

Additionally, ARIN has placed  23.128.0.0/10 in its reserves in accordance with the policy "Dedicated IPv4 block to facilitate IPv6 Deployment" (NRPM 4.10).  There have been no allocations made from this block as of yet, however, once we do begin issuing from this block, the minimum allocation size for this /10 will be a /28 and the maximum allocation size will be a /24.  You may wish to adjust any filters you have in place accordingly.

More information on this policy can be found on our website here:

https://www.arin.net/policy/nrpm.html#four10

Regards,
Leslie Nobile
Director, Registration Services
American Registry for Internet Numbers (ARIN)










From sethm at rollernet.us  Wed Jan 29 22:16:43 2014
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 29 Jan 2014 14:16:43 -0800
Subject: FW: Updated ARIN allocation information
In-Reply-To: 
References: 
Message-ID: <52E97DCB.5090803@rollernet.us>

On 1/29/14, 14:01, Leslie Nobile wrote:
> Additionally, ARIN has placed  23.128.0.0/10 in its reserves in accordance with the policy "Dedicated IPv4 block to facilitate IPv6 Deployment" (NRPM 4.10).  There have been no allocations made from this block as of yet, however, once we do begin issuing from this block, the minimum allocation size for this /10 will be a /28 and the maximum allocation size will be a /24.  You may wish to adjust any filters you have in place accordingly.


I know ARIN doesn't care about routability and all that, but good luck 
with those /28s.

~Seth


From randy at psg.com  Wed Jan 29 22:19:05 2014
From: randy at psg.com (Randy Bush)
Date: Thu, 30 Jan 2014 07:19:05 +0900
Subject: Fw: ipv6 newbie question
In-Reply-To: <1391016925.68774.YahooMailNeo@web140703.mail.bf1.yahoo.com>
References: <1391011638.2024.YahooMailNeo@web140705.mail.bf1.yahoo.com>
 <1391016925.68774.YahooMailNeo@web140703.mail.bf1.yahoo.com>
Message-ID: 

rfc 6164


From kamtha at ak-labs.net  Wed Jan 29 23:37:35 2014
From: kamtha at ak-labs.net (Carlos Kamtha)
Date: Wed, 29 Jan 2014 18:37:35 -0500
Subject: looking for good AU dedicated server providers..
Message-ID: <20140129233735.GA22861@ak-labs.net>

Hello, 

Was wondering if anyone could share any experiences.              

Prerequsites:

a.) reliable upstream provider with established peering. 

b.) relatively acessible support staff. 

c.) FreeBSD preferring but CentOS is ok...


any help would greatly be appreciated. 


Cheers, 
Carlos. 


From mpalmer at hezmatt.org  Thu Jan 30 02:52:31 2014
From: mpalmer at hezmatt.org (Matt Palmer)
Date: Thu, 30 Jan 2014 13:52:31 +1100
Subject: looking for good AU dedicated server providers..
In-Reply-To: <20140129233735.GA22861@ak-labs.net>
References: <20140129233735.GA22861@ak-labs.net>
Message-ID: <20140130025231.GA7209@hezmatt.org>

On Wed, Jan 29, 2014 at 06:37:35PM -0500, Carlos Kamtha wrote:
> b.) relatively acessible support staff. 

Accessable for what?  Hardware maintenance, or full-service outsourced
sysadmin assistance?  What timezones, and what communication method?

(Also, there's AusNOG if you want to get local opinions)



From betty at newnog.org  Thu Jan 30 03:17:17 2014
From: betty at newnog.org (Betty Burke )
Date: Wed, 29 Jan 2014 22:17:17 -0500
Subject: [NANOG-announce] NANOG On The Road - San Diego
Message-ID: 

Colleagues:

In partnership, the American Registry for Internet Numbers (ARIN) and the
North American Network Operators Group (NANOG) will bring ARIN+NANOG on the
Road to San Diego, CA on Tuesday, February 25, 2014.  The one day event
will be held at the Handerly Hotel & Resort.

Please pass along this information to those who would benefit from
attending a free event featuring educational sessions, great discussions,
and networking opportunities!

Morning sessions will get attendees up to speed on Internet number resource
management, ARIN technical services, current policy discussions and more.
Afternoon sessions will feature NANOG Tutorials on Network Security, IPv6,
Traceroutes, BGB, including an update on the NANOG Best Current Operational
Practice (BCOP) project.

Complete information and meeting links are available on the NANOG
website
.

Should you have any questions, please feel free to send them to
nanog-support at nanog.org.

Sincerely,
Betty

-- 
Betty Burke
NANOG Executive Director
48377 Fremont Boulevard, Suite 117
Fremont, CA 94538
Tel: +1 510 492 4030
-------------- next part --------------
_______________________________________________
NANOG-announce mailing list
NANOG-announce at mailman.nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce

From morrowc.lists at gmail.com  Thu Jan 30 03:22:32 2014
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 29 Jan 2014 22:22:32 -0500
Subject: FW: Updated ARIN allocation information
In-Reply-To: <52E97DCB.5090803@rollernet.us>
References:  <52E97DCB.5090803@rollernet.us>
Message-ID: 

On Wed, Jan 29, 2014 at 5:16 PM, Seth Mattinen  wrote:
> On 1/29/14, 14:01, Leslie Nobile wrote:
>>
>> Additionally, ARIN has placed  23.128.0.0/10 in its reserves in accordance
>> with the policy "Dedicated IPv4 block to facilitate IPv6 Deployment" (NRPM
>> 4.10).  There have been no allocations made from this block as of yet,
>> however, once we do begin issuing from this block, the minimum allocation
>> size for this /10 will be a /28 and the maximum allocation size will be a
>> /24.  You may wish to adjust any filters you have in place accordingly.
>
>
>
> I know ARIN doesn't care about routability and all that, but good luck with
> those /28s.

maybe these weren't meant to be used outside the local ASN? :)
I do wonder though what the purpose of this block is? If it's to be
used inside the local ASN (as seems to be indicated based upon minimum
allocation sizes) then why not use the IETF marked 100.64/10 space
instead? Global-uniqueness? ok, sure...

There will need to be popcorn though, for this event.

-chris


From morrowc.lists at gmail.com  Thu Jan 30 03:33:17 2014
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 29 Jan 2014 22:33:17 -0500
Subject: BGP multihoming
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, Jan 29, 2014 at 3:45 PM, Michael Braun (michbrau)
 wrote:
> Does
> that cause any problems where address space is being advertised from a
> non-assigned AS?

how do you mean 'non-assigned' ?
perhaps you have an example in the routing system today you could point at?


From Nanda at aryaka.com  Wed Jan 29 23:42:58 2014
From: Nanda at aryaka.com (Nanda Kumar)
Date: Wed, 29 Jan 2014 23:42:58 +0000
Subject: looking for good AU dedicated server providers..
In-Reply-To: <20140129233735.GA22861@ak-labs.net>
References: <20140129233735.GA22861@ak-labs.net>
Message-ID: <828E88ECFD01984AB7E0ED5636283551243C4E2B@BLRMBX1.corp.aryaka.com>

Carlos, 

Is this for Wan connectivity between where you're and Australia?

Best,
Nanda 



-----Original Message-----
From: Carlos Kamtha [mailto:kamtha at ak-labs.net] 
Sent: Thursday, January 30, 2014 5:08 AM
To: nanog at nanog.org
Subject: looking for good AU dedicated server providers..

Hello, 

Was wondering if anyone could share any experiences.              

Prerequsites:

a.) reliable upstream provider with established peering. 

b.) relatively acessible support staff. 

c.) FreeBSD preferring but CentOS is ok...


any help would greatly be appreciated. 


Cheers, 
Carlos. 



From marka at isc.org  Thu Jan 30 05:17:11 2014
From: marka at isc.org (Mark Andrews)
Date: Thu, 30 Jan 2014 16:17:11 +1100
Subject: FW: Updated ARIN allocation information
In-Reply-To: Your message of "Wed, 29 Jan 2014 22:22:32 -0500."
 
References:  <52E97DCB.5090803@rollernet.us>
 
Message-ID: <20140130051711.986ACE0C64B@rock.dv.isc.org>


In message 
, Christopher Morrow writes:
> On Wed, Jan 29, 2014 at 5:16 PM, Seth Mattinen  wrote:
> > On 1/29/14, 14:01, Leslie Nobile wrote:
> >>
> >> Additionally, ARIN has placed  23.128.0.0/10 in its reserves in accordance
> >> with the policy "Dedicated IPv4 block to facilitate IPv6 Deployment" (NRPM
> >> 4.10).  There have been no allocations made from this block as of yet,
> >> however, once we do begin issuing from this block, the minimum allocation
> >> size for this /10 will be a /28 and the maximum allocation size will be a
> >> /24.  You may wish to adjust any filters you have in place accordingly.
> >
> >
> >
> > I know ARIN doesn't care about routability and all that, but good luck with
> > those /28s.
> 
> maybe these weren't meant to be used outside the local ASN? :)
> I do wonder though what the purpose of this block is? If it's to be
> used inside the local ASN (as seems to be indicated based upon minimum
> allocation sizes) then why not use the IETF marked 100.64/10 space
> instead? Global-uniqueness? ok, sure...
> 
> There will need to be popcorn though, for this event.
> 
> -chris

Or you could just accept that there needs to be more routing slots
as the number of businesses on the net increases.  I can see some
interesting anti-cartel law suits happening if ISP's refuse to
accept /28's from this block.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From mark.tinka at seacom.mu  Thu Jan 30 07:28:22 2014
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Thu, 30 Jan 2014 09:28:22 +0200
Subject: FW: Updated ARIN allocation information
In-Reply-To: <20140130051711.986ACE0C64B@rock.dv.isc.org>
References: 
 
 <20140130051711.986ACE0C64B@rock.dv.isc.org>
Message-ID: <201401300928.22429.mark.tinka@seacom.mu>

On Thursday, January 30, 2014 07:17:11 AM Mark Andrews 
wrote:

> Or you could just accept that there needs to be more
> routing slots as the number of businesses on the net
> increases.  I can see some interesting anti-cartel law
> suits happening if ISP's refuse to accept /28's from
> this block.

I understand the reasoning behind RIR's (and the community 
that supports them) not caring about routability, but if 
there is a lesson we can learn from IPv4, it is that perhaps 
that divorce is not entirely practical.

It might be a good idea to think about how RIR's (and the 
community that supports them) "could care" about 
routability, so we don't end up in the same situation with 
IPv6, whenever that will be, or if any of us will be alive. 
It's definitely too late to do anything about it for IPv4, 
which means there will be even more lessons to learn in the 
coming months/years...

I know it is a moving target (advances in FIB memory is not 
something an RIR [and the community that supports them] can 
depend on, for example), but I also don't think it makes 
complete sense for the RIR's (and the community that 
supports them) to be in a utopia about this - that it will 
all "just sort itself out".

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: 

From streiner at cluebyfour.org  Thu Jan 30 10:19:36 2014
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Thu, 30 Jan 2014 05:19:36 -0500 (EST)
Subject: FW: Updated ARIN allocation information
In-Reply-To: <20140130051711.986ACE0C64B@rock.dv.isc.org>
References:  <52E97DCB.5090803@rollernet.us>
 
 <20140130051711.986ACE0C64B@rock.dv.isc.org>
Message-ID: 

On Thu, 30 Jan 2014, Mark Andrews wrote:

> Or you could just accept that there needs to be more routing slots
> as the number of businesses on the net increases.  I can see some
> interesting anti-cartel law suits happening if ISP's refuse to
> accept /28's from this block.

In the worst case, this would add another 262,144 routes (/10 fully 
assigned, and all assignments are /28s) to the global IPv4 route view. 
Realistically, the number will be a good bit smaller than that, but only 
time will tell for sure exactly how much smaller.  Wash/rinse/repeat for 
any other RIR that adopts a similar policy.

jms


From kamtha at ak-labs.net  Thu Jan 30 13:49:53 2014
From: kamtha at ak-labs.net (Carlos Kamtha)
Date: Thu, 30 Jan 2014 08:49:53 -0500
Subject: looking for good AU dedicated server providers..
In-Reply-To: <828E88ECFD01984AB7E0ED5636283551243C4E2B@BLRMBX1.corp.aryaka.com>
References: <20140129233735.GA22861@ak-labs.net>
 <828E88ECFD01984AB7E0ED5636283551243C4E2B@BLRMBX1.corp.aryaka.com>
Message-ID: <20140130134953.GB22861@ak-labs.net>


well sorta. 

The box will provide services to clients. so it has to be robust and
free from bandwidth limitations.

On Wed, Jan 29, 2014 at 11:42:58PM +0000, Nanda Kumar wrote:
> Carlos, 
> 
> Is this for Wan connectivity between where you're and Australia?
> 
> Best,
> Nanda 


From kamtha at ak-labs.net  Thu Jan 30 13:57:23 2014
From: kamtha at ak-labs.net (Carlos Kamtha)
Date: Thu, 30 Jan 2014 08:57:23 -0500
Subject: looking for good AU dedicated server providers..
In-Reply-To: <20140130025231.GA7209@hezmatt.org>
References: <20140129233735.GA22861@ak-labs.net>
 <20140130025231.GA7209@hezmatt.org>
Message-ID: <20140130135723.GD22861@ak-labs.net>

On Thu, Jan 30, 2014 at 01:52:31PM +1100, Matt Palmer wrote:
> On Wed, Jan 29, 2014 at 06:37:35PM -0500, Carlos Kamtha wrote:
> > b.) relatively acessible support staff. 
> 
> Accessable for what?  Hardware maintenance, or full-service outsourced
> sysadmin assistance?  What timezones, and what communication method?

Remote hands in the event that there is no serial console available
over the network. hardware maint. for sure. 

timezones dont matter but the box *must* be based in AU. email  
comm is fine as long as someone responds within a reasonable
timeframe.. 

> 
> (Also, there's AusNOG if you want to get local opinions)
> 

thanks :)


From tore at fud.no  Thu Jan 30 14:55:57 2014
From: tore at fud.no (Tore Anderson)
Date: Thu, 30 Jan 2014 15:55:57 +0100
Subject: FW: Updated ARIN allocation information
In-Reply-To: 
References:  <52E97DCB.5090803@rollernet.us>
 
 <20140130051711.986ACE0C64B@rock.dv.isc.org>
 
Message-ID: <52EA67FD.7080805@fud.no>

* Justin M. Streiner

> In the worst case, this would add another 262,144 routes (/10 fully
> assigned, and all assignments are /28s) to the global IPv4 route view.
> Realistically, the number will be a good bit smaller than that, but only
> time will tell for sure exactly how much smaller.  Wash/rinse/repeat for
> any other RIR that adopts a similar policy.

I wouldn't worry if I were you. I'll wager you $100 that pretty much all
of the people requesting a block from ARIN under this policy (or any
other) is going to go for a /24 (or larger). There is some precedent;
RIPE policy has not mandated a minimum assignment size for IPv4 PI, at
least not in the last decade, yet the NCC has made almost no assignments
smaller than /24.

Tore


From owen at delong.com  Thu Jan 30 15:34:56 2014
From: owen at delong.com (Owen DeLong)
Date: Thu, 30 Jan 2014 10:34:56 -0500
Subject: Updated ARIN allocation information
In-Reply-To: 
References:  <52E97DCB.5090803@rollernet.us>
 
Message-ID: <1A2E659E-DDC9-492B-960E-4E67CB0BA260@delong.com>

As the author of the policy which set this block aside, I speak only from my perspective as the author and not officially on behalf of ARIN or the AC in any way:

The intent is to provide very small allocations/assignments for organizations which need some amount of IPv4 for a best-effort to facilitate networking after IPv4 general runout.

While I recognize that organizations may or may not be able to get these routes accepted, the reality is that IPv4 runout is going to create interesting routing scenarios and other problems. I figured having a predictable prefix where people could at least make a best effort was better than simply allowing chaos through the entire address space.

Indeed, much popcorn will be required. That is why my networks are all IPv6 capable already.

Owen


> On Jan 29, 2014, at 10:22 PM, Christopher Morrow  wrote:
> 
>> On Wed, Jan 29, 2014 at 5:16 PM, Seth Mattinen  wrote:
>>> On 1/29/14, 14:01, Leslie Nobile wrote:
>>> 
>>> Additionally, ARIN has placed  23.128.0.0/10 in its reserves in accordance
>>> with the policy "Dedicated IPv4 block to facilitate IPv6 Deployment" (NRPM
>>> 4.10).  There have been no allocations made from this block as of yet,
>>> however, once we do begin issuing from this block, the minimum allocation
>>> size for this /10 will be a /28 and the maximum allocation size will be a
>>> /24.  You may wish to adjust any filters you have in place accordingly.
>> 
>> 
>> 
>> I know ARIN doesn't care about routability and all that, but good luck with
>> those /28s.
> 
> maybe these weren't meant to be used outside the local ASN? :)
> I do wonder though what the purpose of this block is? If it's to be
> used inside the local ASN (as seems to be indicated based upon minimum
> allocation sizes) then why not use the IETF marked 100.64/10 space
> instead? Global-uniqueness? ok, sure...
> 
> There will need to be popcorn though, for this event.
> 
> -chris


From joelja at bogus.com  Thu Jan 30 15:46:08 2014
From: joelja at bogus.com (joel jaeggli)
Date: Thu, 30 Jan 2014 07:46:08 -0800
Subject: Terremark Miami
In-Reply-To: <946878424.600361.1390958948430.JavaMail.root@snappytelecom.net>
References: 
 <228610997.594393.1390866209195.JavaMail.root@snappytelecom.net>
 
 <946878424.600361.1390958948430.JavaMail.root@snappytelecom.net>
Message-ID: <52EA73C0.9030204@bogus.com>

On 1/28/14, 5:29 PM, Faisal Imtiaz wrote:
> So essentially, you are looking for a 'direct' x-connect to AWS ?
> and not wanting to go thru a peering fabric or any other network ?

just as an aside amazon peer routes are in my experience regional so if
the goal is to offload traffic in miami bound for prineville you may not
get the oregon DC routes from an east coast peer.

A direct connect partner probably has no such considerations.

> 
> Regards
> 
> Faisal Imtiaz
> Snappy Internet & Telecom
> 7266 SW 48 Street
> Miami, FL 33155
> Tel: 305 663 5518 x 232
> 
> Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net 
> 
> ----- Original Message -----
>> From: "Warren Bailey" 
>> To: "Faisal Imtiaz" 
>> Cc: nanog at nanog.org
>> Sent: Monday, January 27, 2014 10:55:08 PM
>> Subject: Re: Terremark Miami
>>
>> We?re looking at potential connectivity need of 100mbps from a customer
>> colocated in NAP of America?s in Miami to some stuff living in AWS land.
>> We weren?t particularly thrilled about the aspect of a GRE tunnel over the
>> internet (our AWS stuff does some data manipulation) and wanted to use the
>> Amazon Direct Connect functionality. It seems like they do this direct
>> connect as select peering points, and there were no options for anything
>> in Miami. It may just be easier to buy something off of the provider to
>> run the traffic over to a colo with AWS connectivity. I?m really just
>> looking for sexy ways to avoid the internet as a transit route for this
>> data (the data doesn?t have anything to do with the internet).
>>
>> On 1/27/14, 3:43 PM, "Faisal Imtiaz"  wrote:
>>
>>> What kind of issue are you running into ?
>>>
>>> I believe AWS is present on the NOTA/NAP peering fabric, and as such if
>>> one was to get access to the NOTA/NAP peering fabric they should be able
>>> to peer / pass traffic directly to them.
>>>
>>> Regards.
>>>
>>> Faisal Imtiaz
>>> Snappy Internet & Telecom
>>> 7266 SW 48 Street
>>> Miami, FL 33155
>>> Tel: 305 663 5518 x 232
>>>
>>> Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net
>>>
>>> ----- Original Message -----
>>>> From: "Warren Bailey" 
>>>> To: nanog at nanog.org
>>>> Sent: Monday, January 27, 2014 6:14:30 PM
>>>> Subject: Terremark Miami
>>>>
>>>> Anyone out there listening have experience getting traffic originating
>>>> at NAP
>>>> of Americas in Miami to AWS in a non-suck (internet) manner? I know AWS
>>>> has
>>>> direct connect, but they are mum about options in MIA.
>>>>
>>>> Thanks in advance!
>>>> //warren
>>>>
>>
>>
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: OpenPGP digital signature
URL: 

From streiner at cluebyfour.org  Thu Jan 30 12:28:47 2014
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Thu, 30 Jan 2014 07:28:47 -0500 (EST)
Subject: FW: Updated ARIN allocation information
In-Reply-To: <52EA67FD.7080805@fud.no>
References:  <52E97DCB.5090803@rollernet.us>
 
 <20140130051711.986ACE0C64B@rock.dv.isc.org>
 
 <52EA67FD.7080805@fud.no>
Message-ID: 

On Thu, 30 Jan 2014, Tore Anderson wrote:

> I wouldn't worry if I were you. I'll wager you $100 that pretty much all
> of the people requesting a block from ARIN under this policy (or any
> other) is going to go for a /24 (or larger). There is some precedent;
> RIPE policy has not mandated a minimum assignment size for IPv4 PI, at
> least not in the last decade, yet the NCC has made almost no assignments
> smaller than /24.

Depends on the burn rate on that /10...

jms


From pr at isprime.com  Thu Jan 30 15:55:55 2014
From: pr at isprime.com (Phil Rosenthal)
Date: Thu, 30 Jan 2014 10:55:55 -0500
Subject: Updated ARIN allocation information
In-Reply-To: 
References:  <52E97DCB.5090803@rollernet.us>
 
Message-ID: 


On Jan 29, 2014, at 10:22 PM, Christopher Morrow  wrote:

> maybe these weren't meant to be used outside the local ASN? :)
> I do wonder though what the purpose of this block is? If it's to be
> used inside the local ASN (as seems to be indicated based upon minimum
> allocation sizes) then why not use the IETF marked 100.64/10 space
> instead? Global-uniqueness? ok, sure...

Seems like the obvious use case is for 6to4 NAT gateways, which would mean that global reachability would be expected.

-Phil

From m4rtntns at gmail.com  Thu Jan 30 16:51:59 2014
From: m4rtntns at gmail.com (Martin T)
Date: Thu, 30 Jan 2014 18:51:59 +0200
Subject: Are specific "route" objects in RIR databases needed?
Message-ID: 

Hi,

for example there is a small company with /22 IPv4 allocation from
RIPE in European region. This company is dual-homed and would like to
announce 4x /24 prefixes to both ISPs. Both ISP's update their
prefix-lists automatically based on records in RIPE database. For
example Level3 uses this practice at least in Europe. If this small
company creates a "route" object for it's /22 allocation, then is it
enough? Theoretically this would cover all four /24 networks. Or in
which situation it is useful/needed to have "route" object for each
/24 prefix?



regards,
Martin


From job.snijders at hibernianetworks.com  Thu Jan 30 17:01:30 2014
From: job.snijders at hibernianetworks.com (Job Snijders)
Date: Thu, 30 Jan 2014 18:01:30 +0100
Subject: Are specific "route" objects in RIR databases needed?
In-Reply-To: 
References: 
Message-ID: <20140130170130.GO427@Eleanor.local>

On Thu, Jan 30, 2014 at 06:51:59PM +0200, Martin T wrote:

> for example there is a small company with /22 IPv4 allocation from
> RIPE in European region. This company is dual-homed and would like to
> announce 4x /24 prefixes to both ISPs. Both ISP's update their
> prefix-lists automatically based on records in RIPE database. For
> example Level3 uses this practice at least in Europe. If this small
> company creates a "route" object for it's /22 allocation, then is it
> enough? Theoretically this would cover all four /24 networks. Or in
> which situation it is useful/needed to have "route" object for each
> /24 prefix?

You should create a route object for each route that you announce, if
you announce 4 x /24 you should create a route: object for each /24. 

Some providers will create filters solely based on existing route
objects, others will create filters based on all route objects, AND 
allow up to a /24 regardless. I would err to the safe side. 

Kind regards,

Job

ps. Can you please send 20 dollarcent per /24 to my paypal account
(job at instituut.net) with the reference "deaggregation fee"?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 873 bytes
Desc: not available
URL: 

From tore at fud.no  Thu Jan 30 17:13:03 2014
From: tore at fud.no (Tore Anderson)
Date: Thu, 30 Jan 2014 18:13:03 +0100
Subject: Are specific "route" objects in RIR databases needed?
In-Reply-To: <20140130170130.GO427@Eleanor.local>
References: 
 <20140130170130.GO427@Eleanor.local>
Message-ID: <52EA881F.8090405@fud.no>

* Job Snijders

> On Thu, Jan 30, 2014 at 06:51:59PM +0200, Martin T wrote:
> 
>> for example there is a small company with /22 IPv4 allocation from
>> RIPE in European region. This company is dual-homed and would like to
>> announce 4x /24 prefixes to both ISPs. Both ISP's update their
>> prefix-lists automatically based on records in RIPE database. For
>> example Level3 uses this practice at least in Europe. If this small
>> company creates a "route" object for it's /22 allocation, then is it
>> enough? Theoretically this would cover all four /24 networks. Or in
>> which situation it is useful/needed to have "route" object for each
>> /24 prefix?
> 
> You should create a route object for each route that you announce, if
> you announce 4 x /24 you should create a route: object for each /24. 

+1

> ps. Can you please send 20 dollarcent per /24 to my paypal account
> (job at instituut.net) with the reference "deaggregation fee"?

Indeed.

Martin, I'd suggest announcing the 4 x /24s to each ISP tagged with the
no-export community in order to achieve whatever you are trying to do,
*in addition* to the covering /22. That way you're not polluting Job,
my, and everyone else's routing tables more than necessary, only your
own ISPs', but then again you're actually paying them for the privilege.

Tore


From robert at mckay.com  Thu Jan 30 17:13:20 2014
From: robert at mckay.com (Robert McKay)
Date: Thu, 30 Jan 2014 17:13:20 +0000
Subject: FW: Updated ARIN allocation information
In-Reply-To: <52E97DCB.5090803@rollernet.us>
References:  <52E97DCB.5090803@rollernet.us>
Message-ID: <76d55c1b6c050b3ca19f52a1e4d7af1c@webmail.mckay.com>

On Wed, 29 Jan 2014 14:16:43 -0800, Seth Mattinen wrote:
> On 1/29/14, 14:01, Leslie Nobile wrote:
>> Additionally, ARIN has placed  23.128.0.0/10 in its reserves in 
>> accordance with the policy "Dedicated IPv4 block to facilitate IPv6 
>> Deployment" (NRPM 4.10).  There have been no allocations made from 
>> this block as of yet, however, once we do begin issuing from this 
>> block, the minimum allocation size for this /10 will be a /28 and the 
>> maximum allocation size will be a /24.  You may wish to adjust any 
>> filters you have in place accordingly.
>
>
> I know ARIN doesn't care about routability and all that, but good
> luck with those /28s.

"This block will be subject to a minimum size allocation of /28 and a 
maximum size allocation of /24. ARIN should use sparse allocation when 
possible within that /10 block."

Thanks for the initial sparse allocation for some time the /28 will be 
the only tennant of the covering /24 so they will be able to advertise 
the /24 aggregate as well as the /28. In time the reachability of the 
/28s should improve and if some other /28 is allocated inside an already 
populated /24 then as long as they can both see each other's /28s they 
can still both advertise the /24 aggregate - or perhaps agree for a 
common transit provider to do it. As acceptance of the /28s improves 
further and less traffic flows to the aggregates, perhaps large 
providers would agree to replace the customer /24 aggregates with a 
single /10 aggregate to help out the (hopefully few) stragglers who 
still filter /28s.

-Rob


From mpalmer at hezmatt.org  Thu Jan 30 19:46:47 2014
From: mpalmer at hezmatt.org (Matt Palmer)
Date: Fri, 31 Jan 2014 06:46:47 +1100
Subject: looking for good AU dedicated server providers..
In-Reply-To: <20140130134953.GB22861@ak-labs.net>
References: <20140129233735.GA22861@ak-labs.net>
 <828E88ECFD01984AB7E0ED5636283551243C4E2B@BLRMBX1.corp.aryaka.com>
 <20140130134953.GB22861@ak-labs.net>
Message-ID: <20140130194647.GC7209@hezmatt.org>

On Thu, Jan 30, 2014 at 08:49:53AM -0500, Carlos Kamtha wrote:
> The box will provide services to clients. so it has to be robust and
> free from bandwidth limitations.

That's going to get expensive.  .au bandwidth is a touch on the pricey side.

- Matt



From source_route at yahoo.com  Thu Jan 30 19:48:01 2014
From: source_route at yahoo.com (Philip Lavine)
Date: Thu, 30 Jan 2014 11:48:01 -0800 (PST)
Subject: Fw: ipv6 newbie question
In-Reply-To: 
References: <1391011638.2024.YahooMailNeo@web140705.mail.bf1.yahoo.com>	<1391016925.68774.YahooMailNeo@web140703.mail.bf1.yahoo.com>
 
Message-ID: <1391111281.80256.YahooMailNeo@web140704.mail.bf1.yahoo.com>

I guess as a follow up question. Do you use the EUI-64 address as the Default gateway or the link local.



On Wednesday, January 29, 2014 2:19 PM, Randy Bush  wrote:
  
rfc 6164

From mark at exonetric.com  Thu Jan 30 19:50:12 2014
From: mark at exonetric.com (Mark Blackman)
Date: Thu, 30 Jan 2014 19:50:12 +0000
Subject: looking for good AU dedicated server providers..
In-Reply-To: <20140129233735.GA22861@ak-labs.net>
References: <20140129233735.GA22861@ak-labs.net>
Message-ID: 

On 29 Jan 2014, at 23:37, Carlos Kamtha  wrote:

> Hello, 
> 
> Was wondering if anyone could share any experiences.              
> 
> Prerequsites:
> 
> a.) reliable upstream provider with established peering. 
> 
> b.) relatively acessible support staff. 
> 
> c.) FreeBSD preferring but CentOS is ok...
> 
> 
> any help would greatly be appreciated. 
> 
> 
> Cheers, 
> Carlos. 
> 

We?ve got a client who is happily using Intervolve.




From Nanda at aryaka.com  Thu Jan 30 19:52:01 2014
From: Nanda at aryaka.com (Nanda Kumar)
Date: Thu, 30 Jan 2014 19:52:01 +0000
Subject: looking for good AU dedicated server providers..
In-Reply-To: <20140130134953.GB22861@ak-labs.net>
References: <20140129233735.GA22861@ak-labs.net>
 <828E88ECFD01984AB7E0ED5636283551243C4E2B@BLRMBX1.corp.aryaka.com>
 <20140130134953.GB22861@ak-labs.net>
Message-ID: <828E88ECFD01984AB7E0ED5636283551243C596A@BLRMBX1.corp.aryaka.com>

Carlos,

Take a look at this: www.aryaka.com it's a managed services with private links. 

I can give you more details if this is what you're looking for. 

Best,
Nanda

-----Original Message-----
From: Carlos Kamtha [mailto:kamtha at ak-labs.net] 
Sent: Thursday, January 30, 2014 7:20 PM
To: Nanda Kumar
Cc: nanog at nanog.org
Subject: Re: looking for good AU dedicated server providers..


well sorta. 

The box will provide services to clients. so it has to be robust and free from bandwidth limitations.

On Wed, Jan 29, 2014 at 11:42:58PM +0000, Nanda Kumar wrote:
> Carlos,
> 
> Is this for Wan connectivity between where you're and Australia?
> 
> Best,
> Nanda


From richo at psych0tik.net  Thu Jan 30 19:55:09 2014
From: richo at psych0tik.net (richo)
Date: Thu, 30 Jan 2014 11:55:09 -0800
Subject: looking for good AU dedicated server providers..
In-Reply-To: 
References: <20140129233735.GA22861@ak-labs.net>
 
Message-ID: <20140130195509.GA67269@elektra.local>

On 30/01/14 19:50 +0000, Mark Blackman wrote:
>
>We?ve got a client who is happily using Intervolve.

I used to have 2 racks with intervolve. I'd use them again.


From bill at herrin.us  Thu Jan 30 20:25:38 2014
From: bill at herrin.us (William Herrin)
Date: Thu, 30 Jan 2014 15:25:38 -0500
Subject: FW: Updated ARIN allocation information
In-Reply-To: 
References:  <52E97DCB.5090803@rollernet.us>
 
Message-ID: 

On Wed, Jan 29, 2014 at 10:22 PM, Christopher Morrow
 wrote:
> On Wed, Jan 29, 2014 at 5:16 PM, Seth Mattinen  wrote:
>> On 1/29/14, 14:01, Leslie Nobile wrote:
>>>
>>> Additionally, ARIN has placed  23.128.0.0/10 in its reserves in accordance
>>> with the policy "Dedicated IPv4 block to facilitate IPv6 Deployment" (NRPM
>>> 4.10).
>>
>> I know ARIN doesn't care about routability and all that, but good luck with
>> those /28s.
>
> I do wonder though what the purpose of this block is?

https://www.arin.net/policy/nrpm.html#four10

"4.10 Dedicated IPv4 block to facilitate IPv6 Deployment

When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous
/10 IPv4 block will be set aside and dedicated to facilitate IPv6
deployment. Allocations and assignments from this block must be
justified by immediate IPv6 deployment requirements. Examples of such
needs include: IPv4 addresses for key dual stack DNS servers, and
NAT-PT or NAT464 translators."

This was set aside just in case the IPv4 market doesn't pan out and
you can no longer get BGPable /24's. The presumption is that if we hit
the kind of crunch this block is reserved for, convincing folks to
route /28's will be the least of our problems.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: 
Falls Church, VA 22042-3004


From m4rtntns at gmail.com  Thu Jan 30 21:45:17 2014
From: m4rtntns at gmail.com (Martin T)
Date: Thu, 30 Jan 2014 21:45:17 +0000
Subject: Are specific "route" objects in RIR databases needed?
In-Reply-To: <52EA881F.8090405@fud.no>
References: 
 <20140130170130.GO427@Eleanor.local> <52EA881F.8090405@fud.no>
Message-ID: 

Job, Tore: ok, I see. So "route" object in RIR routing registry database
for each announced prefix is needed only because some ISPs create filters
exactly the size of the "route" object in database? So for example if there
is a "route" object for 192.0.2.0/24 in RIR database, then ISP-A might
create a following strict prefix-filter entry:

policy-options {
    policy-statement EXAMPLE {
        term prefixes {
            from {
                route-filter 192.0.2.0/24 exact;
            }
            then next policy;
        }
        then reject;
    }
}

On the other hand, ISP-B might create loose filter based on the same
"route" object like this:

policy-options {
    policy-statement EXAMPLE {
        term prefixes {
            from {
                route-filter 192.0.2.0/24 upto /32;
            }
            then next policy;
        }
        then reject;
    }
}


PS: this is a theoretical question :) I'm also for keeping the BGP table as
short as possible.


regards,
Martin

On Thu, Jan 30, 2014 at 5:13 PM, Tore Anderson  wrote:

> * Job Snijders
>
> > On Thu, Jan 30, 2014 at 06:51:59PM +0200, Martin T wrote:
> >
> >> for example there is a small company with /22 IPv4 allocation from
> >> RIPE in European region. This company is dual-homed and would like to
> >> announce 4x /24 prefixes to both ISPs. Both ISP's update their
> >> prefix-lists automatically based on records in RIPE database. For
> >> example Level3 uses this practice at least in Europe. If this small
> >> company creates a "route" object for it's /22 allocation, then is it
> >> enough? Theoretically this would cover all four /24 networks. Or in
> >> which situation it is useful/needed to have "route" object for each
> >> /24 prefix?
> >
> > You should create a route object for each route that you announce, if
> > you announce 4 x /24 you should create a route: object for each /24.
>
> +1
>
> > ps. Can you please send 20 dollarcent per /24 to my paypal account
> > (job at instituut.net) with the reference "deaggregation fee"?
>
> Indeed.
>
> Martin, I'd suggest announcing the 4 x /24s to each ISP tagged with the
> no-export community in order to achieve whatever you are trying to do,
> *in addition* to the covering /22. That way you're not polluting Job,
> my, and everyone else's routing tables more than necessary, only your
> own ISPs', but then again you're actually paying them for the privilege.
>
> Tore
>

From jared at puck.nether.net  Thu Jan 30 23:05:20 2014
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 30 Jan 2014 18:05:20 -0500
Subject: Updated ARIN allocation information
In-Reply-To: <20140130051711.986ACE0C64B@rock.dv.isc.org>
References:  <52E97DCB.5090803@rollernet.us>
 
 <20140130051711.986ACE0C64B@rock.dv.isc.org>
Message-ID: <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net>


On Jan 30, 2014, at 12:17 AM, Mark Andrews  wrote:

> Or you could just accept that there needs to be more routing slots
> as the number of businesses on the net increases.  I can see some
> interesting anti-cartel law suits happening if ISP's refuse to
> accept /28's from this block.

i suspect it will be more sean doran style 'pay me for your slot'.


From randy at psg.com  Thu Jan 30 23:07:05 2014
From: randy at psg.com (Randy Bush)
Date: Fri, 31 Jan 2014 08:07:05 +0900
Subject: Fw: ipv6 newbie question
In-Reply-To: <1391111281.80256.YahooMailNeo@web140704.mail.bf1.yahoo.com>
References: <1391011638.2024.YahooMailNeo@web140705.mail.bf1.yahoo.com>
 <1391016925.68774.YahooMailNeo@web140703.mail.bf1.yahoo.com>
 
 <1391111281.80256.YahooMailNeo@web140704.mail.bf1.yahoo.com>
Message-ID: 

> I guess as a follow up question. Do you use the EUI-64 address as the
> Default gateway or the link local.
>> rfc 6164

what's link local?  does it do vrrp?  :)

randy


From marka at isc.org  Thu Jan 30 23:58:58 2014
From: marka at isc.org (Mark Andrews)
Date: Fri, 31 Jan 2014 10:58:58 +1100
Subject: Updated ARIN allocation information
In-Reply-To: Your message of "Thu, 30 Jan 2014 18:05:20 -0500."
 <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net>
References:  <52E97DCB.5090803@rollernet.us>
 
 <20140130051711.986ACE0C64B@rock.dv.isc.org>
 <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net>
Message-ID: <20140130235858.3ADEAE14FF7@rock.dv.isc.org>


In message <384BF687-AD8A-4919-9EAB-723A09854E0D at puck.nether.net>, Jared Mauch 
writes:
> 
> On Jan 30, 2014, at 12:17 AM, Mark Andrews  wrote:
> 
> > Or you could just accept that there needs to be more routing slots
> > as the number of businesses on the net increases.  I can see some
> > interesting anti-cartel law suits happening if ISP's refuse to
> > accept /28's from this block.
> 
> i suspect it will be more sean doran style 'pay me for your slot'.

A /8 slot costs as much as a /28 slot to hold process etc.  A routing
slot is a routing slot.  The *only* reason this isn't a legal problems
at the moment is people can still get /24s.  The moment /24's aren't
readily available and they are forced into using this range anyone
filtering on /24 in this range is leaving themselves open to lawsuits.

Now as this range is allocated for transition to IPv6 a defence for
edge networks may be "we can reach all their services over IPv6"
but that doesn't work for transit providers.  Eyeball networks would
need to ensure that all their customers had access to IPv6 and even
that may not be enough.

This range adds a maximum of 245760 (2^18-2^14) routes to the global
routing table.  Do you really want to go to court for this many routes?

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From james.braunegg at micron21.com  Fri Jan 31 00:04:37 2014
From: james.braunegg at micron21.com (James Braunegg)
Date: Fri, 31 Jan 2014 00:04:37 +0000
Subject: looking for good AU dedicated server providers..
In-Reply-To: <20140130195509.GA67269@elektra.local>
References: <20140129233735.GA22861@ak-labs.net>
 
 <20140130195509.GA67269@elektra.local>
Message-ID: 


Have a look on Webhosting Talk Australia, this where a lot of Australian providers hang out ;-)

http://webhostingtalk.com.au
 
Kindest Regards

James Braunegg
P:? 1300 769 972? |? M:? 0488 997 207 |? D:? (03) 9751 7616
E:?? james.braunegg at micron21.com.au? |? ABN:? 12 109 977 666?? 
W:??www.micron21.com.au   T:?@micron21



This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.

-----Original Message-----
From: richo [mailto:richo at psych0tik.net] 
Sent: Friday, January 31, 2014 6:55 AM
To: Mark Blackman
Cc: nanog at nanog.org
Subject: Re: looking for good AU dedicated server providers..

On 30/01/14 19:50 +0000, Mark Blackman wrote:
>
>We?ve got a client who is happily using Intervolve.

I used to have 2 racks with intervolve. I'd use them again.


From sethm at rollernet.us  Fri Jan 31 00:14:26 2014
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 30 Jan 2014 16:14:26 -0800
Subject: Updated ARIN allocation information
In-Reply-To: <20140130235858.3ADEAE14FF7@rock.dv.isc.org>
References:  <52E97DCB.5090803@rollernet.us>
 
 <20140130051711.986ACE0C64B@rock.dv.isc.org>
 <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net>
 <20140130235858.3ADEAE14FF7@rock.dv.isc.org>
Message-ID: <52EAEAE2.6090403@rollernet.us>

On 1/30/14, 15:58, Mark Andrews wrote:
> The moment /24's aren't
> readily available and they are forced into using this range anyone
> filtering on /24 in this range is leaving themselves open to lawsuits.


Because why? Cartels? Illuminati? I want to travel by stargate. Who do I 
sue?

~Seth


From marka at isc.org  Fri Jan 31 00:26:54 2014
From: marka at isc.org (Mark Andrews)
Date: Fri, 31 Jan 2014 11:26:54 +1100
Subject: Updated ARIN allocation information
In-Reply-To: Your message of "Thu, 30 Jan 2014 16:14:26 -0800."
 <52EAEAE2.6090403@rollernet.us>
References:  <52E97DCB.5090803@rollernet.us>
 
 <20140130051711.986ACE0C64B@rock.dv.isc.org>
 <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net>
 <20140130235858.3ADEAE14FF7@rock.dv.isc.org> <52EAEAE2.6090403@rollernet.us>
Message-ID: <20140131002654.2020FE16752@rock.dv.isc.org>


In message <52EAEAE2.6090403 at rollernet.us>, Seth Mattinen writes:
> On 1/30/14, 15:58, Mark Andrews wrote:
> > The moment /24's aren't
> > readily available and they are forced into using this range anyone
> > filtering on /24 in this range is leaving themselves open to lawsuits.
> 
> 
> Because why? Cartels? Illuminati? I want to travel by stargate. Who do I 
> sue?

In Australia I would sue Telstra, Optus, ... if their customers
couldn't reach me due to routes being filtered.  I would take this
to the ACCC (Australian Competition and Consumer Commission) as a
restraint of trade issue.

> ~Seth
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From james at freedomnet.co.nz  Fri Jan 31 01:26:17 2014
From: james at freedomnet.co.nz (james jones)
Date: Thu, 30 Jan 2014 20:26:17 -0500
Subject: Is there such a thing as a 10GBase-T SFP+ transciever
Message-ID: 

I would like to know if anyone has seen one of these? If so where? Also if
they don't exist why? It would seem to me that it would make it a lot
easier to play mix and match with fiber in the DC if they did. Would be so
hard to make the 1G SFPs faster (trying to be funny here not arrogant).


-James

From joelja at bogus.com  Fri Jan 31 01:37:07 2014
From: joelja at bogus.com (joel jaeggli)
Date: Thu, 30 Jan 2014 17:37:07 -0800
Subject: Is there such a thing as a 10GBase-T SFP+ transciever
In-Reply-To: 
References: 
Message-ID: <52EAFE43.1080602@bogus.com>

On 1/30/14, 5:26 PM, james jones wrote:
> I would like to know if anyone has seen one of these? If so where? Also if
> they don't exist why? It would seem to me that it would make it a lot
> easier to play mix and match with fiber in the DC if they did. Would be so
> hard to make the 1G SFPs faster (trying to be funny here not arrogant).

the current chipsets don't fit in the the power/cooling budget of a spf+
transceiver envelope


> 
> -James
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: OpenPGP digital signature
URL: 

From chris at team.dcsi.net.au  Fri Jan 31 02:25:53 2014
From: chris at team.dcsi.net.au (Chris Balmain)
Date: Fri, 31 Jan 2014 13:25:53 +1100
Subject: Is there such a thing as a 10GBase-T SFP+ transciever
In-Reply-To: 
References: 
Message-ID: <52EB09B1.3040606@team.dcsi.net.au>

You may wish to consider twinax for short distance 10G over copper with 
SFP+ at both ends

http://en.wikipedia.org/wiki/Twinaxial_cabling#SFP.2B_Direct-Attach_Copper_.2810GSFP.2BCu.29

Typically marketed as "direct-attach" (you can't remove the cables from 
the transceivers, it's all integrated)

On 31/01/14 12:26, james jones wrote:
> I would like to know if anyone has seen one of these? If so where? Also if
> they don't exist why? It would seem to me that it would make it a lot
> easier to play mix and match with fiber in the DC if they did. Would be so
> hard to make the 1G SFPs faster (trying to be funny here not arrogant).
>
>
> -James


From streiner at cluebyfour.org  Thu Jan 30 23:32:07 2014
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Thu, 30 Jan 2014 18:32:07 -0500 (EST)
Subject: Updated ARIN allocation information
In-Reply-To: <20140131002654.2020FE16752@rock.dv.isc.org>
References:  <52E97DCB.5090803@rollernet.us>
 
 <20140130051711.986ACE0C64B@rock.dv.isc.org>
 <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net>
 <20140130235858.3ADEAE14FF7@rock.dv.isc.org> <52EAEAE2.6090403@rollernet.us>
 <20140131002654.2020FE16752@rock.dv.isc.org>
Message-ID: 

On Fri, 31 Jan 2014, Mark Andrews wrote:

> In Australia I would sue Telstra, Optus, ... if their customers
> couldn't reach me due to routes being filtered.  I would take this
> to the ACCC (Australian Competition and Consumer Commission) as a
> restraint of trade issue.

And if the provider doing the filtering isn't in $your_country?  I'm sure 
a few tech-savvy lawyers are salivating over this one.

jms


From marka at isc.org  Fri Jan 31 03:20:04 2014
From: marka at isc.org (Mark Andrews)
Date: Fri, 31 Jan 2014 14:20:04 +1100
Subject: Updated ARIN allocation information
In-Reply-To: Your message of "Thu, 30 Jan 2014 18:32:07 -0500."
 
References:  <52E97DCB.5090803@rollernet.us>
 
 <20140130051711.986ACE0C64B@rock.dv.isc.org>
 <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net>
 <20140130235858.3ADEAE14FF7@rock.dv.isc.org> <52EAEAE2.6090403@rollernet.us>
 <20140131002654.2020FE16752@rock.dv.isc.org>
 
Message-ID: <20140131032004.1CD49E1E601@rock.dv.isc.org>


In message , "Justin M
. Streiner" writes:
> On Fri, 31 Jan 2014, Mark Andrews wrote:
> 
> > In Australia I would sue Telstra, Optus, ... if their customers
> > couldn't reach me due to routes being filtered.  I would take this
> > to the ACCC (Australian Competition and Consumer Commission) as a
> > restraint of trade issue.
> 
> And if the provider doing the filtering isn't in $your_country?  I'm sure 
> a few tech-savvy lawyers are salivating over this one.
> 
> jms

I figure there will be similar problem for other business in other
countries and they will fight a similar battles.  Eventually the
regulators will step in because it is bad for small businesses to
be shut out of the Internet.

Hopefully most/all eyeball networks will be delivering IPv6
connectivity before allocations like these are needed.  Collectively
you only have yourselves to blame if there are needed in earnest.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From darrenoc at outlook.com  Fri Jan 31 06:54:12 2014
From: darrenoc at outlook.com (Darren O'Connor)
Date: Fri, 31 Jan 2014 06:54:12 +0000
Subject: Are specific "route" objects in RIR databases needed?
In-Reply-To: 
References: 
 <20140130170130.GO427@Eleanor.local> <52EA881F.8090405@fud.no>
 
Message-ID: 

I can't say what everyone else does, but we only make exact matches from route object to prefix-list

http://www.mellowd.co.uk/ccie

> On 30 Jan 2014, at 21:48, "Martin T"  wrote:
> 
> Job, Tore: ok, I see. So "route" object in RIR routing registry database
> for each announced prefix is needed only because some ISPs create filters
> exactly the size of the "route" object in database? So for example if there
> is a "route" object for 192.0.2.0/24 in RIR database, then ISP-A might
> create a following strict prefix-filter entry:
> 
> policy-options {
>    policy-statement EXAMPLE {
>        term prefixes {
>            from {
>                route-filter 192.0.2.0/24 exact;
>            }
>            then next policy;
>        }
>        then reject;
>    }
> }
> 
> On the other hand, ISP-B might create loose filter based on the same
> "route" object like this:
> 
> policy-options {
>    policy-statement EXAMPLE {
>        term prefixes {
>            from {
>                route-filter 192.0.2.0/24 upto /32;
>            }
>            then next policy;
>        }
>        then reject;
>    }
> }
> 
> 
> PS: this is a theoretical question :) I'm also for keeping the BGP table as
> short as possible.
> 
> 
> regards,
> Martin
> 
>> On Thu, Jan 30, 2014 at 5:13 PM, Tore Anderson  wrote:
>> 
>> * Job Snijders
>> 
>>>> On Thu, Jan 30, 2014 at 06:51:59PM +0200, Martin T wrote:
>>>> 
>>>> for example there is a small company with /22 IPv4 allocation from
>>>> RIPE in European region. This company is dual-homed and would like to
>>>> announce 4x /24 prefixes to both ISPs. Both ISP's update their
>>>> prefix-lists automatically based on records in RIPE database. For
>>>> example Level3 uses this practice at least in Europe. If this small
>>>> company creates a "route" object for it's /22 allocation, then is it
>>>> enough? Theoretically this would cover all four /24 networks. Or in
>>>> which situation it is useful/needed to have "route" object for each
>>>> /24 prefix?
>>> 
>>> You should create a route object for each route that you announce, if
>>> you announce 4 x /24 you should create a route: object for each /24.
>> 
>> +1
>> 
>>> ps. Can you please send 20 dollarcent per /24 to my paypal account
>>> (job at instituut.net) with the reference "deaggregation fee"?
>> 
>> Indeed.
>> 
>> Martin, I'd suggest announcing the 4 x /24s to each ISP tagged with the
>> no-export community in order to achieve whatever you are trying to do,
>> *in addition* to the covering /22. That way you're not polluting Job,
>> my, and everyone else's routing tables more than necessary, only your
>> own ISPs', but then again you're actually paying them for the privilege.
>> 
>> Tore
>> 

From cabenth at gmail.com  Fri Jan 31 12:39:48 2014
From: cabenth at gmail.com (Eric Clark)
Date: Fri, 31 Jan 2014 04:39:48 -0800
Subject: Is there such a thing as a 10GBase-T SFP+ transciever
In-Reply-To: <52EB09B1.3040606@team.dcsi.net.au>
References: 
 <52EB09B1.3040606@team.dcsi.net.au>
Message-ID: <2214438F-F463-48DC-AACA-857497642CCF@gmail.com>

What I want to see is reasonably priced 40G single mode transceivers.

I have no idea why 40G and now 100G wasn't rolled out with single mode as the preference. The argument that "there's a large multimode install base" doesn't hold water.

For one thing, you're using enormous amounts of MM fiber to get at best 1/4 of the ports than you previously had.
The best case is that you could get 12 ports where you used to have 48, but that's messy.
The second issue is cost, if you're running and distance, you've got to go to OM4, because MM fiber has very limited range at 10G (you're multiplexing 10G links), and OM4 is insanely expensive.

Single Mode on the other hand is 'cheap' in comparison. One pair of SM fiber will handle every speed from 10M to 100G, and over much longer distances than MM, no matter what grade.

Unfortunately, since the manufacturers haven't seen fit to push the SM, the optics are extremely expensive, so we're stuck with 4-12 times the amount of installed fiber than we really need.

Grumble.


On Jan 30, 2014, at 6:25 PM, Chris Balmain  wrote:

> You may wish to consider twinax for short distance 10G over copper with SFP+ at both ends
> 
> http://en.wikipedia.org/wiki/Twinaxial_cabling#SFP.2B_Direct-Attach_Copper_.2810GSFP.2BCu.29
> 
> Typically marketed as "direct-attach" (you can't remove the cables from the transceivers, it's all integrated)
> 
> On 31/01/14 12:26, james jones wrote:
>> I would like to know if anyone has seen one of these? If so where? Also if
>> they don't exist why? It would seem to me that it would make it a lot
>> easier to play mix and match with fiber in the DC if they did. Would be so
>> hard to make the 1G SFPs faster (trying to be funny here not arrogant).
>> 
>> 
>> -James
> 



From owen at delong.com  Fri Jan 31 13:10:51 2014
From: owen at delong.com (Owen DeLong)
Date: Fri, 31 Jan 2014 05:10:51 -0800
Subject: Updated ARIN allocation information
In-Reply-To: <20140130235858.3ADEAE14FF7@rock.dv.isc.org>
References:  <52E97DCB.5090803@rollernet.us>
 
 <20140130051711.986ACE0C64B@rock.dv.isc.org>
 <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net>
 <20140130235858.3ADEAE14FF7@rock.dv.isc.org>
Message-ID: <3F5D9D08-A27B-45BD-9145-51CB508CE0B6@delong.com>


On Jan 30, 2014, at 3:58 PM, Mark Andrews  wrote:

> 
> In message <384BF687-AD8A-4919-9EAB-723A09854E0D at puck.nether.net>, Jared Mauch 
> writes:
>> 
>> On Jan 30, 2014, at 12:17 AM, Mark Andrews  wrote:
>> 
>>> Or you could just accept that there needs to be more routing slots
>>> as the number of businesses on the net increases.  I can see some
>>> interesting anti-cartel law suits happening if ISP's refuse to
>>> accept /28's from this block.
>> 
>> i suspect it will be more sean doran style 'pay me for your slot'.
> 
> A /8 slot costs as much as a /28 slot to hold process etc.  A routing
> slot is a routing slot.  The *only* reason this isn't a legal problems
> at the moment is people can still get /24s.  The moment /24's aren't
> readily available and they are forced into using this range anyone
> filtering on /24 in this range is leaving themselves open to lawsuits.

On what basis? How do you have the right to force me to carry your route on
my network? Especially in light of the recent strike-down of the net neutrality
rules?

> Now as this range is allocated for transition to IPv6 a defence for
> edge networks may be "we can reach all their services over IPv6"
> but that doesn't work for transit providers.  Eyeball networks would
> need to ensure that all their customers had access to IPv6 and even
> that may not be enough.

Please point to the law which requires a transit provider to provide transit
to every tiny corner of every internet. Please do so for all nations where
this may be an issue.

Owen



From ahebert at pubnix.net  Fri Jan 31 13:58:06 2014
From: ahebert at pubnix.net (Alain Hebert)
Date: Fri, 31 Jan 2014 08:58:06 -0500
Subject: While on the subject of IRR and route objects
In-Reply-To: 
References: 
 <20140130170130.GO427@Eleanor.local> <52EA881F.8090405@fud.no>
 
 
Message-ID: <52EBABEE.800@pubnix.net>

    IRRToolset 5.0.1 (rtconfig really) finally gave out on a pretty
messy RPSL parse.

    After a few hours of research, it seems that its dead since 2009 :(.

    There is some effort at http://irrtoolset.isc.org to reboot
development, its pretty dead since 2012-07-31.

    Beside home made solutions, there seems to be no commercial package.

    Any lead will be appreciated.

-----
Alain Hebert                                ahebert at pubnix.net   
PubNIX Inc.        
50 boul. St-Charles
P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443



From job.snijders at hibernianetworks.com  Fri Jan 31 14:04:48 2014
From: job.snijders at hibernianetworks.com (Job Snijders)
Date: Fri, 31 Jan 2014 15:04:48 +0100
Subject: While on the subject of IRR and route objects
In-Reply-To: <52EBABEE.800@pubnix.net>
References: 
 <20140130170130.GO427@Eleanor.local> <52EA881F.8090405@fud.no>
 
 
 <52EBABEE.800@pubnix.net>
Message-ID: <20140131140448.GY427@Eleanor.local>

On Fri, Jan 31, 2014 at 08:58:06AM -0500, Alain Hebert wrote:
>     IRRToolset 5.0.1 (rtconfig really) finally gave out on a pretty
> messy RPSL parse.
> 
>     After a few hours of research, it seems that its dead since 2009 :(.
> 
>     There is some effort at http://irrtoolset.isc.org to reboot
> development, its pretty dead since 2012-07-31.
> 
>     Beside home made solutions, there seems to be no commercial package.
> 
>     Any lead will be appreciated.

I really like bgpq3 for prefix-filter generation. 

    http://github.com/snar/bgpq3
    http://snar.spb.ru/prog/bgpq3/

Kind regards,

Job
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 873 bytes
Desc: not available
URL: 

From ml at kenweb.org  Fri Jan 31 14:07:51 2014
From: ml at kenweb.org (ML)
Date: Fri, 31 Jan 2014 09:07:51 -0500
Subject: While on the subject of IRR and route objects
In-Reply-To: <20140131140448.GY427@Eleanor.local>
References: 
 <20140130170130.GO427@Eleanor.local> <52EA881F.8090405@fud.no>
 
  <52EBABEE.800@pubnix.net>
 <20140131140448.GY427@Eleanor.local>
Message-ID: <52EBAE37.8000101@kenweb.org>

+1   Easiest to use by far.

Only thing I see as lacking for easy adoption is canned solution for 
managing the push to the routers.



On 1/31/2014 9:04 AM, Job Snijders wrote:
> On Fri, Jan 31, 2014 at 08:58:06AM -0500, Alain Hebert wrote:
>>      IRRToolset 5.0.1 (rtconfig really) finally gave out on a pretty
>> messy RPSL parse.
>>
>>      After a few hours of research, it seems that its dead since 2009 :(.
>>
>>      There is some effort at http://irrtoolset.isc.org to reboot
>> development, its pretty dead since 2012-07-31.
>>
>>      Beside home made solutions, there seems to be no commercial package.
>>
>>      Any lead will be appreciated.
> I really like bgpq3 for prefix-filter generation.
>
>      http://github.com/snar/bgpq3
>      http://snar.spb.ru/prog/bgpq3/
>
> Kind regards,
>
> Job



From jakob at nym.se  Fri Jan 31 14:10:21 2014
From: jakob at nym.se (Jakob Borg)
Date: Fri, 31 Jan 2014 15:10:21 +0100
Subject: Fiber Bypass Switch
In-Reply-To: <7F1FDFB0ED229645954504A27329312D608AE05C@fiber-mail05.CORP.FIBERTECH.com>
References: <7F1FDFB0ED229645954504A27329312D608AE05C@fiber-mail05.CORP.FIBERTECH.com>
Message-ID: 

There's also for example
http://www.silicom-usa.com/Intelligent_Bypass_Switches/IBS10G-Intelligent_10G_Bypass_Switch_33

//jb

2014-01-27 Keyser, Philip :
> Does anyone have any recommendations for a fiber bypass switch? I am looking for something capable of 10G that when there is a power hit will fail over to route traffic out the network ports and away from that site's with the customer handoff.
>
> Thanks,
> Phil Keyser
>


From nick at foobar.org  Fri Jan 31 15:02:22 2014
From: nick at foobar.org (Nick Hilliard)
Date: Fri, 31 Jan 2014 15:02:22 +0000
Subject: While on the subject of IRR and route objects
In-Reply-To: <52EBABEE.800@pubnix.net>
References: 
 <20140130170130.GO427@Eleanor.local> <52EA881F.8090405@fud.no>
 
  <52EBABEE.800@pubnix.net>
Message-ID: <52EBBAFE.7040509@foobar.org>

On 31/01/2014 13:58, Alain Hebert wrote:
>     IRRToolset 5.0.1 (rtconfig really) finally gave out on a pretty
> messy RPSL parse.

of direct relevance to this:

https://lists.isc.org/pipermail/irrtoolset/2011-April/000736.html

tl;dr: rpsl itself is a mess => no point in fixing irrtoolset

There is some work in progress to try to create a new policy description
language which would be a replacement for rpsl.  Very early stages so far,
though.

Nick



From jcurran at istaff.org  Fri Jan 31 16:09:43 2014
From: jcurran at istaff.org (John Curran)
Date: Fri, 31 Jan 2014 11:09:43 -0500
Subject: Updated ARIN allocation information
In-Reply-To: <20140131032004.1CD49E1E601@rock.dv.isc.org>
References:  <52E97DCB.5090803@rollernet.us>
 
 <20140130051711.986ACE0C64B@rock.dv.isc.org>
 <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net>
 <20140130235858.3ADEAE14FF7@rock.dv.isc.org> <52EAEAE2.6090403@rollernet.us>
 <20140131002654.2020FE16752@rock.dv.isc.org>
 
 <20140131032004.1CD49E1E601@rock.dv.isc.org>
Message-ID: <0A78151E-0FDB-4276-9B14-6A88E2941B2B@istaff.org>

On Jan 30, 2014, at 10:20 PM, Mark Andrews  wrote:

> I figure there will be similar problem for other business in other
> countries and they will fight a similar battles.  Eventually the
> regulators will step in because it is bad for small businesses to
> be shut out of the Internet.

Mark - 
 
   ISPS consciously breaking Internet services are bound to attract 
   regulatory attention, but that does not necessarily mean that in 
   the end there will be regulatory action.  In the case of peering 
   and route acceptance, it is fairly easy to show that there is a 
   finite amount of routes that a given ISP can accept, and each of 
   these routes has different value (i.e. some have large traffic 
   flows, some are peer traffic engineering, some of required backup 
   routes for shared multihomed corporate customers, etc.)

   The result is not simple to regulate, because you can't just
   mandate "accept all routes offered" - some ISPs are already 
   trimming what they accept to accommodate their particular
   flavor of routing hardware.

   For last few decades, we've basically been relying on the IP 
   allocation/assignment policies and their minimum block sizes as 
   a proxy for the default "worth accepting" metric, but this may not 
   prevail once there is serious pressure to fragment blocks to obtain 
   better utilization.  It would be nice if there was a way to fairly 
   "settle up" for the imputed cost of adding a given route to the 
   routing table, as this would provide some proportionate backpressure 
   on growth, would create incentives for deaggregate cleanup, etc.  
   We don't have such a system, so it falls to each ISP to decide what 
   route is worth accepting based on type and the offering peer's 
   business relationship...

FYI,
/John

Disclaimer: My views alone. Note - I haven't had enable on any 
            backbone routers in this _century_, so feel free to 
            discount/discard if so desired.  ;-)




   




From ahebert at pubnix.net  Fri Jan 31 16:32:17 2014
From: ahebert at pubnix.net (Alain Hebert)
Date: Fri, 31 Jan 2014 11:32:17 -0500
Subject: While on the subject of IRR and route objects
In-Reply-To: <52EBBAFE.7040509@foobar.org>
References: 
 <20140130170130.GO427@Eleanor.local> <52EA881F.8090405@fud.no>
 
  <52EBABEE.800@pubnix.net>
 <52EBBAFE.7040509@foobar.org>
Message-ID: <52EBD011.9070009@pubnix.net>

On 01/31/14 10:02, Nick Hilliard wrote:
> On 31/01/2014 13:58, Alain Hebert wrote:
>>     IRRToolset 5.0.1 (rtconfig really) finally gave out on a pretty
>> messy RPSL parse.
> of direct relevance to this:
>
> https://lists.isc.org/pipermail/irrtoolset/2011-April/000736.html
>
> tl;dr: rpsl itself is a mess => no point in fixing irrtoolset
>
> There is some work in progress to try to create a new policy description
> language which would be a replacement for rpsl.  Very early stages so far,
> though.
>
> Nick

    Well,

    Thanks to all.

Job:

    bgpq3 works great the as-set that was borking rtlookup generate a
~183k long prefix list =D.

ML:

    as for auto-deploying / auto-push to routers...  I still prefer to
do that manually myself.

Nick:

    Yes, I saw those tidbits while looking for a replacement.

    If you're talking about RPSLng, it does not seems to gain any traction.

    From what I could see...

-----
Alain Hebert                                ahebert at pubnix.net   
PubNIX Inc.        
50 boul. St-Charles
P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443



From job.snijders at hibernianetworks.com  Fri Jan 31 16:38:11 2014
From: job.snijders at hibernianetworks.com (Job Snijders)
Date: Fri, 31 Jan 2014 17:38:11 +0100
Subject: While on the subject of IRR and route objects
In-Reply-To: <52EBD011.9070009@pubnix.net>
References: 
 <20140130170130.GO427@Eleanor.local> <52EA881F.8090405@fud.no>
 
 
 <52EBABEE.800@pubnix.net> <52EBBAFE.7040509@foobar.org>
 <52EBD011.9070009@pubnix.net>
Message-ID: <20140131163811.GZ427@Eleanor.local>

On Fri, Jan 31, 2014 at 11:32:17AM -0500, Alain Hebert wrote:
>     bgpq3 works great the as-set that was borking rtlookup generate a
> ~183k long prefix list =D.

I recommend using it like this, to enable aggregation where possible: bgpq3 -A 

Kind regards,

Job
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 873 bytes
Desc: not available
URL: 

From ahebert at pubnix.net  Fri Jan 31 16:47:38 2014
From: ahebert at pubnix.net (Alain Hebert)
Date: Fri, 31 Jan 2014 11:47:38 -0500
Subject: While on the subject of IRR and route objects
In-Reply-To: <20140131163811.GZ427@Eleanor.local>
References: 
 <20140130170130.GO427@Eleanor.local> <52EA881F.8090405@fud.no>
 
  <52EBABEE.800@pubnix.net>
 <52EBBAFE.7040509@foobar.org> <52EBD011.9070009@pubnix.net>
 <20140131163811.GZ427@Eleanor.local>
Message-ID: <52EBD3AA.2070800@pubnix.net>

    Yes, its the first thing I tried.

    Iti's still ~82k =D

    The as-set included some of his peering as export too.

    We're both looking into it.

-----
Alain Hebert                                ahebert at pubnix.net   
PubNIX Inc.        
50 boul. St-Charles
P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443

On 01/31/14 11:38, Job Snijders wrote:
> On Fri, Jan 31, 2014 at 11:32:17AM -0500, Alain Hebert wrote:
>>     bgpq3 works great the as-set that was borking rtlookup generate a
>> ~183k long prefix list =D.
> I recommend using it like this, to enable aggregation where possible: bgpq3 -A 
>
> Kind regards,
>
> Job



From cscora at apnic.net  Fri Jan 31 18:15:39 2014
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 1 Feb 2014 04:15:39 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201401311815.s0VIFdYk003132@thyme.rand.apnic.net>

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

Daily listings are sent to bgp-stats at lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 01 Feb, 2014

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

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

BGP routing table entries examined:                              480599
    Prefixes after maximum aggregation:                          191158
    Deaggregation factor:                                          2.51
    Unique aggregates announced to Internet:                     238143
Total ASes present in the Internet Routing Table:                 46049
    Prefixes per ASN:                                             10.44
Origin-only ASes present in the Internet Routing Table:           35565
Origin ASes announcing only one prefix:                           16380
Transit ASes present in the Internet Routing Table:                6011
Transit-only ASes present in the Internet Routing Table:            168
Average AS path length visible in the Internet Routing Table:       4.6
    Max AS path length visible:                                      53
    Max AS path prepend of ASN ( 50404)                              51
Prefixes from unregistered ASNs in the Routing Table:              1925
    Unregistered ASNs in the Routing Table:                         498
Number of 32-bit ASNs allocated by the RIRs:                       5868
Number of 32-bit ASNs visible in the Routing Table:                4473
Prefixes from 32-bit ASNs in the Routing Table:                   14209
Number of bogon 32-bit ASNs visible in the Routing Table:            12
Special use prefixes present in the Routing Table:                   12
Prefixes being announced from unallocated address space:            451
Number of addresses announced to Internet:                   2666406948
    Equivalent to 158 /8s, 238 /16s and 36 /24s
    Percentage of available address space announced:               72.0
    Percentage of allocated address space announced:               72.0
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               95.7
Total number of prefixes smaller than registry allocations:      167446

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

Prefixes being announced by APNIC Region ASes:                   114261
    Total APNIC prefixes after maximum aggregation:               34379
    APNIC Deaggregation factor:                                    3.32
Prefixes being announced from the APNIC address blocks:          116741
    Unique aggregates announced from the APNIC address blocks:    49004
APNIC Region origin ASes present in the Internet Routing Table:    4887
    APNIC Prefixes per ASN:                                       23.89
APNIC Region origin ASes announcing only one prefix:               1222
APNIC Region transit ASes present in the Internet Routing Table:    843
Average APNIC Region AS path length visible:                        4.6
    Max APNIC Region AS path length visible:                         28
Number of APNIC region 32-bit ASNs visible in the Routing Table:    817
Number of APNIC addresses announced to Internet:              730362496
    Equivalent to 43 /8s, 136 /16s and 114 /24s
    Percentage of available APNIC address space announced:         85.4

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 63488-63999, 131072-133631
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
                       163/8, 171/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, 223/8,

ARIN Region Analysis Summary
----------------------------

Prefixes being announced by ARIN Region ASes:                    164828
    Total ARIN prefixes after maximum aggregation:                82581
    ARIN Deaggregation factor:                                     2.00
Prefixes being announced from the ARIN address blocks:           166122
    Unique aggregates announced from the ARIN address blocks:     77099
ARIN Region origin ASes present in the Internet Routing Table:    16105
    ARIN Prefixes per ASN:                                        10.31
ARIN Region origin ASes announcing only one prefix:                6084
ARIN Region transit ASes present in the Internet Routing Table:    1678
Average ARIN Region AS path length visible:                         4.0
    Max ARIN Region AS path length visible:                          21
Number of ARIN region 32-bit ASNs visible in the Routing Table:      60
Number of ARIN addresses announced to Internet:              1077860096
    Equivalent to 64 /8s, 62 /16s and 215 /24s
    Percentage of available ARIN address space announced:          57.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, 62464-63487, 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,  23/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,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/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, 100/8, 104/8, 107/8, 108/8, 128/8,
                       129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8,
                       137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8,
                       146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8,
                       157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8,
                       165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8,
                       173/8, 174/8, 184/8, 192/8, 198/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:                    121242
    Total RIPE prefixes after maximum aggregation:                61587
    RIPE Deaggregation factor:                                     1.97
Prefixes being announced from the RIPE address blocks:           125111
    Unique aggregates announced from the RIPE address blocks:     79912
RIPE Region origin ASes present in the Internet Routing Table:    17629
    RIPE Prefixes per ASN:                                         7.10
RIPE Region origin ASes announcing only one prefix:                8328
RIPE Region transit ASes present in the Internet Routing Table:    2852
Average RIPE Region AS path length visible:                         5.0
    Max RIPE Region AS path length visible:                          53
Number of RIPE region 32-bit ASNs visible in the Routing Table:    2602
Number of RIPE addresses announced to Internet:               656540036
    Equivalent to 39 /8s, 34 /16s and 1 /24s
    Percentage of available RIPE address space announced:          95.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, 56320-58367
                       59392-61439, 61952-62463, 196608-200191
RIPE Address Blocks      2/8,   5/8,  25/8,  31/8,  37/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,
                       141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8,
                       193/8, 194/8, 195/8, 212/8, 213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   53911
    Total LACNIC prefixes after maximum aggregation:               9944
    LACNIC Deaggregation factor:                                   5.42
Prefixes being announced from the LACNIC address blocks:          59451
    Unique aggregates announced from the LACNIC address blocks:   27614
LACNIC Region origin ASes present in the Internet Routing Table:   2061
    LACNIC Prefixes per ASN:                                      28.85
LACNIC Region origin ASes announcing only one prefix:               545
LACNIC Region transit ASes present in the Internet Routing Table:   408
Average LACNIC Region AS path length visible:                       4.8
    Max LACNIC Region AS path length visible:                        32
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   985
Number of LACNIC addresses announced to Internet:             148746272
    Equivalent to 8 /8s, 221 /16s and 176 /24s
    Percentage of available LACNIC address space announced:        88.7

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       61440-61951, 262144-263679 plus ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       191/8, 200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                  11973
    Total AfriNIC prefixes after maximum aggregation:              2627
    AfriNIC Deaggregation factor:                                  4.56
Prefixes being announced from the AfriNIC address blocks:         12723
    Unique aggregates announced from the AfriNIC address blocks:   4137
AfriNIC Region origin ASes present in the Internet Routing Table:   698
    AfriNIC Prefixes per ASN:                                     18.23
AfriNIC Region origin ASes announcing only one prefix:              201
AfriNIC Region transit ASes present in the Internet Routing Table:  151
Average AfriNIC Region AS path length visible:                      4.7
    Max AfriNIC Region AS path length visible:                       24
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    9
Number of AfriNIC addresses announced to Internet:             50338048
    Equivalent to 3 /8s, 0 /16s and 25 /24s
    Percentage of available AfriNIC address space announced:       50.0

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 154/8, 196/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2955      11559         949   Korea Telecom
17974     2742        902          88   PT Telekomunikasi Indonesia
 7545     2151        320         116   TPG Telecom Limited
 4755     1814        392         193   TATA Communications formerly 
 9829     1590       1283          39   National Internet Backbone
 9583     1301        102         534   Sify Limited
 7552     1235       1080          13   Viettel Corporation
 9498     1215        309          69   BHARTI Airtel Ltd.
 4808     1168       2117         354   CNCGROUP IP network China169 
24560     1094        382         167   Bharti Airtel Ltd., Telemedia

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

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

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3026       3688          53   BellSouth.net Inc.
22773     2326       2940         139   Cox Communications Inc.
 1785     2156        689         129   PaeTec Communications, Inc.
18566     2048        379         178   MegaPath Corporation
20115     1684       1664         580   Charter Communications
 4323     1632       1090         410   tw telecom holdings, inc.
  701     1498      11173         768   MCI Communications Services, 
30036     1372        296         567   Mediacom Communications Corp
 6983     1296        756         581   ITC^Deltacom
 7018     1295      18004         844   AT&T Services, Inc.

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

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8402     1785        544          16   OJSC "Vimpelcom"
34984     1398        244         227   TELLCOM ILETISIM HIZMETLERI A
20940     1215        453         915   Akamai International B.V.
13188     1046        100          20   TOV "Bank-Inform"
31148     1014         45          21   Freenet Ltd.
 6849      862        363          38   JSC "Ukrtelecom"
 8551      825        370          41   Bezeq International-Ltd
 6830      772       2327         425   Liberty Global Operations B.V
12479      697        797          55   France Telecom Espana SA
35228      553        246          16   Telefonica UK Limited

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

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
28573     3330       1878          78   NET Servi?os de Comunica??o S
10620     2712        437         222   Telmex Colombia S.A.
18881     1837        909          21   Global Village Telecom
 7303     1745       1165         220   Telecom Argentina S.A.
 8151     1375       2882         426   Uninet S.A. de C.V.
11830      869        364          15   Instituto Costarricense de El
 6503      866        434          60   Axtel, S.A.B. de C.V.
 7738      847       1626          39   Telemar Norte Leste S.A.
27947      837         93          94   Telconet S.A
 6147      767        373          27   Telefonica del Peru S.A.A.

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

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

  ASN   No of nets  /20 equiv  MaxAgg  Description
36998     1810        240           6   Sudanese Mobile Telephone (ZA
24863      912        380          28   Link Egypt (Link.NET)
 6713      602        685          28   Office National des Postes et
 8452      478        956           9   TE-AS
24835      298        144           9   Vodafone Data
36992      271        783          24   ETISALAT MISR
 3741      246        921         208   Internet Solutions
29571      246         21          14   Cote d'Ivoire Telecom
15706      219         32           6   Sudatel (Sudan Telecom Co. Lt
29975      192        668          21   Vodacom

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

Global Per AS prefix count summary
----------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
28573     3330       1878          78   NET Servi?os de Comunica??o S
 6389     3026       3688          53   BellSouth.net Inc.
 4766     2955      11559         949   Korea Telecom
17974     2742        902          88   PT Telekomunikasi Indonesia
10620     2712        437         222   Telmex Colombia S.A.
22773     2326       2940         139   Cox Communications Inc.
 1785     2156        689         129   PaeTec Communications, Inc.
 7545     2151        320         116   TPG Telecom Limited
18566     2048        379         178   MegaPath Corporation
18881     1837        909          21   Global Village Telecom

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

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
 6389      3026        2973      BellSouth.net Inc.
17974      2742        2654      PT Telekomunikasi Indonesia
10620      2712        2490      Telmex Colombia S.A.
22773      2326        2187      Cox Communications Inc.
 7545      2151        2035      TPG Telecom Limited
 1785      2156        2027      PaeTec Communications, Inc.
 4766      2955        2006      Korea Telecom
18566      2048        1870      MegaPath Corporation
18881      1837        1816      Global Village Telecom
36998      1810        1804      Sudanese Mobile Telephone (ZA

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
30662   UNALLOCATED  8.2.129.0/24          3356       Level 3 Communicatio
14728   UNALLOCATED  8.8.192.0/23          3356       Level 3 Communicatio
14728   UNALLOCATED  8.8.196.0/22          3356       Level 3 Communicatio
14728   UNALLOCATED  8.8.200.0/23          3356       Level 3 Communicatio
14728   UNALLOCATED  8.8.202.0/23          3356       Level 3 Communicatio
53506   UNALLOCATED  8.17.102.0/23         2828       XO Communications
20260   UNALLOCATED  8.25.160.0/24         3356       Level 3 Communicatio
20260   UNALLOCATED  8.25.161.0/24         3356       Level 3 Communicatio
46473   UNALLOCATED  8.27.122.0/24        12180       Internap Network Ser
46473   UNALLOCATED  8.27.124.0/24        12180       Internap Network Ser

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Prefixes from private and non-routed address space (Global)
-----------------------------------------------------------

Prefix             Origin AS  Description
100.88.0.0/16         6697     Republican Unitary Telecommun
100.89.0.0/16         6697     Republican Unitary Telecommun
100.90.0.0/16         6697     Republican Unitary Telecommun
100.91.0.0/16         6697     Republican Unitary Telecommun
100.92.0.0/16         6697     Republican Unitary Telecommun
100.93.0.0/16         6697     Republican Unitary Telecommun
100.94.0.0/16         6697     Republican Unitary Telecommun
100.95.0.0/16         6697     Republican Unitary Telecommun
100.104.0.0/13        6697     Republican Unitary Telecommun
100.112.0.0/13        6697     Republican Unitary Telecommun

Complete listing at http://thyme.rand.apnic.net/current/data-dsua

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
27.100.7.0/24        56096     >>UNKNOWN<<
41.73.1.0/24         37004     Suburban Telecom
41.73.2.0/24         37004     Suburban Telecom
41.73.10.0/24        37004     Suburban Telecom
41.73.11.0/24        37004     Suburban Telecom
41.73.12.0/24        37004     Suburban Telecom
41.73.13.0/24        37004     Suburban Telecom
41.73.15.0/24        37004     Suburban Telecom
41.73.16.0/24        37004     Suburban Telecom
41.73.18.0/24        37004     Suburban Telecom

Complete listing at http://thyme.rand.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:16       /9:13      /10:30      /11:92      /12:253     
/13:477     /14:945     /15:1652    /16:12897   /17:6812    /18:11503   
/19:23726   /20:33431   /21:36070   /22:51224   /23:44601   /24:254651  
/25:791     /26:940     /27:428     /28:12      /29:16      /30:8       
/31:0       /32:11      

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

  ASN   No of nets  Total ann.   Description
18566     2003          2048      MegaPath Corporation
36998     1771          1810      Sudanese Mobile Telephone (ZA
 6389     1697          3026      BellSouth.net Inc.
22773     1570          2326      Cox Communications Inc.
 8402     1466          1785      OJSC "Vimpelcom"
30036     1212          1372      Mediacom Communications Corp
11492     1162          1199      CABLE ONE, INC.
 1785     1161          2156      PaeTec Communications, Inc.
 6983     1037          1296      ITC^Deltacom
22561      971          1251      CenturyTel Internet Holdings,

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

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

   1:945       2:788       3:3         4:16        5:886       6:21     
   8:649      12:1860     13:3        14:923      15:9        16:3      
  17:24       18:19       20:36       23:667      24:1725     27:1733   
  31:1536     32:44       33:2        34:5        36:118      37:1884   
  38:922      39:4        40:189      41:3266     42:244      44:14     
  46:2153     47:12       49:664      50:898      52:12       54:44     
  55:6        56:3        57:26       58:1142     59:590      60:370    
  61:1512     62:1205     63:1958     64:4382     65:2301     66:4152   
  67:2037     68:1025     69:3294     70:881      71:471      72:2013   
  74:2657     75:313      76:307      77:1145     78:1010     79:694    
  80:1311     81:1100     82:674      83:744      84:724      85:1262   
  86:467      87:1028     88:521      89:1730     90:146      91:5725   
  92:672      93:1643     94:2075     95:1482     96:536      97:351    
  98:1072     99:39      100:32      101:759     103:4094    105:535    
 106:143     107:418     108:537     109:2060    110:987     111:1231   
 112:615     113:819     114:778     115:1080    116:1024    117:831    
 118:1243    119:1305    120:323     121:784     122:1915    123:1260   
 124:1394    125:1445    128:633     129:240     130:360     131:661    
 132:351     133:156     134:319     135:73      136:280     137:297    
 138:350     139:153     140:205     141:355     142:551     143:418    
 144:501     145:99      146:595     147:415     148:781     149:343    
 150:151     151:528     152:420     153:208     154:82      155:518    
 156:317     157:420     158:293     159:843     160:355     161:466    
 162:1076    163:222     164:672     165:593     166:274     167:643    
 168:1045    169:124     170:1172    171:196     172:13      173:1621   
 174:697     175:568     176:1417    177:2661    178:1962    179:412    
 180:1621    181:958     182:1420    183:495     184:638     185:1219   
 186:2776    187:1443    188:2010    189:1269    190:7397    191:40     
 192:7090    193:5447    194:4003    195:3368    196:1356    197:1092   
 198:4868    199:5539    200:5972    201:2508    202:9030    203:8911   
 204:4501    205:2657    206:2942    207:2820    208:3971    209:3658   
 210:3104    211:1641    212:2222    213:1983    214:876     215:84     
 216:5491    217:1687    218:604     219:323     220:1270    221:593    
 222:334     223:586    

End of report


From Petter.Bruland at allegiantair.com  Fri Jan 31 18:59:27 2014
From: Petter.Bruland at allegiantair.com (Petter Bruland)
Date: Fri, 31 Jan 2014 18:59:27 +0000
Subject: Level3 - Las Vegas - issues?
Message-ID: 

Are there anyone from Level3 here, who can tell me if there are issues with Level3 in Las Vegas area?

We're hosted out of the Switch SuperNAP, and we're having high packet loss on two different Internet circuits. And at 9:30 AM PST we had no connectivity to all our 70+ remote locations spread all over US on different carriers, from our VPN hub hosted on Level3

Any feedback is much appreciated, thanks!

-Petter

Petter Bruland | Network Engineer
Allegiant Travel Company





From fernando at gont.com.ar  Fri Jan 31 20:40:58 2014
From: fernando at gont.com.ar (Fernando Gont)
Date: Fri, 31 Jan 2014 17:40:58 -0300
Subject: Question on DHCPv6 address assignment
Message-ID: <52EC0A5A.9060605@gont.com.ar>

Folks,

I'm wondering about the following two aspects of different DHCPv6
implementations out there:

1) What's the pattern with which addresses are generated/assigned? Are
they sequential (fc00::1, fc00::2, etc.)?  Random? Something else?

2) What about their stability? Is there any intent/mechanism for them to
be as "stable" as possible? Or is it usual for hosts to get a new
address for each lease?

P.S.: I understand this is likely to vary from one implementation to
another... so please describe which implementation/version you're
referring to.

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From cgrundemann at gmail.com  Fri Jan 31 20:56:34 2014
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Sat, 1 Feb 2014 05:56:34 +0900
Subject: Ad Hoc BCOP Committee - Call for Volunteers
Message-ID: 

Hail NANOGers!

Per approval of the NANOG Board in February 2013, a community effort to
develop a NANOG sponsored regional BCOP effort was engaged. NANOG BCOP
Tracks and updates were provided at RIPE, ARIN, NANOG 57, 58, and 59.

In November of 2013, sufficient interest and momentum in the NANOG BCOP
effort emerged. On November 21, 2013, the NANOG Board approved the
appointment of an Ad Hoc Committee Chair who would report to the Board and
direct the efforts of NANOG-BCOP.

I have agreed to serve as Chair and am now seeking volunteers to continue
with the important work of the committee. Please consider volunteering your
time and effort in support of this important NANOG activity!

To help guide you, please review the following committee expectations:

Strategies and Goals:
* Support an open, transparent, and bottom-up/grassroots process for the
creation of current
and living practical network operation documentation
* Facilitate the development of mutually rewarding documents and guides
* Maintain the sense of community and accessibility in BCOP materials
* Develop and deploy a portfolio of guides that meet the needs of the broad
range of NANOG operators

Deliverables:
* Responsible for recruiting a minimum of 1 shepard per calendar year.
* Responsible for recruiting a minimum of 1 author per calendar year.
* Required to attend at least 75% of all scheduled committee calls.
* Expected to attend 66% of all NANOG meetings over the course of your
two-year term.
* A BCOP Ad Hoc Committee Member is expected to volunteer up to 10 hours in
the 12 weeks Leading into a NANOG meeting and an additional 15 hours all
year round

Also see the website at http://bcop.nanog.org for more information.

If you are interested in participating, please send your short bio to Betty
Burke, NANOG Executive Director, betty at nanog.org. Betty can also answer any
and all questions you may have. Betty or I will be sure to follow-up with
each volunteer and get our important work underway as soon as possible.

Cheers,
~Chris

-- 
@ChrisGrundemann
http://chrisgrundemann.com

From fernando at gont.com.ar  Fri Jan 31 21:10:10 2014
From: fernando at gont.com.ar (Fernando Gont)
Date: Fri, 31 Jan 2014 18:10:10 -0300
Subject: Question on DHCPv6 address assignment
In-Reply-To: <20140131205942.GA11129@vacation.karoshi.com>
References: <52EC0A5A.9060605@gont.com.ar>
 <20140131205942.GA11129@vacation.karoshi.com>
Message-ID: <52EC1132.50408@gont.com.ar>

Hi, Bill,

On 01/31/2014 05:59 PM, bmanning at vacation.karoshi.com wrote:
> 
> i in my bespoke version:

Is there any reference I could use for it?


> 1- psudo-random within a /32 space
> 2- not stable, unless coded to a fixed address

Regarding "2)", do you mean they are only stable if you ahve a MAC->IPv6
mapping "database", or something else?

Cheers,
-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From mpalmer at hezmatt.org  Fri Jan 31 21:29:56 2014
From: mpalmer at hezmatt.org (Matt Palmer)
Date: Sat, 1 Feb 2014 08:29:56 +1100
Subject: Updated ARIN allocation information
In-Reply-To: <0A78151E-0FDB-4276-9B14-6A88E2941B2B@istaff.org>
References: <52E97DCB.5090803@rollernet.us>
 
 <20140130051711.986ACE0C64B@rock.dv.isc.org>
 <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net>
 <20140130235858.3ADEAE14FF7@rock.dv.isc.org>
 <52EAEAE2.6090403@rollernet.us>
 <20140131002654.2020FE16752@rock.dv.isc.org>
 
 <20140131032004.1CD49E1E601@rock.dv.isc.org>
 <0A78151E-0FDB-4276-9B14-6A88E2941B2B@istaff.org>
Message-ID: <20140131212956.GC9822@hezmatt.org>

On Fri, Jan 31, 2014 at 11:09:43AM -0500, John Curran wrote:
>    better utilization.  It would be nice if there was a way to fairly 
>    "settle up" for the imputed cost of adding a given route to the 
>    routing table, as this would provide some proportionate backpressure 
>    on growth, would create incentives for deaggregate cleanup, etc.  
>    We don't have such a system, so it falls to each ISP to decide what 
>    route is worth accepting based on type and the offering peer's 
>    business relationship...

I almost hesitate to mention this, just in case I put ideas into some
beancounter's head, but it seems to me that the cost model of carrying
packets isn't that different to carrying routes.  In both cases, practically
everyone is acting as a middleman, and money flows hither and yon and
(presumably) balances out in the end, with everyone having their costs
covered with a little left over for the shareholders.

Imagine one of the big players saying, "we're going to charge you $X per
route you send to us" (just like transit agreements that state, "we will
charge you $X/GB of traffic"), or "your contract allows you to send us N
routes" (just like, "your contract allows you to send us N Gb of traffic"). 
About 15 minutes later everyone else would start doing it, to recoup the
costs of sending routes to that provider.  Peering would be considered not
only if the volume of traffic was mutually advantageous, but also if the
routes exchanged were mutually advantageous.

- Matt


-- 
"[the average computer user] has been served so poorly that he expects his
system to crash all the time, and we witness a massive worldwide
distribution of bug-ridden software for which we should be deeply ashamed."
		-- Edsger Dijkstra



From sam at themerritts.org  Fri Jan 31 21:44:51 2014
From: sam at themerritts.org (Sam Hayes Merritt, III)
Date: Fri, 31 Jan 2014 15:44:51 -0600 (CST)
Subject: looking for good AU dedicated server providers..
In-Reply-To: 
References: <20140129233735.GA22861@ak-labs.net>
 
Message-ID: 


I've used shared hosting from Rimuhosting (www.rimuhosting.com) for years. 
They have dedicated servers in Brisbane. Looks like they are colo'ed with 
Oz Servers.


sam


From cidr-report at potaroo.net  Fri Jan 31 22:00:00 2014
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 31 Jan 2014 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201401312200.s0VM0047057462@wattle.apnic.net>

This report has been generated at Fri Jan 31 21:13:37 2014 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/2.0 for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        24-01-14    490385      274907
        25-01-14    490771      275139
        26-01-14    491167      275204
        27-01-14    491133      275651
        28-01-14    491297      275851
        29-01-14    490853      275986
        30-01-14    491565      275149
        31-01-14    491578      275863


AS Summary
         46226  Number of ASes in routing system
         18963  Number of ASes announcing only one prefix
          4461  Largest number of prefixes announced by an AS
                AS7029 : WINDSTREAM - Windstream Communications Inc
      119428352  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 31Jan14 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     491735   275851   215884    43.9%   All ASes

AS28573     3341       80     3261    97.6%   NET Servi?os de Comunica??o
                                               S.A.
AS6389      3026       56     2970    98.1%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS7029      4461     1704     2757    61.8%   WINDSTREAM - Windstream
                                               Communications Inc
AS17974     2741      184     2557    93.3%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS22773     2328      207     2121    91.1%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS4766      2955      959     1996    67.5%   KIXS-AS-KR Korea Telecom
AS1785      2156      406     1750    81.2%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS18881     1837       90     1747    95.1%   Global Village Telecom
AS36998     1810       97     1713    94.6%   SDN-MOBITEL
AS10620     2712     1122     1590    58.6%   Telmex Colombia S.A.
AS18566     2047      565     1482    72.4%   MEGAPATH5-US - MegaPath
                                               Corporation
AS4323      2944     1515     1429    48.5%   TWTC - tw telecom holdings,
                                               inc.
AS7303      1745      415     1330    76.2%   Telecom Argentina S.A.
AS4755      1814      598     1216    67.0%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS7552      1260      153     1107    87.9%   VIETEL-AS-AP Viettel
                                               Corporation
AS7545      2162     1083     1079    49.9%   TPG-INTERNET-AP TPG Telecom
                                               Limited
AS22561     1261      227     1034    82.0%   AS22561 - CenturyTel Internet
                                               Holdings, Inc.
AS9829      1590      680      910    57.2%   BSNL-NIB National Internet
                                               Backbone
AS18101      991      185      806    81.3%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS35908      903      101      802    88.8%   VPLSNET - Krypt Technologies
AS4808      1168      393      775    66.4%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS701       1499      769      730    48.7%   UUNET - MCI Communications
                                               Services, Inc. d/b/a Verizon
                                               Business
AS24560     1094      371      723    66.1%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS8151      1384      666      718    51.9%   Uninet S.A. de C.V.
AS6983      1296      581      715    55.2%   ITCDELTA - ITC^Deltacom
AS7738       847      148      699    82.5%   Telemar Norte Leste S.A.
AS4788       930      237      693    74.5%   TMNET-AS-AP TM Net, Internet
                                               Service Provider
AS855        746       57      689    92.4%   CANET-ASN-4 - Bell Aliant
                                               Regional Communications, Inc.
AS13977      807      145      662    82.0%   CTELCO - FAIRPOINT
                                               COMMUNICATIONS, INC.
AS4780      1027      371      656    63.9%   SEEDNET Digital United Inc.

Total      54882    14165    40717    74.2%   Top 30 total


Possible Bogus Routes

        27.100.7.0/24        AS56096 
        41.73.1.0/24         AS37004 
        41.73.2.0/24         AS37004 
        41.73.10.0/24        AS37004 
        41.73.11.0/24        AS37004 
        41.73.12.0/24        AS37004 
        41.73.13.0/24        AS37004 
        41.73.15.0/24        AS37004 
        41.73.16.0/24        AS37004 
        41.73.18.0/24        AS37004 
        41.73.20.0/24        AS37004 
        41.73.21.0/24        AS37004 
        41.76.48.0/21        AS36969 MTL-AS
        41.78.120.0/23       AS22351 INTELSAT Intelsat Global BGP Routing Policy
        41.87.32.0/19        AS37242 
        41.190.72.0/23       AS37451 CongoTelecom
        41.190.74.0/23       AS37451 CongoTelecom
        41.191.92.0/22       AS37245 
        41.191.108.0/22      AS37004 
        41.191.108.0/24      AS37004 
        41.191.109.0/24      AS37004 
        41.191.110.0/24      AS37004 
        41.191.111.0/24      AS37004 
        41.217.208.0/22      AS37158 
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.122.216.0/22      AS48727 
        63.247.0.0/19        AS226   LOS-NETTOS-AS - Los Nettos
        63.247.0.0/24        AS27609 
        63.247.1.0/24        AS27609 
        63.247.2.0/24        AS27609 
        63.247.3.0/24        AS27609 
        63.247.4.0/24        AS27609 
        63.247.5.0/24        AS27609 
        63.247.6.0/24        AS27609 
        63.247.7.0/24        AS27609 
        63.247.8.0/24        AS27609 
        63.247.9.0/24        AS27609 
        63.247.10.0/24       AS27609 
        63.247.11.0/24       AS27609 
        63.247.13.0/24       AS27609 
        63.247.14.0/24       AS27609 
        63.247.15.0/24       AS27609 
        63.247.16.0/24       AS27609 
        63.247.17.0/24       AS27609 
        63.247.18.0/24       AS27609 
        63.247.19.0/24       AS27609 
        63.247.20.0/24       AS27609 
        63.247.21.0/24       AS27609 
        63.247.22.0/24       AS27609 
        63.247.23.0/24       AS27609 
        63.247.24.0/24       AS27609 
        63.247.25.0/24       AS27609 
        63.247.26.0/24       AS27609 
        63.247.27.0/24       AS27609 
        63.247.28.0/24       AS27609 
        63.247.29.0/24       AS27609 
        64.25.16.0/23        AS19535 
        64.25.20.0/24        AS19535 
        64.25.21.0/24        AS19535 
        64.25.22.0/24        AS19535 
        64.25.27.0/24        AS7046  RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business
        64.111.0.0/20        AS8039  CCC-ASN-1 - Cinergy Communications
        64.111.160.0/20      AS40551 
        64.111.160.0/24      AS40551 
        64.111.161.0/24      AS40551 
        64.111.162.0/24      AS40551 
        64.111.167.0/24      AS40551 
        64.111.169.0/24      AS40551 
        64.111.170.0/24      AS40551 
        64.111.171.0/24      AS40551 
        64.111.172.0/24      AS40551 
        64.111.173.0/24      AS40551 
        64.111.174.0/24      AS40551 
        64.111.175.0/24      AS40551 
        64.119.240.0/22      AS26072 
        64.119.240.0/23      AS26072 
        64.119.242.0/23      AS26072 
        64.185.224.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.225.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.226.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.227.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.228.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.229.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.230.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.231.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.232.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.233.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.234.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.235.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.236.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.237.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.238.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.185.239.0/24      AS27431 JTLNET - JTL Networks Inc.
        64.202.48.0/22       AS23380 
        64.202.52.0/23       AS23380 
        64.202.54.0/24       AS23380 
        64.202.55.0/24       AS23380 
        64.202.56.0/22       AS23380 
        64.202.60.0/24       AS23380 
        64.202.61.0/24       AS23380 
        64.202.62.0/24       AS23380 
        64.202.63.0/24       AS23380 
        65.75.216.0/23       AS10494 AAI - Accurate Automation, Inc.
        65.75.217.0/24       AS10494 AAI - Accurate Automation, Inc.
        65.111.1.0/24        AS32258 SDNGLOBAL - SDN Global
        66.11.112.0/20       AS14572 
        66.55.96.0/23        AS17203 
        66.55.98.0/24        AS17203 
        66.55.99.0/24        AS17203 
        66.55.100.0/22       AS17203 
        66.55.102.0/23       AS17203 
        66.55.104.0/21       AS17203 
        66.159.98.0/24       AS17206 
        66.180.64.0/21       AS32558 ZEUTER - Zeuter Development Corporation
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.187.240.0/20      AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.
        66.205.224.0/19      AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        66.206.208.0/22      AS23380 
        66.206.211.0/24      AS14288 MPINET - MPInet
        66.206.212.0/24      AS23380 
        66.206.213.0/24      AS14288 MPINET - MPInet
        66.206.214.0/24      AS23380 
        66.206.215.0/24      AS23380 
        66.206.216.0/23      AS14288 MPINET - MPInet
        66.206.218.0/23      AS23380 
        66.206.220.0/22      AS23380 
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.254.160.0/20      AS11402 CCCAS-1 - Charlotte Colocation Center, LLc
        66.254.176.0/21      AS11402 CCCAS-1 - Charlotte Colocation Center, LLc
        66.254.184.0/22      AS11402 CCCAS-1 - Charlotte Colocation Center, LLc
        66.254.188.0/22      AS3356  LEVEL3 Level 3 Communications
        67.21.144.0/22       AS174   COGENT Cogent/PSI
        67.21.148.0/22       AS174   COGENT Cogent/PSI
        69.46.224.0/20       AS32592 HT-HB32592 - HuntTel
        69.46.236.0/24       AS32592 HT-HB32592 - HuntTel
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.19.0.0/19         AS16526 BIRCH-TELECOM - Birch Telecom, Inc.
        72.35.224.0/22       AS30097 NUWAVE - NuWave
        72.35.232.0/21       AS30097 NUWAVE - NuWave
        74.112.100.0/22      AS16764 
        74.113.200.0/23      AS46939 
        74.114.52.0/22       AS40818 
        74.114.52.0/23       AS40818 
        74.114.52.0/24       AS40818 
        74.114.53.0/24       AS40818 
        74.114.54.0/23       AS40818 
        74.114.54.0/24       AS40818 
        74.114.55.0/24       AS40818 
        74.114.140.0/22      AS32757 
        74.115.124.0/23      AS46540 NARSASN - National Asset Recovery Services, Inc
        74.118.132.0/22      AS5117  
        77.243.80.0/24       AS42597 
        77.243.81.0/24       AS42597 
        77.243.88.0/24       AS42597 
        77.243.91.0/24       AS42597 
        77.243.94.0/24       AS42597 
        77.243.95.0/24       AS42597 
        80.250.32.0/22       AS37106 ODUA-AS
        85.202.160.0/20      AS44404 
        91.193.60.0/22       AS3356  LEVEL3 Level 3 Communications
        91.195.66.0/23       AS3356  LEVEL3 Level 3 Communications
        91.197.36.0/22       AS43359 
        91.199.90.0/24       AS44330 
        91.199.185.0/24      AS29076 CITYTELECOM-AS Filanco LTD
        91.207.1.0/24        AS174   COGENT Cogent/PSI
        91.207.152.0/24      AS64100 
        91.207.153.0/24      AS64100 
        91.209.115.0/24      AS31103 KEYWEB-AS Keyweb AG
        91.214.65.0/24       AS30822 MAGEAL-AS Private Enterprise Mageal
        91.220.176.0/24      AS16265 LEASEWEB LeaseWeb B.V.
        91.229.182.0/24      AS56960 
        91.229.186.0/24      AS56967 
        93.190.10.0/24       AS47254 
        100.88.0.0/16        AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom
        100.89.0.0/16        AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom
        100.90.0.0/16        AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom
        100.91.0.0/16        AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom
        100.92.0.0/16        AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom
        100.93.0.0/16        AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom
        100.94.0.0/16        AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom
        100.95.0.0/16        AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom
        100.104.0.0/13       AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom
        100.112.0.0/13       AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom
        100.120.0.0/14       AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom
        100.124.0.0/14       AS6697  BELPAK-AS Republican Unitary Telecommunication Enterprise Beltelecom
        102.2.88.0/22        AS38456 PACTEL-AS-AP Pacific Teleports. 
        103.11.1.0/24        AS9822  AMNET-AU-AP Amnet IT Services Pty Ltd
        103.11.216.0/24      AS13208 
        103.11.217.0/24      AS13208 
        103.11.218.0/23      AS13117 KINGCORP-AS-IX Opennet Internet Exchange
        103.11.219.0/24      AS13208 
        103.13.184.0/23      AS58674 
        103.15.228.0/22      AS38809 NXGNET-AS-AP Nextgen Networks
        103.15.228.0/23      AS38809 NXGNET-AS-AP Nextgen Networks
        103.15.230.0/23      AS38809 NXGNET-AS-AP Nextgen Networks
        103.17.108.0/23      AS56301 MN-NDC-MN National Data Center building
        103.22.208.0/24      AS57792 PROVITEX-AS PE Glazunov Yuriy Anatol'yevich
        107.178.48.0/20      AS3257  TINET-BACKBONE Tinet SpA
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        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
        124.64.0.0/10        AS4847  CNIX-AP China Networks Inter-Exchange
        151.216.128.0/17     AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM"
        151.216.128.0/18     AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM"
        151.216.192.0/18     AS28840 TATTELECOM-AS OJSC "OAO TATTELECOM"
        164.40.184.0/24      AS19821 
        172.85.0.0/24        AS29571 CITelecom-AS
        172.99.34.0/24       AS9198  KAZTELECOM-AS JSC Kazakhtelecom
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        172.116.0.0/24       AS7018  ATT-INTERNET4 - AT&T Services, Inc.
        174.136.192.0/18     AS14572 
        176.111.168.0/22     AS50586 MACROSOLUTIONS MacroSolution SRL
        178.218.240.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.241.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.242.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.243.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.244.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.245.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.246.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.247.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.248.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.249.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.250.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.251.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.252.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.253.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.254.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        178.218.255.0/24     AS44109 PROJECT-A-AS Stroy-Industria-1 LLC
        183.182.80.0/22      AS3257  TINET-BACKBONE Tinet SpA
        185.64.0.0/23        AS6870  H1ASN H1 LLC
        190.3.160.0/21       AS27975 SYNAPSIS COLOMBIA SAS
        190.107.238.0/24     AS27765 TRANSNEXA S.A. E.M.A.
        190.124.252.0/22     AS7303  Telecom Argentina S.A.
        192.166.32.0/20      AS702   AS702 Verizon Business EMEA - Commercial IP service provider in Europe
        193.9.59.0/24        AS1257  TELE2
        193.16.106.0/24      AS31539 
        193.16.145.0/24      AS31392 
        193.22.224.0/20      AS6824  HERMES-NETWORK Hermes Telecom International Ltd
        193.22.238.0/23      AS62383 LDS-AS Lambrechts Data Services VOF
        193.26.0.0/24        AS34028 
        193.33.6.0/23        AS3356  LEVEL3 Level 3 Communications
        193.164.152.0/24     AS3356  LEVEL3 Level 3 Communications
        193.178.217.0/24     AS20737 
        193.186.193.0/24     AS158   ERI-AS - Ericsson Network Systems, Inc.
        193.186.199.0/24     AS8437  UTA-AS Tele2 Telecommunication GmbH
        193.188.252.0/24     AS8697  JTC-AS8697 Jordan Telecommunications Company
        193.200.52.0/23      AS16276 OVH OVH Systems
        193.200.244.0/24     AS3356  LEVEL3 Level 3 Communications
        193.201.244.0/24     AS702   AS702 Verizon Business EMEA - Commercial IP service provider in Europe
        193.201.245.0/24     AS702   AS702 Verizon Business EMEA - Commercial IP service provider in Europe
        193.201.246.0/24     AS702   AS702 Verizon Business EMEA - Commercial IP service provider in Europe
        193.202.8.0/21       AS6824  HERMES-NETWORK Hermes Telecom International Ltd
        193.202.9.0/24       AS6824  HERMES-NETWORK Hermes Telecom International Ltd
        193.223.103.0/24     AS3248  SIL-AT Tele2 Telecommunication GmbH
        193.227.109.0/24     AS3356  LEVEL3 Level 3 Communications
        193.227.121.0/24     AS9143  ZIGGO Ziggo B.V.
        193.254.218.0/23     AS25229 VOLIA-AS Kyivski Telekomunikatsiyni Merezhi LLC
        194.49.17.0/24       AS13135 CREW-AS Wieske's Crew GmbH
        194.50.82.0/24       AS16276 OVH OVH Systems
        194.63.152.0/22      AS3356  LEVEL3 Level 3 Communications
        194.88.226.0/23      AS3356  LEVEL3 Level 3 Communications
        194.99.67.0/24       AS9083  CARPENET carpeNet Information Technologies GmbH
        194.113.27.0/24      AS12518 SHLINK SHLINK Internet Service
        194.126.152.0/23     AS3356  LEVEL3 Level 3 Communications
        194.126.219.0/24     AS34545 
        194.187.24.0/22      AS8856  UKRNET UkrNet Ltd
        195.28.168.0/23      AS8655  
        195.64.128.0/23      AS8751  MEDIASAT Media Sat SRL
        195.85.194.0/24      AS3356  LEVEL3 Level 3 Communications
        195.114.4.0/23       AS41158 
        195.114.14.0/23      AS31554 ALTFEL SC Almsoft Computers SRL
        195.128.240.0/23     AS21202 DCSNET-AS Bredband2 AB
        195.130.208.0/24     AS16265 LEASEWEB LeaseWeb B.V.
        195.149.119.0/24     AS3356  LEVEL3 Level 3 Communications
        195.189.174.0/23     AS3356  LEVEL3 Level 3 Communications
        195.216.234.0/24     AS31309 NMV-AS New Media Ventures BVBA
        195.234.156.0/24     AS25028 
        195.242.182.0/24     AS3356  LEVEL3 Level 3 Communications
        200.1.112.0/24       AS29754 GO2TEL GO2TEL.COM INC.
        200.18.112.0/20      AS1916  Associa??o Rede Nacional de Ensino e Pesquisa
        200.58.248.0/21      AS27849 
        201.71.16.0/20       AS28638 EMTEC EMPRESA DE TECNOLOGIA EMPREENDIMENTOS DE COM
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        202.53.138.0/24      AS4058  CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited
        202.58.113.0/24      AS19161 
        202.83.120.0/21      AS37972 
        202.83.124.0/24      AS37972 
        202.83.125.0/24      AS37972 
        202.83.126.0/24      AS37972 
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.158.251.0/24     AS9255  CONNECTPLUS-AS Singapore Telecom
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        203.142.219.0/24     AS45149 
        203.191.56.0/21      AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service
        204.9.116.0/22       AS30097 NUWAVE - NuWave
        204.10.88.0/21       AS3356  LEVEL3 Level 3 Communications
        204.10.92.0/23       AS30097 NUWAVE - NuWave
        204.10.94.0/23       AS30097 NUWAVE - NuWave
        204.15.208.0/22      AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC
        204.69.144.0/24      AS27283 RJF-INTERNET - Raymond James Financial, Inc.
        204.106.16.0/24      AS4323  TWTC - tw telecom holdings, inc.
        204.187.11.0/24      AS51113 ELEKTA-AS Elekta
        204.225.173.0/24     AS6407  PRIMUS-AS6407 - Primus Telecommunications Canada Inc.
        205.159.44.0/24      AS40157 ADESA-CORP-AS - ADESA Corp
        205.207.66.0/24      AS15290 ALLST-15290 - Allstream Corp.
        205.211.160.0/24     AS30045 UHN-ASN - University Health Network
        205.236.71.0/24      AS852   ASN852 - TELUS Communications Inc.
        206.81.112.0/20      AS32618 ADKNO-KC - Adknowledge, Inc.
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        206.221.176.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.177.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.178.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.179.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.180.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.181.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.182.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.183.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.184.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.185.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.186.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.187.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.188.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.189.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.190.0/24     AS27431 JTLNET - JTL Networks Inc.
        206.221.191.0/24     AS27431 JTLNET - JTL Networks Inc.
        207.2.120.0/21       AS6221  USCYBERSITES - US Cybersites, Inc
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.
        207.254.128.0/21     AS30689 FLOW-NET - FLOW
        207.254.128.0/24     AS30689 FLOW-NET - FLOW
        207.254.136.0/21     AS30689 FLOW-NET - FLOW
        208.66.120.0/22      AS32757 
        208.68.180.0/22      AS4323  TWTC - tw telecom holdings, inc.
        208.69.192.0/23      AS6461  MFNX MFN - Metromedia Fiber Network
        208.69.195.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        208.74.224.0/22      AS174   COGENT Cogent/PSI
        208.75.152.0/21      AS32146 
        208.76.20.0/24       AS31812 
        208.76.21.0/24       AS31812 
        208.77.164.0/24      AS22659 
        208.77.165.0/24      AS22659 
        208.77.166.0/24      AS4323  TWTC - tw telecom holdings, inc.
        208.77.167.0/24      AS22659 
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.84.232.0/24      AS33131 
        208.84.234.0/24      AS33131 
        208.84.237.0/24      AS33131 
        208.84.238.0/24      AS33131 
        208.85.116.0/23      AS25956 ALPHEUS - Alpheus Data Services, L.L.C.
        208.85.212.0/22      AS32618 ADKNO-KC - Adknowledge, Inc.
        208.89.32.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.33.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.34.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.89.35.0/24       AS27431 JTLNET - JTL Networks Inc.
        208.91.72.0/24       AS17361 BRASS - Sungard Trading System (ASC)
        208.91.73.0/24       AS17361 BRASS - Sungard Trading System (ASC)
        208.91.76.0/23       AS21681 ANDOVER-TRADING - ANDOVER TRADING
        208.91.164.0/22      AS46099 
        208.92.224.0/22      AS32757 
        208.92.226.0/24      AS32757 
        209.161.96.0/20      AS8039  CCC-ASN-1 - Cinergy Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.193.112.0/20     AS209   ASN-QWEST-US NOVARTIS-DMZ-US
        209.209.51.0/24      AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.
        209.212.63.0/24      AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        209.234.112.0/23     AS32252 
        209.234.114.0/23     AS32252 
        209.234.116.0/24     AS32252 
        209.234.117.0/24     AS32252 
        209.234.118.0/24     AS32252 
        209.234.119.0/24     AS32252 
        209.234.120.0/24     AS32252 
        209.234.121.0/24     AS32252 
        209.234.122.0/24     AS32252 
        212.119.32.0/19      AS12550 
        213.184.64.0/24      AS13071 
        213.184.65.0/24      AS13071 
        213.184.66.0/24      AS13071 
        213.184.67.0/24      AS13071 
        213.184.68.0/24      AS13071 
        213.184.69.0/24      AS13071 
        213.184.70.0/24      AS13071 
        213.184.71.0/24      AS13071 
        213.184.72.0/24      AS13071 
        213.184.73.0/24      AS13071 
        213.184.74.0/24      AS13071 
        213.184.75.0/24      AS13071 
        213.184.76.0/24      AS13071 
        213.184.77.0/24      AS13071 
        213.184.78.0/24      AS13071 
        216.12.163.0/24      AS26627 AS-PILOSOFT - Pilosoft, Inc.
        216.14.64.0/20       AS14728 
        216.146.0.0/19       AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC
        216.152.24.0/22      AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.
        216.170.96.0/24      AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.170.101.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.170.104.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.170.105.0/24     AS4565  MEGAPATH2-US - MegaPath Networks Inc.
        216.234.132.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.
        216.234.139.0/24     AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.


Please see http://www.cidr-report.org for the full report

------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  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 Jan 31 22:00:01 2014
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 31 Jan 2014 22:00:01 GMT
Subject: BGP Update Report
Message-ID: <201401312200.s0VM01pr057478@wattle.apnic.net>

BGP Update Report
Interval: 23-Jan-14 -to- 30-Jan-14 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS12301           41185  2.0%     352.0 -- INVITEL Invitel Tavkozlesi Zrt.
 2 - AS8402            31749  1.5%      16.3 -- CORBINA-AS OJSC "Vimpelcom"
 3 - AS9829            30959  1.5%      19.5 -- BSNL-NIB National Internet Backbone
 4 - AS35181           29116  1.4%    2426.3 -- PWC Autonomous System Number for Public WareHouse Company
 5 - AS15467           25622  1.2%     915.1 -- ENTERNET-LIBERCOM-AS Enternet 2001 Ltd., Hungary
 6 - AS13118           23046  1.1%     523.8 -- ASN-YARTELECOM OJSC Rostelecom
 7 - AS4775            17722  0.9%     305.6 -- GLOBE-TELECOM-AS Globe Telecoms
 8 - AS6713            15942  0.8%      27.0 -- IAM-AS
 9 - AS24810           15918  0.8%     306.1 -- TELESET-KAZAN OJSC Rostelecom
10 - AS59217           14990  0.7%   14990.0 -- AZONNELIMITED-AS-AP Azonne Limited
11 - AS39649           14590  0.7%      70.8 -- VIALI-AS SC Viali Computers SRL
12 - AS28573           14465  0.7%      11.2 -- NET Servi?os de Comunica??o S.A.
13 - AS62904           14037  0.7%     159.5 -- SERVERHUB-DALLAS - Eonix Corporation
14 - AS41691           12726  0.6%     353.5 -- SUMTEL-AS-RIPE Summa Telecom LLC
15 - AS647             12172  0.6%     105.8 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center
16 - AS11976           11632  0.6%     323.1 -- FIDN - Fidelity Communication International Inc.
17 - AS47331           11468  0.6%       4.7 -- TTNET TTNet A.S.
18 - AS40994           10695  0.5%      62.5 -- SKYLINE-AS Internet Network Vision SRL
19 - AS27738           10245  0.5%      17.8 -- Ecuadortelecom S.A.
20 - AS25780           10180  0.5%     212.1 -- HUGESERVER-NETWORKS - HugeServer Networks, LLC


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS59217           14990  0.7%   14990.0 -- AZONNELIMITED-AS-AP Azonne Limited
 2 - AS12922            7084  0.3%    7084.0 -- MULTITRADE-AS CEDACRI S.P.A.
 3 - AS7202             8661  0.4%    4330.5 -- FAMU - Florida A & M University
 4 - AS19406            3513  0.2%    3513.0 -- TWRS-MA - Towerstream I, Inc.
 5 - AS16561            3292  0.2%    3292.0 -- ARIBANETWORK Ariba Inc. Autonomous System
 6 - AS54465            8581  0.4%    2860.3 -- QPM-AS-1 - QuickPlay Media Inc.
 7 - AS35181           29116  1.4%    2426.3 -- PWC Autonomous System Number for Public WareHouse Company
 8 - AS30437            4060  0.2%    2030.0 -- GE-MS003 - General Electric Company
 9 - AS32244            5785  0.3%    1928.3 -- LIQUID-WEB-INC - Liquid Web, Inc.
10 - AS62431            1910  0.1%    1910.0 -- NCSC-IE-AS National Cyber Security Centre
11 - AS6629             8979  0.4%    1795.8 -- NOAA-AS - NOAA
12 - AS14287            9402  0.5%    1567.0 -- TRIAD-TELECOM - Triad Telecom, Inc.
13 - AS17300            3128  0.1%    1564.0 -- 
14 - AS35051            1484  0.1%    1484.0 -- QWERTYNET-AS QwertyNet Ltd.
15 - AS44302            1444  0.1%    1444.0 -- IECHU-AS NETregator Kft.
16 - AS57542            2010  0.1%    1005.0 -- OOOP-AS LLC "Neonovaya Company"
17 - AS62751             942  0.1%     942.0 -- HSAUWC-AS - HSA-UWC
18 - AS15467           25622  1.2%     915.1 -- ENTERNET-LIBERCOM-AS Enternet 2001 Ltd., Hungary
19 - AS24959             894  0.0%     894.0 -- LINJEGODS-AS Schenker AS
20 - AS44789            4362  0.2%     872.4 -- HIRSAT-AS HIR-SAT 2000 Szolgaltato es Kereskedelmi Kft.


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 85.239.28.0/24    23060  1.1%   AS35181 -- PWC Autonomous System Number for Public WareHouse Company
 2 - 109.161.64.0/20   22660  1.0%   AS13118 -- ASN-YARTELECOM OJSC Rostelecom
 3 - 103.243.164.0/22  14990  0.7%   AS59217 -- AZONNELIMITED-AS-AP Azonne Limited
 4 - 192.58.232.0/24    8970  0.4%   AS6629  -- NOAA-AS - NOAA
 5 - 222.127.0.0/24     8768  0.4%   AS4775  -- GLOBE-TELECOM-AS Globe Telecoms
 7 - 206.152.15.0/24    8579  0.4%   AS54465 -- QPM-AS-1 - QuickPlay Media Inc.
 8 - 79.181.80.0/24     7183  0.3%   AS8551  -- BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbone
 9 - 89.221.206.0/24    7085  0.3%   AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC
10 - 194.105.61.0/24    7084  0.3%   AS12922 -- MULTITRADE-AS CEDACRI S.P.A.
11 - 216.109.107.0/24   6584  0.3%   AS11486 -- COLO-PREM-VZB - Verizon Online LLC
                                     AS16561 -- ARIBANETWORK Ariba Inc. Autonomous System
12 - 67.210.190.0/23    6552  0.3%   AS11976 -- FIDN - Fidelity Communication International Inc.
13 - 85.239.24.0/24     6010  0.3%   AS35181 -- PWC Autonomous System Number for Public WareHouse Company
14 - 205.247.12.0/24    5521  0.2%   AS6459  -- TRANSBEAM - I-2000, Inc.
15 - 85.249.160.0/20    5357  0.2%   AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC
16 - 67.210.188.0/23    4928  0.2%   AS11976 -- FIDN - Fidelity Communication International Inc.
17 - 199.187.118.0/24   4690  0.2%   AS11054 -- LIVEPERSON LivePerson, Inc
18 - 168.223.206.0/23   4368  0.2%   AS7202  -- FAMU - Florida A & M University
19 - 168.223.200.0/22   4293  0.2%   AS7202  -- FAMU - Florida A & M University
20 - 165.156.25.0/24    4057  0.2%   AS30437 -- GE-MS003 - General Electric Company

Details at http://bgpupdates.potaroo.net
------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From marka at isc.org  Fri Jan 31 22:01:15 2014
From: marka at isc.org (Mark Andrews)
Date: Sat, 01 Feb 2014 09:01:15 +1100
Subject: Updated ARIN allocation information
In-Reply-To: Your message of "Fri, 31 Jan 2014 11:09:43 -0500."
 <0A78151E-0FDB-4276-9B14-6A88E2941B2B@istaff.org>
References:  <52E97DCB.5090803@rollernet.us>
 
 <20140130051711.986ACE0C64B@rock.dv.isc.org>
 <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net>
 <20140130235858.3ADEAE14FF7@rock.dv.isc.org> <52EAEAE2.6090403@rollernet.us>
 <20140131002654.2020FE16752@rock.dv.isc.org>
 
 <20140131032004.1CD49E1E601@rock.dv.isc.org>
 <0A78151E-0FDB-4276-9B14-6A88E2941B2B@istaff.org>
Message-ID: <20140131220115.2098DE2C45A@rock.dv.isc.org>


In message <0A78151E-0FDB-4276-9B14-6A88E2941B2B at istaff.org>, John Curran writes:
> On Jan 30, 2014, at 10:20 PM, Mark Andrews  wrote:
> 
> > I figure there will be similar problem for other business in other
> > countries and they will fight a similar battles.  Eventually the
> > regulators will step in because it is bad for small businesses to
> > be shut out of the Internet.
> 
> Mark - 
>  
>    ISPS consciously breaking Internet services are bound to attract 
>    regulatory attention, but that does not necessarily mean that in 
>    the end there will be regulatory action.  In the case of peering 
>    and route acceptance, it is fairly easy to show that there is a 
>    finite amount of routes that a given ISP can accept, and each of 
>    these routes has different value (i.e. some have large traffic 
>    flows, some are peer traffic engineering, some of required backup 
>    routes for shared multihomed corporate customers, etc.)
>
>    The result is not simple to regulate, because you can't just
>    mandate "accept all routes offered" - some ISPs are already 
>    trimming what they accept to accommodate their particular
>    flavor of routing hardware.
> 
>    For last few decades, we've basically been relying on the IP 
>    allocation/assignment policies and their minimum block sizes as 
>    a proxy for the default "worth accepting" metric, but this may not 
>    prevail once there is serious pressure to fragment blocks to obtain 
>    better utilization.  It would be nice if there was a way to fairly 
>    "settle up" for the imputed cost of adding a given route to the 
>    routing table, as this would provide some proportionate backpressure 
>    on growth, would create incentives for deaggregate cleanup, etc.  
>    We don't have such a system, so it falls to each ISP to decide what 
>    route is worth accepting based on type and the offering peer's 
>    business relationship...
> 
> FYI,
> /John

I understand this but this block changes the status quo.  It is a
policy changer.  AFAIK ARIN hasn't done allocations to the /28 level
like this in the past.  This is all new territory.

Concentrating the allocation is a good thing as it allow selective
extentions of the filter lengths. This is about a potential 1.6%
global growth of routes.

It's not 1500% potential growth that a global /24 -> /28 would give.

> Disclaimer: My views alone. Note - I haven't had enable on any
> backbone routers in this _century_, so feel free to
> discount/discard if so desired.  ;-)
-- 
Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742			 INTERNET: marka at isc.org


From bill at herrin.us  Fri Jan 31 22:50:04 2014
From: bill at herrin.us (William Herrin)
Date: Fri, 31 Jan 2014 17:50:04 -0500
Subject: Updated ARIN allocation information
In-Reply-To: <20140131212956.GC9822@hezmatt.org>
References: <52E97DCB.5090803@rollernet.us>
 
 <20140130051711.986ACE0C64B@rock.dv.isc.org>
 <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net>
 <20140130235858.3ADEAE14FF7@rock.dv.isc.org> <52EAEAE2.6090403@rollernet.us>
 <20140131002654.2020FE16752@rock.dv.isc.org>
 
 <20140131032004.1CD49E1E601@rock.dv.isc.org>
 <0A78151E-0FDB-4276-9B14-6A88E2941B2B@istaff.org>
 <20140131212956.GC9822@hezmatt.org>
Message-ID: 

On Fri, Jan 31, 2014 at 4:29 PM, Matt Palmer  wrote:
> Imagine one of the big players saying, "we're going to charge you $X per
> route you send to us" (just like transit agreements that state, "we will
> charge you $X/GB of traffic"), or "your contract allows you to send us N
> routes" (just like, "your contract allows you to send us N Gb of traffic").
> About 15 minutes later everyone else would start doing it, to recoup the
> costs of sending routes to that provider.  Peering would be considered not
> only if the volume of traffic was mutually advantageous, but also if the
> routes exchanged were mutually advantageous.

Hi Matt,

It doesn't work. Here's why not:

First, there's an error in your bytes model. You express it as "your
contract allows you to send us N Gb of traffic" but that's not
accurate. It's send AND receive Gb of traffic. The two bottoms of the
pyramid, sender and recipient both pay. Their fees combine with other
fees as their ISP pays the next ISP up until it reaches two ISPs who
"peer" with each other. The peers trade bytes which each has been paid
by their endpoint to move to and from the other.

This model works. We know it works because the Internet currently runs on it.


Your route originator pays to have his route introduced into the
system, and his ISP pays to have it introduced further up, and so on
up to the top of the pyramid where two ISPs peer. Now you have a
problem. How does the other side of the pyramid get paid carry the
routes on the way back down?


There are at least a couple of potential solutions to this problem.

One solution is that you auction off the right to announce a covering
route for each /8. Then your ISP deals with paying everybody in a
reliable set of transit chains that announces your route to that
aggregation carrier. The "auction" is sort upside down where instead
of paying for the right to announce the covering route a company bids
on offering the best price cross reliability guarantee on a RAND
basis.

Everybody is free to carry your specific route, of course, but those
who choose not to will still be fully connected to you via the
covering /8 route. Even if the packet starts its trip via the covering
route, it won't necessarily reach the aggregator. As soon as it enters
any network carrying your specific announcement, the packet veers off
towards you.


Another solution would be some kind of international route
clearinghouse. Everybody operating BGP on the Internet joins the
clearinghouse and specifies how much they charge to carry a route.
Then for each route you wish to introduce, you pick all the ASes whose
price you're willing to pay. You pay the clearinghouse. The
clearinghouse does the accounting and provides each AS with their
payment and the list of routes they're being paid to accept upon
receiving an advertisement.

Analysts with the clearinghouse evaluate all the ASes, their
geography, size, connectedness and their required payments. They
collect ASes into technically useful sets with an aggregate price
which buyers can use instead of having to examine each AS for
themselves. By design, these sets try to exclude small-time ASes
asking for too much money (or any money) to carry your route.

Finally, anybody who is not a "tier-1" transit free provider adds a
default route to one or several of their upstream transit providers to
carry packets for the routes they chose not to accept. So, if the
clearinghouse analysts did their jobs well and you bought the route
sets which made sense, you remain fully connected.


Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: 
Falls Church, VA 22042-3004


From owen at delong.com  Fri Jan 31 23:07:10 2014
From: owen at delong.com (Owen DeLong)
Date: Fri, 31 Jan 2014 15:07:10 -0800
Subject: Question on DHCPv6 address assignment
In-Reply-To: <52EC0A5A.9060605@gont.com.ar>
References: <52EC0A5A.9060605@gont.com.ar>
Message-ID: 


On Jan 31, 2014, at 12:40 PM, Fernando Gont  wrote:

> Folks,
> 
> I'm wondering about the following two aspects of different DHCPv6
> implementations out there:
> 
> 1) What's the pattern with which addresses are generated/assigned? Are
> they sequential (fc00::1, fc00::2, etc.)?  Random? Something else?
> 

Depends on your DHCPv6 server implementation. I believe ISC defaults to random. I?m not sure if that?s configurable or not.

> 2) What about their stability? Is there any intent/mechanism for them to
> be as "stable" as possible? Or is it usual for hosts to get a new
> address for each lease?

I believe they are generally stable in that once a DUID is associated with an address, that association is persistent, but that may also be implementation dependent.

> 
> P.S.: I understand this is likely to vary from one implementation to
> another... so please describe which implementation/version you're
> referring to.

I have limited experience with the ISC DHCPv6 server. Mostly I just use SLAAC.

Owen



From owen at delong.com  Fri Jan 31 23:10:56 2014
From: owen at delong.com (Owen DeLong)
Date: Fri, 31 Jan 2014 15:10:56 -0800
Subject: Updated ARIN allocation information
In-Reply-To: <20140131212956.GC9822@hezmatt.org>
References: <52E97DCB.5090803@rollernet.us>
 
 <20140130051711.986ACE0C64B@rock.dv.isc.org>
 <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net>
 <20140130235858.3ADEAE14FF7@rock.dv.isc.org> <52EAEAE2.6090403@rollernet.us>
 <20140131002654.2020FE16752@rock.dv.isc.org>
 
 <20140131032004.1CD49E1E601@rock.dv.isc.org>
 <0A78151E-0FDB-4276-9B14-6A88E2941B2B@istaff.org>
 <20140131212956.GC9822@hezmatt.org>
Message-ID: 


On Jan 31, 2014, at 1:29 PM, Matt Palmer  wrote:

> On Fri, Jan 31, 2014 at 11:09:43AM -0500, John Curran wrote:
>>   better utilization.  It would be nice if there was a way to fairly 
>>   "settle up" for the imputed cost of adding a given route to the 
>>   routing table, as this would provide some proportionate backpressure 
>>   on growth, would create incentives for deaggregate cleanup, etc.  
>>   We don't have such a system, so it falls to each ISP to decide what 
>>   route is worth accepting based on type and the offering peer's 
>>   business relationship...
> 
> I almost hesitate to mention this, just in case I put ideas into some
> beancounter's head, but it seems to me that the cost model of carrying
> packets isn't that different to carrying routes.  In both cases, practically
> everyone is acting as a middleman, and money flows hither and yon and
> (presumably) balances out in the end, with everyone having their costs
> covered with a little left over for the shareholders.

Meh, sort of?

> 
> Imagine one of the big players saying, "we're going to charge you $X per
> route you send to us" (just like transit agreements that state, "we will
> charge you $X/GB of traffic"), or "your contract allows you to send us N
> routes" (just like, "your contract allows you to send us N Gb of traffic"). 
> About 15 minutes later everyone else would start doing it, to recoup the
> costs of sending routes to that provider.  Peering would be considered not
> only if the volume of traffic was mutually advantageous, but also if the
> routes exchanged were mutually advantageous.

That?s the optimistic outcome. The pessimistic outcome is that they get
rapidly depeered by everyone unwilling to pay $X/GB and then start losing
customers because their customers can no longer reach anyone else?s
customers through them.

The reality probably lies somewhere in between. I suspect whoever chooses
to conduct this little experiment first should be prepared for substantial pain.

YMMV.

Owen



From tore at fud.no  Fri Jan 31 23:45:24 2014
From: tore at fud.no (Tore Anderson)
Date: Sat, 01 Feb 2014 00:45:24 +0100
Subject: Updated ARIN allocation information
In-Reply-To: <20140131220115.2098DE2C45A@rock.dv.isc.org>
References:  <52E97DCB.5090803@rollernet.us>
 
 <20140130051711.986ACE0C64B@rock.dv.isc.org>
 <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net>
 <20140130235858.3ADEAE14FF7@rock.dv.isc.org> <52EAEAE2.6090403@rollernet.us>
 <20140131002654.2020FE16752@rock.dv.isc.org>
 
 <20140131032004.1CD49E1E601@rock.dv.isc.org>
 <0A78151E-0FDB-4276-9B14-6A88E2941B2B@istaff.org>
 <20140131220115.2098DE2C45A@rock.dv.isc.org>
Message-ID: <52EC3594.8080304@fud.no>

* Mark Andrews

> I understand this but this block changes the status quo.  It is a
> policy changer.  AFAIK ARIN hasn't done allocations to the /28 level
> like this in the past.  This is all new territory.

It's not exactly new. Like I've mentioned earlier in this thread, the
RIPE NCC has granted assignments smaller than /24 to requestors since,
well, "forever". There are currently 238 such assignments listed in
delegated-ripencc-extended-latest.txt. However, these microscopic
assignments have proven hugely unpopular, amounting for only a fraction
of a percent of the total (there are 27733 assignments equal to or
larger than /24 in the same file).

What I fail to understand from this thread is the apparent expectation
that these smaller-than-/24 microscopic delegations from ARIN will be
popular. As I read the policy in question, the requestors may get a /24
instead. That's a pretty miniature block to begin with and trivial to
justify, and given human nature of wanting to grab as much of something
as you can (especially when you in all likelihood cannot get nearly as
much as you actually need), coupled with the fact that a /24 is likely
to be immensely more useful than anything smaller...well, I just don't
see why we shouldn't realistically expect that pretty much all of the
assignments being made from this block will be exactly /24, and that
exceptions that prove the rule will amount for <1% of the total - just
like we've seen happen in the RIPE region.

Oh well. Time will tell, I suppose.

Tore


From bill at herrin.us  Fri Jan 31 23:58:26 2014
From: bill at herrin.us (William Herrin)
Date: Fri, 31 Jan 2014 18:58:26 -0500
Subject: Updated ARIN allocation information
In-Reply-To: <52EC3594.8080304@fud.no>
References:  <52E97DCB.5090803@rollernet.us>
 
 <20140130051711.986ACE0C64B@rock.dv.isc.org>
 <384BF687-AD8A-4919-9EAB-723A09854E0D@puck.nether.net>
 <20140130235858.3ADEAE14FF7@rock.dv.isc.org> <52EAEAE2.6090403@rollernet.us>
 <20140131002654.2020FE16752@rock.dv.isc.org>
 
 <20140131032004.1CD49E1E601@rock.dv.isc.org>
 <0A78151E-0FDB-4276-9B14-6A88E2941B2B@istaff.org>
 <20140131220115.2098DE2C45A@rock.dv.isc.org> <52EC3594.8080304@fud.no>
Message-ID: 

On Fri, Jan 31, 2014 at 6:45 PM, Tore Anderson  wrote:
> What I fail to understand from this thread is the apparent expectation
> that these smaller-than-/24 microscopic delegations from ARIN will be
> popular.

Hi Tore,

There is every expectation that they will be unpopular. They're a
hedge against the possibility of a grueling last-minute IPv6
conversion following a failed IPv4 market. They're something that can,
with difficulty, be made to work. They serve no other purpose.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: 
Falls Church, VA 22042-3004